OFX, QBO, QFX, QIF or IIF: Which Bank File Format Do You Need?

You have a bank statement and a piece of accounting software, and between them sits a file extension you did not choose. Your bank offers OFX. QuickBooks Desktop wants QBO. Quicken rejects the QBO and asks for QFX. An old Microsoft Money archive is sitting in QIF. Somebody on a forum told you to use IIF. They are not interchangeable, and the fastest route to an answer starts from your software, not from the file you happen to be holding.

Start with the software you import into

One pattern runs through it. Desktop-era software wants a structured banking file, because it was built around a direct bank connection and file import is the fallback for it. Cloud accounting prefers CSV, because upload is the manual escape hatch from a live feed and the importer is deliberately forgiving.

The family tree

OFX (Open Financial Exchange) is the base: an SGML document wrapping a list of <STMTTRN> blocks, each holding a posting date, an amount, a transaction type and a description. Everything else here is either a dialect of OFX or an older format unrelated to it.

QBO is OFX plus an Intuit block: the same statement body with an <INTU.BID> financial institution identifier added inside the sign-on response. QuickBooks Desktop checks for that tag before treating the file as a Web Connect download, which is why a valid OFX sometimes imports and sometimes throws "QuickBooks is unable to verify the Financial Institution Information for this Download."

QFX is the Quicken dialect. Same OFX body, but Quicken expects an Intuit branding identifier that banks pay to license, plus an <INTU.USERID> field. That is why free converters produce OFX, QBO and QIF but not QFX.

QIF (Quicken Interchange Format) is unrelated to any of them, older and much simpler: plain text, one field per line, each starting with a letter code. D is the date, T the amount, P the payee, M the memo, and a bare ^ ends the record. No account identifiers, no transaction IDs, no currency. That simplicity is why it survives in GnuCash, Moneydance, MoneyMoney and Banktivity, and why Quicken now restricts QIF import to cash, asset and liability accounts.

IIF (Intuit Interchange Format) is tab-delimited text for bulk loading QuickBooks Desktop lists and register entries, not a bank statement format. A !TRNS header row declares the column order, then each transaction is a TRNS line, a balancing SPL line with the opposite sign, and an ENDTRNS line. It writes straight into the register without passing through Bank Feeds, so nothing is matched or reviewed.

CSV is not a banking standard at all, just a spreadsheet of Date, Description, Amount and sometimes Balance. It carries no metadata, which is why every importer accepts it and every importer makes you map the columns by hand.

Why renaming the extension does not work

CSV renamed to .qbo or .ofx. QuickBooks looks at the first bytes for OFXHEADER:100, finds Date,Description,Amount, and rejects the file as not a valid Web Connect file.

OFX renamed to .qbo. The closest to working and the most frustrating. The body parses fine, but with no <INTU.BID> tag QuickBooks will not associate the file with a financial institution. You need the tag inserted, not the name changed.

QFX renamed to .qbo. The Intuit block is there but branded for Quicken, so QuickBooks reads an identifier it does not accept. A QBO renamed to .qfx fails Quicken's check for the same reason in reverse.

QIF renamed to .qfx or .qbo. No shared syntax at all. A QIF has no angle brackets and no header block, so the parser fails on the first line.

IIF renamed to .csv. It opens, which is the trap. Excel drops the tab-delimited data into column A, and even after splitting it, every transaction occupies three rows whose balancing split carries the opposite sign, so summing the amount column gives zero.

Converting means reading transactions out of one structure and writing them into another. ConvertFin does that in your browser, detecting the real format from the file contents rather than the extension, which matters because banks routinely hand out an OFX named .qbo.

The three things that break imports regardless of format

Wrong sign on debits. Many banks print withdrawals and deposits in two unsigned columns, so a converter reading "42.00" from each imports your rent payment as income. Headings do not settle it, since "Debit" means money out at one bank and money in at another. The one source that cannot be misread is the running balance: if it moved from 1,240.00 to 1,198.00, that row is negative whatever the heading says. ConvertFin takes the sign from that difference, then tells you on screen whether the statement reconciles.

Ambiguous dates. 06/09/2026 is the 6th of September in London and the 9th of June in Chicago, and a statement sometimes changes style across a page break. Structured formats are explicit: OFX and QBO write <DTPOSTED> as a fixed-width YYYYMMDD, so nothing is left to interpret once written. The risk sits entirely at conversion time. ConvertFin reads slash and dash dates as US month-first unless the first field is 13 or higher, where it can only be a day, and dotted dates like 31.12.2026 as European day-first. Check the first and last preview rows against your statement before downloading.

Duplicate transaction IDs. Every <STMTTRN> block carries a <FITID>, and QuickBooks and Quicken both use it to decide whether they have seen a transaction before. Emit the same FITID twice and the second row is dropped silently, which you discover at reconciliation when the closing balance is short by exactly one coffee. Two identical 4.50 charges to one merchant on one day are common, so uniqueness needs more than date plus amount. ConvertFin builds the FITID from the date, the row position and the amount in cents, keeping every row distinct even when the transactions are not.

When CSV is genuinely the better answer

Reach for a structured file when your software has no CSV path at all. QuickBooks Desktop is the main case: it has no bank-transaction CSV import, so QBO or IIF is the only way in. Everywhere else, CSV is usually the better answer.

QuickBooks Online imports CSV natively under Transactions → Bank transactions → Upload from file, where the mapping screen lets you say which column is which, including whether you have one signed amount column or a separate debit and credit pair. Xero takes a CSV under Business → Bank accounts → Manage Account → Import a Statement. Wave, FreshBooks and Zoho Books do the same.

CSV is also the only one of these you can inspect and fix. A QBO or OFX is consumed whole, so misread dates mean undoing the whole imported batch. A CSV opens in a spreadsheet, where you sort by date, scan for a missing year and correct one cell before uploading. On a client file you are seeing for the first time, that review beats the convenience of a structured import.

One caveat: CSV carries no transaction IDs, so nothing can deduplicate it against an existing bank feed. If a live feed already covers part of the period, import only the range it does not.

Start here

From a PDF statement: convert to CSV for cloud accounting, QBO for QuickBooks Desktop, OFX for GnuCash or Banktivity, QIF for Quicken, MoneyMoney and Moneydance.

From a CSV your bank gave you: CSV to QBO for Web Connect, CSV to QIF for Quicken and GnuCash, CSV to IIF for a direct register import.

Holding a file you cannot open: QBO to CSV also reads .ofx and .qfx, QIF to CSV or QIF to Excel for old Quicken and Microsoft Money archives, IIF to CSV for QuickBooks Desktop exports.

Migrating between packages: QIF to QBO moves Quicken history into QuickBooks Desktop. The full matrix is at /convert, and what a QBO file actually is goes deeper on that one format.