Every payments platform reconciles. The question is only whether the system does it or whether people do.
When a platform is small, the difference is invisible. A handful of unmatched items a week is an hour of someone's time. The trouble is that unmatched volume grows with transaction volume, while the capacity to investigate manually does not — so a system that quietly delegates reconciliation to humans is building a cost that scales exactly as the business succeeds.
Where mismatches actually come from
Rarely from anything exotic. In practice:
- Timing. The movement lands in one system today and the other tomorrow, straddling a cut-off.
- Retries. A request timed out, was retried, and both attempts eventually succeeded.
- Partials. The amount settled is not the amount expected, for a reason recorded somewhere else.
- Fees. A charge deducted at one end and not represented at the other.
- Reversals. A movement undone later, referencing an original the matching logic never expected to see twice.
Each of these is predictable. Each can be modelled. What makes them expensive is treating them as anomalies to be investigated individually rather than as classes to be handled.
Idempotency comes first
If a retried request can create a second movement, no amount of downstream matching will save you.
Every operation that moves money needs a client-supplied idempotency key and a server that treats a repeat of the same key as a request to return the original result, not to perform the action again. This is unglamorous and it eliminates an entire category of exception before it exists.
Match continuously, not monthly
Batch reconciliation at period end has an unfortunate property: it surfaces problems at the point of maximum time pressure, and it surfaces them in aggregate, which is the hardest form to investigate.
Running the match continuously changes the character of the work. Exceptions appear within hours of the transaction, while the context is still recoverable and while the counterparty still remembers. The queue stays short because it is worked down daily rather than in a monthly push.
Make exceptions first-class
An unmatched item should be a record in the system with a class, an owner, a state and a resolution history — not a highlighted row in a spreadsheet someone maintains.
Once exceptions are records, useful things follow. You can see which class is growing. You can measure how long resolution takes and whether that is improving. You can automate the classes that turn out to be mechanical, which is usually most of them once the pattern is visible.
The test
A reconciliation design is working when the finance team's month-end effort no longer grows with transaction volume. If it does grow, the matching is still being done by people; the software is just where they record the result.