All posts
bank-statement-converterquickbooksqboiifdesktopaccountingguide

QuickBooks Desktop bank statement import: the .QBO and .IIF workflow

The two formats QuickBooks Desktop accepts behave nothing alike. .QBO goes through Bank Feeds with FITID dedupe and validation; .IIF writes straight into the company file with none. Here's when to use which, the Web Connect workflow step-by-step, the five Desktop-specific failure modes (ACCTID mismatches, the 90-day rolling window, FI Org / FID errors, the IIF 'Excess credit' trap, multi-currency rejects), and why PDF still has to be converted to .QBO first.

StatementEdge··10 min read

The 30-second version

QuickBooks Desktop takes bank-statement data in two formats that are easy to confuse and behave nothing alike. .QBO (Web Connect / OFX 1.0.2) is the safe one: structured, validated, lands in the Bank Feeds Center, and matches against your existing register using stable transaction IDs. .IIF (Intuit Interchange Format) is the dangerous one: a tab-separated ledger import that writes straight into your company file with no validation, including ACCNTTYPE, posting account, and double-entry sides. Use.QBO for bank statements. Reserve .IIF for chart-of-accounts setup, lists, and bulk journal entries where you actually want raw ledger control — and always back up the company file first.

QuickBooks Desktop still runs a meaningful share of US small-business bookkeeping in 2026, and its bank-statement import story is genuinely more capable than QuickBooks Online's — once you know which file to feed it. The catch is that the two formats it accepts, .QBO and .IIF, are completely different tools that happen to share Intuit's logo on the documentation page. Picking the wrong one is the most common reason a Desktop import either silently does nothing or, much worse, scrambles a working chart of accounts. This is the practical walkthrough: what each format actually is, when to use which, how to run the imports, the per-bank quirks that bite Desktop users specifically, and how PDF fits into the picture in the years since the bank-feed ecosystem started fragmenting.

Why Desktop is a different beast from Online

QuickBooks Online and QuickBooks Desktop look superficially similar, but the import surface area is not the same product. Online has one upload wizard and quietly accepts .qbo, .qfx, and .csv through the same path. Desktop exposes the actual file-handling machinery: a Bank Feeds Center for OFX-family files, an Import menu for IIF, the Make Deposits register for raw entry, and three different bank-connection modes (Direct Connect, Web Connect, Express Web Connect) that look identical to the user but fail in different ways. If you came from the Online world, the biggest shift is this: nothing in Desktop's import path is forgiving. The Bank Feeds Center will accept a malformed.qbowithout complaint and then refuse to display the transactions. The IIF importer will accept tab-separated rows for accounts that don't exist yet and create them with whatever type you specify, including ones that break reconciliation later.

If you're evaluating whether to stay on Desktop or migrate to Online for bank-feed reliability, our 2026 QBO import guide covers the Online side end-to-end. The format-level decisions below apply to both.

Format 1: .QBO — Web Connect, the one you usually want

A .QBOfile is plain text wrapped in an OFX 1.0.2 envelope. Open one in a text editor and you'll see a header like OFXHEADER:100, then SGML tags for the financial institution (<FI>), the account (<BANKACCTFROM>), a statement period (<DTSTART>, <DTEND>), and a list of transactions (<STMTTRN>) each carrying a posted date, an amount, a name, a memo, and the key field nobody talks about: <FITID>, the bank's stable transaction identifier.

Web Connect is the import mode that takes .QBOfiles downloaded manually from a bank's website. Direct Connect, by contrast, pulls them automatically over OFX from the bank's server — which is why a working Direct Connect connection looks like a feature and not a file format. They produce the same underlying data; Web Connect just makes you click Download yourself.

The Web Connect workflow in QuickBooks Desktop 2026:

  1. Banking → Bank Feeds → Set Up Bank Feed for an Account — attach your bank account to the QuickBooks register the first time. After that you can skip this step.
  2. Download or create the .QBO. Either export it from the bank's portal directly (look for "Download for QuickBooks" or "Web Connect (.qbo)" on the statements page), or convert a CSV or PDF statement using our CSV-to-QBO tool if your bank only offers those.
  3. File → Utilities → Import → Web Connect Files, or double-click the .QBO in Windows Explorer — both routes land in the same Bank Feeds Center review queue.
  4. In the Bank Feeds Center, switch to Transaction List mode (the Side-by-Side mode is the new default and confuses long-time Desktop users; either works). Review the matched and unmatched transactions. Click Add to QuickBooks per row or in bulk.

