Playbook
Treasury recognition procedure
Finance posting gates, dual-control checkpoints, and separation from lifecycle Confirmed states.
01
Objective
Post treasury recognition only when finance reconciliation gates pass—distinct from lifecycle Confirmed and from customer fulfillment decisions.
02
Prerequisites
- Recognition policy matrix approved by finance.
- Dual-control workflow for material postings.
- Mapping from payment_id to ledger accounts documented.
03
Operational signals
- Treasury postings timestamped before provider Confirmed events.
- Merchant balance diverges from finance ledger.
- Payout requests exceed recognized balance.
04
Decision points
- Which SKUs require treasury posting before fulfillment.
- Hold versus release for ambiguous rail outcomes.
- Payout approval separate from recognition posting.
05
Escalation paths
- Treasury analyst → controller for policy exceptions.
- Engineering → operations for provider plane gaps blocking posting.
06
Failure modes
- Using Confirmed webhook as automatic treasury posting trigger without finance rules.
- Recognizing on detection for high-value flows.
07
Recovery patterns
- Reverse posting with documented approval tied to payment_id.
- Reconcile provider events and rematch finance plane.
- Tighten checkpoint between Confirmed and treasury posting.
- Retries are normal. Webhook delivery is at-least-once. Design consumers to tolerate duplicates and out-of-order arrivals where possible.
- Asynchronous by design. Payers, chains, and your servers operate on different clocks. UI and finance should not assume synchronous finality.
- Eventual consistency. API reads, webhooks, and portal views may briefly diverge during transitions. Reconciliation jobs exist to converge truth.
Walkthroughs: /operations