Every payments product launches on the happy path. A customer pays, the authorization succeeds, money lands, the ledger balances. Then the first settlement file arrives and the deposit is short by an amount nobody can immediately explain. That gap is the real job, and it never shows up in the pitch deck.
Reconciliation is the discipline of proving that what you expected to receive matches what you actually received, transaction by transaction, across every source that touches the money. Exceptions are everything that does not match. We budget engineers to move money and almost no one to confirm it moved correctly. The result is a queue that grows quietly until it becomes a finance close problem, a customer support problem, or a regulator problem.
Why your ledger and the settlement file never agree
When you authorize a card payment, you record the gross amount. What settles into your account days later is the net amount, after the network and your acquirer subtract interchange, scheme assessments, and processor markup. Card settlement typically lands one to three business days after the transaction, so timing alone guarantees that any single day's authorizations and any single day's deposit will not line up.
On top of timing and fees, you get refunds, partial captures, reversals, currency conversion differences, and chargebacks that claw money back weeks after the original sale. Each of these arrives on its own clock and often in its own file format. A multi-provider stack makes it worse: every processor names fields differently, batches differently, and reports fees differently.
The practical model is three-way matching. You hold an internal record of what you expected, the provider sends a settlement file of what they processed, and your bank statement shows what actually moved. Reconciliation confirms all three agree within a defined tolerance. Anything outside tolerance becomes an exception.
Match, tolerance, then route
A working reconciliation engine applies configurable rules across every ingested source at once. Records that match within tolerance close automatically with no human review. Records that do not match get surfaced and routed to a person. The goal is not to eliminate exceptions, which is impossible, but to drive the auto-match rate high enough that humans only see the genuine breaks.
Tolerance matters because exact matching is a trap. A payout that is off by a few cents from rounding on a currency conversion is not a fraud event, and forcing a human to clear it wastes the one resource exceptions consume most: attention. Set tolerances deliberately, log every auto-clear, and review the tolerance bands as volume grows.
A worked example
Say you run a marketplace and process $100,000 in card sales on Monday. You record $100,000 of expected revenue. On Wednesday your acquirer deposits $97,600.
Here is the reconciliation. Interchange and assessments run roughly two percent of volume for a typical card mix, call it $2,000. Your processor markup adds another $150. A customer refunded a $200 order on Tuesday, netted out of the deposit. That accounts for $2,350 of the $2,400 gap, leaving $50 unexplained.
That $50 is your exception. Maybe one transaction settled in a later batch and will appear Thursday. Maybe a partial capture came in below the authorized amount. Maybe a provider fee was miscoded. You do not close the books until you know which. The discipline is that the $97,650 you can explain gets confirmed and closed, and only the $50 break stays open and assigned to someone. Tracking the break separately keeps the audit trail on the original 99.95 percent intact.
Disputes are a separate, slower queue
Chargebacks deserve their own workflow because they reopen money you already counted. Treat a chargeback as a new exception linked to the original transaction, not as a reopening of the original settlement match. That keeps the original audit trail clean while the dispute and its financial impact are tracked on their own.
The timelines are long and asymmetric, which is why disputes wreck unprepared teams. Under both Visa and Mastercard rules, a cardholder generally has up to 120 days from the transaction or expected delivery date to dispute. So a sale you reconciled and forgot in January can come back in May.
Response windows are tight on your side. As of July 21, 2025, Visa shortened the merchant dispute response window for transactions processed locally in the US and Canada to 9 days, down from 20. For other regions, and for disputes opened before that date, the window is 18 days. Mastercard generally gives a merchant 45 days to respond to the initial chargeback. Miss the window and you lose by default regardless of the evidence. The schemes run this through their own systems, Mastercom for Mastercard and Visa Resolve Online for Visa, each with its own rules and formats.
Build the dispute clock into the system
Because the clock starts when the dispute is filed and runs short, dispute handling cannot be a someone-will-notice process. Every incoming chargeback needs a hard deadline, an owner, and an evidence path the day it arrives. The cost of a missed deadline is the full transaction value plus a scheme fee, so the math favors staffing this even at low dispute volumes.
Staffing the queue before it staffs you
The unbudgeted cost is people. Auto-match handles the bulk, but exceptions, edge cases, and disputes need humans who understand the money flow. As you add providers, currencies, and payment methods, the exception surface grows faster than transaction volume, because each new rail introduces a new file format, a new fee structure, and a new failure mode.
Decide early who owns the exception queue and the close. A clean monthly close depends on every break being explained, not waved through. The teams that struggle are the ones who treated reconciliation as a reporting afterthought rather than an operating function with a headcount line.
The takeaway
Reconciliation is proof that your money movement actually worked, not bookkeeping hygiene. Budget for it like infrastructure: a high auto-match rate with deliberate tolerances, a routed exception queue with named owners, and a dispute workflow with the scheme clocks built in. A product that ships money but cannot reconcile it only looks finished. The reckoning is deferred, not avoided.