Why the deposit never equals the orders

Somebody on your finance team keeps a spreadsheet that nobody asked them to build. It has one column for what the store says it sold, one for what the bank says arrived, and a third column that exists only to hold the difference. That third column is the job.

I want to take one ordinary payout apart, because the gap almost never comes from one place. It comes from six, and they arrive on different days.

One day, one deposit

Say you had a quiet Tuesday. One hundred orders, fifty dollars each.

Gross sales                        $5,000.00
Interchange (1.80% + $0.10/txn)      -100.00
Assessments / scheme fees (0.14%)      -7.00
Processor markup (0.30% + $0.05)      -20.00
Refund, issued today                  -50.00
Chargeback                            -50.00
Chargeback fee                        -15.00
FX spread, 12 orders billed in EUR     -6.37
                                   ----------
Deposit                            $4,751.63

Your ledger says you made five thousand dollars. Your bank says four thousand seven hundred fifty-one and change. Both are correct. Nobody made an error. And if you want to close the month, somebody has to explain all $248.37 of that, in writing, in a way that survives an auditor asking about it in March.

Going down the list

The fee lines are the easy part, and even they aren't easy. Interchange isn't one rate. It's a rate card — hundreds of categories that depend on card type, whether the card was present, what industry you're in, whether the customer used a rewards card that day. A premium rewards card costs you more than a basic debit card, and you don't find out which one it was until the settlement file shows up. So the 1.80% above is an average of a hundred different numbers, and next Tuesday it'll be a slightly different average.

The refund is where periods start bleeding into each other. That fifty dollars went back to a customer today, but the sale happened three weeks ago. It was already recognized. It was already in a report somebody presented. Now it's reducing today's deposit, and if you book it against today's revenue, both months are wrong — one too high, one too low, and they don't cancel out in any way that helps.

The chargeback is the same problem with worse timing and an extra fee. Somewhere there's an order from six weeks ago that the customer is disputing. The processor took the money back and charged you fifteen dollars for the trouble. The reference number in the payout file may or may not resemble the order ID in your system. Often it doesn't. Often it's a different string entirely, assigned by the card network, and matching it back to the original sale is a manual lookup someone does with two browser tabs open.

The FX spread is the line people skip because it's small. Twelve orders were billed in euros. You quoted a price, the customer paid it, and the conversion happened somewhere between those two events at a rate that was never shown to anyone. Six dollars and thirty-seven cents. Small enough to write off. It is also six dollars and thirty-seven cents every day, across every currency, and at the end of the year somebody asks where roughly two thousand dollars went.

The part that actually hurts

None of the individual lines are hard. Each one is a five-minute problem if you know where to look.

The hard part is that there are hundreds of them, they're interleaved, and no single system holds the whole picture. The processor knows the fees but not your revenue recognition rules. Your ledger knows the orders but not what the card network decided about interchange. The bank knows one number — the deposit — and nothing about how it was assembled.

So the work becomes: pull three exports, line them up, find the ones that don't agree, and then figure out why each one doesn't agree. The finding is quick. The why takes the afternoon. And the why is the only part that matters, because "there's a $248.37 discrepancy" is not something you can post to a ledger. "A refund from July 24 landed in today's batch" is.

Multiply that by four processors, each with its own file format, its own settlement calendar, and its own idea of what a transaction ID looks like. That's not a spreadsheet problem anymore. That's why close slips.

Why "just automate the matching" isn't the answer

Plenty of tools will match transactions for you. Matching is the part computers are already good at — amounts, dates, reference numbers, arithmetic that either reconciles or doesn't.

But matching only clears the transactions that agree. What lands on a controller's desk is everything that didn't, and that pile is exactly where the judgment lives. An unmatched line isn't information. "This $50 debit is a refund against order #8812 from July 24, which was recognized in the July close" — that's information. One of those you can act on. The other you have to go investigate, which is the thing you were trying to avoid.

That's the actual gap in most reconciliation tooling. It ends where the work begins.

The version of this that would genuinely help isn't faster matching. It's an exception queue where every item arrives with its explanation already attached, and the source rows sitting right there so you can check the explanation in ten seconds instead of trusting it. You still decide. You just stop doing the archaeology first.

Which is a much less impressive thing to claim than "AI reconciles your books." It's also the part that would give you your afternoon back.