Payment reconciliation is the process of matching the money that actually moved against the records that say it should have moved. Every payment a business sends or receives creates at least two artifacts, a bank or network record and a ledger entry, and reconciliation is the control that proves those two agree. The scale is the reason it matters. The ACH Network alone carried 35.19 billion payments worth $93.00 trillion in 2025, averaging 141 million transactions a day, and 8.08 billion of those were business-to-business.
​

Reconciliation sounds clerical. In practice it is the step that decides whether a finance team can close the books, answer an auditor, or tell a customer where their money went. When it breaks, it breaks quietly, and the discovery usually happens weeks later during month end.
​

Payment reconciliation is the matching of payment records from an external source, such as a bank statement or processor settlement file, against internal ledger entries. The goal is a one-to-one match for every transaction, with any difference explained. Unmatched items are called breaks, and each break represents money whose status the business cannot yet confirm.
​

Three artifacts have to agree. The first is the payment instruction, meaning what the business intended to pay or collect. The second is the network or bank record, meaning what actually settled. The third is the general ledger entry, meaning how the movement was booked. Reconciliation compares those three and produces either a match or a break with a reason code.
​

The volume involved is what makes this a systems problem rather than a clerical one. Business-to-business payments alone accounted for 8.08 billion ACH transactions carrying $63.11 trillion in 2025, and each one produces a record on both sides that has to be matched.
​

The distinction that trips teams up is between reconciliation and settlement. Settlement is the transfer of value. Reconciliation is the confirmation that the transfer matches the record. A payment can settle perfectly and still fail reconciliation because the remittance data did not carry enough information to identify which invoice it paid. Eco covers the mechanics of the transfer side in orchestration versus clearing versus settlement.
​

Reconciliation works by pulling an external record set and an internal record set for the same period, normalizing both to a common format, then matching transactions on identifiers such as amount, date, reference, and counterparty. Matched pairs clear. Unmatched items become breaks that a human investigates and resolves before the period closes.
​

The normalization step is where most of the work sits. Bank files, card processor reports, and payment API responses each use different field names, date conventions, and fee treatments. A card settlement often arrives net of fees, so the deposit in the bank account will never equal the sum of the underlying transactions unless the fee line is modeled separately. Teams that skip normalization end up reconciling gross figures against net deposits and generating breaks on every single batch.
​

Matching itself runs in tiers. Exact matching handles transactions where amount and reference align perfectly. Fuzzy matching handles near misses, such as a payment split across two deposits or a reference with a transposed digit. Rules-based matching handles known patterns, such as a recurring subscription that always arrives two days late. What remains after all three tiers is the genuine exception queue, and the size of that queue is the practical measure of how healthy a reconciliation process is.
​

What the tiers can achieve depends on what the payment message carries. The Federal Reserve's payments improvement program notes that the ISO 20022 standard supplies the data content and structured format needed to automate e-remittance information, which is the difference between a rule that matches deterministically and one that guesses.
​

Tier order matters as much as tier content. Running fuzzy matching before exact matching lets a near miss consume a record that a later exact match needed, which produces two breaks where there should have been none. The convention is strictest first, with each tier only seeing what the previous tier left unmatched, and every automatic match tagged with the rule that made it so a reviewer can reconstruct the decision.
​

The last structural choice is what happens to a break once opened. A break with no owner and no reason code is a note, not a control. Assigning each break a category at creation, whether timing, fee, partial, or missing reference, is what turns the queue into data about which upstream system needs fixing.
​

Reconciliation breaks when the payment record does not carry enough structured information to identify what it paid for. The money arrives, but the remittance detail is missing, truncated, or written as free text a machine cannot parse. The result is a payment that settled correctly and still requires a human to research which invoice it closes.
​

This is a data format problem more than a process problem. The Federal Reserve's payments improvement program has published guidance specifically on the correct use of structured remittance information, noting that the standard provides the data content and structured format needed to automate e-remittance information and that correct formatting is what makes straight-through processing possible. Swift makes the same point from the network side, describing ISO 20022 as enabling richer, better structured and more granular data end-to-end in payment messages.
​

