Three populations that never line up on the same day
Card money moves in three separate flows and every reconciliation failure in this space comes from treating two of them as the same thing.
The authorisation is a reservation. It happens at the moment of purchase, creates a hold, and may never be followed by anything at all.
The presentment arrives in the scheme's clearing file. It is the financial claim: this is the transaction, this is its final amount, this is the merchant. It usually arrives a day or more after the authorisation, often for a different amount, and sometimes with no authorisation to match.
Settlement is the money. It is a single net movement of funds between you and the scheme for a settlement date. It covers the transactions in that date's clearing, plus everything else the scheme is charging or paying you.
Because those three have different timings and different populations, the reconciliation is not one comparison but two: your postings against the clearing detail, and the clearing detail against the money received. A great many implementations do only the first and treat the settlement figure as an accounting entry, which is precisely how a fee change or a missed clearing file goes unnoticed for a month.
The correct mental model is a bridge that starts from gross transaction value and arrives at the cash you expect, with every difference on its own line and each line separately explainable. Suppose a settlement date whose clearing detail contains transactions with a stated gross value; the cash will differ from it for reasons that are all legitimate.
| Bridge line | Why it moves the figure |
|---|
| Gross presentments for the settlement date | The starting point, taken from the clearing detail rather than from your own postings |
| Refunds and credits | Move in the opposite direction and are frequently for a different date than the original sale |
| Interchange | Deducted or paid according to the scheme's published rates for the card, merchant category and channel |
| Scheme fees and assessments | Charged on volume and count, often with fixed components that no per-transaction calculation reproduces |
| Chargebacks and representments | Reverse and re-present earlier transactions from earlier dates entirely |
| Currency conversion | Applies where the transaction currency and the settlement currency differ, at the scheme's rate on its own date |
| Timing and cut-off | Transactions cleared just either side of the scheme's cut-off belong to the adjacent settlement date |
Two features of this table are the answer to the question. The first is that a difference between your postings and the cash is expected and quantifiable. So the control is not "these numbers are equal" but "every component of the difference is identified and only a residual remains".
The second is that several lines refer to earlier dates. Today's cash cannot be reconciled purely from today's transactions: a chargeback appearing in this settlement belongs to a sale weeks old, and your reconciliation must be able to find it.
Match at the item level, then prove the total
Both directions of the control are necessary and each catches what the other misses.
Item-level matching pairs each presentment with your own record, keyed on the scheme's transaction identifier rather than on a reconstructed composite of card number, amount and date.
The composite key is what produces the classic wrong match: two identical purchases at the same merchant for the same amount within a minute of each other, matched to each other's records. The totals net to zero while two merchants are paid the wrong way round. It also produces the mismatch when a presentment amount differs legitimately from its authorisation, which is normal for fuel, hotels, tips and partial shipments.
Total-level proof takes the bridge above and asserts that gross, less each explained adjustment, equals the cash movement on the bank statement for the settlement account. Note the last clause: the proof terminates at the statement, not at the scheme's own report of what it paid you. Reconciling the scheme's advice to your ledger and never to the actual credit means a missing or partial payment is invisible.
What a break looks like here, and where it lives while you work it
The useful discipline is that the difference has somewhere to sit and someone to own it. Unmatched items and unexplained residuals post to a suspense account, which exists so that the ledger stays balanced while the answer is unknown.
The properties that make suspense a control rather than a dustbin are that every entry carries the identifier of the item that caused it, the balance is aged, and the ageing is reported to someone with the authority to escalate. A suspense account with an old balance nobody can decompose is the finding an auditor writes up, and it usually means items were posted there to make a daily control pass.
The recurring break types are worth knowing by name because each has a different cause. A presentment with no matching authorisation may be a legitimate offline or forced transaction, or it may be a merchant presenting something they were never authorised for. An authorisation with no presentment simply expires, and the hold has to be released on a defined schedule rather than left.
A fee variance against your expectation usually means the scheme changed a rate or a category and nobody updated the expectation, which is why calculating expected interchange independently and comparing it to what was charged is a control worth having rather than accepting the deduction as given. And a whole-file absence — a clearing file that did not arrive — is the failure most likely to be mistaken for a quiet day, which is why file-level expectation monitoring by settlement date belongs alongside the item matching.
Balancing to the penny is not the same as being right
The trap here is a reconciliation designed to produce a difference of zero rather than to produce explanations. It is entirely possible to net two errors against each other, to force a residual into suspense to make the daily control pass, or to match items pairwise incorrectly and still balance. The stronger design measures itself on match quality and not only on the residual: the proportion of items matched on the scheme's own identifier as opposed to a fuzzy fallback, the count and age of unmatched items, the size of each bridge line against its expected size, and the residual as an absolute figure with a threshold that requires sign-off rather than a percentage that hides in a large denominator.
Derive that threshold openly from what you can afford to investigate rather than asserting a number. If a break of any size costs an analyst a couple of hours, and you have a small team, then a threshold that generates more items than the team can work means the oldest ones will never be looked at — so the threshold has to be set with the queue's capacity in view, and reported as a decision rather than a configuration value.
The scheme's net payment and your transaction postings are not supposed to be equal, so build the control as a bridge whose every line has a name and terminate it at the bank statement rather than at the scheme's advice.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).