Use case · Updated August 26, 2026

Why card payment reconciliation almost never ties out

If you take cards across several locations, there are three systems that should tell the same story, and they almost never do. This use case explains why, walks through the five mistakes that throw the match off, and lays out what has to be in place for it to tie out.

The three sources that should agree

A card sale leaves a trail in three different places, and each one tells it its own way.

Your ERP records that you made the sale, when, and with which payment method. That's what you reported.

The card processor's settlement says which transactions it recognizes, how much it deducts in processing fees and financing costs, and when it will pay you. That's what they acknowledge.

The bank statement shows the deposit that actually hit the account, almost always batched and net of fees. That's what you collected.

Reconciliation means proving that all three tell the same story. When they don't, the gap could be a sale that was never settled, a fee charged at the wrong rate, a tax withholding, or simply a file nobody has downloaded yet. The hard part isn't adding things up. It's telling which of those four it is.

The five mistakes that throw the match off

1. Matching against only one processor

A store that takes cards rarely gets paid through a single channel. The same terminal can settle through different processors depending on the card, and then there are digital wallets, which show up in the settlement under the card brand behind them, with no trace of the wallet itself.

If you match your sales against one processor's files, everything that came in through the others shows up as missing. That number isn't lost money. It's the part of your revenue you didn't look at.

2. Matching on the wrong date

Settlement files usually carry more than one date for the same transaction: the day the card was swiped, the presentment date, and the payout date. They're not interchangeable, and they can be weeks apart.

Matching the sale against the payout date throws everything out of line, because it compares what you sold on Monday with what you collected the following Friday. The rule is simple: the sale is matched against the day the card was swiped, and the money is matched against the day it hit the bank. Those are two separate matches.

3. Accepting an amount that's close enough

This is the most dangerous one, because it produces results that look good. With thousands of transactions a month, there's always a sale for roughly the same amount as any slip you're looking for. If the only matching rule is the amount, with a tolerance of a few pesos on top, the system finds a partner for almost everything and reports a near-perfect match.

The way to tell whether a match is real is to run the same match with the dates deliberately shifted, say by three weeks. Any match that survives that shift is a coincidence, because those transactions have nothing to do with each other. That percentage is the method's chance floor, and every result should be published next to it. If your match rate is 80% and pure chance gets you 60%, the match is explaining a lot less than it seems.

4. Confusing "money is missing" with "a file is missing"

Processors don't always deliver complete data, or on the same schedule. Some months the settlement file covers only a fraction of the transactions, and downloading it by hand depends on someone remembering to.

When that happens, a shortfall calculated as "what I sold minus what's in the files" mixes two very different things: money you didn't collect, and data you didn't download. The first is a problem with the processor or your operation. The second is a file-management problem on your end, and you fix it by downloading the file.

A serious control flags those sales separately, under their own label, and never adds them to the red. If the number you're shown mixes the two, you can't base any decision on it.

5. Treating the end-of-day report as evidence

The batch report the terminal prints, or the one the store puts together by hand, is a valuable source, but it has a limit worth understanding: it's consistent with itself by design. The totals match the detail because the same process produces both.

A report that balances internally tells you nothing about whether it reflects what actually happened. The only thing that confirms it is matching it against a source the store doesn't control, which is exactly the processor's settlement and the bank statement.

What has to be in place for it to tie out

Complete sources, with a cutoff date. Every processor you take payments through, and knowing what date each one's file runs through. Without that, you can't claim anything is missing.

An identity key, not a resemblance. Merchant ID, settlement number, slip number, authorization code. If two transactions don't share the key, they're not the same transaction, even if the amount is identical.

A clear line between what's missing and what can't be confirmed. Two separate columns, always, with the total of the second one in plain view. As long as that column is large, the red can't be read as lost money.

The chance floor published next to the result. Every match rate should come with the rate the same method produces on data that's been deliberately misaligned.

Why this matters even if you don't suspect anyone

Companies usually take on reconciliation once there's already a problem. But its real value is preventive: it's the only way to know that the rate you're being charged is the rate you negotiated, that bank promotions are being settled the way they should be, and that no terminal has quietly stopped reporting.

When the match runs automatically every day, a discrepancy shows up the next morning, while a phone call can still fix it. When it's done by hand once a month, it shows up weeks later, when all that's left to do is argue about whose fault it was.