Reconciliation is easier when the system preserves the evidence chain instead of rebuilding it at month-end.
Layer 1: commercial ledger
Invoices or obligations show what became due, what was paid and what remains outstanding.
Layer 2: payment attempts
Each attempt records the selected method, provider route, request identifiers and normalized state.
Layer 3: provider transaction evidence
Keep the raw provider transaction ID, result code or status, amount and timestamp used to prove payment.
Layer 4: reconciliation match
Record how the successful provider transaction maps to the invoice and whether the match was automatic or manually verified.
Layer 5: settlement evidence
Finance can later attach the settlement batch, statement entry, fees and net amount supplied under the merchant's provider relationship.
Keep the states independent
Invoice: Paid. Payment: Succeeded. Reconciliation: Matched. Settlement: Pending is a valid combination.
Do not keep the customer overdue merely because finance is still closing settlement.
Exception paths matter
- Successful provider transaction with no invoice match.
- Paid invoice with no payment evidence.
- Amount mismatch.
- Duplicate success.
- Settlement mismatch.
Those exceptions should be explicit records with owners rather than silent manual corrections.
Design reconciliation as an evidence graph
The useful question is not whether two totals match. It is whether finance can walk from invoice to satisfying attempt to provider transaction to reconciliation match to settlement evidence without guessing.
That chain should survive provider migration and manual exception resolution.
Keep automated and manual matches distinguishable
An automatic match can be based on a strong reference, amount and merchant account. A manual match should record who made the decision, when, and why. Both can produce a Matched status, but the audit evidence is different.
Reconciliation jobs should be replay-safe
Provider exports, webhooks or settlement files may be reprocessed. Matching the same transaction twice should not create duplicate ledger effects. Use provider transaction identity and deterministic reconciliation keys to make repeated processing safe.
Useful controls
- Every provider success is matched or in an exception queue.
- Every paid invoice has supporting evidence.
- Duplicate provider successes are visible.
- Manual matches are attributable.
- Settlement differences do not reopen customer collection.
A reconciliation architecture is successful when finance spends its time on exceptions instead of rebuilding transaction history each month.
Reconciliation should be observable
Track automatic-match rate, exception age and paid-to-reconciled lag. Those metrics show whether the evidence chain is improving or whether finance is quietly absorbing more manual work as payment volume grows.
