QBO files: INTU.BID, FITID, and why imports fail
A .qbo file is OFX 1.02 with two Intuit-specific quirks bolted on. Both of them cause the two complaints people actually have. Everything below is read out of this converter’s own exporter, src/export/qbo.ts — not from another converter’s marketing page.
QuickBooks labels my import with the wrong bank
Because of one number. A .qbo file carries an <INTU.BID> element, and QuickBooks validates it against Intuit's registry of banks that hold a Web Connect agreement. An arbitrary id is rejected, so every converter ships a registered one as its default — and the common default, 3000, belongs to Wells Fargo. That is why a Chase statement can import under a Wells Fargo label.
It is cosmetic. The id decides the institution name and logo shown during import. It does not decide where the transactions land — you still choose the actual QuickBooks account in the import dialog. A mislabelled file is confusing, not wrong.
This converter defaults to 3000 for the same reason everyone does, says so on the page rather than hiding it, and lets you replace it: the QBO bank id field next to the download buttons, ?intuBid= on the API, or --intu-bid on the CLI. To find your bank's id, open a .qbo that your bank generated itself and read the <INTU.BID> line — that is the authoritative source, and the only one we will point you at.
I converted the statement again and nothing imported
That is <FITID> doing its job. Every transaction carries a financial-institution transaction id, and QuickBooks remembers the ones it has already seen for an account — permanently. A transaction whose FITID was imported before is skipped in silence. That is what stops a re-import from duplicating your register.
So the id has to be stable across exports of the same statement, and unique within one. Here it is sha1(accountId | date | amountCents | first 48 characters of the description), truncated to 24 hex characters, with a -1, -2 counter appended when a statement genuinely lists the same transaction twice on the same day.
The consequence worth knowing: the id is derived from the transaction, so if you correct an amount before exporting, that row's FITID changes and QuickBooks treats it as a new transaction. Correct first, import once.
The fields that decide whether the file opens at all
| Element | What it does | What this converter writes |
|---|---|---|
INTU.BID | Institution id; must be one Intuit recognises | 3000 unless you override it |
FITID | Per-transaction id; deduplicates re-imports | sha1 of the transaction, stable |
BANKID | Routing number | 000000000 unless you override it |
ACCTTYPE | CHECKING / SAVINGS / MONEYMRKT / CREDITLINE | your pick; drives the message set |
DTSTART / DTEND | Range the transaction list covers | widened to span every row in the file |
TRNAMT | Signed amount | negative for money out |
Source: src/export/qbo.ts.
A credit card is not a bank account
OFX puts card statements in a different message set: <CREDITCARDMSGSRSV1> with <CCACCTFROM>, not <BANKMSGSRSV1> with <BANKACCTFROM>. Export a card statement as Checking and QuickBooks offers to import it into a bank account. Choosing Credit card switches the whole envelope, not just a label.
DTSTART and DTEND can silently drop rows
An importer is entitled to ignore transactions dated outside the declared range, and statements routinely list a row that posted a day before the period started. This converter widens the range to cover every transaction actually in the file — a bug we found and fixed rather than a feature.
The file looks malformed to an XML validator
It is supposed to. OFX 1.02 is SGML, not XML: leaf elements have no closing tag, so <TRNAMT>-84.97 ends at the newline. A validator that expects </TRNAMT> is reading the wrong specification. The header block above <OFX> is likewise plain key–value lines.
Accents come out flattened
The header declares ENCODING:USASCII, so the body has to actually be ASCII. Accented Latin characters are transliterated (Zürich → Zurich); anything with no ASCII equivalent becomes ?. Payee names are also capped at 32 characters — the OFX limit for <NAME> — with the full description written into <MEMO>, which is where the rest of a truncated description went.
QuickBooks Online also takes CSV — a different animal
The .qbo file is for QuickBooks Desktop's Web Connect. QuickBooks Online's manual upload takes CSV instead, and it accepts exactly two layouts: three columns (Date, Description, Amount, money out negative) or four (Date, Description, Credit, Debit). Two things about it surprise everyone:
- The 4-column direction is inverted. Intuit's own instruction is to put payments under
Creditand deposits underDebit— the ledger's view of the account, not the bank's. Files built the "obvious" way import with every sign reversed, and the import succeeds, so nobody notices until reconciliation. - Uploads are capped at 1,000 rows and 350 KB. A longer statement has to be split into parts, each with its own header row.
This converter's CSV export has a QuickBooks Online preset that emits both layouts with Intuit's direction, drops the columns QuickBooks would choke on, and splits long statements into importable parts automatically.
What this page will not tell you
Which INTU.BID belongs to your specific bank. Published lists circulate, they are unofficial, and a wrong id produces exactly the confusion this page exists to explain. Read it out of a .qbo your own bank issued.