An authorization is a promise. Settlement is the cash. The gap between the two is where revenue quietly leaks, and it is the part of the stack most teams instrument last, if at all. Earlier modules optimized the moment of purchase: approval rates, routing, recovery. This module is about proving that the money those decisions earned actually arrived, in the right amount, on the expected day.
Reconciliation is unglamorous and it is also where finance and payments stop trusting each other when it goes wrong. A deposit that does not match sales is not a rounding problem. It is fees you cannot explain, chargebacks you did not see coming, and FX you did not model. The job is to reconstruct the path from gross sales to net cash and account for every deduction.
Gross, net, and why your deposit never matches sales
Card settlement is a net process. The acquirer does not wire you the face value of every sale and then bill you separately. It aggregates a period of transactions, nets credits against debits, subtracts interchange, scheme fees, and its own markup, and deposits a single figure. The number that hits your bank is net revenue, not gross.
This is the first thing finance teams get wrong. They book gross sales from the order system and expect the bank deposit to match. It never will, because the deposit already has fees and adjustments removed. Reconciliation means rebuilding the gross-to-net bridge and confirming each deduction was applied at the contracted rate.
The three layers of fees
Every card transaction carries three fee components, and they settle differently:
- Interchange, paid to the issuer, varies by card type, region, and merchant category. This is usually the largest line.
- Scheme fees, charged by Visa or Mastercard, are smaller and harder to predict because they are assessed across many sub-categories.
- Acquirer markup, the margin your processor negotiated with you, sits on top.
If your reconciliation only checks "did the deposit roughly match sales," scheme fees are exactly where overcharges hide, because they are too small to notice per transaction and large in aggregate.
The files that prove settlement
Two kinds of files tell the settlement story, and you need both.
Scheme-level files come from the networks. Visa delivers settlement reporting through VSS reports, with the VSS-110 daily summary as the standard starting point. These come in two encodings: TC46 is machine-readable, TC47 is the human-readable equivalent. Mastercard delivers clearing through the IPM format, with separate records for clearing data and aggregate amounts. Which specific reports you receive depends on your Visa or Mastercard setup, so confirm availability with your representative rather than assuming.
Processor and acquirer files come from whoever you connect to. These arrive as CSV, XML, or fixed-width, on different timelines, and they restate the scheme data with the acquirer's fees and adjustments folded in. Adyen, Stripe, and similar platforms publish a settlement-detail report at the transaction level that is the most practical anchor for day-to-day reconciliation.
Fields you actually reconcile on
Across formats, the load-bearing fields are consistent. You need a stable transaction identifier, and the network reference ID is the one that survives across authorization, clearing, and dispute, so normalize to it. You need the settlement date, which groups every clearing tied to a given payout, and is distinct from the authorization date or capture time. You need amount, currency, and the fee breakdown. Everything else is context.
Normalization is the unsexy core of the work: standardize IDs, dates, currencies, and amounts so a record from your order system, your processor file, and the scheme report can be compared as the same event.
Three-way reconciliation
The discipline that catches problems is matching three sources, not two.
- Your internal record: what your system captured. The orders you believe you sold.
- The processor or scheme settlement file: what the network cleared and the acquirer is settling.
- The bank statement: the cash that actually landed.
Two-way matching against the processor file alone tells you the file agrees with itself. The bank leg is what confirms the money moved. A match across all three is a closed loop. Any single break is a flag.
A worked example
Say you captured 10,000 transactions on a given day totaling $500,000 gross.
- The processor settlement file lists 9,985 transactions clearing to $499,200. Fifteen captures did not clear. Break one: investigate the 15. Some will clear next cycle, some are expired authorizations you should write back.
- The file deducts $9,100 interchange, $1,400 scheme fees, and $2,500 acquirer markup, leaving a net of $486,200. You recompute interchange independently from your card-type mix and get $9,050. Break two: a $50 gap. Small, but if it recurs daily it is a misapplied rate worth a call.
- The file also carries two chargeback lines: a $120 debit for a disputed sale and a $15 dispute fee. These are separate line items, not nested in the sale, so your gross-to-net bridge must subtract them explicitly. If you later win the dispute, a third line appears: a reversal credit for the recovered $120.
- The expected deposit is $486,200 minus $135 in chargeback items, or $486,065. The bank shows $486,065 two days later. Break three resolved: the loop closes, with the 15 unmatched captures carried as an open item.
The point of the example is that "the deposit was close" would have hidden a recurring interchange overcharge and 15 captures that never turned into cash.
Timing, FX, and the open-items list
Settlement is not instant. Clearing typically follows authorization within one to two business days, and the cash deposit lands after that, depending on your acquirer's payout schedule and your settlement currency. Cross-currency sales add an FX conversion that the scheme applies at its own rate on its own date, which is a frequent source of cents-level breaks that compound.
Treat unmatched records as a managed queue, not noise. Every break is one of a few things: a timing difference that resolves next cycle, a fee discrepancy worth disputing, a chargeback to route to module 8's recovery flow, or a genuine loss to write off. Aging that queue is how you tell a slow file from a real leak.
The takeaway
Reconciliation closes the loop that authorization opens. Build it as a three-way match across your records, the settlement file, and the bank, anchor on the network reference ID and settlement date, and rebuild the gross-to-net bridge line by line so every deduction is accounted for. The deposit will never equal gross sales, and once you can explain exactly why, down to the scheme fee and the FX date, you have a settlement process you can trust and a finance team that trusts it too.