Home / Wiki / T / Transaction Reconciliation

Transaction Reconciliation

Financial InfrastructureUpdated 05 Nov 2026

Transaction reconciliation is the process of matching individual transactions recorded in one system with the corresponding transactions recorded in another, one record at a time, to confirm that each event appears in both places with the same amount, date and identity. It is the line-level form of reconciliation. Banks, payment companies, marketplaces, exchanges and corporate finance teams run it daily, often on millions of records, to find missing, duplicated or altered transactions.

It is the counterpart of balance reconciliation, which only checks that totals agree at a point in time. Two balances can agree while individual transactions are wrong, for example when a missing payment and a duplicate payment of the same size cancel out, which is why serious operations run both. Transaction matching is the engine behind bank reconciliation, payment reconciliation and settlement reconciliation.

01

Transaction reconciliation in plain terms

Imagine two people who each kept a list of the same trip's expenses. To check them, they go down both lists side by side, ticking off each item that appears on both: taxi 20, dinner 45, museum 15. Anything left unticked needs explaining. Perhaps one of them forgot the coffee, or wrote 54 instead of 45.

Transaction reconciliation is that ticking exercise done by software, at scale. Each record carries clues, such as an amount, a date and a reference number, that help pair it with its twin in the other list. The pairs are set aside, and the unmatched leftovers go to a person to investigate.

02

How matching works

A matching engine compares two data sets, for example an internal ledger export and a bank or processor file, using rules applied in order of strictness:

  1. Exact match on a unique key. A shared identifier, such as a payment ID, an ISO 20022 end-to-end ID, a SWIFT UETR or a card network reference number, is the strongest link.
  2. Match on several fields. Amount, currency, value date and counterparty must all agree when no shared key exists.
  3. Tolerance match. Small differences are allowed, such as a date one business day apart or an amount differing by a known fee or rounding.
  4. Grouped match. One record is matched to several (one-to-many), such as a single bank deposit covering many card sales, or several to several (many-to-many).

A simple measure of performance is the auto-match rate:

Auto-match rate=Nmatched automaticallyNtotal×100%\text{Auto-match rate} = \frac{N_{\text{matched automatically}}}{N_{\text{total}}} \times 100\%

Here Nmatched automaticallyN_{\text{matched automatically}} is the number of records paired by rules without human help and NtotalN_{\text{total}} is all records in the run. If 98,500 of 100,000 records match automatically, the rate is 98.5%, leaving 1,500 exceptions for review.

03

Exceptions and what causes them

ExceptionTypical cause
In our records, not theirsPayment not yet processed, rejected or lost; timing cut-off
In their records, not oursFee, chargeback or unexpected credit not yet booked
Amount mismatchFees deducted, FX conversion, partial payment, keying error
DuplicateRetry posted twice, file loaded twice

Exceptions are given an owner, a reason code and an age. Ageing reports show how long items have been open, and most firms escalate or write off items past a set number of days under an approved policy. Duplicates caused by retries are prevented upstream by designing payment calls with idempotency, so that the same instruction sent twice is processed once.

04

Uses in payments and finance

  • Card acquiring. Merchants and payment service providers match each authorised sale to its cleared record and then to the payout, catching sales that never settled.
  • Bank payment operations. Outgoing ACH, wire and instant payments are matched against acknowledgements and status reports from the payment system.
  • Remittances. Money transfer operators match each transfer sent with the payout partner's record of transfers paid.
  • Crypto. Exchanges and custodians match internal ledger entries with on-chain transactions identified by transaction hash and wallet address.
  • Securities. Brokers and custodians match trades with counterparties' confirmations and with depository records.
05

Data quality and tooling

Match rates depend mostly on data, not software. Structured references carried end to end, such as those in ISO 20022 messages, raise rates sharply; free-text references typed by customers lower them. Firms ingest files from banks, processors and partners through a reconciliation API or file transfer, normalise formats, and run the rules in reconciliation software, an ERP module or in-house code. When data passes through several systems in sequence, matching is often chained, as described under multi-step reconciliation. Results ultimately support the account-level sign-off in account reconciliation and help detect payment fraud and processing faults early.

Last updated 05 Nov 2026