📊 Reconciliation and reporting around the world

Five statement families, five banking histories

A bank statement is the document in which a bank reports the transactions posted to an account, along with the opening and closing balances. Its structure varies by country, because each national banking tradition developed its own. A group operating in six markets therefore receives the same document in six different forms. European banks deliver ISO 20022 XML, US banks a fixed-position file, Brazilian banks 240-character records, and Japanese banks a 120-character file. All of them describe the same money movements, using different conventions for fields, encoding, and record layout.

The format determines what a matching engine can do with the data it receives. Four factors set that ceiling: the length of the reference carried, the presence of a standardized transaction code, a separate booking date and value date, and access to the detail of transactions grouped under a single aggregated entry. Each one is a piece of information the file either carries or does not. A format that is weak on these four points caps the auto-match rate, because no downstream processing can rebuild data that is missing at the source.

camt.053: convergence, and what it leaves unsolved

The camt (Cash Management) family covers the ISO 20022 messages used for account reporting. Three of them handle most use cases, each for a different need: tracking the intraday cash position, closing the accounting day, or itemizing the transactions behind an aggregated entry.

• `camt.052`, Bank to Customer Account Report: the intraday report, sent several times a day, with no guarantee of completeness. It supports cash management, not the close.
• `camt.053`, Bank to Customer Statement: the official end-of-day statement, including opening and closing balances. It is the document of record for reconciliation.
• `camt.054`, Bank to Customer Debit/Credit Notification: the transaction advice, often the only message that itemizes a batch shown as a single entry on the statement.

Several versions of the message coexist, and moving from one to another changes the tree structure that parsers expect, breaking integrations that did not plan for it. Older European deployments run on camt.053.001.02, while newer offerings deliver .001.08 and later, aligned with the recommendations of the CGI-MP group (Common Global Implementation – Market Practice). Its Working Group 2 publishes camt best practices through Swift. The tree structures are similar across versions but not identical, and the same version can be implemented differently from one bank to the next. Parser testing must therefore cover each version and bank combination you actually receive, not just compliance with the standard.

<Ntry>                                        <!-- one statement entry -->
  <Amt Ccy="EUR">14208.55</Amt>
  <CdtDbtInd>CRDT</CdtDbtInd>
  <BookgDt><Dt>2026-08-06</Dt></BookgDt>      <!-- booking date -->
  <ValDt><Dt>2026-08-07</Dt></ValDt>          <!-- value date: the one that matters for treasury -->
  <AcctSvcrRef>BNK2608061147</AcctSvcrRef>    <!-- bank reference -->
  <BkTxCd>
    <Domn><Cd>PMNT</Cd>                       <!-- domain: payments -->
      <Fmly><Cd>RCDT</Cd>                     <!-- family: received credit -->
        <SubFmlyCd>ESCT</SubFmlyCd></Fmly>    <!-- subfamily: SEPA credit transfer -->
    </Domn>
  </BkTxCd>
  <NtryDtls><TxDtls>                          <!-- detail under the aggregated entry -->
    <Refs><EndToEndId>PAYOUT-2026-08-06-000871</EndToEndId></Refs>
    <RmtInf><Ustrd>PSP BATCH 000871</Ustrd></RmtInf>
  </TxDtls></NtryDtls>
</Ntry>

The formats that won't migrate: BAI2, CNAB, Zengin

BAI2 (Cash Management Balance Reporting Specifications, Version 2) is the format US banks use to report account balances and transactions to corporate clients. It remains the most widely used bank-to-corporate statement format in the US, outside Europe's move to ISO 20022. It descends from a lockbox standard published in 1971. BAI1 came in 1980, the current version in 1987, and loan transaction codes in 2001. Ownership then changed when the Bank Administration Institute transferred the rights to the Accredited Standards Committee X9 in 2008. The record structure published in 1987 is still the one in use today.

