What is reconciliation?
The most boring word in payments, and the place money quietly disappears.
It is balancing a chequebook, if the chequebook covered ten thousand transactions a day, deducted a variable commission from each, and settled in batches whose composition you had to reconstruct.
Three systems, three versions of the same day. The difference between them is not an error. It is money.
Why three records exist and disagree
Your system records a sale. Your payment provider records a transaction. Your bank records a deposit. In an ideal world these agree perfectly.
They do not, routinely, for entirely mundane reasons. Settlements arrive net of fees, so the deposit never matches the sale. Refunds and chargebacks are deducted from later batches, so today's deposit reflects last week's returns. Transactions near a cutoff time land in a different day's batch. Currency conversion introduces rounding.
None of these are errors. All of them create differences that must be explained rather than ignored.
What breaks when nobody reconciles
Revenue is recognised that never arrived. Failed payments are treated as successful and goods are shipped for free. Duplicate charges to customers go unnoticed until they complain. Fee overcharges by providers are never detected, because nobody is checking the arithmetic on thousands of small deductions.
That last one is worth sitting with. Provider fee calculations are complex, tiered, and occasionally wrong. The businesses that reconcile properly find discrepancies. The ones that do not, do not find them, which is not the same as their absence.
Nobody has ever been promoted for reconciling well. Several people have been removed for not doing it.
What actually breaks it
Reconciliation almost never fails because a payment vanished. It fails because two systems described the same payment differently, and the difference is legitimate on both sides.
Timing is the biggest offender. Authorisation lands on one date and settlement on another, so a sale booked on the last day of a month can settle in the next one. Your revenue report and your bank statement are both correct and will not agree.
Partial refunds are the second. One sale becomes two records of unequal size, and if the refund settles in a later batch than the original, the pair never appears in the same file.
Fees are the third, and the most tedious. Some are netted off the settlement before it reaches you, some are invoiced monthly, some are deducted per transaction and some per batch. The gross amount you were expecting and the net amount that arrived differ by a number that has to be reconstructed rather than read.
Then FX rounding, which produces differences of a few units per transaction that are individually invisible and collectively a line item. And chargebacks, which pull money back out of a period that closed weeks ago, so a reconciled month quietly becomes unreconciled.
None of these are errors. All of them have to be modelled, which is why reconciliation is engineering work rather than accounting work.
Where you meet it
If you run any business taking payments, in the gap between your dashboard and your bank statement. If you do not, in the fact that your duplicate charge eventually got noticed by somebody.
Building this? A second pair of eyes on the architecture is what the advisory is for. →
