Payment Settlement Reconciliation: Tracing Every Break Back to a Single Transaction Before Close

Why settlement reconciliation stops working exactly when it matters

The pattern is always the same. Someone built a spreadsheet that takes the processor's daily report, sums it, compares it to the bank deposit, and highlights the difference in red. For a year it worked, because the difference was zero or close enough. Then you added a second acquirer, a second currency and a marketplace payout model, and the red cell became a number with four digits that changes every day. The controller asks what it is. The honest answer is that nobody knows, because the spreadsheet compares totals and the difference is made of thirty individual transactions doing thirty different things.

A settlement break is never a single event. It is a capture that was authorised on the twenty ninth and funded on the second, so it belongs to a different month than your revenue recognition thinks. It is a transaction that downgraded to a more expensive interchange category after the fact because the data quality on the authorisation was poor. It is a refund that netted against the day's funding rather than arriving as a debit. It is a monthly scheme assessment that landed as one lump and belongs across forty thousand transactions. It is an FX conversion done at the processor's rate on a day you did not choose. Each of those has a different fix and a different owner, and a total to total comparison hides all of them behind one number.

The cost is not the labour, although the labour is real. The cost is that unreconciled settlement is unrecognised revenue. You cannot close, you cannot report a true take rate, and you cannot tell a board which product line actually makes money, because the fees that determine that answer are sitting unallocated in a suspense account.

Problem one: every processor reports a different reality

Visa settlement reporting, Mastercard clearing files, and each acquirer's own daily funding report describe the same money in incompatible shapes. One gives you gross with fees itemised, another gives you net with a summary fee block, a third gives you a funding advice that covers three business days and includes an adjustment with a reference number that appears nowhere in your system. Add a local acquirer in a second market and you get a fourth model, usually with a fixed width file and a character encoding surprise.

SmartStream TLM and Gresham Clareti are real enterprise matching engines and they will handle this, with the caveat that they are implemented and priced like enterprise programs and their strength is matching rather than modelling your revenue. Duco is genuinely good at self service data matching and gets a finance team productive quickly, but it stops at matched or unmatched and does not own your ledger or your contracted fee schedule. Kani Payments is purpose built for fintech and programme manager reporting and onboards fast when your model resembles the one it was built around. Modern Treasury is strong on bank payment operations and ledgering, and less focused on the card scheme fee detail that drives an acquirer break.

What a custom build does: an ingestion adapter per source that normalises into one internal settlement event model, with the raw file retained and linked. Every event carries its source, its file, its line number and its parsed values, so a break can always be traced back to the exact row in the exact file. That traceability is the whole product. Without it your analysts are re opening files by hand and you have bought a nicer spreadsheet.

Problem two: matching one to one is the easy case and it is rare

An authorisation, a capture, a partial refund, a second partial refund, a chargeback, a representment and a final funding line are seven events describing one customer purchase, spread across weeks and arriving from three sources. Reconciliation is not pairing rows, it is assembling that lifecycle and asserting that the money nets to what the ledger says it should.

What a custom build does: match at the level of the transaction lifecycle, not the row. Group by the acquirer reference and your internal order identifier, keep the group open until the lifecycle is terminal, and apply tolerances that reflect reality, such as rounding on multi currency conversion. Anything unmatched gets classified into a bucket a human can act on: timing difference expected to clear, fee variance against contract, missing from processor, missing from ledger, duplicate, or genuine loss. A break with a category and an owner gets fixed. A break in a list gets aged.

Problem three: nobody validates the fees, so you pay whatever arrives

Your acquirer contract has an interchange plus structure with a negotiated markup, specific scheme fee pass throughs and a monthly minimum. What lands on your account each day is a net figure. Almost nobody checks that the net figure matches the contract, because doing it requires recomputing interchange per transaction against the card type, the region, the entry mode and the merchant category, then adding scheme fees and the markup.

