Payment success is not reconciliation success
A payment can be marked paid and still be operationally unexplained. The customer may have paid correctly while a provider fee is missing, a settlement is delayed, a refund was not posted, or the internal ledger contains a duplicate credit.
Reconciliation answers a different question than payment processing:
Do all systems that describe this value lifecycle agree — and if not, can we explain exactly why?
The five layers to reconcile
1. Business obligation
Invoice, order, subscription or payment intent: expected amount, currency, customer and due/expiry context.
2. External execution evidence
Managed model: provider order, transaction and provider ledger. Custom model: blockchain transaction, token, network, address and confirmation/finality evidence.
3. Internal product ledger
The accepted business credit/debit entries, fees, refunds and adjustments.
4. Settlement or treasury movement
Managed model: provider conversion, payout or withdrawal. Custom model: sweep, treasury transfer, off-ramp or liquidity movement.
5. Bank/accounting evidence
Where fiat settlement exists, bank records and accounting exports close the operational loop.
Correlation identifiers are the foundation
Every layer needs a deterministic reference. A useful chain is invoiceId → paymentIntentId → providerOrderId/txHash → ledgerEntryId → settlementBatchId. Missing correlation keys are one of the most expensive reconciliation defects because finance then has to infer relationships from amounts and timestamps.
Reconcile movements, not only balances
Two end-of-day balances can match while individual transactions are wrong. Reconcile individual value movements first, then totals.
For each payment compare:
- expected gross amount,
- actual customer payment,
- accepted product credit,
- provider/network fee where applicable,
- refunds/chargebacks where relevant,
- net settlement or treasury movement.
Managed provider reconciliation
With CoinGate, use the provider order and provider ledger as separate evidence sources. CoinGate’s ledger transaction API is explicitly designed to expose credits/debits and supports filtering by date, currency, type and source. This is better suited to scheduled reconciliation than relying only on webhook logs.
A managed reconciliation job can:
- load product payments for a time window,
- load CoinGate orders/ledger transactions for the same window,
- match by provider order/source reference,
- compare gross, received, fee, refund and settlement values,
- create exception records for differences,
- mark the reconciliation window complete only when unresolved exceptions meet policy.
Custom on-chain reconciliation
For direct wallet infrastructure, compare the product ledger against independently observed chain transactions. Do not query only current wallet balance. Reconstruct the relevant transaction set by block range/checkpoint and verify token contract, network, receiving address, amount and finality state.
Then reconcile downstream sweeps and treasury movements separately. A failed sweep should create a treasury exception, not a customer-payment mismatch.
Common mismatch classes
| Mismatch | Example | Owner |
|---|---|---|
| Missing external payment | Ledger credit exists, provider/chain evidence missing | Engineering / risk |
| Missing ledger credit | Provider paid, product never credited | Product operations |
| Amount mismatch | Underpayment, overpayment, FX or fee issue | Finance / operations |
| Settlement mismatch | Paid orders do not match payout batch | Finance |
| Refund mismatch | Refund completed externally but ledger not adjusted | Operations / finance |
| Duplicate effect | One external event created two credits | Engineering |
Build an exception queue
Do not make reconciliation a boolean report. Create a first-class exception entity containing type, expected, observed, references, severity, owner, status, notes and resolution history.
That turns financial operations into a measurable workflow rather than an inbox of screenshots.
Webhook processing and reconciliation must be independent
Real-time callbacks optimise responsiveness. Reconciliation optimises correctness. If callback delivery fails and is replayed later, scheduled reconciliation should still detect a payment that exists externally but is missing internally.
Daily close example
- Freeze the reconciliation window.
- Import provider ledger or scan chain range.
- Match all external movements to payment intents and ledger entries.
- Reconcile fees/refunds.
- Match settlement batch or treasury sweep.
- Match bank payout if relevant.
- Open exceptions.
- Store a close summary with counts and totals.
Metrics that matter
- unreconciled payment count,
- unreconciled value,
- oldest open exception,
- duplicate-event prevention count,
- provider/chain ingestion lag,
- settlement variance,
- refund reconciliation lag.
Relationship with the internal ledger
Reconciliation is only as useful as the ledger it audits. If your product still relies on mutable balances, first implement the model in How to Design an Internal Ledger for Stablecoin Payments.
Reconciliation windows and late events
Define explicit reconciliation windows rather than assuming midnight-to-midnight is always correct. Provider settlement cut-offs, blockchain finality and bank posting times can cross calendar boundaries. Keep a window status such as OPEN, PROCESSING, EXCEPTIONS, CLOSED and REOPENED so late evidence can be handled without rewriting history.
Gross-to-net reconciliation
For provider-managed settlement, reconcile the economic equation explicitly: gross accepted value minus provider fees minus refunds plus/minus documented adjustments equals the expected net settlement for the relevant batch or period. If FX conversion is involved, store the conversion evidence and distinguish commercial price from settlement value.
Operational ownership
Every mismatch class should have an owner and SLA. Engineering owns missing or duplicated ingestion; operations owns payment/customer investigations; finance owns settlement and accounting discrepancies; compliance or risk may own invalid or screened payments. The exception queue should route accordingly.
Reconciliation as a regression test
Historical reconciliation windows can be replayed in staging against new code. This creates a powerful regression dataset for provider adapters and chain observers because the expected financial outcome is already known.
Conclusion
The goal of reconciliation is not merely “numbers equal”. The goal is explainability: every payment should have a traceable story from commercial obligation, through execution, to product credit, fees/refunds and final settlement.