DEV Community: Satwinder Dev

What's inside a QBO file (and why QuickBooks silently skips transactions)

Satwinder Dev — Mon, 26 Oct 2026 15:24:26 +0000

When you download transactions from a bank "for QuickBooks", you get a .qbo file. I recently added a QBO export to BankStatementHub, a free tool that turns PDF bank statements into spreadsheets and accounting files. It turned out a QBO file is mostly something older and simpler, plus one extra line. There's also one field that decides whether your transactions quietly disappear.

Here's what I learned.

1. A QBO file is OFX with one extra line

QBO (QuickBooks Web Connect) is OFX 1.x, the bank-download format from the late '90s. It isn't XML. It's SGML: a plain-text header, then tags where the leaf elements are never closed.

A trimmed-down file looks like this:

OFXHEADER:100
DATA:OFXSGML
VERSION:102
SECURITY:NONE
ENCODING:USASCII
CHARSET:1252
COMPRESSION:NONE
OLDFILEUID:NONE
NEWFILEUID:NONE

<OFX>
<SIGNONMSGSRSV1>
<SONRS>
<STATUS><CODE>0<SEVERITY>INFO</STATUS>
<DTSERVER>20260930
<LANGUAGE>ENG
<INTU.BID>3000
</SONRS>
</SIGNONMSGSRSV1>
<BANKMSGSRSV1>
<STMTTRNRS>
<TRNUID>1
<STATUS><CODE>0<SEVERITY>INFO</STATUS>
<STMTRS>
<CURDEF>USD
<BANKACCTFROM>
<BANKID>000000000
<ACCTID>4821
<ACCTTYPE>CHECKING
</BANKACCTFROM>
<BANKTRANLIST>
<DTSTART>20260901
<DTEND>20260930
<STMTTRN>
<TRNTYPE>DEBIT
<DTPOSTED>20260903
<TRNAMT>-54.20
<FITID>20260903-9c1e4a7b-1
<NAME>Green Grocer
<MEMO>Card Purchase Green Grocer
</STMTTRN>
</BANKTRANLIST>
<LEDGERBAL><BALAMT>1765.80<DTASOF>20260930</LEDGERBAL>
</STMTRS>
</STMTTRNRS>
</BANKMSGSRSV1>
</OFX>

Notice <TRNAMT>-54.20 with no </TRNAMT>. That's valid here, and it's the first thing that breaks if you reach for an XML library.

The QuickBooks-specific part is <INTU.BID>, the Intuit bank ID. Without it you have an .ofx file. With it, and the .qbo extension, you have Web Connect.

2. INTU.BID: QuickBooks Desktop checks it

QuickBooks Online accepts .qbo, .ofx and .qfx uploads without much fuss. QuickBooks Desktop is stricter: it checks the bank ID against Intuit's list of supported banks, and if the number isn't on it, the import stops.

So when you generate QBO files yourself:

use a bank ID that QuickBooks Desktop recognises (converters commonly use a well-known one)
let the user change it, because the one that works can differ between setups

3. The FITID trap

Every transaction has a FITID. QuickBooks (and Quicken) remember the FITIDs they've imported for an account and silently skip any they've seen before. That's how they avoid duplicates when you download overlapping date ranges.

It also means the way you generate FITIDs decides whether transactions go missing. There are two easy ways to get it wrong.

Wrong #1: ID from the row's position. FITID = statementId + rowIndex looks unique, but convert an overlapping statement next month and the same transaction gets a different index. QuickBooks treats it as new, and you get duplicates.

Wrong #2: ID from the transaction's content only. FITID = hash(date + amount + description) is stable across conversions, which is good. But two genuine $4.50 coffees on the same day hash to the same ID, and QuickBooks drops the second one without a word.

What works: hash the content, then count repeats of that same content within the file.

const seen = new Map();

function fitid(t) {
  const key = `${t.date}|${t.amount.toFixed(2)}|${t.description.trim().toLowerCase()}`;
  const n = (seen.get(key) ?? 0) + 1; // 1st, 2nd... identical transaction
  seen.set(key, n);
  return `${t.date.replaceAll("-", "")}-${hash(key)}-${n}`;
}

Converting the same or an overlapping statement again gives the same IDs, so nothing duplicates. Two identical coffees get -1 and -2, so neither disappears.

If you already have a file with colliding IDs from a bank, the repeats need new IDs before import. I made a small free tool for exactly that: Fix duplicate FITIDs.

4. Credit cards have their own block

Bank accounts live in BANKMSGSRSV1 → STMTTRNRS → STMTRS → BANKACCTFROM. Credit cards use a parallel set: CREDITCARDMSGSRSV1 → CCSTMTTRNRS → CCSTMTRS → CCACCTFROM (with no BANKID or ACCTTYPE).

Write a card statement in the bank block and it gets treated as a bank account. For signs, TRNAMT follows the account holder: money out of a bank account is negative, and so is a purchase on a card. A payment to the card is positive.

5. Small things that cause import errors

Dates are YYYYMMDD (optionally with a time), not ISO with dashes.
Escape &, < and > in NAME and MEMO. A payee like AT&T breaks an unescaped file.
NAME is short. OFX 1.x limits it to 32 characters. Put the full description in MEMO.
CHARSET:1252 is what most banks send. Stick to plain ASCII in payee names if you can.
LEDGERBAL carries the closing balance. Include it when you know it.

6. Check the numbers before you write the file

QuickBooks imports whatever is in the file. If a row was misread or a page was skipped, the file looks fine and the problem shows up weeks later as a reconciliation that won't balance.