This is the part of the build with the clearest payback and the part most teams skip. Encode the contracted rate card, recompute expected cost per transaction, and compare to what was charged. You will find downgrades caused by your own data quality on authorisation, which is a fixable engineering problem worth real basis points. You will find fees charged on transaction types your contract excludes. You will find cross border assessments on transactions that were domestic. Bring the exceptions to your acquirer with transaction references, because a conversation with references gets a credit and a conversation without them gets an explanation.

Problem four: reconciliation that does not post to the ledger is a report

A break queue that lives in a separate tool and produces a monthly summary changes nothing. The finance team still journals manually and the suspense account still grows.

What a custom build does: matched groups post automatically to the general ledger with the correct split between gross revenue, processing cost, chargeback loss and FX gain or loss, with the posting reference carrying the transaction group so an auditor can walk from journal line to source file in two clicks. Unmatched items post to a controlled suspense account with an aging policy and a named owner, and the aging report goes to the controller weekly rather than being discovered at close. Model this as double entry with immutable postings. If a correction is needed it is a reversing entry, never an edit, because the day you allow edits is the day your audit trail becomes an opinion.

What a custom reconciliation build must include

• A source adapter per processor, scheme and bank, retaining raw files with line level traceability
• Lifecycle level matching rather than row pairing, with configurable tolerances per currency and source
• A break taxonomy with owners, aging and required resolution notes, not a generic exceptions list
• Contracted rate card modelling with expected versus actual fee comparison per transaction
• Automated general ledger posting with a controlled suspense account and reversing corrections only
• FX handling that records the rate, the source and the date used, because processor rates are not your treasury rates
• A restatement safe design, so that a file received late can be applied without rewriting closed periods
• Operational reporting that answers take rate by product, by merchant segment and by processor, after real costs

What it costs and how long it takes

A first release, meaning file ingestion for your live connections, lifecycle matching against your ledger, and a break queue with categories and aging, runs $70,000 to $160,000 and ships in 12 to 16 weeks. A full platform adding fee validation against contracted rates, FX, chargeback and refund lifecycle handling, automated journal posting and multi entity support runs $200,000 to $500,000 across 6 to 14 months.

What pushes cost up specifically here: the number of processors and schemes, since each is a distinct file grammar. Multi currency, because FX turns every tolerance decision into a policy question. Multi entity structures where one processor account funds several legal entities and the split has to be derived. Marketplaces and facilitators, where you are reconciling not just your own money but sub merchant balances and reserves. Historic backfill, if you want the last two years reconciled rather than starting clean. And how good your own transaction data is: a ledger that does not store the acquirer reference on the transaction makes the first matching pass much harder, and fixing that upstream is often the cheapest week in the project.

Build versus buy for settlement reconciliation

Buy, and keep it simple, if you have one processor, one currency, and a daily file that already balances to the deposit. A matching tool plus a disciplined close is enough, and building would be an expensive way to automate something that takes an analyst two hours a month.

Build when two or more of these are true. You run three or more processor or acquirer connections. You operate in more than one currency or more than one legal entity. You are a facilitator or marketplace holding funds for others, which makes reconciliation a custody question rather than an accounting one. Your close is being delayed by unreconciled settlement. Or you cannot currently state your true net take rate by product line, which means your pricing decisions are being made on an estimate.

How to choose a developer for reconciliation work

Ask them to explain how they would reconcile a purchase that was authorised in one month, captured in the next, partially refunded twice and then charged back. If they describe pairing rows, they will build you a matching script that fails in week three. If they describe a lifecycle group held open until terminal, they have done this.

Ask what they will do with a break. A developer who has run finance operations builds a taxonomy with owners and aging. A developer who has not builds an exceptions table that becomes a graveyard.

Ask which settlement files they have parsed, by processor name, and what they did about the adjustment lines that reference nothing. That question cannot be answered from documentation.

Ask who owns the code, the rate card definitions and the cloud accounts, and get it in the contract before kickoff. Your encoded fee contracts and matching rules are the reason the system keeps paying for itself. At Digital Heroes that is yours from the first commit, and any developer who wants to hold your reconciliation logic in their own platform is selling a subscription, not a solution.