IIF — Intuit Interchange Format — is a tab-delimited text format QuickBooks Desktop imports natively. It is old, sparsely documented, and unforgiving in ways the documentation does not warn you about. Most of what is known about making it work correctly is folklore accumulated by people who imported a bad file into a live company once and had to undo it.
This piece is our contribution to that folklore. Every item below is something we got wrong first and fixed after watching a real import behave badly.
The structure, briefly
An IIF file is a set of sections, each introduced by a header row beginning with !. A
transaction is not one row — it is a TRNS row for the transaction, one or more
SPL rows for its splits, and an ENDTRNS row to close it. That is double-entry
bookkeeping expressed as text: the TRNS line hits the bank account, the SPL lines hit the expense or
income accounts, and the amounts must sum to zero.
A file that emits one row per transaction is not producing double-entry data. It may import; what it lands will not be correct.
Failure 1: entities you never declared
This is the most common outright failure. If a TRNS row names a payee that does not already exist in the company file, QuickBooks may reject the row, or — worse, depending on version and settings — create a name in a list you did not intend.
The fix is to declare every distinct payee in your file before using it, in an !OTHERNAME
block at the top. It costs a few lines and it converts an unpredictable import into a deterministic one.
A converter that does not emit this block is relying on your company file already containing every
vendor on the statement, which for a new client is never true.
Why "Other Name" rather than Vendor
A statement payee is not necessarily a vendor in the accounting sense — it may be a transfer, a fee, or a customer refund. Declaring them as Other Names avoids polluting the Vendor list with entries that will need cleaning up later, while still satisfying the requirement that the name exists.
Failure 2: the payee on the wrong line
Intuitively you might put the payee name on both the TRNS row and each SPL row. Do not. QuickBooks treats the name on a split line as a job or customer assignment for that split, not as a repetition of the payee — so the same name appearing in both places produces transactions with peculiar customer assignments that are tedious to unpick afterwards.
Payee goes on the TRNS line only. Leave the name field on the SPL lines empty unless you genuinely mean job costing.
Failure 3: three hundred cheques in the print queue
A check-type disbursement imported without an explicit print flag defaults to "to be printed". Import a year of history and QuickBooks now believes you intend to print several hundred cheques for transactions that cleared months ago. The client discovers this when the print queue offers to consume a box of check stock.
Nothing is broken, but the cleanup is manual and irritating. Emit a TOPRINT column with a
value of N on disbursement rows and the problem never occurs.
Failure 4: credit card refunds imported as payments
On a credit card statement, a credit can be a payment you made against the card or a refund from a merchant. They are different transactions and they hit different accounts.
Mapping both to the generic PAYMENT type is wrong: PAYMENT in QuickBooks relates to
accounts receivable, and a merchant refund on a credit card is not a customer paying you. The correct
type is CCARD REFUND. Get this wrong and the books balance while the AR aging quietly does
not, which is the worst kind of error — invisible until someone runs a report they trust.
Failure 5: the bank account that is not an account
Every TRNS row needs the QuickBooks account the transaction posts to. A converter has to get that account name from somewhere, and the tempting shortcut is to use the account description the extractor read off the statement header.
That header text is almost always the account holder's name — "SMITH FAMILY LANDSCAPING LLC" — which is not a QuickBooks account and will not match one. The import either fails or creates something that looks plausible and is not.
The only correct answer is to require a staff member to confirm the bank account before export, chosen from the client's known accounts with an option to add a new one. It is one extra field and it is not optional. A converter that silently falls back to the statement header is guessing with your client's books.
A pre-import checklist
- Back up the company file. IIF imports cannot be undone as a batch. This is the whole reason the rest of this list matters.
- Import into a copy first for any client or converter you have not used before.
- Confirm the target bank account is a real account in the company file, spelled identically.
- Check the date range against what is already posted — duplicate imports are the second most common cleanup job after the print queue.
- Spot-check five transactions after import: a check, a deposit, a credit card charge, a refund, and a transfer. If those five are right, the rest almost certainly are.
- Run a balance sheet before and after. The delta should equal the statement's net movement. If it does not, stop and restore.
When to use something else
IIF is the right choice when you need true double-entry detail in QuickBooks Desktop. It is the wrong choice for QuickBooks Online, which does not accept it at all, and unnecessary when you only need to get transactions in front of a human for review — CSV is simpler and cannot damage anything.
QIF sits in between: accepted by QuickBooks Desktop and Quicken, simpler than IIF, but without split detail. For a single-account bank statement with straightforward transactions it is often enough, and its failure modes are milder.
What Kveldo's exporter does
All five fixes above are built in, because all five came from watching real imports go wrong. Kveldo's
IIF export emits an !OTHERNAME block defining every distinct payee, puts the payee on the
TRNS line only, adds TOPRINT N so check-type disbursements stay out of the print queue,
maps credit card refunds to CCARD REFUND rather than PAYMENT, and requires a
staff-confirmed QuickBooks bank account — the Export IIF button stays disabled until it is set, and the
exporter never falls back to the AI-extracted statement header.
CSV, XLSX and QIF are available alongside it, and every export is saved to the client's Files tab so a previously generated file can be re-downloaded rather than regenerated.
See the QuickBooks integration →
Read next: what AI extraction really does to a bank statement →