Before writing any QBO file I check that:

opening balance + every amount in the file = closing balance

and, where the statement prints one, that each row's running balance follows from the one before. If either fails, the user sees which row before downloading anything.

You can try the whole thing with a PDF statement here: Bank statement to QBO converter. Free, no signup. If you already have a bank CSV or QBO file and want to check it before importing, there's a bank CSV checker that reads QBO files too.

Have you run into other OFX or QBO quirks? I'd like to hear about them in the comments.

Show DEV: RingMasti, a free ringtone site with Next.js, nginx and a Flutter app

Satwinder Dev — Mon, 26 Oct 2026 01:09:21 +0000

I have been building RingMasti, a free ringtone site. This is a short introduction to what it is, how it is put together, and how I handle content. Feedback is welcome.

What it does

Browse ringtones and listen on the page first, then get the file as MP3 for Android or M4A for iPhone.
No sign-up and no account.
Clips are short (under a minute) and cut to the part people actually recognise, not the whole song.
Hindi, Punjabi, Tamil, Telugu, Malayalam and other regional music, plus BGM, instrumentals, devotional tones and notification sounds.
A ringtone cutter that trims your own audio file in the browser.
A name ringtone maker that turns a name into a custom tone.
An Android app (Flutter) on Google Play.

The stack

Frontend: Next.js 15 (App Router) with ISR, so popular ringtone pages are served from cache.
Files: a separate nginx + PHP host. PHP only checks access, and nginx sends the audio itself (X-Accel-Redirect), which keeps PHP workers free during traffic spikes.
Data: MariaDB.
Edge: Cloudflare in front of both.
Mobile: Flutter app using the same API.

How content is handled

Ringtones are added as short clips, and automated imports are capped each day so the catalogue grows steadily instead of in bulk. Anything longer than about a minute is rejected, so full songs do not end up on the site. If a rights holder asks for something to be removed, it is taken down and that URL returns 410 Gone. The site has a DMCA page and a contact page for this.

What I would like feedback on

Is the listen-first flow clear on mobile?
Does the M4A option for iPhone make sense, or would you expect something else?
What would make the ringtone cutter more useful?

If you try it, tell me what felt slow or confusing.

What I learned building a bank statement PDF to Excel converter

Satwinder Dev — Sat, 24 Oct 2026 12:33:24 +0000

A PDF bank statement looks like a table. It isn't one. There are no rows or columns inside the file, only pieces of text placed at x/y positions on a page. Everything that makes it a "table" is in your head.

I spent the last few months building BankStatementHub, a free tool that turns PDF bank and credit card statements into Excel, CSV and QuickBooks files. Here is what broke along the way, and the one check that caught most of it.

1. Columns are a guess

To rebuild rows you group text by its vertical position, then split it into columns by horizontal position. That works until:

a description is long enough to run into the amount column
one transaction's description wraps onto two or three lines
the page header (bank name, account number, "continued") repeats on every page and lands in the middle of your data
a "Balance forward" or "Subtotal" line looks exactly like a transaction

Every bank does this a little differently, and the same bank changes its layout every few years.

2. The sign of an amount lives in different places

"Is this money in or money out?" has no single answer:

separate Withdrawals and Deposits columns (most US checking accounts)
one Amount column with a minus sign
a CR or DR suffix, or a trailing minus like 45.00-
credit card statements, where a positive number is a charge and a payment is negative, the opposite of a checking account

Get this wrong and the totals still look plausible, which is the dangerous part.

3. Numbers and dates are not what you expect

1,234.56 in the US, 1.234,56 in much of Europe and Latin America
amounts with no leading zero, like .15, which a careless regex reads as 15
dates printed without a year (Dec 28, Jan 03), so a statement that runs from December into January needs the year worked out from the statement period

4. The check that saved me: the balance

The most useful thing I built was not a better parser. It was a check.

A statement gives you an opening balance, a closing balance, and usually a running balance on every row. So after reading the transactions you can test:

opening balance + money in − money out = closing balance

and, row by row:

previous row balance ± this amount = this row balance

If either fails, something was misread, dropped or double counted, and you know which row to look at.

A real example: on a 14-page BBVA México statement, one whole page of transactions was skipped. Every row that was read looked perfect. The only sign of trouble was that the totals didn't add up to the closing balance, and that check flagged it.

Credit card statements usually have no running balance, so there the check falls back to the statement totals (previous balance, payments, purchases, new balance). It's weaker, but it still catches a missing page.

The lesson I'd pass on: don't trust extracted data you can't reconcile. If the numbers can't be checked against something on the page, show the user that clearly instead of handing them a clean-looking spreadsheet.

5. Export formats have their own traps

CSV and Excel are easy. QuickBooks and Quicken files (QBO/OFX) are not:

each transaction needs a FITID, an ID that should be unique within the account
QuickBooks silently skips a transaction if it has already seen that FITID, so two genuine $4.50 coffees on the same day can turn into one if the IDs collide
the account type (checking vs credit card) changes how the signs are read

I ran into the duplicate FITID problem often enough that I made a small free tool just for that: Fix duplicate FITIDs.

What it does now

PDF to Excel, CSV, QuickBooks (QBO), Xero and Quicken (OFX)
every row checked against the balance, with mismatches flagged
bulk conversion of up to 12 statements at once
password-protected PDFs
free, no signup

If you've worked with bank statement PDFs, I'd like to hear about the strangest layout you've come across. And if you try BankStatementHub on a statement it gets wrong, tell me in the comments; that's how most of these fixes happened.