Open every .QBO in a text editor first

The fastest .QBO diagnostic is to open the file in Notepad or VS Code. Confirm OFXHEADER:100 is the first line, <ACCTID> matches the bank-feed account number QuickBooks expects, the dates are reasonable, and every <STMTTRN> has both a <TRNAMT> and a unique <FITID>. Five seconds of inspection catches the "imports successfully but nothing shows up" failure before you spend twenty minutes looking for it in the Bank Feeds Center.

Format 2: .IIF — what it's for, and what it isn't for

.IIF is the Intuit Interchange Format: a tab-separated export/import format that QuickBooks Desktop has supported since the late 1990s for moving lists and transactions between company files. It was originally designed for accountants to script chart-of-accounts setup, vendor lists, and journal entries — and it remains genuinely useful for those jobs. It was not designed as a bank-statement import path, and using it for bank statements is where most of the horror stories come from.

An .IIF bank-statement import looks something like this in skeleton form:

!TRNS	TRNSTYPE	DATE	ACCNT	NAME	AMOUNT	DOCNUM	MEMO
!SPL	TRNSTYPE	DATE	ACCNT	NAME	AMOUNT	DOCNUM	MEMO
!ENDTRNS
TRNS	DEPOSIT	03/15/2026	Checking	Customer A	1500.00	1234	Invoice payment
SPL	DEPOSIT	03/15/2026	Sales		-1500.00	1234	Invoice payment
ENDTRNS

Three things make this dangerous in practice. First, every row is a full double-entry journal: you must specify both the bank-account side (TRNS) and the posting-account side (SPL), and if they don't net to zero, QuickBooks either rejects the row outright or, on older builds, silently posts an unbalanced entry that breaks the General Ledger. Second, the importer creates accounts that don't exist instead of failing — a typo in Checking becomes a new account named Cheking with no warning. Third, .IIFhas no equivalent of a FITID, so re-running the same import duplicates every transaction.

Back up the company file before any .IIF import

Unlike .QBO imports, an .IIFimport writes directly into your company file without an intermediate review queue. There is no "reject all and start over" button. If the file references a nonexistent account, the importer will create it. If a transaction is unbalanced, on older builds you could end up with a corrupt company file. Always run File → Back Up Company → Create Local Backup before touching the IIF importer, and verify the backup opens cleanly before you proceed.

That said, when you actually want raw ledger control — bulk chart-of-accounts setup for a new client, importing 200 journal entries from a year-end working paper, migrating vendors from a spreadsheet — .IIF is the right tool and .QBOcan't do the job. The decision rule is simple:

Use .QBO when the source is a bank. Use .IIFwhen the source is your own ledger. Mixing the two is where Desktop accountants get hurt.

Choosing between .QBO and .IIF in practice

SituationUseWhy
Monthly bank statement (any bank).QBOGoes through Bank Feeds review, FITID dedupe, matched register
Credit-card statement.QBOSame path; signs handled correctly
Year-end journals from working paper.IIFNeed explicit GL coding; backup first
Chart of accounts setup for new client.IIFBank Feeds path can't create accounts
Bulk vendor or customer import.IIFLists aren't transactions; .QBO doesn't carry them
PDF bank statementConvert to .QBO firstDesktop can't parse PDFs natively
CSV bank exportConvert to .QBO firstDesktop's CSV path is the third-party SDK route — fragile

The five Desktop-specific failure modes

1. "Imports successfully" — but nothing shows in the Bank Feeds Center

The most common one. Web Connect accepted the file, no error appeared, the Bank Feeds Center says "0 new transactions". Almost always one of three causes: the <ACCTID> in the .QBOdoesn't match the account number QuickBooks has on file for that connected account; the <FITID>s in the file are identical to ones already imported (QBD dedupes silently); or the date range overlaps an existing imported period and the auto-match logic moved every transaction straight into the "already in QuickBooks" bucket. Open the .QBO in a text editor, check <ACCTID> against Lists → Chart of Accounts → Edit Account → Bank Feed Settings, and confirm FITIDs are unique.

2. The 90-day rolling-window cutoff