The other common break sources are timing, fees, and partial payments. Timing breaks occur when a payment settles in one period and books in another, which is routine across weekends and month boundaries. Fee breaks occur when the gross amount and the net deposit differ and the difference was never modeled. Partial payment breaks occur when a customer pays part of an invoice, or pays several invoices with one transfer, and the matching logic expects a one-to-one relationship that does not exist.
​

Volume compounds all three. B2B ACH payments grew 9.9% in 2025 to 8.08 billion payments carrying $63.11 trillion, and a break rate that was tolerable at one volume becomes an unmanageable queue at another.
​

Reconciliation is not one process. Finance teams typically run several in parallel, each comparing a different pair of record sets, each with its own failure modes, and each on its own cadence. Bank reconciliation runs daily, processor reconciliation runs per settlement batch, and intercompany reconciliation often runs monthly, which means breaks surface at different times.
​

Volume is distributed unevenly across them. Direct Deposit alone moved 8.74 billion payments worth $16.49 trillion in 2025, which is why payroll reconciliation is usually the most automated of the set while lower-volume flows stay manual.
​

Bank reconciliation compares the general ledger cash account against the bank statement. It is the oldest form and the one most accounting software automates by default. Its weakness is that a bank statement shows net movement, so it confirms that cash arrived without confirming what the cash was for.
​

That limitation is why bank reconciliation clears quickly and still leaves work behind. A single lump deposit can be confirmed against the statement in seconds and still require an afternoon to allocate across the many invoices it settled. Teams that report bank reconciliation as complete while the allocation queue grows are tracking the easy half of the problem.
​

Processor reconciliation compares individual transactions against the processor's settlement report and the resulting bank deposit. This is where fee modeling matters most, because the processor deducts its fees before depositing and the deposit will not match the transaction total.
​

Refunds, chargebacks, and holds complicate it further. Each arrives on its own schedule, often in a different settlement batch from the original transaction, so the matching logic has to associate records across periods rather than within one. A refund issued in September against a payment taken in August will never reconcile inside a single monthly window.
​

Businesses operating across entities or currencies reconcile transfers between their own accounts. Foreign exchange movement between booking and settlement creates differences that are real rather than errors, and they need to be posted as FX gain or loss rather than chased as breaks.
​

The failure mode here is treating an FX difference as a matching failure. If the rule set has no concept of an acceptable variance band, every cross-currency transfer generates a break that a human closes manually with the same explanation each time. Encoding the variance treatment once converts a recurring queue into an automatic posting.
​

Businesses settling in stablecoins reconcile onchain transfers against their ledger. The record here is a blockchain transaction rather than a bank file, which changes the timing profile but not the underlying requirement. Eco covers this pattern in its daily reconciliation workflow guide.
​

Onchain records remove the wait for a settlement file, since the transaction is queryable the moment it confirms. What they add is a finality question. A transfer that is visible is not necessarily final, and a reconciliation process that matches on visibility rather than on confirmation depth will occasionally clear a transaction that later reorganizes. The rule needs a confirmation threshold, chosen per chain.
​

Automated reconciliation applies matching rules to both record sets programmatically and routes only the exceptions to a human. Manual reconciliation asks a person to compare records directly, usually in a spreadsheet. The difference is not effort alone, it is that manual matching cannot scale with transaction volume and cannot produce a consistent audit trail.
​

The decision usually comes down to how many distinct record sources a team carries. One bank and one processor is a spreadsheet problem. Four banks, three processors, two entities, and an onchain wallet is a systems problem, and no amount of discipline makes the spreadsheet version work.
​

Real-time settlement changes reconciliation from a periodic batch process into a continuous one. When value moves and confirms within seconds, the reconciliation window can close in seconds too, which removes the timing breaks that batch files create and shrinks the period during which a business does not know its true cash position.
​

The pressure is already visible in conventional rails. Same Day ACH volume grew 16.7% in 2025 to 1.45 billion payments worth $3.92 trillion, and the second quarter of 2026 saw 9.3 billion ACH payments worth $25.9 trillion. Faster settlement without faster reconciliation simply means the gap between money moving and books reflecting it gets more expensive.
​

Stablecoin settlement pushes this further because the settlement record and the reconciliation record are the same object. A blockchain transaction carries its own amount, timestamp, counterparty address, and finality state, so there is no separate settlement file to request and normalize. The stablecoin market stood at $311.0 billion in total supply as of September 9, 2026, led by USDT at $183.4 billion and USDC at $74.4 billion, according to DeFiLlama. For teams already running onchain treasury operations, that shared record removes a category of break rather than speeding up the search for it.
​

