Three of these four are the same underlying format wearing different extensions, and the fourth is older than any of them. Knowing which is which decides whether your import works, whether re-importing doubles your books, and whether you need a number you have never heard of.
The short answer
OFX is the base format. QBO and QFX are OFX with one extra tag that Intuit products check, one for QuickBooks and one for Quicken. QIF is an unrelated plain-text format from the Quicken of the early nineties, kept alive because almost everything still reads it. The table below is the whole comparison in one place; the rest of this post explains why each cell says what it says.
| OFX | QBO | QFX | QIF | |
|---|---|---|---|---|
| Structure | Tagged (SGML in 1.x, XML in 2.x) | OFX 1.x | OFX 1.x | One field per line, code letter first |
| Intuit bank ID (INTU.BID) | No | Yes, QuickBooks list | Yes, Quicken list | No |
| Transaction IDs (FITID) | Yes | Yes | Yes | No |
| Dates | YYYYMMDD, unambiguous | YYYYMMDD | YYYYMMDD | Order not stated in the file |
| Account and period | In the file | In the file | In the file | Account type only |
| Main readers | Xero, Sage, MYOB, Wave, Zoho Books, QuickBooks Online | QuickBooks Online and Desktop | Quicken | Quicken, Xero, MYOB, Sage, many others |
If you already know your software and just want the answer, the software pages list which format each accounting package accepts along with what goes wrong with each.
OFX is the one the others are made of
Open Financial Exchange is a specification for moving financial data between institutions and software, first published in 1997 by CheckFree, Intuit and Microsoft and now maintained by the Financial Data Exchange consortium. It carries a sign-on block saying who produced the file, an account, a statement period, a list of transactions, and closing balances. Everything else here is either OFX with something added or a much older format solving the same problem with less information.
It exists in two forms. Version 1.x is SGML: a block of colon-separated header lines, then tags, many of which are never closed. Version 2.x is proper XML and starts with an XML declaration and an OFX processing instruction. Both are valid OFX, and software that reads one will not necessarily read the other. Desktop accounting software, QuickBooks Desktop above all, expects the older 1.0.2 form.
OFXHEADER:100 <- version 1.x, SGML
DATA:OFXSGML
VERSION:102
CHARSET:1252
<?xml version="1.0" encoding="UTF-8"?> <- version 2.x, XML
<?OFX OFXHEADER="200" VERSION="220" ...?>What a transaction looks like in OFX, QBO and QFX
All three Intuit-adjacent formats describe a transaction the same way, inside a STMTTRN element. Five fields do nearly all the work, and they are identical whichever extension the file carries:
<STMTTRN>
<TRNTYPE>DEBIT type: DEBIT, CREDIT, CHECK, FEE, INT ...
<DTPOSTED>20260315 date posted, year first
<TRNAMT>-45.20 signed: negative is money out
<FITID>20260315-0001 unique ID, the duplicate-detection key
<NAME>SHELL OIL payee or description, short
<MEMO>CARD 1234 SHELL OIL 0412 LONDON
</STMTTRN>The FITID is the field that matters most in practice. QuickBooks and Quicken remember every FITID they have seen on an account and skip it next time, which is what makes re-importing an overlapping file harmless. QIF has no equivalent, and that single difference is the strongest reason to prefer the OFX family whenever your software offers it.
QBO and QFX are OFX plus a licence check
Both are Intuit variants. Structurally they are OFX 1.x with one extra tag in the sign-on block: INTU.BID, which identifies the financial institution the file came from. Intuit’s own partner documentation calls it a Branding ID and ties it to an institution’s Web Connect contract. QuickBooks and Quicken check that number against Intuit’s list of participating institutions and refuse the file if it is not there.
<SONRS>
<STATUS><CODE>0<SEVERITY>INFO</STATUS>
<DTSERVER>20260401120000
<LANGUAGE>ENG
<FI><ORG>Example Bank<FID>12345</FI>
<INTU.BID>12345 <- the tag Intuit checks
</SONRS>QBO is for QuickBooks and QFX is for Quicken. They are not interchangeable, and this catches people: the same bank usually has a different ID for each product, because QuickBooks and Quicken keep separate lists. Copying the number out of a QFX into a QBO, or renaming one extension to the other, produces a file that looks right and is rejected.
This is a commercial requirement, not a technical one
Nothing about the transactions needs a bank ID. The tag exists so that Intuit can tell whether the file came from an institution participating in Web Connect. That is why plain OFX, which carries the same data, needs no such number and is accepted by Xero, Sage, MYOB, Wave, Zoho Books and QuickBooks Online’s file upload.
QIF is the old one, and it is still useful
Quicken Interchange Format predates OFX and was never formally specified. It is line-oriented: the first character of each line is a field code, each transaction ends with a caret, and a header line beginning with an exclamation mark declares what kind of account the transactions belong to.
!Type:Bank account type header
D03/15/2026 date
T-45.20 amount, signed
PSHELL OIL payee
MCard purchase memo
LAuto:Fuel category
^ end of transaction
D03/16/2026
T1,250.00
PACME LTD
N1042 cheque or reference number
^| Code | Meaning |
|---|---|
| !Type:Bank / CCard / Cash / Oth A / Oth L / Invst | Account type for the transactions that follow |
| D | Date, in whatever order the writer chose |
| T (or U) | Amount, signed |
| P | Payee |
| M | Memo |
| N | Cheque or reference number |
| C | Cleared status (* or X) |
| L | Category, or [Account Name] for a transfer |
| S, E, $ | Split category, split memo, split amount |
| ^ | End of the transaction |
It has no institution, no transaction identifiers, no statement period, and no way to say which order its dates are in. That last one is a genuine hazard: 03/04/2026 is March in a US file and April in a UK one, and the reader decides. Older Quicken files also write years after 2000 with an apostrophe, as in 3/15’26, which some importers misread. But QIF has no bank ID requirement either, which makes it the format that imports when nothing else will.
Quicken’s own position on QIF has moved over the years. From around the 2005–2006 releases, Quicken for Windows stopped importing QIF into checking, savings and credit card accounts, steering people to QFX instead; a current Quicken help page says QIF can be imported into any existing account type. If you are on an older release, expect the restriction, and check your version’s help before relying on QIF for a bank account.
Which software reads which
The list below reflects what each vendor’s help currently documents for manual statement import. Where a package takes several, the first one listed is the one with the fewest ways to go wrong.
| Software | Best choice | Also accepted |
|---|---|---|
| QuickBooks Online | QBO | QFX, OFX, CSV (three or four columns), PDF or image upload |
| QuickBooks Desktop | QBO (Web Connect) | IIF, written straight to the register |
| Quicken | QFX | QIF, with restrictions that vary by version |
| Xero | OFX | QFX, QIF, QBO, CSV |
| MYOB Business | OFX | QIF (AccountRight desktop also takes QFX and OFC) |
| Sage Accounting | OFX | QIF, CSV, Excel |
| Wave | OFX | QBO, QFX, CSV |
| Zoho Books | OFX | QIF, CSV, TSV, CAMT.053, MT940 |
Choosing, in one pass
- QuickBooks Online or Desktop, and you can get your bank’s QuickBooks ID: QBO. You keep the banking feed and its duplicate detection.
- Quicken, with the bank’s Quicken ID: QFX. It is a different number from the QBO one at most banks.
- Xero, Sage, MYOB, Wave or Zoho Books: plain OFX. No bank ID, self-describing dates, no mapping step, and transaction IDs that let the importer spot repeats.
- QuickBooks Desktop and the bank is not in Web Connect: IIF, with the care that format needs.
- Nothing else worked, or the software only takes it: QIF. It imports almost anywhere, and you give up duplicate detection and date certainty.
- You want to look at the data before it goes anywhere: Excel, then CSV or OFX for the import itself.
The mistakes that cause most failed imports
- Renaming the extension. A .ofx renamed to .qbo still has no INTU.BID, and a .qbo renamed to .qfx carries the QuickBooks ID, not the Quicken one. The extension is a label; the contents decide.
- Borrowing a bank ID. A number from a forum post for a similarly named bank gets past the check only to attach your account to someone else’s institution.
- Feeding OFX 2.x to software that expects 1.x. The file is valid and is rejected anyway; it opens in a browser as a neat XML tree, which is the giveaway.
- Importing QIF with the wrong date order. Days above twelve are rejected, days below are silently swapped, so a partial failure means the accepted rows are suspect too.
- Re-importing a QIF that overlaps an earlier one. With no transaction IDs there is nothing to deduplicate on, and every repeated row lands twice.
What none of them carry
No category, in any useful sense. QIF has a category line and OFX has a type field, but neither maps onto your chart of accounts, and importers largely ignore them. Categorisation happens in your accounting software, against accounts it knows about, which is the right place for it.
Nor do any of them prove the transactions are complete. A file with a missing row imports exactly as cleanly as a full one. The only check that catches that is arithmetic against the statement itself: the opening balance plus every transaction should land on the closing balance the bank printed.