Payment Reconciliation Automation: Where Matching Logic Breaks Down

Payment reconciliation automation is usually sold as a solved problem: connect the bank feed, match transactions against internal records, flag exceptions. In practice, most platforms find that the matching logic works cleanly for perhaps eighty per cent of transactions and then falls over on the rest. The failures are rarely random. They cluster around a small number of predictable gaps between how banking data is generated and how internal systems expect to receive it.

Understanding those gaps matters more than choosing a particular reconciliation tool. A well-built matching engine running against messy inputs will still produce a large exception queue. This article sets out where reconciliation logic typically breaks, and what to check before assuming the automation itself is at fault.

The reference field is not guaranteed

Most reconciliation logic is built around a simple assumption: the payer will include a reference, and that reference will survive the journey from initiation to bank statement line intact. This assumption holds reasonably well for domestic UK payments over Faster Payments, where the reference field is short but usually preserved end to end. It holds far less reliably for cross-border payments over SWIFT.

A SWIFT payment can pass through one or more intermediary banks before it reaches the beneficiary's account. Each intermediary applies its own message formatting rules, and some truncate, reformat or partially overwrite the remittance information field. A reference that was clean and structured at the point of initiation can arrive as a fragment, or padded with intermediary bank codes that were never part of the original text. Reconciliation logic that expects an exact string match against a reference will treat these as exceptions even though the payment is entirely legitimate.

The practical fix is to build matching logic that treats the reference as one signal among several, not the sole key. Amount, sender identifier, currency and expected settlement window should all contribute to a match score, with the reference used to increase confidence rather than as a binary pass or fail.

Statement formats are not standardised in the way people assume

Banks deliver transaction data in several different formats, and the choice of format affects what reconciliation logic can actually see. MT940 is a widely used SWIFT format for end-of-day statements, structured as fixed fields with limited space for narrative text. camt.053, the ISO 20022 equivalent, carries considerably more structured detail, including separate fields for remittance information, originator details and return codes. A platform that has built its matching logic against camt.053 fields and then receives MT940 files from a different account or provider will find that fields it relies on either don't exist or are compressed into a single narrative block that needs parsing differently.

This becomes a real issue for platforms operating GBP collection accounts and EUR IBAN issuance side by side, particularly where the accounts sit on different underlying infrastructure. Two accounts that look identical from a product perspective, each with a sort code and account number or an IBAN, can deliver statement data in structurally different ways. Reconciliation logic needs to normalise incoming data into a single internal schema before matching runs, rather than trying to write matching rules that cope with every source format directly.

Timing differences get misread as missing payments

Reconciliation exceptions often show up as "payment not received" when the payment has, in fact, been sent and is simply still in transit. Faster Payments typically settles within seconds. A SEPA credit transfer typically settles within one business day. A SWIFT cross-border payment can take several business days, particularly where correspondent banking relationships are involved or where currency conversion happens mid-route. If reconciliation logic expects all incoming payments to appear within a fixed window, cross-border transactions will regularly get flagged as missing before they've had a realistic chance to settle.

The fix here is to build expected settlement windows per payment type and rail, rather than applying a single timeout across all inbound flows. A payment initiated via SWIFT should be given a longer grace period before it enters the exception queue than one initiated via a domestic instant rail. Getting this wrong doesn't just create noise, it trains operations teams to distrust the exception queue, which defeats the purpose of automating in the first place.

Virtual accounts need their own matching layer

Platforms that allocate a virtual account or dedicated reference per customer, common in marketplace payouts and client money account structures, often assume that reconciliation becomes trivial because every incoming payment is already tagged to an individual. In practice, senders don't always use the exact virtual account details provided. They may pay to a shared collection account with a manually typed reference, or reuse an old reference from a previous transaction. Automated matching built purely around the virtual account identifier will misroute or fail to match these payments.

A more resilient design treats the virtual account identifier as the primary match key but keeps a secondary matching pass, using amount, timing and sender details, for anything that lands in the general collection account instead of the expected sub-account. This secondary pass is where most of the manual reconciliation effort tends to concentrate, and it's worth building deliberately rather than treating it as an afterthought.

Partial payments and batch settlements distort one-to-one matching

Reconciliation logic built around one-to-one matching, one payment record against one bank line, breaks down wherever payments are batched or split. A payer might settle three invoices with a single transfer. A card acquirer might deliver one net settlement figure covering hundreds of underlying transactions, with the detail available only in a separate settlement report. An API banking platform providing programmatic access to statement data will usually expose the raw transaction line, but reconciling it against internal records still requires logic capable of one-to-many and many-to-one matching, not just one-to-one.

Designing for exceptions rather than eliminating them

No reconciliation system, however well designed, reaches zero exceptions. Payment scheme membership rules, correspondent banking routes, and the sheer variety of ways senders fill in payment references mean that some proportion of transactions will always need a human to look at them. The realistic goal is to shrink that proportion and make the remaining exceptions easy to investigate, with enough contextual data attached, sender details, amount, timing, originating rail, that a person can resolve them quickly rather than starting from a blank transaction line.

Platforms building on fintech banking infrastructure that spans multiple currencies and rails should expect reconciliation logic to need ongoing tuning as payment volumes and payer behaviour shift, rather than treating it as something configured once and left alone.