Reconciling multi-country payments. 7 chapters and a final quiz.

Chapter 1. One canonical model, two statements: camt.053 and BAI2.

A company operating in 10 countries doesn't receive 10 comparable statements. It gets ISO 20022 XML from its German bank, BAI2 from its US bank, CNAB 240 from its Brazilian bank, and CFONB120 from its French bank: four grammars for saying that an account was credited. The temptation is to build one reconciliation engine per country, and within five years that choice costs more than any other. The approach that holds up separates two layers. On one side sit parsers, one per format, which all produce the same object, a canonical entry. On the other sits an engine that knows only that canonical entry. Adding a country then means writing a parser, not reworking the business rules. Here are the fields the canonical entry must carry.

• Normalized account identifier: the IBAN where one exists, otherwise the (bank code, account number) pair plus the country
• Account currency, in ISO 4217, never inferred from the country
• Amount in minor units, as a signed integer: the sign comes from a format-specific rule, not from the generic parser
• Explicit direction (credit or debit), redundant with the sign and checked against it
• Booking date and value date: two separate fields, never merged
• The original transaction code, kept as is, plus an internal canonical family (incoming transfer, direct debit, fee, reject…)
• Bank reference: the identifier the bank can trace if there is a dispute
• Originator reference (EndToEndId, customer reference, or Nosso Número, depending on the format)
• Full raw description, not truncated, not normalized
• Source file hash and line number, to get back to the evidence in a single query

camt.053 is the ISO 20022 end-of-day statement. Its strength lies in three things that fixed-position formats can't carry: a currency attached to every amount, two separate dates, and a standardized transaction classification. Its weakness is its flexibility. Two banks can produce camt.053 files that are both valid and yet different, because each one decides what it actually structures and what it leaves as free text.

<Ntry>
  <Amt Ccy="EUR">12500.00</Amt>
  <CdtDbtInd>CRDT</CdtDbtInd>
  <BookgDt><Dt>2026-07-10</Dt></BookgDt>
  <ValDt><Dt>2026-07-13</Dt></ValDt>
  <AcctSvcrRef>0004512</AcctSvcrRef>
  <BkTxCd>
    <Domn>
      <Cd>PMNT</Cd>
      <Fmly><Cd>RCDT</Cd><SubFmlyCd>ESCT</SubFmlyCd></Fmly>
    </Domn>
  </BkTxCd>
  <NtryDtls>
    <TxDtls>
      <Refs><EndToEndId>ADYEN-SETTLEMENT-2026-BATCH42</EndToEndId></Refs>
    </TxDtls>
  </NtryDtls>
</Ntry>

• With `Amt` and its `Ccy` attribute, the currency belongs to the amount, not to the account. A multicurrency account carries entries in different currencies.
• `CdtDbtInd` is either CRDT or DBIT. The amount itself is always positive: converting it into a signed integer is the parser's job.
• `BookgDt` and `ValDt` show, in this example, booking on Friday the 10th and value on Monday the 13th. For treasury, that's a three-day gap.
• `BkTxCd` holds three levels drawn from the ISO 20022 external code lists: domain PMNT, family RCDT (received credit transfer), and subfamily ESCT. This is the field that lets you route an entry without reading the description.
• `AcctSvcrRef` and `EndToEndId` give the reference the bank will be able to trace and the one the originator set. The second is the real key for automated matching.

# Lines starting with # are annotations; they are not in the real file.
# 01 file header: sender, receiver, date, time, ID, version 2
01,BANKUS33,ACMECORP,260710,0800,001,,,2/
# 02 group header: as-of date of the report and group currency
02,ACMECORP,BANKUS33,1,260710,,USD,/
# 03 account + balances: type code 010 = opening balance, in CENTS
03,0012345678,USD,010,15234025,,/
# 16 transaction: type code 142 = ACH credit received; funds type Z = availability unknown
16,142,1250000,Z,0004512,PAYOUT-BATCH-42,ADYEN SETTLEMENT/
# 49 account trailer: control total = sum of the 03 and 16 amounts, then line count
49,16484025,3/
# 98 group trailer: total, number of accounts, number of lines in the group
98,16484025,1,5/
# 99 file trailer: total, number of groups, number of lines in the file
99,16484025,1,7/

