Electronic Bank Statement Formats

Electronic bank statements are machine-readable data files that banks deliver to enable automated reconciliation and cash application. Unlike PDF statements designed for human eyes, formats like BAI2, MT940, and ISO 20022 CAMT contain structured transaction data that accounting systems can parse, match, and post without manual intervention.

Choosing the right format—and knowing how to process it—directly impacts how quickly your finance team can close the books and apply cash to open invoices. This guide covers the major electronic bank statement formats, their structure and regional adoption, and how they fit into automated AR workflows.

What is an Electronic Bank Statement

What is an electronic bank statement and why does it matter for finance teams?

Electronic bank statements are standardized data files provided by financial institutions for automated reconciliation. The most common formats include BAI2 (predominant in the US), SWIFT MT940 (the global standard for end-of-day data), and ISO 20022 CAMT.053/054 (the modern XML standard). Unlike PDF statements designed for human reading, these machine-readable files contain structured transaction data that accounting systems can process automatically.

The key difference comes down to what happens after you receive the file. With a PDF, someone has to manually key each transaction into your accounting system. With an electronic bank statement, your ERP or billing platform can parse the file, extract transactions, and match them to open invoices without human intervention.

Common Electronic Bank Statement Formats

Several standard formats exist globally. The right choice depends on your geography, which banks you work with, and what your ERP or billing system supports. Most organizations end up using at least two formats when they have banking relationships across regions.

BAI2

BAI2 is the dominant electronic bank statement format in the United States, developed by the Bank Administration Institute. Nearly every US bank supports it, and most ERP systems can import BAI2 files natively.

MT940

MT940 is a SWIFT messaging standard used primarily in Europe and for international banking. It has been the go-to format for end-of-day account statements outside North America for decades, though it is gradually being replaced.

ISO 20022 CAMT

ISO 20022 is the modern XML-based global standard replacing legacy formats like MT940. The CAMT (Cash Management) messages within ISO 20022 offer richer, more structured data than older formats can provide.

MultiCash

MultiCash is a format popular in Germany and parts of Europe, consisting of paired header and transaction files. Many legacy ERP systems still support it, though it is being phased out in favor of ISO 20022.

OFX and regional variants

OFX (Open Financial Exchange) is commonly used for consumer and small business banking in North America. Other regional variants exist depending on local banking practices.

BAI2 Bank Statement Format Explained

How is a BAI2 file structured?

A BAI2 file follows a hierarchical record structure, with each line beginning with a two-digit code that identifies the record type. The file flows from headers down to transaction details and back up through trailers that contain control totals for validation.

The transaction type codes are what make BAI2 powerful for automation. For example, code 115 indicates a lockbox deposit, 475 represents an ACH credit, and 165 flags a preauthorized ACH credit. Your accounting system uses these codes to automatically categorize transactions and route them to the correct GL accounts.

MT940 Bank Statement Format Explained

What information does an MT940 message contain?

MT940 messages use a tag-based structure where each field begins with a colon followed by a number. The format includes both mandatory fields (like opening and closing balances) and optional fields for additional transaction details.

The :86: field is particularly important for cash application because it often contains the customer reference or invoice number. However, banks populate this field inconsistently, which can complicate automated matching.

ISO 20022 and CAMT Bank Statement Formats

What are CAMT messages and how do they differ from legacy formats?

CAMT (Cash Management) messages are the ISO 20022 standard for bank-to-customer reporting. Unlike the fixed-position fields in BAI2 or the tagged structure of MT940, CAMT uses XML with self-describing elements that can carry significantly more detail.

The XML structure means each data element is explicitly labeled, making parsing more reliable. CAMT messages also support extended remittance information, so you can include full invoice numbers, purchase order references, and structured creditor details that legacy formats simply cannot accommodate.

BAI2 vs MT940 vs ISO 20022 Format Comparison

Which electronic bank statement format is right for your organization?

The answer usually depends on where your banks are located and what your accounting systems support. Many organizations do not get to choose—they use whatever their banks provide.

If you are setting up new banking relationships, it is worth asking whether ISO 20022 is available. The richer data structure pays dividends in automated cash application accuracy.

How Electronic Bank Statements are Delivered and Imported

How do finance teams receive and process electronic bank statement files?

Getting bank data into your accounting system involves establishing connectivity, retrieving files on a schedule, validating the data, and loading transactions for processing.

Step 1. Establish bank reporting connectivity

Bank reporting connectivity refers to the technical link between your bank and your treasury or ERP system. Options include host-to-host connections via SFTP, the SWIFT network for larger organizations, or manual download from bank portals for smaller operations.

Step 2. Retrieve the statement file

Retrieval can be automated (files pushed to your server on a schedule) or manual (someone downloads from the bank portal). End-of-day statements typically arrive overnight, while intraday reports may be available multiple times per day.

Step 3. Validate and parse the file

Before loading transactions, your system validates the file against control totals, checking that record counts and amounts match the trailer records. Parsing then extracts individual transactions from the structured format into a usable data set.

Step 4. Load transactions into the ERP or billing system

The final step maps bank transaction codes to internal GL accounts or AR records. Billing platforms can ingest bank data to automatically match payments against open invoices and post the appropriate journal entries.

The Role of Electronic Bank Statements in Bank Reconciliation

How do electronic bank statements enable automated bank reconciliation?

Bank reconciliation is the process of matching bank transactions to internal accounting records, confirming that what the bank shows matches what your books show. Electronic formats make this process automatable rather than manual.

Matching deposits to open invoices

Deposit transactions from the statement are matched to outstanding AR invoices using remittance data, amounts, and customer identifiers. When a customer pays invoice #1234 for $5,000, the system finds the matching open invoice and applies the payment.

Identifying fees, chargebacks, and adjustments

Transaction type codes help categorize bank fees, returned payments, and chargebacks. A BAI2 code of 455 indicates a returned ACH item, which triggers different accounting treatment than a standard deposit.

Posting journal entries to the general ledger

Once transactions are matched and categorized, the system generates journal entries to update cash, AR, and expense accounts. Integrated billing systems automate this posting, eliminating manual journal entry creation.

How Electronic Bank Statements Power Cash Application and AR Automation

What is cash application and how do electronic bank statements improve it?

Cash application is the process of applying incoming payments to the correct customer invoices. When a customer sends a $15,000 wire transfer, someone has to figure out which invoices that payment covers. Structured remittance data in electronic statements enables automated matching, reducing manual research.

For recurring revenue businesses, this automation becomes critical as customer counts grow. A company with 500 customers paying monthly cannot afford to manually research each payment. Ordway’s AR automation capabilities leverage bank data to reconcile payments and post journal entries automatically.

Best Practices for Choosing an Electronic Bank Statement Format

1)Confirm bank and ERP support

Start by verifying which formats your banks can deliver and which formats your accounting or billing system can import natively. There is no point requesting ISO 20022 if your ERP cannot parse XML files.

2) Evaluate remittance data richness

Assess whether the format provides enough transaction detail for automated cash application. If your customers include invoice numbers in their payments, you want a format that captures and delivers that information.

3) Plan for ISO 20022 migration

SWIFT is deprecating MT940 messages as part of the broader migration to ISO 20022. If you are currently using MT940, start planning for the transition.

4) Standardize across multiple banks and entities

Where possible, use a single format across all banking relationships. Standardization simplifies processing logic and reduces the number of import configurations your team maintains.

Frequently Asked Questions about Electronic Bank Statement Formats