IIF format reference

IIF (Intuit Interchange Format) is QuickBooks Desktop's tab-separated text format for moving lists and transactions in and out of a company file. Solid Accounting reads IIF for ad-hoc transaction imports — see Migrate from QuickBooks for the recommended path on full company-file migrations.

This page is the technical reference: format structure, field mapping, dialects we tolerate, and what we deliberately don't try to handle.

When to use IIF (and when not to)

IIF is best as a tool for transactional one-offs: a year of bank-feed downloads someone gave you, a client's exported customer list, a colleague's chart of accounts to bootstrap a new file. For full migrations, lean on .qbextract first.

Format structure

IIF is tab-separated text with header rows beginning with !. The two main constructs we read:

Account list

A !ACCNT block declares accounts:

!ACCNT  NAME                  ACCNTTYPE   DESC
ACCNT   Operating Checking    BANK        Main checking account
ACCNT   Accounts Receivable   AR
ACCNT   Service Income        INC
ACCNT   Office Supplies       EXP

Field meanings:

Account-type mapping from QuickBooks to Solid:

QuickBooks has additional sub-types (CCARD, INVASSET, etc.) that Solid maps to the closest equivalent — usually you don't need to worry about this; the import preview surfaces anything ambiguous.

Transactions

Transactions come in !TRNS + !SPL blocks:

!TRNS  TRNSID  TRNSTYPE  DATE       ACCNT                NAME           AMOUNT  MEMO
!SPL   SPLID   TRNSTYPE  DATE       ACCNT                NAME           AMOUNT  MEMO
!ENDTRNS

TRNS   1042    CHECK     04/15/26   Operating Checking                   -642.18 April utilities
SPL    1043    CHECK     04/15/26   Auto Loan Payable                     485.32 Principal
SPL    1044    CHECK     04/15/26   Interest Expense                      112.86 Interest
SPL    1045    CHECK     04/15/26   Loan Escrow                            44.00 Escrow
ENDTRNS

The structure:

• !TRNS declares the columns of the transaction header row
• !SPL declares the columns of split lines (one per additional GL line)
• !ENDTRNS declares the end-marker (always literal ENDTRNS with no fields)
• Then real rows: one TRNS (the primary line), zero-to-many SPL (other splits), one ENDTRNS

In double-entry IIF, the sum of all TRNS and SPL amounts on one transaction is zero — the entry balances. Solid validates this on import; entries that don't balance are flagged in the review step.

Field reference for !TRNS / !SPL

QuickBooks sometimes emits additional fields per-row (DUEDATE, TERMS, PRICE, QNTY, INVITEM, etc.). We read what we recognize and store the rest as raw metadata — visible from the imported entry's source-data tab if you need to investigate something.

Date format

IIF dates are MM/DD/YYYY per QuickBooks's U.S. default. We accept:

• MM/DD/YYYY (canonical) — e.g. 04/15/2026
• M/D/YYYY — e.g. 4/15/2026
• MM/DD/YY — interpreted as 21st-century if YY <= 49, 20th-century otherwise

Anything else fails the parse and the import surfaces the offending row. If your QuickBooks export came out in a non-U.S. regional format (e.g. 15/04/2026), re-export with U.S. English regional settings. We don't try to auto-detect format.

Encoding

IIF files from QuickBooks Desktop are typically Windows-1252 / CP-1252 (the Windows default code page). Solid reads UTF-8 first and falls back to CP-1252 if UTF-8 decoding fails. Almost no IIF files contain characters outside ASCII, so encoding rarely matters in practice.

If you have an IIF file from a non-English version of QuickBooks with non-ASCII characters in account names or memos, save it as UTF-8 from a text editor before importing.

Subaccount hierarchy

Subaccounts use colon-delimited names: Bank:Operating Checking, Income:Service:Consulting. We preserve the hierarchy on import — the parent and each level of child are created if they don't already exist.

The !ACCNT block declares accounts in any order; we resolve parent references after parsing all account rows, so the parent doesn't need to come before its children.

Cleared / reconciled status

IIF carries the cleared status on each split line via the CLEAR field (Y or N). We map this to the line's cleared flag so historical reconciliation status survives the import.

If you reconcile in QuickBooks after the export, those status changes obviously aren't in the IIF — you'd need to re-export.

Multi-currency

IIF carries the base-currency amount on every line. There's no per-line currency code, exchange rate, or original-currency amount in the format. If you have multi-currency data in QuickBooks, the IIF export has already collapsed everything to base currency before writing.

For multi-currency migration, prefer the .qbextract path or QBO OAuth — both preserve the full multi-currency picture.

Class tracking → dimensions

QuickBooks "classes" — used for project-, location-, or department-tracking — come through on the CLASS field of TRNS and SPL rows. Solid maps these to its dimension system (Professional and Accountant tiers).

If you've used classes in QB and you're on the Standard tier, the class data is imported as memo text on the line (because dimensions aren't available on Standard). Upgrade to Pro to convert that memo data to first-class dimensions later.

What we deliberately don't import

• Memorized transactions — IIF carries posted transactions, not templates. Recreate as recurring entries in Solid after import.
• Sales tax codes — QB's tax-code definitions aren't in IIF (!TAXTBL and friends are inconsistent across QB versions). Set up tax codes in Solid before importing transactions that reference them.
• Item lists with full inventory cost layers — IIF flattens cost layers and emits totals. For inventory-heavy migrations, prefer the .qbextract path.
• Attached documents / receipts — QuickBooks Document Center attachments aren't in IIF.
• Bank Feed connection state — set up Bank Feeds in Solid separately after import.
• Custom fields beyond MEMO — fields outside the standard list go into raw metadata, visible from the source-data tab.

Common parse errors

"Unbalanced transaction at row N" — the TRNS + SPL lines for that transaction don't sum to zero. Usually a corrupt export. Open the IIF in a text editor at the offending row; one common cause is QuickBooks emitting only the TRNS line for credit-card-charge transactions, which represent it as a single-sided entry.

"Unknown account type CCARD" / similar — IIF account-type code Solid doesn't recognize. Edit the IIF: change CCARD to OCLIAB (or whichever Solid type matches) before re-importing. Or skip the account in the import preview and create it manually.

"Date 1/1/1980 detected" — date column was empty or in an unexpected format. The default in some QB versions is to fill missing dates with epoch. Re-export with regional settings set to U.S. English and the date format explicitly set.

"Account 'Foo:Bar' not found in !ACCNT declarations" — the transaction references an account that wasn't declared in the !ACCNT block. Re-export from QuickBooks with every account checked on the lists-export step, then re-run.

"Encoding error decoding row N" — non-UTF-8 bytes that aren't valid CP-1252 either. Open the IIF in a text editor, save as UTF-8, retry.

Cross-references

• Migrate from QuickBooks — the migration walk-through that decides between IIF, .qbextract, and QBO OAuth
• General Ledger → transaction types — the Solid-side transaction_type enum that IIF transaction types map to
• Import & Export — overview of every supported format