01,SENDER,RECEIVER,260807,0730,1,,,2/      file header
02,RECEIVER,BANKID,1,260806,,USD,2/        group header (one date, one currency)
03,0001234567,USD,010,15250000,,/          account + opening balance (code 010), in cents
88,015,17310000,,/                         continuation: closing ledger balance (code 015)
88,045,16980000,,/                         continuation: closing available balance (code 045)
16,275,2500000,0,DEP0099,,VIREMENT PSP/    code in the 100-399 range = credit
16,475,1440000,0,CHK0451,,PAIEMENT FRNS/   code in the 400-699 range = debit (475 = check paid)
49,32050000,5/                             account total + record count
98,32050000,1,7/                           group total
99,32050000,1,9/                           file total

Reading a BAI2 file depends on two conventions, and ignoring them causes most integration errors. First, amounts are expressed in the currency's minor units, with no decimal separator. Second, the direction of a transaction comes from the range its type code falls in, not from the code on its own. Codes 010 to 099 carry balances, on record 03. Codes 100 to 399 are credits, 400 to 699 are debits, and codes above 900 are defined by each bank. Software can therefore rely on the range to determine direction, even though the precise meaning of a code varies from bank to bank.

Brazil has its own family of formats. FEBRABAN publishes the CNAB 240 Layout Padrão, in which statements for bank reconciliation are exchanged through segment E, which carries an entry category for each transaction. CNAB 400, a legacy of the 1980s, is still used by many billers for boleto submission and return files. A Brazilian integration therefore handles two generations of files at once, plus the business key that links them. That key is the Nosso Número, the boleto identifier assigned by the bank. In Japan, the Japanese Bankers Association's Zengin format uses four 120-character record types, identified by their first character. It carries no structured reference. The payer's only identifier is the name they typed, in katakana.

Acquirer files: why the net amount is what it is

An acquirer file itemizes the cleared transactions and the resulting amounts, on behalf of the card network or acquirer that produces it. These files follow scheme- and acquirer-specific formats that have nothing in common with bank statement formats. They carry the breakdown that a bank statement lacks, since the statement shows the amount that reached the account without saying what it is made of. Visa has historically cleared in Base II files, organized by transaction codes. A sale is a TC05, a credit a TC06. Mastercard uses IPM (Integrated Product Messages), in which a 1240 message carries a first presentment, a 1442 a chargeback, and a 1740 fees.

Settlement itself appears in a separate set of reports. VSS (VisaNet Settlement Service) reports are delivered as machine-readable TC46 records; TC47 is the human-readable version. The VSS-110 report contains the day's settlement summary, which an acquirer uses to reconcile its position. Merchants have no access to these files. They receive a settlement report from their PSP, which is derived from them. Reconciliation then means checking that report, line by line, against the credit received in the bank account.

The reconciliation key, rail by rail

The reconciliation key is the identifier that travels with a transaction from initiation to its entry on the statement and links the two records. Each rail produces one, and only one, that survives the whole journey. Its format, who creates it, and where it first appears vary from one system to another. The auto-match rate depends on that key being present in every source being reconciled, so identifying it is the first step in designing a payment acceptance setup.

Brazil's Pix uses two separate identifiers. The `EndToEndId` is a 32-character code generated by the payer's institution at initiation, built as E + the participant's ISPB + a timestamp + a sequence number. It is unique within the SPI and follows the transaction end to end, which makes it the natural deduplication key. The `txid`, by contrast, is chosen by the payee and returned with the payment. The Banco Central's rulebook explicitly assigns it the job of merchant-side reconciliation. The payee sets its own reference before collection and gets it back unchanged in the incoming message, with no manual rekeying.

Mexico relies on centralized proof of settlement rather than a reference carried by the merchant. For every SPEI transfer that the receiving bank has confirmed as credited, Banco de México issues a Comprobante Electrónico de Pago (CEP). The document shows the clave de rastreo, the banks, the accounts, and a digital seal, and can be downloaded as a PDF or as verifiable XML. High-volume businesses automate the download and check each reported credit against its CEP. The service is public. Most other markets have nothing like it.

