Why two way reconciliation misses the interesting cases
Instruction against posting tells you the payment was booked. Settlement against posting tells you the money moved. Only the three way view tells you that a payment was instructed for one amount, settled net of a lifting fee, and posted at the instructed amount, which is the case that quietly creates a suspense balance nobody owns.
| Pair | What it proves | What it misses |
|---|---|---|
| Instruction to posting | The payment reached the ledger | Whether it actually settled, and for how much |
| Settlement to posting | The cash moved and was booked | Payments instructed but never settled |
| Instruction to settlement | The scheme did what was asked | Whether your books agree with either |
| All three | Where the difference is, and on which leg | Nothing, which is the point |
The break types payment operations actually sees
- Repairs: a payment held because a party field or reference was unusable. The volume of these is a direct cost, and it falls when structured data survives the journey.
- Returns and rejects: money coming back with a reason code that must be tied to the original instruction, not posted as a fresh credit.
- Partial settlement: a batch settled short. The settled leg matches, the residual stays open against the same reference.
- Lifting fees and charges: deducted at an intermediary, so the posted amount will never equal the instructed amount unless the fee is modelled.
- Duplicates: a re-presented instruction that posts twice. Caught on the ledger side before it becomes a customer call.
From a pacs.008 batch to a worked queue
Input
- Instructed · 2026-09-03 · E2E/2026090303 · 87,400.00 EUR · NORTHWIND LTD
- Posted · 2026-09-03 · 2026090303 · 87,375.00 EUR · NORTHWIND LTD
- Posted · 2026-08-30 · RTN/2026083011 · 31,240.00 EUR · RETURNED PAYMENT
Output
- Fee not accrued 25.00 EUR deducted in flight. Post the charge and add it to the standing accrual.
- Missing reference a return posted with no matching instruction, aged 4 days. Trace to the original, repair and re-present or reverse.
- Both routed to Payments Ops with the audit note written and the difference explained on the item.
A three way case, worked
Input
- Instruction: 2026-09-03 - PAY/90012 - 187,650.00 USD - KESTREL LOGISTICS
- Settlement: 2026-09-03 - pacs.008 leg - 187,650.00 USD - confirmed
- Ledger: 2026-09-03 - PAY/90012 - 187,650.00 USD, and 2026-08-30 - PAY/90012/R - 187,650.00 USD
Output
- Instruction and settlement agree, so a two way match reports success.
- The ledger holds a second posting against the same reference, four days earlier.
- Duplicate posting raised, routed to Finance, reversal proposed under maker-checker with the original item noted.
Repairs, returns and investigations are one workflow
Payment operations teams usually run these as three separate activities with three sets of records, and they are the same shape of work: an item that cannot complete without a decision, an owner, an age and a required evidence set. Running them in one worklist has an effect that is easy to underestimate, because it makes the connection between them visible. A repair that rewrote a reference is frequently the reason a reconciliation break appeared two days later, and when both are items in the same system the link is obvious rather than discovered.
US domestic payments follow the same three way logic with a different clock. ACH settles in FedACH windows and returns can arrive days or, for unauthorized consumer entries, weeks after the original, so the entry, the settlement and the return all have to be tied together. That workflow has its own page: ACH reconciliation software for banks and credit unions.
| Item type | Aged from | Required evidence | Typical owner |
|---|---|---|---|
| Repair | The moment the payment stopped | The field that failed and the corrected value | Payment operations |
| Return | The original settlement date | Coded reason tied to the original message | Payment operations |
| Investigation | The date the query was raised | Identifier quoted, correspondent response | Payment operations, escalating to the relationship |
| Reconciliation break | The value date | Both sides, the computed difference and the action | Treasury, payments or finance by classification |
Repair rate is the number worth managing
A repair costs an analyst a few minutes and it costs the reconciliation far more, because a repaired payment often continues with a changed reference and stops matching automatically at the far end. Measuring repairs by the field that caused them turns a vague quality complaint into a short list of fixable causes. In most banks the list is dominated by two or three items, usually a party field populated as free text, a reference format from one channel, or a purpose code that arrives empty. Each of those is a fix in one place rather than a permanent operational cost.
Card and scheme settlement is the same engine with different vocabulary
Card and ATM settlement files use their own layouts, their own fee structures and their own netting, and they are still a reconciliation between an external record and core postings. The differences that matter are that fees are frequently interchange and scheme charges that must be modelled rather than tolerated, and that netting means the settled amount rarely equals the sum of the transactions. A reconciliation that models the netting and accrues the fees turns what looks like a permanent difference into a matched position, which is why a card settlement account is often the second thing a bank automates after nostro.
Receivables collected through a lockbox service reconcile on the same engine, with the deposit report on one side and the depository account on the other. The exception population there is described in lockbox automation.
The ISO 20022 dividend is real, and it is here
Structured remittance information, proper party fields and an end to end id that survives the chain are what make automatic matching possible on payments. That is why ISO 20022 payment automation and payment reconciliation are the same project in most banks, and why a migration deadline is often what finally funds the reconciliation work.
Questions about payment reconciliation software
Does this cover card and ATM settlement?
Yes. Scheme settlement files and ATM network files are supported sources, reconciled against the settlement account postings, with interchange and scheme fees modelled rather than left to surface as amount differences. The card sample in the resolver shows exactly that case.
Can we reconcile instant payments?
Instant rails produce more frequent, smaller files and a shorter tolerance for open items, which the engine handles by running the same matching more often rather than differently. What changes is the aging thresholds you set.
How do returns get tied back to the original?
By the original end to end id where it survives, and by amount, party and date matching where it does not. An unmatched return becomes an investigation item rather than an unexplained credit.
Does it produce the numbers for our repair rate?
Break counts by classification over time are exportable, so repair and return volumes become a measured series rather than an anecdote. What those numbers say about your bank is your data, not our claim.