RECONCILIATION
Why your order system and your payment provider disagree
Twice a month, somebody in operations finds a number that does not match. An order recorded at €120.00, a capture of €119.40. Or an order with no payment against it at all. Or — the worst one — a refund larger than anything that was ever collected.
Then a week goes by. Operations says the payment system is wrong. Engineering says the order system is wrong. Somebody exports both to a spreadsheet, and the spreadsheet becomes the thing everyone argues about instead of the systems. Eventually a decision gets made because the week ran out, not because anyone established what happened.
I have watched this in banking, in healthcare, in gaming and in public administration. Every team was certain their situation was unusual. It never was. There are four shapes, they look similar from a distance, and they need completely different responses — which is why the week gets spent.
One
The basket changed and nobody said so
A customer starts a checkout at €120, amends it to €150, and pays €150. Your order system has both numbers. Your payment provider has one. Depending on which export you pulled and when, the two disagree by €30 and both are correct.
This is the most common one and it is not a fault. It is a missing fact: the records describe two different versions of the same purchase, and nothing in the export says which is which.
How to tell. You will find two order totals for the same identifier, or a total that changed between two exports.
What to do. Nothing to the money. Fix the export so that each version of a basket carries its own identifier, and the disagreement stops being a disagreement.
Two
One payment, taken in two pieces
A €150 order, captured as €100 and €50 — partial capture, or a retry after a decline, or a split across two payment methods.
Compare totals and this reads as a €50 shortfall. Compare the transactions one by one and it reads as an extra payment nobody ordered. Both readings are wrong, and both are what a spreadsheet produces on its own.
How to tell. The captures against one order sum to the order total.
What to do. Again, nothing to the money. But notice that a comparison working on totals will report this as a discrepancy every single time, which is how teams learn to ignore the report.
Three
The same payment reported twice
Your provider reports a capture. Your ledger reports the same capture. If a comparison adds both, the order appears overpaid by exactly its own value — and somebody goes looking for a refund to issue.
This one is dangerous precisely because it looks like a finding rather than a duplicate. It produces a plausible number and a plausible action, and the action is wrong.
How to tell. Two records referring to the same operation identifier from two sources.
What to do. Decide, once, which source is authoritative for each kind of record, and write it down. Nothing that compares records can work this out for you — there is no fact in the data that says which system to believe.
Four
A record that never arrived
A webhook that failed and was never retried. A nightly export that ran while a transaction was mid-flight. A refund issued in the provider's dashboard by somebody in support, which your order system never hears about.
This is the only one of the four that is a genuine problem, and it is the one that looks most like the other three.
How to tell. The required record is absent, not different.
What to do. Find out why it is missing before anything else. A missing record is not a discrepancy to reconcile; it is a hole in how the systems talk.
The distinction that matters
Three of those four are not errors. They are the records being incomplete, or duplicated, or describing different moments — and each has a different answer, none of which is "adjust the figure".
This is why the week gets spent. The team is arguing about which system is wrong when the question is which of the four shapes they are looking at. That question is answerable in minutes if the comparison is set up to distinguish them, and unanswerable in a spreadsheet, because a spreadsheet compares totals and all four produce a mismatched total.
What a comparison has to do to be useful
It has to refuse to guess. Given two versions of a basket, it must say there are two baskets here and no rule for choosing between them, not pick the larger one. Given the same payment from two sources, it must say two systems claim this rather than adding them. Given a missing record, it must say this is absent rather than treating the absence as a zero.
And when it says everything agrees, that has to mean something narrow and stated: the records you supplied are consistent with each other. Not that the money arrived. Not that your provider's history is complete. The moment a green result means more than the evidence supports, the whole report becomes something to be checked by hand, which is what it replaced.
The requirement teams skip
The answer has to be reproducible without the tool that produced it. If I tell you that order 4,412 is short by €40, you should be able to take the inputs I used, recompute the comparison yourself, and get the same answer — or prove that I am wrong. A finding you cannot check is a finding you have to trust, and trust is exactly what is missing in the week everyone spent arguing.