Banks send account data in a dozen shapes: BAI2 for balance reporting, MT940 and camt.053 for statements, NACHA for ACH payments, OFX and QFX for accounting software, and a PDF when nothing else is offered. Upload whichever one you were given and BankXLSX turns it into the same clean spreadsheet rows. Start free, no credit card.
Upload your bank statement
Drop file here or click to upload
PDF, JPG, PNG, BMP, HEIC, TIFF, MT940
Uploading...
Every one of these formats was designed for software to read, in a different decade, by a different standards body. That history is why the file your bank sent will not simply open as a table.
Balance reporting arrives as BAI2 in North America and MT940 or camt.053 elsewhere, and most portals give you no say in which one you can download.
BAI2 and NACHA are positional text, MT940 is tag based text, camt.053 is XML. Excel opens all of them and understands none of them.
BAI2 and NACHA store whole cents with the decimal implied, while MT940 uses a comma as the decimal separator. Each one totals wrong if you import it raw.
BAI2 overflows long text onto continuation records and MT940 compresses the counterparty, reference, and description into the free text of tag 86.
A single BAI2 or NACHA file can carry dozens of accounts or batches stacked together, so pulling out the one you need by hand is slow and error prone.
Plenty of US banks, and most credit unions, still offer smaller business customers nothing but a PDF statement.
Rather than a separate tool per format, BankXLSX reads the structure of whichever file you upload and writes the same predictable columns out the other side.
BAI and BAI2, MT940 and MT942, camt.052 and camt.053, NACHA ACH files, OFX and QFX, plus PDF and scanned statements.
Whatever went in, you get date, description, amount, debit, credit, and balance in the same shape, so your downstream template never changes.
Implied decimals restored, comma decimals converted, and signs resolved from the type or transaction code so your totals tie out.
Multi account and multi batch files are separated so you can work one account at a time.
Download XLSX or CSV, or map straight to QBO, OFX, QIF, and IIF for QuickBooks, Quicken, and Sage.
256-bit encryption on upload, no reselling of your data, and you can delete your files whenever you want.
No software to install and no credit card to start.
Open the file in a text editor. Numbered records mean BAI2, colon tags mean MT940, angle brackets mean camt.053, and 94 character lines mean NACHA.
Tip: The table below tells them apart.
Drag the file into the box above. Rename it to .txt first if it has an unusual extension like .bai or .ach.
Tip: Renaming never changes the data.
Save as XLSX or CSV, then check your totals against the control records or closing balance in the original file.
Tip: Matching totals prove nothing was dropped.
The people dealing with raw bank files are usually managing cash across several banks, closing the books, or loading another system that will not accept what the bank sent.
Build a daily cash position from files that arrive in three different formats from three different banks.
Reconcile bank activity to the ledger using opening and closing balances lifted straight from the file.
Test and map bank files during a NetSuite, SAP, Business Central, or treasury system implementation.
Turn whatever a client forwards, usually a PDF, into rows you can categorize and import.
Get a complete, tie-out-able transaction population rather than a stack of statements.
Inspect real bank files while building an integration, without writing a parser first.
The fastest way to identify a bank file is to open it in a plain text editor and look at the first few lines. Each format has a signature you cannot mistake once you have seen it. This table covers the formats US finance teams actually receive, what each one is for, and how to recognize it.
| Format | What it is | How to recognize it | Typically used for |
|---|---|---|---|
| BAI2 | North American cash management balance reporting, from the Bank Administration Institute. | Plain text lines starting 01, 02, 03, 16, 49, 88, 98, 99. | Daily balance and transaction reporting to US corporates. |
| MT940 | SWIFT end of day customer statement message. | Text lines beginning with colon tags such as :20:, :60F:, :61:, :62F:. | Final daily statements, common outside the US. |
| MT942 | SWIFT interim transaction report. | Same colon tag style as MT940, but intraday and without a final closing balance. | Intraday cash positioning during the day. |
| camt.053 | ISO 20022 XML bank to customer statement. | XML opening with a Document tag and nesting under BkToCstmrStmt. | The modern replacement for MT940. |
| camt.052 | ISO 20022 XML intraday account report. | XML nesting under BkToCstmrAcctRpt. | The ISO 20022 equivalent of MT942. |
| NACHA | ACH payment file, not a statement. | Every line exactly 94 characters, starting with 1, 5, 6, 7, 8, or 9. | Payroll, vendor payments, and collections. |
| OFX and QFX | Open Financial Exchange, the download format for finance software. | Tagged text with OFX headers. QFX is the Quicken branded variant. | Importing into Quicken and other accounting software. |
| QBO | The QuickBooks flavor of OFX. | OFX style tags with a QuickBooks intuit identifier. | Importing into QuickBooks. |
| PDF statement | The human readable monthly statement. | Opens in any PDF reader. | The official record lenders and auditors accept. |
This trips people up constantly, so it is worth stating plainly. BAI2, MT940, MT942, camt.052, camt.053, OFX, and QBO are statement or reporting files: they tell you what happened to an account. A NACHA file is a payment instruction file: it tells the bank what to do. If you are reconciling, you want a statement file. If you are verifying payroll or vendor payments before release, you want the ACH file. They are not interchangeable, and a NACHA file will never contain a closing balance.
Each format fails in Excel for its own reason, and knowing which failure you are looking at saves a lot of time. BAI2 and NACHA are fixed position text with no delimiters, so every line lands in one column, and both store amounts as whole cents with the decimal implied. A $1,250.00 payment reads as 125000. MT940 is tag based rather than columnar, its records run across several lines, and it uses a comma as the decimal separator with six digit YYMMDD dates. camt.053 is valid XML, so Excel can technically load it, but the nesting means one transaction spreads across many elements and the resulting sheet is unusable without flattening. And in every one of these formats, Excel strips the leading zeros off routing and account numbers or converts them to scientific notation, which quietly corrupts them.
Yes, gradually. camt.053 is the ISO 20022 XML statement that carries the same information as MT940 in named XML elements rather than positional tags, which is why banks and ERPs have been migrating toward it. In SWIFT's own mapping, MT940 and MT950 correspond to camt.053, MT942 corresponds to camt.052, and MT900 and MT910 correspond to camt.054. The practical difference is reconciliation: MT940 compresses the counterparty, payment reference, and description into the free text of tag 86, so your ERP has to parse it with pattern matching, while camt.053 gives remittance information, the transaction code, and the credit or debit indicator their own dedicated fields. Most US treasury teams still receive a mix, so plan to handle both for a while yet. For a fuller comparison see our guide on camt.053 versus MT940 and on choosing between MT940, BAI2, and camt.053.
If you get a choice and the destination is a spreadsheet or a smaller accounting package, ask for CSV or BAI2, because both are the least work to turn into rows. If the destination is an ERP with a proper bank statement importer, camt.053 carries the most structured detail and will need the least mapping maintenance over time. MT940 is a reasonable middle ground and is often all a European bank offers. Take the PDF when it is the only option, or when you specifically need the official statement a lender, auditor, or underwriter will accept, since a raw data file is not that document.
Each format has its own converter page with the record structures and code tables spelled out. Start with the BAI to Excel converter for BAI2 balance reporting, the MT940 to Excel converter for SWIFT statements including MT942, the camt.053 to Excel converter for ISO 20022 XML, or the NACHA file to Excel converter for ACH payment files. Working from a PDF instead? Use the PDF bank statement to Excel converter or the main bank statement converter. Going the other way, into software, map the output through the OFX converter, the QuickBooks QBO format, or the QIF converter. If what you are holding is already one of those software files and you need it back out as rows, the OFX to CSV converter reads .ofx and .qfx and the QBO to CSV converter reads QuickBooks Web Connect files, both in the browser. Enterprise teams loading an ERP can go straight to the NetSuite, SAP, or Business Central converter pages, and bank statement reconciliation covers the tie-out once the data is in.
Converting is usually the middle step, not the last one. If the destination is QuickBooks Online, a CSV to QBO converter turns the exported file into something QuickBooks will accept. Teams that need board-ready reports from the converted data can build them with an AI financial statement generator, and finance teams processing other document types at volume can extract them with enterprise document OCR.
The common ones are BAI2 for North American balance reporting, MT940 and MT942 for SWIFT statements, camt.053 and camt.052 for ISO 20022 XML, OFX, QFX, and QBO for accounting software imports, CSV for spreadsheets, and the PDF statement itself. NACHA files also come from banks but carry ACH payments rather than statement data.
Open it in a text editor. Lines starting 01, 02, 03, and 16 mean BAI2. Colon tags like :20: and :61: mean MT940 or MT942. Angle brackets and a Document element mean camt.053. Lines of exactly 94 characters starting with 1, 5, and 6 mean a NACHA ACH file.
They do the same job in different regions. BAI2 is the North American balance reporting standard built from numbered records, while MT940 is the SWIFT end of day statement message built from colon tags and used more widely outside the US. Both carry an opening balance, transactions, and a closing balance.
MT940 is the end of day customer statement, a final record of a completed banking day with a closing balance. MT942 is an interim transaction report sent during the day so treasury teams can see activity as it happens. MT942 is provisional and does not close the day out.
No. A NACHA file is an ACH payment instruction file that tells a bank which payments to make, so it contains entries but no balances. A bank statement file such as BAI2, MT940, or camt.053 reports what actually posted to your account, including opening and closing balances.
Excel will open both as text, but neither becomes a usable table. BAI2 lines all land in one column with amounts that have no decimal point, and MT940 records run across multiple lines with a comma as the decimal separator. Both need converting before the data is reliable.
camt.053 usually needs the least mapping maintenance because every field is named and the remittance information, transaction code, and credit or debit direction each have their own element. BAI2 is a solid North American alternative, and CSV is simplest when the ERP importer is flexible.
Upload the file to BankXLSX and download the result as XLSX or CSV. The converter identifies the format, restores implied or comma decimals, keeps routing and account numbers as text, and writes one row per transaction. Check your totals against the control records or closing balance to confirm nothing was dropped.
Convert BAI and BAI2 balance reporting files.
Convert SWIFT MT940 and MT942 statements.
Convert ISO 20022 camt.053 XML statements.
Convert NACHA ACH payment files.
From the same family of tools
Get started converting bank statements to spreadsheets.
USD
per month
billed as
$288 yearly
Choose speed vs accuracy when extracting
| Base AI Faster | 2,500 pages |
| Pro AI Best accuracy | 500 pages |
Scale statement conversion across your team with automation.
USD
per month
billed as
$888 yearly
Choose speed vs accuracy when extracting
| Base AI Faster | 10,000 pages |
| Pro AI Best accuracy | 2,000 pages |
Enterprise-grade bank statement conversion and controls.
USD
per month
billed as
$ yearly
Choose speed vs accuracy when extracting
| Base AI Faster | pages |
| Pro AI Best accuracy | pages |
