James Allman / JA Technology Solutions LLC
2026-04-15
Understanding BAI2 Files: A Guide for Treasury and IT Teams
Everything you need to know about the banking industry's standard cash reporting format — from file structure to automation.
What Is BAI2 and Why Does It Matter?
BAI2 is a standardized file format for reporting bank account activity and balances to corporate customers. Developed by the Bank Administration Institute, it replaced the original BAI format in the late 1980s and has remained the dominant standard for electronic cash reporting in the United States ever since. If your organization receives transaction data from a bank, there is a strong chance BAI2 is involved somewhere in the process.
The format exists to solve a fundamental problem: businesses need a consistent, machine-readable way to know what happened in their bank accounts. Before standardized formats, every bank delivered data differently, forcing companies to build custom integrations for each banking relationship. BAI2 established a common language — a structured text file that any treasury system, ERP, or reconciliation tool can parse.
Despite being decades old, BAI2 remains deeply embedded in corporate banking infrastructure. Most major U.S. banks still deliver BAI2 files daily, and most treasury management systems and ERP platforms expect to consume them. Understanding how these files work is essential for anyone responsible for cash management, bank reconciliation, or the integrations that connect banking data to internal systems.
Where BAI2 Files Come From
Banks generate BAI2 files and deliver them to their corporate customers, typically on a daily basis. The files reflect the previous business day's account activity — deposits, withdrawals, fees, wire transfers, ACH transactions, and other movements — along with opening and closing balance information. Some banks also provide intraday BAI2 files for organizations that need real-time visibility into cash positions.
Delivery mechanisms vary. Historically, BAI2 files arrived via secure file transfer (SFTP) or were downloaded from a bank's corporate banking portal. Many organizations still retrieve them this way. Some banks offer API-based delivery or push files directly to a customer's infrastructure. Regardless of the transport method, the file format itself follows the same BAI2 specification.
If your organization banks with multiple institutions, you likely receive a separate BAI2 file from each one. This is where the standardized format pays off — your downstream systems can use the same parsing logic for every bank, even though each file comes from a different source.
The Hierarchical Structure
A BAI2 file is organized as a strict hierarchy with four levels: File, Group, Account, and Transaction. Understanding this hierarchy is the key to reading and parsing BAI2 data correctly. Every record in the file belongs to one of these levels, and they nest inside each other like containers.
At the top level, the File contains one or more Groups. Each Group typically represents a single bank or financial institution and contains one or more Accounts. Each Account represents a specific bank account and contains the balance and transaction detail for that account. Transactions are the individual line items — the deposits, debits, fees, and transfers that make up the day's activity.
This hierarchy means a single BAI2 file can carry data for multiple banks, multiple accounts, and hundreds or thousands of transactions. In practice, most files you receive from a single bank contain one Group with multiple Accounts. But the format is flexible enough to handle more complex arrangements when needed.
Record Types Explained
Every line in a BAI2 file begins with a two-digit record type code that identifies what kind of data it contains. There are only eight record types, and once you know what each one does, the file becomes surprisingly readable.
Record type 01 is the File Header. It appears once at the very beginning and identifies the sender, receiver, and creation date of the file. Record type 99 is the File Trailer, appearing once at the end, and it contains control totals for the entire file. These two records bookend everything else.
Record type 02 is the Group Header, marking the start of a bank's data, and record type 98 is the Group Trailer that closes it. Within a group, record type 03 is the Account Identifier, which opens an account's section and carries balance information — typically opening ledger balance, closing ledger balance, and closing available balance. Record type 49 is the Account Trailer that closes the account section.
Record type 16 is the Transaction Detail record, where the actual account activity lives. Each type 16 line describes a single transaction with its amount, type code, and optional reference information. Finally, record type 88 is the Continuation record, used when data for any other record type exceeds a single line.
Type Codes and What They Mean
Within the 03 (Account) and 16 (Transaction) records, three-digit type codes classify what kind of balance or transaction is being reported. These codes are defined in the BAI2 specification and provide a standardized vocabulary for bank activity.
For balances reported on the 03 record, you will commonly see codes like 010 (Opening Ledger Balance), 015 (Closing Ledger Balance), and 045 (Closing Available Balance). The distinction between ledger and available balances matters — ledger reflects posted transactions, while available accounts for holds and float.
For transactions on the 16 records, codes in the 100-399 range generally represent credits (money in), while codes in the 400-699 range represent debits (money out). For example, 115 is a lockbox deposit, 165 is a preauthorized ACH credit, 195 is an incoming wire transfer, 475 is a check paid, and 455 is a preauthorized ACH debit.
In practice, not every bank uses type codes the same way. Some banks map their internal transaction types to BAI2 codes more precisely than others. You may encounter miscellaneous codes far more often than expected, simply because the originating bank did not classify the transaction more specifically. This ambiguity is a reality you need to account for in any reconciliation logic.
How Organizations Use BAI2 Data
The most common use of BAI2 files is bank reconciliation — matching the transactions reported by the bank against the transactions recorded in your general ledger or accounts payable and receivable systems. This is a core accounting control, and BAI2 files provide the bank side of that equation.
Cash position reporting is another major use case. Treasury teams need to know how much cash is available across all accounts at the start of each business day to make funding, investment, and payment decisions. BAI2 files, especially intraday versions, feed this process.
Many organizations also feed BAI2 data into ERP systems like SAP, Oracle, or Microsoft Dynamics for automated posting. The BAI2 file becomes the source document for creating bank statement entries in the ERP, which then drive the reconciliation workflow within that system.
Common Problems and Format Variations
While BAI2 is a standard, it is a loosely enforced one. Banks interpret the specification differently, and the files you receive from one institution may have subtle differences from another.
Continuation records (type 88) are a frequent pain point. When a record's data exceeds the line length limit, the remainder spills into one or more 88 records. Your parser needs to correctly reassemble these continuations with their parent record.
Field formatting is another area of inconsistency. The BAI2 spec uses comma-delimited fields with slashes as record terminators, but some banks omit trailing slashes, use different line endings, or include unexpected whitespace. Amount fields should be unsigned integers, but occasionally you will encounter files with signed amounts or decimal points.
Perhaps the most frustrating issue is when a bank changes its BAI2 output format without notice. Robust BAI2 processing needs to handle these surprises gracefully rather than failing on the first unexpected input.
Working with BAI2 Files in Practice
If you need to inspect a BAI2 file manually, start by understanding that it is plain text. You can open it in any text editor. Each line starts with the record type code, and fields within a line are separated by commas.
For a faster approach, the free BAI2 Explorer on this site lets you drop in a BAI2 file and see its contents parsed into a readable, structured format. If you need to create test files for development or QA purposes, the BAI2 Generator tool lets you build valid BAI2 files with configurable accounts and transaction data.
When building or maintaining automated BAI2 processing, validation is critical. At a minimum, verify that control totals match, that every group and account has matching header and trailer records, and that continuation records are correctly reassembled.
Building Reliable BAI2 Automation
Manual handling of BAI2 files does not scale. Once your organization processes more than a handful of accounts or banks, the daily routine of downloading files, importing them, and investigating exceptions becomes a significant operational burden.
A well-designed BAI2 automation pipeline typically includes file retrieval (pulling files from bank SFTP servers on a schedule), parsing and validation (converting raw BAI2 into structured data with error checking), transformation (mapping bank data to your internal chart of accounts), and loading (posting the data into your ERP, TMS, or reconciliation platform).
The transformation step is where most of the business logic lives. Different banks may report similar transactions with different type codes, descriptions, or reference number formats. Your transformation layer needs to normalize these differences so downstream systems see consistent data regardless of which bank originated it.
Error handling deserves special attention. BAI2 files that fail to parse, contain unexpected data, or have control total mismatches need to trigger alerts and be routed for manual review without blocking the rest of the pipeline.
When to Bring in Help
If your team is spending significant time on BAI2-related manual work — downloading files, reformatting data, investigating reconciliation breaks, or maintaining fragile import scripts — it may be time to invest in a more robust solution.
This is the kind of integration work where experience with the format matters. Knowing the common bank variations, understanding the edge cases around continuation records and type codes, and having built parsers that handle real-world BAI2 files makes a significant difference in how quickly a solution comes together and how reliably it runs in production.
Whether you need a standalone BAI2 processing pipeline, integration with your existing ERP or treasury system, or a broader cash management automation strategy, this is a domain where practical expertise can save considerable time and frustration.