QuickBooks Desktop rejects .QBOfiles that contain transactions older than roughly 90 days from today on accounts in Express Web Connect mode. The error reads "The financial institution is not available" even though the file is local and no network call is happening. The workaround is to switch the account to Web Connect mode (not Express) via Edit Account → Bank Feed Settings, or to split the statement into a current and a back-dated file and import the current one first.

3. The FI Org / FID / Bank ID mismatch

Every .QBO file carries an <ORG> name and an <FID>bank identifier in the financial-institution block. QuickBooks checks both against the bank profile attached to the account. If you converted the file from a PDF and the converter put the wrong institution name there, Desktop will refuse the file with a generic "Could not verify the bank" error. A good converter sets the institution from your bank selection at conversion time; an OK one lets you edit the file post-conversion to set ORG and FID manually.

4. The "Excess credit" trap on IIF imports

An .IIF import where the TRNS and SPLlines don't sum to zero produces an "Excess credit" or "Excess debit" error on recent builds. Older builds silently posted the unbalanced entry, and the company file would later fail Verify Data. If you're on QuickBooks Desktop 2024 or older and using .IIF, treat every import as suspect until you've run File → Utilities → Verify Data against the company file. (And keep the backup you made — see the warning above.)

5. The QuickBooks Mac and multi-currency quirks

QuickBooks for Mac uses a different import dialect; .QBOworks but with a slimmer Bank Feeds UI, and .IIF is partially supported with several documented gotchas around list items. Multi-currency company files add another layer: a .QBOfile containing transactions in a currency that doesn't match the account's currency on file is rejected with no useful error. Confirm the account's currency in Lists → Chart of Accounts before importing a foreign-currency statement.

Where PDF fits in 2026

QuickBooks Desktop has never read PDF bank statements natively, and 2026 is not the year that changes. The realistic options if your bank only emits PDFs (or only emits CSV in a format Desktop's Bank Feeds Center won't accept) are:

  • Convert to .QBO and import via Web Connect. This is the smoothest path. The converter produces a file with FITIDs, ACCTID, and ORG already set; Desktop treats it as if it had come from a Direct Connect feed.
  • Convert to CSV and use the third-party CSV-to-QBO SDK route. Desktop has a built-in CSV importer for credit-cardaccounts only, and it's fragile. For checking and savings accounts, CSV import on Desktop requires a third-party connector and is harder to maintain than going straight to .QBO.
  • Use the Online migration path if Intuit's bank-feed coverage for your bank is reliable on QBO but flaky on Desktop. This is a bigger decision than an import workflow, but worth weighing if your monthly close is dominated by Web Connect re-runs.

For the PDF-to-QBO conversion step specifically, the requirements are: structured field mapping (not OCR-then-regex), correct sign handling for Money-In / Money-Out style statements, locale-aware amount parsing for European banks, and a reconciled total against the bank's own opening and closing balance. Our post on what auto-reconciled actually means goes into why the last one is the only check that catches the silent failure mode of a single misread digit on a 200-row statement.

Reconciliation: the same trap as Online, twice as expensive on Desktop

Desktop's reconciliation feature is more powerful than Online's, but it's also slower to undo. A bad import propagates through Reconcile, the bank-feed register, and any memorised reports that pivot on the affected accounts. Once you click Reconcile Now with bad numbers, rolling back means either an undo-reconciliation pass (Accountant Edition only on most recent versions) or restoring the pre-import backup and redoing every entry since. The .QBO-with-reconciliation path is therefore disproportionately valuable on Desktop: catching a wrong-number row before the reconcile click is the difference between a five-minute review and a half-day cleanup.

If you're running a multi-client Desktop practice, the accountants' workflow guidecovers batch patterns by practice size — the same patterns apply on Desktop with the addition that you can use the converter's REST API to drop finished .QBO files into a watch folder that the Desktop operator picks up.

The short answer if you're mid-close

  1. You have a PDF or CSV statement. Convert it on StatementEdge.
  2. Check the reconciliation badge is green (or amber with a flag count you can review).
  3. Download as QuickBooks (.qbo).
  4. In Desktop: File → Utilities → Import → Web Connect Files. Pick the .qbo. Done.
  5. Review in the Bank Feeds Center. Add to QuickBooks. Reconcile.

And the rule one more time, because it's the rule that keeps a Desktop company file healthy: bank statements go in as .QBO, never as .IIF. Reserve .IIF for the jobs it was actually designed for — list setup and journal entries — and always with a backup ready.

Further reading

Keep reading