James Allman | JA Technology Solutions LLC
Understanding OFX and QFX Bank Statement Files
Banks export all your accounts into one file. Most accounting and ERP systems import one cash account at a time. Here is what is inside an OFX or QFX file, and why splitting it by account is the step that keeps your books accurate.
When a bank's online portal offers a "Download transactions" button, the file it produces is almost always OFX or QFX. OFX stands for Open Financial Exchange, a format developed in the late 1990s by Microsoft, Intuit, and CheckFree to standardize how financial institutions share transaction data with software. QFX is Intuit's branded variant, used by Quicken; the internal structure is identical to OFX for practical purposes. The same file format that drives Quicken imports on a home PC also drives bank reconciliation in mid-market ERP systems.
Both formats carry the same core payload: one or more bank account statements, each with an account identifier, a routing number, a date range, opening and closing balances, and a list of transactions. The transaction list is what accounting teams care about. The account and balance header is what trips up imports when the file contains more than one account.
Two flavors: SGML and XML
OFX exists in two structurally different encodings. The original format, from the 1990s, uses SGML: tag-like identifiers without closing tags, no attribute quoting, and header fields separated by colons. A transaction block opens with <STMTTRN> and fields like <TRNAMT>-1250.00 just sit there, with no matching </TRNAMT> to close them. Standard XML parsers reject this without preprocessing.
Starting with OFX 2.0, the format moved to proper XML, with closing tags, quoted attributes, and an XML declaration at the top. Most bank portals now offer the XML variant when you choose OFX explicitly, but older portals, certain payroll services, and legacy accounting software connectors still generate SGML-style files. The OFX/QFX Explorer handles both automatically, detecting the format from the file header and routing to the appropriate parser.
What is inside a statement block
Each account in an OFX file is wrapped in a statement response element: STMTRS for bank and checking accounts, CCSTMTRS for credit cards. Inside that wrapper, the BANKACCTFROM element carries three fields: BANKID (the ABA routing number), ACCTID (the account number), and ACCTTYPE (CHECKING, SAVINGS, or MONEYMRKT). These three together uniquely identify the account in your ERP or accounting system's chart of accounts.
Below the account identifier sits the date range covered by the statement (DTSTART and DTEND), then the transaction list wrapped in BANKTRANLIST, then closing balances: LEDGERBAL for the posted balance and AVAILBAL for the available balance. Each transaction in the list is a STMTTRN element carrying the transaction type (TRNTYPE: CREDIT, DEBIT, INT, DIV, FEE, SRVCHG, DEP, ATM, POS, XFER, CHECK, PAYMENT, CASH, DIRECTDEP, DIRECTDEBIT), the posting date, the amount (negative for debits), a unique transaction ID (FITID), a check number if applicable, the payee name (NAME), and a memo field.
The multi-account problem
Here is the problem that sends people searching for a file parser in the first place. Banks frequently export all of a company's accounts into one OFX or QFX file. A company with three checking accounts, a savings account, and a money market account gets one download with five STMTRS blocks inside it.
Most accounting and ERP systems, including Acumatica, QuickBooks, and similar mid-market platforms, import bank transactions one cash account at a time. The import dialog expects a file scoped to a single account and maps it to a specific general ledger cash account. When a multi-account file arrives instead, the system may import only the first account, may reject the file entirely, or may pool transactions across accounts in ways that are difficult to untangle later.
The fix is to split the file before import: one clean OFX file per account, each containing only its STMTRS block and a valid OFX envelope. The OFX/QFX Explorer reads the combined file, displays each account separately, and lets you download a clean single-account OFX for each one. The split preserves the original header and statement block exactly, so the per-account file passes the same format validation the bank's original would.
When automated bank feeds fall short
Automated bank feeds, delivered through aggregators like Plaid or MX, are the preferred route for high-volume reconciliation: transactions arrive in the accounting system daily, with no manual download step. But automated feeds break more often than their marketing suggests. Banks that require multi-factor authentication on every session, institutions outside the US and Canada, and banks that force password resets without warning all interrupt aggregator connections in ways that can take days to restore.
SFTP-based BAI2 feeds (described in detail in the companion article Understanding BAI2 Files) are more reliable for larger treasury operations, but they require a formal bank enrollment and are not available from every institution. When either route is unavailable or has failed, the manual fallback is a bank portal export in OFX or CSV format. Getting that export into the ERP correctly, including splitting multi-account files, is what keeps the books current while the automated feed is being restored.
For organizations that run multiple banks, or that acquire entities with different banking relationships, the manual export path stays relevant indefinitely. Knowing the file format well enough to inspect and fix a download before it reaches the import dialog saves the reconciliation work of cleaning up a bad import.
Reading an OFX or QFX file yourself
The OFX/QFX Explorer handles both SGML and XML variants and works on multi-account files. Drop in the file and it shows each account separately under its routing number, account number, and account type, with the date range and balances, then a sortable transaction table. Credits and debits are color-coded. The combined CSV and Excel exports add an account-number column so you can reconcile across accounts in a spreadsheet. The single-account OFX download splits the file cleanly for systems that need it. Everything runs in the browser; the file never leaves your machine.
For other bank formats, the BAI2 File Explorer covers the BAI2 cash reporting format used by treasury and AP teams at larger organizations. The two formats serve different audiences: OFX and QFX are the download formats for general-purpose bank portals, while BAI2 is the structured feed format banks deliver to treasury management systems.
Automating what the portal makes manual
Downloading an OFX file every morning, splitting it by account, and importing each piece into the ERP is a workflow that works fine until it doesn't. The steps that fail are the ones no one notices until the reconciliation is late: the bank changed the portal login flow, the download arrived with an extra account, the import mapped to the wrong cash account, or the person who knew the process is out.
I build integrations that remove the manual steps: pulling transaction data from bank APIs or SFTP directories, normalizing across accounts and institutions, matching against ERP records, and posting results to the correct cash accounts automatically. For organizations processing data from several banks, the account-splitting logic that this article describes becomes part of the pipeline rather than a manual step before import. See integration services for how that work is shaped, or Ask James and describe how your bank reconciliation flows today.