Three dates per transaction, and none of them line up

Every transaction carries at least three dates. The transaction date is when the sale or purchase took place. The booking date is when the entry is posted to the account. The value date drives interest calculations and the cash actually available. Some markets add a fourth, the funds availability date, which is distinct from the other three. Reconciling on a different date from the one the other source uses creates a daily discrepancy. The next day's opposite discrepancy offsets it but never eliminates it.

In Brazil, receivables from payment arrangements, meaning what the acquirer owes the merchant before the payment date, are registered with entities licensed by the Banco Central. CERC, Núclea, B3, TAG, and CRDC are linked by an interoperability agreement published by the central bank. Brazilian merchants therefore have an official, legally enforceable record of their agenda de recebíveis (receivables schedule) that is independent of their acquirer. Reconciliation relies on this registry as much as on the bank statement, and no other large market has an equivalent.

Reconciling mobile money

Mobile money is a payment and transfer service built on an e-money account held with an operator and used from a mobile phone. It is the dominant rail in several dozen markets, and reconciling it follows different rules from a bank account. The money in circulation is e-money issued by the operator and backed by a safeguarding account, while the agent network handles conversion to and from cash. Three ledgers therefore coexist where a bank keeps only one.

These networks process more transactions than many card schemes. M-PESA in Kenya, run by Safaricom since 2007, processed 46.41 billion transactions in the fiscal year ended March 31, 2026. They were worth KES 41,680 billion, across 40 million monthly active customers. The distribution of transaction sizes is unusual. Free micro-transactions reached 17.1 billion, or 58% of activity. A matching engine calibrated on European ticket sizes therefore gets vastly more lines for the same revenue, and breaks down at that volume. MTN MoMo, for its part, reports 23.3 billion fintech transactions worth $500.3 billion in fiscal 2025.

Mobile money collection relies on a payment pushed by the payer to the merchant's account. The customer approves the payment to a Paybill or Till number; the merchant does not pull the funds. The notification arrives through an HTTP callback, with a TransID generated by the operator and a BillRefNumber typed by the customer on their phone keypad. That manual entry is the main source of unmatched items: one transposed digit in an invoice number makes the payment impossible to apply, even though the funds have arrived. The merchant wallet also separates the account that receives collections from the one that funds disbursements, called the Utility Account and the Working Account at Safaricom. Reconciliation therefore covers two separate balances for the same merchant.

Automating: reconciliation engine, virtual accounts, exception queue

Automating reconciliation involves two workstreams. The first makes transactions matchable upstream, through a key set before collection, a negotiated statement format, and virtual accounts. The second industrializes the handling of whatever the engine leaves unmatched. Nearly all organizations that achieve high auto-match rates fixed the source data before writing a single matching rule.

• Exact key matching. EndToEndId, txid, ARN, TransID, trace number. The only case where a match is proof rather than a presumption.
• Batch matching. The bank payout against the settlement report total, then the batch broken down into transactions. Essential whenever the bank aggregates.
• One to many. A customer transfer that pays eight invoices; it needs allocation logic, not a one-to-one match.
• Many to one. A split payment, an order paid in two installments, or a mobile money payment topped up by a second transfer.
• Controlled tolerance. A difference of a few units from FX conversion or rounding can be matched automatically, below a documented threshold and with logging. Without that log, the differences absorbed by the tolerance can no longer be counted after the fact, and internal control loses track of what was accepted without review.

Some rails carry no usable reference at all. Virtual accounts solve this with a banking setup rather than another matching rule. The bank assigns the merchant a range of account numbers, one per customer or contract, all linked to a single physical account. The payer sends funds to the number they were given, and the payment is applied based on the account credited, deterministically, however poor the statement format. This is the standard answer to the Zengin format in Japan, to BAI2 statements with no standardized reference, and to most Asian and African rails that route by account number.