Reconciliation Is Not a Nice-to-Have

Mostafa Dhouib·September 7, 2026·7 min read

Reconciliation Is Not a Nice-to-Have

The short answer. Every prevention mechanism in a payment system fails silently: an idempotency key that did not cover the effect, a retry outside the deduplication window, a webhook processed twice, a transfer that succeeded while its acknowledgement was lost. Reconciliation is the only component that compares what you believe happened against what actually happened, which makes it the sole detector for an entire class of failure. It gets deferred because it ships no feature and looks like it does nothing, which is exactly what a working detector looks like.

Ask a team how they prevent double charges and you get a confident answer about idempotency keys.

Ask how they would know if one occurred anyway, and the answer is usually that a customer would complain.

That is a detection strategy, and it is worth naming as one, because it means the failure is found by the person harmed, at a time of their choosing, with no supporting evidence attached.

What reconciliation is actually for

Reconciliation compares two independently maintained records of the same reality and reports the differences. Your ledger against the processor's. Your ledger against the bank. Your internal event stream against your ledger.

The property that makes it valuable is independence. Your ledger can be wrong in a way your own system cannot see, because the bug that produced the wrong entry is the same code that would check it. An external record was produced by different code, run by a different organisation, with a different set of bugs.

This is the same reason a verifier has to be independent of the generator to be worth anything. A check that shares the failure mode of the thing it checks agrees confidently in exactly the cases you care about.

The four classes it catches

Duplicates. Two ledger entries for one intent, or two processor charges for one of your records. The failure idempotency was meant to prevent, caught after the fact.

Missing. You believe money moved and it did not, or the processor has a transaction you have no record of. The second is worse and more common than people expect: the request was received, the acknowledgement was lost, your side treated it as failed and never retried.

Amount and currency mismatches. Rounding, fee handling, currency conversion applied on a different side than expected. Small individually, systematic in aggregate, and usually indicative of a semantic disagreement rather than a bug.

Timing and state divergence. Settled on one side, pending on the other, past the window where that is normal. Frequently the earliest visible sign of a genuine processing problem.

What makes a reconciliation useful rather than ceremonial

Plenty of organisations run a reconciliation that finds things, produces a report, and changes nothing. The difference is in four properties.

It runs on a cadence short enough to act on. Daily catches yesterday's problem while the trail is warm. Monthly catches it after it has recurred thirty times, and after the operational context is gone.

Breaks are assigned, not listed. A report with a hundred unexplained differences and no owner is a document. A queue where each break has a name, an age, and a resolution is a process. Break age is the metric that matters and almost nobody tracks it.

Every break gets a cause, not just a correction. Adjusting the ledger to match the processor resolves the symptom and loses the finding. The valuable output is the pattern: these forty breaks all came from the same retry path, which is a bug rather than forty incidents.

Tolerances are explicit and small. A tolerance wide enough that nothing ever breaks is a reconciliation that has been configured not to work. If you need a tolerance for rounding, state the exact expected rounding rule and treat anything else as a break.

The cost of deferring it

Reconciliation is deferred because on the day you build it there is nothing wrong, so it produces no visible value, while the feature you could build instead has a number attached.

Three costs land later.

Detection lag becomes discovery scale. Without it, the first duplicate and the ten thousandth are found the same way. The interval between the bug shipping and someone noticing is the interval over which the exposure accumulates.

You lose the evidence. A break found the next day comes with logs, traces, and a person who remembers the deploy. A break found in a quarterly close comes with none of those, and the investigation costs several times more for a worse answer.

Remediation gets harder with age. Refunding a duplicate charge from yesterday is routine. Refunding one from eight months ago involves customers who have moved on, accounts that have closed, and a conversation about why it took eight months.

Where the same discipline applies outside payments

The pattern generalises further than most teams notice, and naming it makes it portable.

Any system with an external side effect should reconcile its record of the effect against the system that holds the effect. Emails claimed as sent against the provider's log. Records claimed as written against the destination. Jobs claimed as complete against their output.

Agents that take actions need this acutely, because they retry enthusiastically and their record of what they did is the least trustworthy record in the system. An agent reporting that a migration completed and a count of migrated rows in the target database are two independently maintained records of the same reality, and comparing them is reconciliation by another name.

Any pipeline with a hand-off benefits from comparing counts across the boundary. Sent versus received, intended versus executed. That comparison is the instrument, and its absence is why the failures at that boundary stay hidden.

The three questions

If a duplicate charge happened today, how would we find out, and when? If the answer involves a customer, that is your detection mechanism.

What is our oldest unresolved break, and who owns it? If nobody can answer, breaks are being listed rather than worked.

When we resolve a break, do we record the cause? If not, you are correcting symptoms and discarding the only diagnostic signal the system produces.

For regulated fintech work this is not optional, and the useful framing is that reconciliation is not a control you run for the regulator. It is the only instrument you have that can see the failures your prevention mechanisms miss, and the regulator asks for it because that is true.

FAQ

Why is reconciliation necessary if we already use idempotency keys? Because prevention mechanisms fail silently. A key that did not cover the effect, a retry outside the deduplication window, a webhook processed twice, or a lost acknowledgement all produce a discrepancy that no part of your own system can see. Reconciliation compares against an independently maintained record, which is the only way to detect them.

How often should payment reconciliation run? Daily at minimum. The interval between a bug shipping and someone noticing is the interval over which exposure accumulates, and a break found the next day comes with logs, traces, and someone who remembers the deploy, while one found at quarter end comes with none of those.

What makes a reconciliation process actually work? Breaks assigned to named owners with tracked age rather than listed in a report, a recorded cause for each resolution rather than just a correction, tolerances that are explicit and small, and a cadence short enough to act on.

What are the main types of reconciliation break? Duplicates, missing transactions in either direction, amount and currency mismatches usually from fee or conversion handling, and timing divergence where the two sides disagree about state past the normal window.

Does reconciliation apply outside payments? Yes, anywhere a system has an external side effect. Emails claimed sent against the provider's log, rows claimed migrated against the destination count, tool calls intended against those executed. An agent's own report of what it did is the least trustworthy record available, which makes an independent comparison essential.