Chapter 2. CNAB 240 and CFONB120: fixed-position files.

Brazil and France share one family of formats and nothing else: fixed-length records where only position matters. Shift one character and the rest of the line goes wrong without raising a single error. Here, the balance check from the previous chapter is the only real protection.

CNAB 240, whose version 10.11 dates from August 21, 2023, is published by FEBRABAN, the Brazilian Federation of Banks, not by the regulator. A file holds 240-position records organized into batches, one batch per service and per paying account. A single file can therefore mix a batch of transfers and a batch of boletos.

The file that matters for reconciliation is the retorno de cobrança, the return file the bank sends back for the boletos issued. Two segments carry everything an accountant is looking for. Segment T identifies the bill and its return movement code, which says whether the boleto was paid, rejected, or written off. Segment U carries the amounts.

• Segment T: bill identification (Nosso Número on the bank side, Seu Número on the company side), return movement code, occurrence reason, and the bank fee (tarifa)
• Segment U: amount paid, net amount credited, interest and discounts applied, occurrence date, and the actual credit date
• The credit date is not the payment date: the payer pays the boleto one day, and the money reaches the account one or more days later
• The amount paid is not the amount billed: late-payment interest, early-payment discounts, and the tarifa widen the gap

CFONB120: overpunch and what it means for a multi-country setup

CFONB120 lines up 120-character records: a 01 for the previous balance, 04s for transactions, 05s for supplementary details, and a 07 for the new balance. The encyclopedia guide maps them position by position. Only one point matters for a multi-country engine: the last character of the amount encodes both a digit and the sign, a legacy of punch cards. { means +0, } means −0, A through I mean +1 to +9, and J through R mean −1 to −9.

Chapter 3. Acquirer files and their discrepancies.

The bank statement shows one line, a transfer from the acquirer, that covers thousands of transactions, refunds, chargebacks, and six families of fees. The settlement report is the document that explains how you get from one to the other. Without it, the bank line can't be substantiated, and the audit trail stops at the net amount.

Large acquirers publish the structure of these reports, starting with Adyen's settlement details report, which has 24 columns, including Gross Currency, Gross Credit (GC), Exchange Rate, Net Currency, and Net Credit (NC). Four of them isolate costs: Commission, Markup, Scheme Fees, and Interchange. At Stripe, the Payout reconciliation report exists only for accounts on automatic payouts, and the Balance report includes the automatic_payout_id and automatic_payout_effective_at columns, the latter expressed in UTC.

The six discrepancies you see everywhere

Settlement reports with a published structureAdyenStripeWorldline

Chapter 4. Value dates, time zones, and cutoffs.

Multi-country reconciliation rarely fails on amounts. It fails on dates. A single transaction carries four different dates, each correct in its own system, and an accountant who picks one at random creates month-end open items. The discipline is to name all four and decide which one sets the window.

• Never match on equal dates. An identical reference makes a match; a date serves as a tolerance window, calibrated by corridor
• Store the time in UTC and the original time zone separately. Adyen publishes a TimeZone column next to the creation date, and Stripe expresses automatic_payout_effective_at in UTC
• Know the cutoff time of every acquirer and every bank, in its own time zone: it decides which side of a month-end an evening sale falls on
• Keep a business-day calendar for each country, including local holidays. A transfer sent the day before a long weekend in India doesn't arrive on a European schedule
• Recognize revenue on the transaction date, never on the settlement date, or you'll shift revenue from one fiscal year to another

This example spans five calendar days and three distinct reference dates. Revenue belongs to Friday the 10th, while bank matching happens on Tuesday the 14th and treasury counts the funds on Wednesday the 15th. Three correct dates, three different uses.

Chapter 5. Mobile money: three records, no bank line.

In much of sub-Saharan Africa and South Asia, as in some Central American corridors, payments don't land in a bank account. They land in an e-money account held by an operator and tied to a shortcode. The money stays there until the company triggers a transfer to its bank. No bank statement describes the day's sales.

The operational consequence is direct: reconciliation runs across three records, not two. It compares the log of notifications received by the merchant system, the operator's platform statement, and the bank credit from the periodic transfer. All three must balance separately.

