Explainers
Why payment reconciliation still burns treasury hours
Why reconciliation exists at all, where the hours actually go, and what richer data, real-time confirmation, and shared ledgers change about it.
Reconciliation is the tax an organization pays for keeping money in systems that do not share a record. The treasury believes it sent 4,000 payments last month; the banks report what actually moved; the ERP holds the invoices the payments were meant to settle. Three sets of records, produced by different systems on different clocks, and someone has to prove they describe the same reality. Most of the time software matches them automatically. The hours go to the residue that will not match, and cross-border payments produce residue at an industrial rate.
Why the records disagree
The disagreements are built into the architecture.
Messaging is separate from settlement. A payment instruction is a message; the movement of money is a separate event on a separate system, sometimes days later. Anything that happens in between, a cut-off missed, a compliance hold, a rejected instruction, shows up as a mismatch between what was sent and what settled.
Intermediaries edit the payment in flight. Through a correspondent chain, each intermediary bank may deduct fees from the principal, convert currency at its own rate, and truncate references. The beneficiary receives an amount that matches no invoice, carrying a reference that matches no record. Someone in accounts receivable gets to guess.
Batch files hide individual payments. Rails that settle in batches report in batches. A single net figure on a statement can represent hundreds of underlying transactions, which must be exploded and matched line by line.
Timing differences masquerade as errors. A payment booked today with a value date of tomorrow sits as a break for a day even when nothing is wrong. Month-end cut-offs turn those innocent breaks into a reporting scramble.
Where the hours actually go
The routine matches cost nothing; software clears them. The cost concentrates in exceptions. The LexisNexis Risk Solutions True Impact of Failed Payments study put the average bank charge for a rejected or repaired payment at about $12.10 per payment, and found that most failures trace to errors in beneficiary name and address details. The charge is the visible part. Behind it sits the investigation: a payment that failed or went astray triggers a case that crawls across banks by message and email, and Swift’s own case-management work exists precisely because exceptions and investigations have historically been slow, manual, and multi-party.
Each exception is small. The burden is the queue: a percentage of every day’s flow, every day, staffed by people whose job is to reconstruct what a chain of systems did to a payment after the fact.
What actually improves it
Three changes attack different causes.
Richer data. ISO 20022 lets remittance information travel with the payment in structured form, so receipts arrive explaining themselves. Fewer mangled references, fewer guesses.
Real-time confirmation. Tracking systems such as SWIFT gpi confirm where a payment is and when it arrived, which converts “missing” payments from investigations into status lookups.
A shared record. The deeper fix is architectural. When both sides of a payment settle on the same ledger, there is one record of what happened, not three estimates of it. Settlement that is final and visible to both counterparties at the same instant leaves nothing to reconstruct: the statement, the instruction, and the movement are the same entry.
Honesty requires the caveat: no organization runs on one ledger for everything, so reconciliation never disappears entirely. The realistic goal is to shrink the surface area, fewer systems disagreeing about fewer payments, with exceptions caught at settlement time rather than at month-end.
Where Frame fits
Frame is the settlement layer for global finance: one integration to orchestrate payments at scale across fiat rails, stablecoins, and tokenized deposits, with compliance enforced on every transaction and settlement in seconds instead of days.
Reconciliation burden is a symptom of settlement that happens somewhere else, out of sight, on someone else’s record. Frame settles payments across whichever rail fits each transaction, and every settled transaction produces verifiable evidence that its conditions were met, without exposing the underlying business data. Compliance is evaluated by Frame’s Rules Engine inside settlement rather than discovered afterward as an exception, so a transfer that cannot satisfy its governing policies does not settle in the first place. For banks, payment providers, exchanges, platforms, and enterprises, that moves the work from proving what happened last month to defining what is allowed to happen at all.
See how a rail-neutral settlement layer works: the Frame Blueprint.
Common questions
- What is payment reconciliation?
- Payment reconciliation is the process of matching what an organization believes happened to its money against what its banks say happened: instructions against statements, invoices against receipts, ledger entries against account movements. It exists because the systems that initiate payments and the systems that settle them are separate, so each keeps its own record and the records disagree in small ways that must be found and resolved by hand.
- Why is reconciliation harder for cross-border payments?
- Because more parties keep more records. A cross-border payment can pass through several correspondent banks, each applying its own fees, references, and timing, so the amount that arrives rarely matches the amount that left, and the remittance information explaining what the payment is for is often truncated or stripped along the way. Matching a short receipt with a mangled reference to the right invoice is manual work, multiplied by every corridor a business operates in.
- How much do failed and repaired payments cost?
- The LexisNexis Risk Solutions True Impact of Failed Payments study, based on 400 payment executives across four regions, put the average bank fee for a rejected or repaired payment at about $12.10, before counting the internal staff time to investigate and resolve it. It also found most failures trace to errors in beneficiary name and address details, exactly the data that legacy payment messages carry badly.
- Does ISO 20022 fix reconciliation?
- It helps with one cause: poor data. ISO 20022 messages carry structured, richer remittance information, so a receipt can arrive with the invoice references intact instead of crammed into a free-text field. What it does not change is the architecture, in which messaging and settlement remain separate systems whose records still need matching. Better inputs shrink the exception queue; they do not remove the need for one.
Sources
Last reviewed 2026-07-16