BAI2 vs CAMT.053: Which Bank Statement Format Should You Ask Your Bank For?

Ask a US bank for an electronic bank statement and you will usually be offered BAI2. Ask a European bank and you will usually be offered CAMT.053. Both carry the same thing, the entries booked to an account for a period and the balances either side of them, but they are built on completely different assumptions. BAI2 is a compact flat text file designed in the 1970s and 1980s for cash management balance reporting. CAMT.053 is an ISO 20022 XML message designed decades later, when storage was cheap and structured remittance data mattered more than file size.

If you are configuring an ERP, negotiating a treasury service, or trying to work out why your reconciliation is missing payer detail, the choice matters. Here is the practical comparison.

What is the difference between BAI2 and CAMT.053?

BAI2 is a fixed structure flat text file built from numbered record types, where meaning comes from position and from a numeric type code. CAMT.053 is an XML document where every value sits inside a named element. The practical consequence is that BAI2 is smaller and faster to parse but carries less detail, while CAMT.053 is verbose but can carry structured remittance information, full party names, and multiple related references per transaction. BAI2 dominates in the United States, CAMT.053 in Europe and increasingly everywhere else.

How a BAI2 file is actually laid out

A BAI2 file reads as a hierarchy of paired records. Type 01 opens the file and type 99 closes it. Inside that, type 02 opens a group, usually one bank and one as of date, and type 98 closes it. Inside a group, type 03 opens an account with its currency and summary balances, and type 49 closes it with control totals. The transactions themselves are type 16 records, each carrying a BAI type code, an amount, a bank reference, a customer reference, and free text.

The type code is where the meaning lives. Codes in the 100 range are credits, codes in the 400 range are debits, and specific values identify wires, ACH entries, lockbox deposits, returned items, and fees. Two banks will not always pick the same code for the same event, which is the single most common reason a BAI2 mapping that worked at one bank needs rework at the next one.

How CAMT.053 is laid out

CAMT.053 wraps everything in a BkToCstmrStmt document. Inside it, each Stmt element is one statement for one account. Balances appear as Bal elements typed by code, with OPBD for opening booked and CLBD for closing booked being the two that matter for reconciliation. Transactions are Ntry elements, each with an amount, a credit or debit indicator, a booking date, a value date, a status, and a bank transaction code split into domain, family, and subfamily. Below that, NtryDtls and TxDtls can carry the debtor, the creditor, their accounts, the end to end identifier, and remittance information.

That extra depth is the entire argument for CAMT.053. If your receivables team is trying to match incoming payments to open invoices automatically, structured remittance data is worth far more than a compact file.

Which format should I ask my bank for?

If you operate only in the United States and your ERP reconciles on amount and date, ask for BAI2. Every large US bank supports it, your ERP almost certainly parses it out of the box, and it will be delivered without a project. If you operate across regions, or your matching depends on knowing who paid and what invoice they were paying, ask for CAMT.053 and accept the longer setup. If you are running both, standardize the downstream mapping rather than the upstream format, because banks will not all move at the same pace.

One warning. Ask what the bank actually populates, not what the schema permits. CAMT.053 allows rich structured remittance data, but a bank that receives a payment with nothing in the remittance field cannot invent one. A CAMT.053 file from a bank that fills only the mandatory elements gives you no more usable detail than BAI2 did, at several times the size.

Does CAMT.053 replace MT940?

Yes, that is its purpose. CAMT.053 is the ISO 20022 successor to the SWIFT MT940 prior day statement, and it also supersedes what BAI2 does in cash management balance reporting. MT940 is a flat text format built from positional tags such as 60F for the opening balance, 61 for each statement line, and 62F for the closing balance. Its main limitation is the 86 field, which crams counterparty and remittance detail into a handful of narrative lines that every bank fills differently.

Which ERPs read which format?

Most enterprise finance systems handle both, which takes format out of the decision more often than people expect. Oracle Fusion Cash Management ships with parsers for BAI2, SWIFT MT940, EDIFACT FINSTA, and the ISO 20022 camt.052 and camt.053 messages, and its import accepts .txt, .dat, .csv, .xml, and .ack extensions. Workday brings statements in through its Bank Statements connector, which supports BAI2 at version 2 and the ISO 20022 customer bank statement format. SAP, NetSuite, and Microsoft Dynamics all read BAI2 and camt.053 as well.

So the real constraint is rarely the ERP. It is whether the bank will transmit anything at all for that account. Balance reporting is a treasury product with a price attached, and coverage thins out fast as accounts get smaller. Regional banks, credit unions, and overseas subsidiary accounts frequently offer neither format, which leaves the monthly PDF as the only complete record. That gap is what the Oracle Fusion bank statement converter and the Workday bank statement converter pages deal with: getting the transactions into structured rows when no bank file exists behind the account.

Can I convert BAI2 or CAMT.053 into Excel?

Yes, and it is worth doing when you need to read a file rather than load it. A BAI2 file is human readable in principle and unreadable in practice, because meaning depends on knowing what each numeric type code means. Converting it into columns with the type codes resolved lets you check a control total or trace a single entry in seconds. The BAI to Excel converter handles the record types, and the CAMT.053 to Excel converter flattens the XML into rows. For a deeper walkthrough of the BAI2 structure, the record code and type code guide covers it field by field, and CAMT.053 vs MT940 compares the two flat and XML statement standards directly.

A practical migration order

Teams that move from BAI2 to CAMT.053 without pain tend to do it in the same order. Start by receiving both formats in parallel for one account for a full month, and reconcile them against each other rather than against the ledger. Map the bank transaction codes to your existing internal codes before you switch any matching rules. Then move one account, watch a full close, and only then roll the rest. What catches people out is not the parsing, it is the codes: the domain, family, and subfamily triplet does not map one to one onto the BAI type codes you spent years tuning.

And keep a manual path open. However good the automation gets, at some point an account will have no file, a transmission will fail on the last business day of the quarter, or an acquisition will arrive with two years of statements in PDF form. Being able to turn a PDF table into a spreadsheet is the difference between closing on time and explaining why you did not.