Your ledger (Module 4) knows what your system believes happened. The rail knows what actually settled. These are two different sources of truth, recorded at different times, in different currencies of certainty, and a payments product that does not reconcile them is one that will eventually report a balance no auditor can trust.
Reconciliation is the daily act of proving those two records agree. Settlement timing is the reason they rarely agree on the same calendar day. Get both wrong and you will book revenue you do not have, miss money you are owed, and discover the discrepancy weeks later when it is expensive to unwind.
Authorization is a promise, settlement is the cash
When a card payment is authorized, no money has moved. The issuer has placed a hold and made a promise. The funds do not leave the cardholder and arrive in your account until clearing and settlement run, which happens later, in batch, on the network's schedule rather than yours.
The networks aggregate clearing items from every issuer and acquirer, compute a multilateral net position for each participant, and move money between issuers and acquirers on that net basis. Your acquirer then funds you on its own commercial schedule, which may not match the network's settlement at all.
This is why settlement typically lags authorization by one to three days depending on region, batching windows, and weekends. A sale authorized on Friday evening can clear over the weekend but not settle until Monday or Tuesday, because the underlying bank-to-bank rails do not run on weekends. Someone funds that gap, and your product needs to know who and for how long.
Gross versus net is the trap
The number on your acquirer's statement is net. The rail does not pay you the sticker price of each sale. It pays you the sum of sales, minus refunds, minus chargebacks, minus interchange, minus scheme fees, minus your acquirer's markup, all collapsed into a single deposit.
If your ledger only recorded gross sale amounts, it can never match a net deposit. You have to model every fee and deduction as its own ledger entry so that gross minus the fee lines equals the payout. Reconciliation that does not decompose the payout into its parts is not reconciliation, it is hoping.
Reconcile against the report, not the bank line
The bank deposit tells you a lump sum arrived. It does not tell you which transactions it covers. The settlement report from your processor or acquirer is the document that itemizes the payout, and that is what you reconcile against.
Stripe is a useful reference here because its model is explicit. Every payment, refund, fee, and payout generates an immutable balance transaction object, and replaying those objects up to any point reconstructs your balance, which is exactly the ledger discipline from Module 4. Its payout reconciliation report then groups the transactions that make up each bank deposit by reporting category, so you can tie a single arriving deposit back to the individual charges and fees inside it.
The general pattern holds across providers. There are three records to align: your internal ledger, the processor's settlement or payout report, and your actual bank statement. Two-way reconciliation (ledger to report) catches application bugs. Three-way reconciliation (ledger to report to bank) catches the cases where the money never actually arrived.
A worked example
You run a Tuesday batch. Your ledger shows 1,000 captured sales totaling $50,000.00 gross. On Thursday, a deposit of $48,150.00 lands.
Pull the settlement report for that payout. It should decompose to something like: $50,000.00 in sales, minus $300.00 in refunds (six refunds processed Wednesday), minus $1,450.00 in processing fees, minus a $100.00 chargeback debit. That nets to $48,150.00, and it matches the deposit. Reconciled.
Now suppose the deposit is $48,150.00 but your ledger only expected $48,450.00 because it never recorded the chargeback. The $300.00 gap is not a bank error. It is a missing ledger entry, and the reconciliation just caught a real liability your books were ignoring. That is the entire point of doing this daily rather than monthly.
Timing differences are normal, breaks are not
The hardest part of reconciliation is separating timing differences from true breaks. A refund issued Wednesday that lands in Thursday's payout is a timing difference, expected and self-clearing. A sale in your ledger that never appears in any settlement report is a break, and it needs a human.
Model this with a clearing or in-transit account. When you capture a sale, credit it to "funds in transit." When the payout lands and reconciles, move it from in transit to your settled cash account. Anything that sits in transit past its expected settlement window is your exceptions queue, and that queue is the real output of reconciliation.
Build the exceptions workflow before you need it
The reconciliation job that prints "matched" on a good day is easy. The one that matters is what happens on the bad day: a payout that is short, a transaction with no matching ledger entry, a fee line you cannot explain.
Every break needs a state (open, investigating, resolved), an owner, and an audit trail of how it was cleared. Without that, breaks get silently written off, and silent write-offs are how a payments product loses real money one rounding error at a time. Treat the exceptions queue as a first-class part of the product, not a spreadsheet someone opens at month end.
Closing the books
Reconciliation produces a defensible daily close: this is what we sold, this is what the rail paid us, this is the difference, and here is why each piece of the difference exists. When finance, your auditors, or a settlement dispute with your acquirer comes asking, that record is the answer.
The discipline is simple to state and easy to skip. Decompose every payout into gross and fees, reconcile three ways (ledger, report, bank), treat timing differences and true breaks as different things, and never let a break close without an owner and a reason. Do that every day and the books stay correct. Skip it and you inherit a backlog that compounds, which is the next module's problem when compliance comes to audit the trail.