← All articles

IIF vs QBO for QuickBooks Desktop

6 min read

QuickBooks Desktop accepts both, and they do not do the same thing. One goes through the banking feed; the other writes straight into the register with no safety net at all.

The fundamental difference

QBO enters through the banking feed. QuickBooks matches incoming transactions against ones it already holds, warns about likely duplicates, and lets you review before anything is accepted into the register.

IIF writes directly into the register. There is no feed, no matching, no review step. What is in the file becomes what is in the books, immediately.

What that means for a mistake

A bad QBO import is excluded from the feed in a couple of clicks. A bad IIF import is already in the register, possibly categorised, possibly reconciled, and has to be deleted transaction by transaction — with no undo.

Because QuickBooks will import an unbalanced IIF without complaint, a converter that writes both sides of every entry so the file balances is doing work you would otherwise have to check by hand.

IIF is double-entry, and QuickBooks does not check it

An IIF transaction is a TRNS line, one or more SPL lines, and an ENDTRNS. The TRNS carries the bank side; the SPLs carry the category side; and the amounts across all of them must sum to zero.

!TRNS	TRNSID	TRNSTYPE	DATE	ACCNT	NAME	AMOUNT
!SPL	SPLID	TRNSTYPE	DATE	ACCNT	NAME	AMOUNT
!ENDTRNS
TRNS		CHECK	03/15/2026	Checking	Shell	-45.20
SPL		CHECK	03/15/2026	Uncategorized Expense	Shell	45.20
ENDTRNS

QuickBooks does not verify that they sum to zero. It accepts the file and leaves the books unbalanced, which is a considerably worse failure than a rejection — a rejection you notice. Tally, by comparison, rejects an unbalanced voucher outright.

No escaping, either

IIF is tab-delimited with no quoting or escape mechanism of any kind. A tab inside a description shifts every column after it by one, and the result is not a malformed file that fails to import — it is a well-formed file whose columns are wrong, which imports cleanly. Values have to be stripped rather than escaped, because there is nothing to escape with.

Which to use

  • QBO, whenever you can get your bank’s Intuit ID. The feed and its duplicate detection are worth the effort of finding the number once.
  • IIF when the bank is not in Web Connect and there is no valid ID to be had — the situation IIF genuinely solves.
  • Never IIF for QuickBooks Online. Intuit removed IIF import from QBO entirely, and you find out at the point there is no import button to click.

If you do use IIF, import each period exactly once and check the date range before rather than after. Without a feed there is nothing between the file and your books.

What IIF can express that QBO cannot

For all its hazards, IIF is the more expressive format. A QBO transaction is a bank movement and nothing more — QuickBooks decides where the other side goes when you categorise it in the feed. An IIF transaction states both sides itself.

  • Splits across several accounts. One TRNS with several SPL lines posts a single payment across multiple expense accounts.
  • The category, decided in the file rather than in the feed.
  • Classes, where the company file uses them.
  • Non-bank transaction types — bills, invoices, journal entries — which the banking feed has no concept of at all.

That expressiveness is exactly why it bypasses the feed. There is nothing for the feed to do: the file has already made every decision the review step exists to let you make.

The CLEAR column, and why it should stay N

Both record types carry a CLEAR field marking a transaction as cleared. It is tempting to set it — the transactions came from a bank statement, so they have obviously cleared the bank.

Do not. Cleared in QuickBooks means reconciled within QuickBooks, by you, against a statement. Importing rows pre-marked as cleared removes them from the next reconciliation, which is the one control that would have caught a bad import in the first place. Leave it N and reconcile normally.

Related