Reconciliation as a first-class service
Reconciliation gets treated as a nightly batch afterthought. Elevating it to a first-class service changes what the rest of the platform can guarantee.
Reconciliation is often the last service anyone thinks about. It runs at night, produces reports someone reads once a week, and gets attention only when something drifts. But reconciliation is what actually gives a payment platform the ability to claim its state is truthful. Treating it as a first-class service changes what everything upstream can promise.
Written July 2026 from platform reviews.
What "first-class" means here
- Reconciliation runs continuously, not nightly. Discrepancies are detected in minutes, not the next morning.
- Reconciliation results feed back into the platform. If a transaction is reconciled as REVERSED, downstream reporting and merchant views update.
- Reconciliation errors are alertable operational events, not entries in a spreadsheet.
- The reconciliation model is the platform's source of truth for financial state.
The layered model
Three reconciliations happen, each with a different partner:
- Transaction-level reconciliation with the acquirer. Every authorization and capture matched with the acquirer's ledger.
- Batch-level reconciliation with the scheme. Batches settled with the scheme, matched to captured transactions.
- Fund-level reconciliation with the bank. Money in and out, matched to expected flows.
Each layer catches different failures. Skipping any of them leaves a class of drift undetected.
The engineering payoff
When reconciliation is first-class, the rest of the platform can be more relaxed about ambiguous states. A transaction can stay in UNKNOWN for hours; reconciliation will resolve it. A reversal can be REVERSAL_PENDING; reconciliation will confirm or reject it. Without a good reconciliation layer, every ambiguous state has to be resolved synchronously, which pushes complexity into every request path.
Reconciliation is where honesty about state pays off.