• The operator's transaction ID is the unique key. The M-PESA C2B notification carries it as TransID, along with TransAmount, BusinessShortCode, and the TransTime timestamp
• The order reference is entered by the customer, in the BillRefNumber field on a biller-type number. It is wrong in a significant share of cases, so fuzzy matching is mandatory
• Notifications get lost and get repeated. Delivery isn't guaranteed to happen once: deduplicate on the identifier, then query the transaction status API when in doubt
• The payer's number may be masked, depending on how the service is configured: don't build your matching on it
• The merchant account float is a separate asset, to be tracked like a cash drawer: Mobile Money Limited, a subsidiary of MTN Ghana, reports GHS 38.4 billion in float for 2025 alone (MTN Ghana results, March 2026)

Chapter 6. Multicurrency and FX.

Selling in 10 currencies and reporting in one requires two conversions at two different moments. The first is performed by the acquirer or the bank, at its own rate, at settlement. The second is an accounting conversion: it translates the transaction into the presentation currency of the financial statements. Confusing the two creates an FX difference that looks like an operating loss.

IAS 21, the IASB standard on the effects of changes in foreign exchange rates, sets the accounting framework. A foreign-currency transaction is recorded at the spot rate on the transaction date. At the closing date, monetary items (receivables, payables, cash) are remeasured at the closing rate. Nonmonetary items measured at historical cost stay at their original rate. The resulting differences go to profit or loss.

• Store three values, never one: the amount in the transaction currency, the amount in the settlement currency, and the rate that links them
• Never recompute a rate from the ratio of two rounded amounts: rounding hides fees and produces a false rate
• Set the rounding rule once and for all, and document it. A half-cent resolved differently by two systems creates one-cent discrepancies per transaction, invisible one at a time and massive across a million
• Isolate the acquirer's FX markup: derive it by comparing the report's rate with a reference rate for the same day, and negotiate it like a fee
• Treat conversion imposed on the cardholder (dynamic currency conversion) as a separate line: it changes the gross amount without changing the sale

That leaves nonconvertible currencies and those subject to exchange controls, where funds collected locally can't leave the country freely. The receivable exists, and so does the collection, but repatriation doesn't. Track these balances in a dedicated account, country by country, with their aging.

Chapter 7. Automating without losing the audit trail.

Automated reconciliation fails in two opposite ways. Too cautious, it leaves a queue of open items that no one works. Too permissive, it matches lines that have nothing to do with each other and produces books that are wrong but balanced. The way out is a cascade of named rules, ordered from safest to riskiest, each one logging what it did.

References that survive the journey

• ISO 20022 `EndToEndId`, set by the originator and passed on to the payee when the chain preserves it
• Swift UETR, a unique end-to-end identifier in UUID version 4 format, mandatory in field 121 of the user header for all Swift users since November 18, 2018
• ISO 11649 structured creditor reference: the prefix RF, two check digits calculated with MOD 97-10, then up to 21 free-form characters. The check catches a typo before it enters the engine
• Pix `EndToEndId`, 32 characters mandated by the Banco Central do Brasil: E, the agent's 8-digit ISPB, a yyyyMMddHHmm timestamp in UTC, then 11 sequence characters
• Acquirer batch identifier, present both in the report and in the transfer description; it's the linchpin of the settlement level

• The source file is never modified. It is kept exactly as received, with its cryptographic hash and date of receipt
• A matching rule never writes off a difference. Creating an adjusting entry to make a discrepancy disappear is an accounting decision, subject to a threshold and separate approval
• Open items age, and they get counted. An aging report by country and by acquirer, reviewed weekly, keeps the queue from becoming a graveyard
• Measure the auto-match rate by corridor, not globally: a good worldwide figure always hides a country that no longer balances
• Test every new rule against historical data before activating it, and measure its effect on the false-match rate, not just on the match rate

One last trade-off comes up in every project: a single engine deployed across all countries, or a tool chosen subsidiary by subsidiary. The single engine wins as soon as the same customers pay in several countries, because a refund then crosses accounting boundaries. A local tool still has its place when a country imposes its own reporting format. The two share the canonical model, which is common everywhere and specific nowhere.