I'm building a small tool that converts bank CSV files into .qbo files for QuickBooks (qbofile.com). When a generated file is wrong, QuickBooks rejects it with vague errors and the OFX spec doesn't tell you what QuickBooks actually checks. So I ran some experiments. Notes below, in case someone else hits the same wall.
The file is not XML
.qbo is Intuit's version of OFX 1.0.2, which is SGML. Leaf tags have no closing tag:
<TRNAMT>-42.50
<FITID>8f3a2b...
Only aggregate tags close. The file also needs a 9-line key:value header, then one blank line, then the body. Line endings are CRLF. My first bug was closing every tag like XML.
"Missing bid data" means one tag: INTU.BID
QuickBooks checks <INTU.BID> against an internal list of banks that pay Intuit for Web Connect. I tested three variants on QuickBooks Desktop for Mac 2024:
| Variant | Result |
|---|---|
No <FI> block, no <INTU.BID>
|
Rejected: "Missing bid data" |
Only <INTU.BID>
|
Accepted |
<FI> block + <INTU.BID>
|
Accepted |
So the whole <FI> block (bank name, org id) can be dropped, but INTU.BID cannot. I have only tested the Mac version. If you know whether Windows versions behave the same, I'd like to hear.
FITID decides duplicates
QuickBooks dedupes on FITID, not on date + amount. If a converter generates random FITIDs, re-importing an overlapping date range creates duplicate transactions. I hash account + date + amount + description, so the same transaction always gets the same FITID. Credit card statement cycles never match calendar months, so overlapping imports happen more often than I expected.
QuickBooks cannot export .qbo
This one surprised me. No version of QuickBooks can produce a .qbo file. The format only goes one direction, from bank to QuickBooks. Every .qbo file in the world came from a bank's download button or from a converter.
That's what I have so far. The tool is free for single files and runs fully in the browser, nothing gets uploaded. I have only tested against QuickBooks Desktop — if you use QuickBooks Online, I'm interested in what its importer accepts.
Top comments (2)
The FITID finding matches my experience — dedupe on date+amount breaks the moment two identical coffees land on the same day, so a deterministic hash is the only sane approach. On your QuickBooks Online question: it has no manual .qbo import at all, that path is Desktop-only, which is a big part of why this gap exists. The deeper fix is pulling transactions straight from a PSD2 API — the bank returns its own stable transaction IDs, so FITID stops being something you have to synthesize. (John Frandsen — I maintain open-banking.io, a small PSD2 API.)
Thanks — the coffee example is exactly it. Two identical amounts on the same day and date+amount has nothing left to match on.
On Online, I hit the same thing from the other direction. Someone posting about a bank feed problem said .qbo was the first thing they tried and it failed, and the CSV "loaded flawlessly". That's been sitting in my notes for two days and I hadn't done anything with it, so your comment is what got me to fix the page today. It now tells Online users to upload the plain CSV first instead of converting.
Still one report though. I don't know whether .qbo just doesn't work on Online at all, or whether it was something about that particular file. If you've seen it more than once I'd like to know.