The caveat is that onchain records solve identity of the transfer, not identity of the invoice. A wallet address is not a customer reference. Businesses still need to attach structured remittance data to onchain payments, which is the same discipline ISO 20022 imposes on bank rails, and the same discipline that determines whether reconciliation is automatic or manual.
​

Break reduction comes from fixing the data at origination rather than matching harder downstream. Every break has a root cause in a missing reference, an unmodeled fee, or a timing assumption, and each of those is addressable at the point the payment is created rather than at the point it fails to match.
​

Structured remittance data is the highest leverage change. The ASC X9 standards body publishes a remittance market practices guide for exactly this purpose, advancing what it describes as a major benefit of ISO 20022, supporting automation and straight-through processing of remittance data. If the payment carries the invoice reference in a structured field, matching is deterministic. If it carries the reference in a free-text memo, matching is probabilistic.
​

Fee modeling is the second. Any source that nets fees before depositing needs its fee schedule represented in the matching rules, so the expected deposit is calculated rather than assumed. Third is cutoff discipline, meaning an explicit rule for which period a transaction belongs to, applied consistently across every source rather than decided per case.
​

The sequencing advice is to fix the largest single break category before buying tooling. Software applied to a feed that carries no invoice reference will not invent one, and teams that automate first frequently discover they have accelerated the production of the same exceptions. Identifying the top category, tracing it to the system that emits the record, and changing the payload there is unglamorous and usually removes more manual work than any matching engine.
​

What remains after those three is a genuine exception queue rather than a backlog of self-inflicted mismatches. Teams comparing tooling for this can start with Eco's rundown of settlement APIs with audit trails and reconciliation compared.
​

Reconciliation health is measured by how much of the work happens without a human. The core figures are auto-match rate, the share of transactions cleared by rules alone, break aging, meaning how long unmatched items sit open, and time to close, meaning how long after period end the books are final. Together they describe whether a process scales.
​

Auto-match rate is the headline number, but it is easy to flatter. A team can raise it by loosening tolerance bands until near misses clear automatically, which converts a visible break queue into invisible misallocation. Reading auto-match rate alongside the volume of post-close adjustments is what keeps that honest, because adjustments are where loosened tolerances eventually surface.
​

Break aging matters more than break count. A hundred breaks opened and cleared within a day is a functioning process. Ten breaks open for six weeks is an unresolved control problem, and it is the second pattern that auditors ask about. Aging also identifies which source system is generating the recurring failures, which is the input to fixing data at origination rather than matching harder.
​

Segment the numbers by source rather than reporting one blended rate. A blended 92% auto-match can hide a processor feed matching at 99% and an international wire feed matching at 40%. The blended figure looks healthy and the international queue is what actually consumes the team. Nacha's own reporting segments this way, breaking out categories such as 547.66 million healthcare claim payments worth $2.94 trillion in 2025 rather than reporting network totals alone.
​

Eco operates the routing and execution layer that stablecoin value moves through, which means the payment record and the settlement record originate in the same system rather than in two. For a finance team, that removes the step of requesting a settlement file from one provider and matching it against a ledger held somewhere else entirely.
​

The wider industry is moving the same direction on the messaging side. Swift closed the MT and ISO 20022 coexistence period for cross-border payments in November 2025, and describes the standard as enabling richer, better structured and more granular data end-to-end in payment messages.
​

That does not eliminate reconciliation, and it should not be sold as if it does. It removes one specific category of break, the kind caused by two systems disagreeing about what happened, while leaving the invoice-identity problem exactly where it was. Eco's coverage of multi-chain routing explains how that execution path is structured.
​

Methodology. ACH volume and value figures are from Nacha's published ACH Network statistics for full year 2025 and its second quarter 2026 release, retrieved September 9, 2026. Remittance data guidance is from the Federal Reserve payments improvement program, Swift ISO 20022 documentation, and the ASC X9 remittance market practices guide. Stablecoin supply figures are from DeFiLlama as of September 9, 2026, and move intraday. Every figure above is attributed to a named third-party source linked in the section where it appears.
​