ISO 20022 gave payments richer data. Reconciliation still has to use it

The migration is done

Two of the largest payment systems changed their message format in 2025. The Federal Reserve moved the Fedwire Funds Service to ISO 20022 in a single-day implementation on 14 July 2025, retiring its proprietary format.¹ Swift ended the period in which cross-border payment instructions could be sent in either the old MT format or ISO 20022 on 22 November 2025. ISO 20022 is now required for all payment instructions on the network.^2,3

For banks, the project was a messaging change. For the finance teams of their customers, it is a data opportunity that has mostly not been taken up.

Volume keeps rising

Reconciliation workload grows with the number of payments, not their value. Nacha reports that the ACH Network carried 35.2 billion payments in 2025, up nearly 5 percent, with a value of $93 trillion. Business-to-business payments grew almost 10 percent to about 8.1 billion, and Same Day ACH reached 1.4 billion payments.⁴

Each of those payments has to be matched to an invoice, an order or a ledger entry by someone. Where matching fails, a person investigates, and the cost of that investigation does not fall as volume rises.

Why matching breaks

Payment reconciliation rarely fails for novel reasons. The same causes recur across processors, banks and industries.

Netted fees

A processor settles the day’s sales minus fees, reserves and adjustments, so the bank credit matches no single invoice or batch total.

Timing

Cut-off times, weekends and time zones put the same transaction in different periods in the gateway, the bank statement and the ledger.

Refunds and chargebacks

Reversals arrive weeks later, often netted against new sales, and must be traced back to the original payment.

Currency conversion

Rates applied at authorization, settlement and booking differ, leaving small residual amounts that need a rule or a person.

Missing references

The invoice number or customer reference was truncated or never captured, so the payment can only be matched by amount and date.

Richer messages address the last item directly and help with the others. ISO 20022 can carry structured remittance information, ultimate debtor and creditor details, and charges as separate fields, rather than squeezing them into a short free-text line.

Where the data gets lost

The structured data reaches the bank. Whether it reaches the reconciliation process depends on every system in between. Bank portals and statement files may still export older formats. ERP bank-statement imports often map only the amount, date and a single reference field. Matching rules written for those fields ignore anything else.

The structured data reaches the bank. Whether it reaches reconciliation depends on every system in between.

The practical work is therefore unglamorous: requesting camt statement formats from the bank, extending the import to keep remittance and party fields, and rewriting matching rules to use them before falling back to amount and date. None of it requires a model. Deterministic matching on a reliable reference is faster, cheaper and easier to audit than any probabilistic approach.

Five tests for a reconciliation process

1. 1Structured data kept end to endRemittance, party and charge fields survive from the bank file into the ledger, rather than being dropped at import.
2. 2A source of truth for each fieldFor amount, date, fees and reference, it is written down which system wins when sources disagree.
3. 3Versioned matching rulesRules are kept in code or configuration with a change history, so a match can be explained months later.
4. 4Exceptions classed and ownedEach break is assigned a known cause and an owner, and the volume by cause is reported every period.
5. 5Evidence attached to the matchThe documents and decisions behind a manual match are stored with it, not in an email thread.