How to convert a bank statement to OFX (2026)
Turn PDF or CSV bank statements into a clean OFX file Sage, Quicken, and other accounting apps accept, with the field rules most converters skip.
OFX (Open Financial Exchange) is the format Sage, Quicken, MoneyDance, GnuCash, and a long tail of older or specialty accounting apps rely on for bank imports. If your bank does not offer a native OFX download, and many do not, you have to build one from a PDF or CSV statement. This guide walks through what an OFX file actually contains, how to convert PDF and CSV statements into it cleanly, the fields that decide whether an import succeeds, and how to categorize transactions before the upload so nothing lands in the wrong ledger.
What an OFX file actually is
OFX is a plain-text financial exchange format published by Intuit, Microsoft, and CheckFree. Versions 1.x use an SGML style and versions 2.x are valid XML. A minimal OFX file contains a signon message, an account block, and a list of statement transactions. Each transaction carries a unique ID (the FITID), a posted date, an amount, a type such as DEBIT or CREDIT, and a memo. The receiving app uses the account block to map the file to the right ledger and uses FITID to dedupe against previously imported rows.
QBO, the Intuit-specific file QuickBooks uses, is a flavor of OFX with an extra header block. Sage, Quicken, and most non-QuickBooks tools want a standard OFX file instead. If you have been generating QBO and getting rejected by a non-Intuit app, an OFX file is what you actually need.
The four real ways to get an OFX file
1. Direct OFX download from your bank
The easiest path. Sign in to online banking, choose Download transactions, pick the OFX or Microsoft Money format, and upload the file to your accounting app. Coverage is thin outside the US and thin on credit-card issuers everywhere. If you do not see an OFX option, skip to the next section.
2. Convert CSV to OFX
If you can download a CSV of the same transactions, a CSV-to-OFX converter can wrap it in the OFX envelope your app expects. A reliable converter has to assign a unique FITID per transaction (usually a hash of date, amount, and memo), infer the transaction type from the sign of the amount, format dates as YYYYMMDDHHMMSS, and populate the account identifier so the receiving app maps the file to the right account. Skip any of these and you get duplicate transactions or a rejected file.
3. Convert PDF to OFX
The hardest case. You have to extract structured transactions from an unstructured PDF first and then wrap them in the OFX envelope. Generic PDF converters struggle with column boundaries, wrapped descriptions, running-balance columns, and scanned statements that need OCR. The wrapping step is straightforward once extraction is correct; getting the extraction right on a real bank PDF is the whole problem.
4. Extract, categorize, then export with Karchu
The workflow Karchu is built around splits the problem into two clean steps: parse and categorize with Karchu, then export the categorized transactions in an OFX-compatible format. Karchu handles extraction from PDF (digital or scanned), CSV, or Excel, applies your rule-based categorization so every transaction lands in the right account, and exports a clean file your accounting app can accept. That way the transactions Sage or Quicken receive already carry the account, memo, and payee your rules assigned, so the manual matching step inside the accounting app shrinks to a handful of edge cases.
The OFX fields that actually matter
- BANKID / ACCTID. Your bank routing number and account number. These identify which ledger the file belongs to.
- ACCTTYPE.
CHECKING,SAVINGS, orCREDITLINE. Must match the account type in your app. - DTSTART / DTEND. Statement date range in
YYYYMMDDHHMMSSformat. Wrong ordering causes silent row skipping. - FITID. Globally unique per-transaction ID. Reuse it and the transaction is silently ignored on re-import.
- TRNTYPE.
DEBITorCREDIT. Wrong sign puts every row in the wrong column. - DTPOSTED. Transaction date in
YYYYMMDDHHMMSSformat. - TRNAMT. Signed amount. Debits are negative in OFX.
- NAME / MEMO. Payee and description. What most apps show in the register.
OFX vs QBO vs QIF: which one do you need?
OFX is the neutral format Sage, Quicken, MoneyDance, and GnuCash accept. QBO is QuickBooks-only, an OFX file with an Intuit header. QIF is the older Quicken text format some legacy setups still require. If you are on QuickBooks, use QBO. If you are on Sage or modern Quicken, use OFX. If you are on a legacy Quicken workflow that refuses OFX, fall back to QIF.
Common OFX import errors
Most rejected OFX imports come down to a malformed header, missing required tags, duplicate FITID values, or the wrong ACCTTYPE. Open the file in a plain-text editor, check that the header is intact, that every transaction has a unique FITID, and that dates are in the YYYYMMDDHHMMSS format. If you are still stuck, generate a minimal one-transaction OFX and re-import: if that works, the issue is a specific row in your file, not the format.
Categorize before you export
The point of moving to OFX is not just to import rows; it is to import them into the right accounts. Karchu applies your categorization rules to every transaction before the export, so your accounting app receives clean, pre-categorized data instead of a flat list you have to code by hand. Rules run deterministically, so the same statement always produces the same category assignments, which matters for month-over-month reporting and audit trails.