Short version: Most IIF import failures come from one of ten causes, and nearly all of them are visible in the file before you import if you know what to look for: an entry that doesn't net to zero, an account name that doesn't exactly match the chart, a tab shifted by one column, a date in the wrong format, a transaction dated in a closed period, a name that already exists as a different list type, a header row that doesn't match the data rows, a missing ENDTRNS, stray characters from the spreadsheet export, or a field over its length limit. Here's each one, what QuickBooks says when it happens, and the fix.
QuickBooks Desktop's IIF import has two failure modes, and the second is worse. The first is an error message, which at least tells you something went wrong. The second is a silent partial import: the file loads, some transactions post, and the rest just don't, with no list of which. That's why the pre-import checks at the end of this guide matter more than the error decoder. But you'll still hit errors, so here's what they mean.
If you're new to the format, start with what an IIF file is and how to build one for journal entries. This guide assumes you've got a file and it won't load.
Cause: the debits and credits inside one TRNS/SPL/ENDTRNS block don't sum to zero. In IIF, debits are positive and credits are negative, and the TRNS line's amount plus every SPL line's amount must equal exactly 0.00. The usual culprits are a sign error on one line, a rounding difference from a spreadsheet formula (a line showing 33.33 that's really 33.333), or a split line that got deleted.
Fix: add a check column in the spreadsheet that sums each entry and flags anything that isn't 0.00. Round every amount to two decimals before you export, not in the display format.
Cause: the ACCNT field doesn't exactly match an account name in the chart. IIF matches on the full name, including the parent, with a colon between levels: Expenses:Utilities:Electric, not Electric. Trailing spaces, an ampersand written as "and," or a capital letter difference all fail. If you use account numbers, the name QuickBooks matches on may include the number prefix depending on your preference setting.
Fix: export the chart of accounts to IIF (File > Utilities > Export > Lists to IIF Files) and paste the exact names into a lookup sheet. Build the ACCNT column from that lookup, never by typing.
Cause: a tab is missing or extra somewhere in a row, so every field after it shifts one column. Common when a memo contains a tab character, when a spreadsheet cell was blank and the export dropped the delimiter, or when the header row has a different column count from the data rows. QuickBooks may not error at all; it may just put the memo in the amount field and fail the balance check instead.
Fix: open the exported file in a plain text editor with "show whitespace" on and confirm every row has the same number of tabs as the header. Strip tabs and line breaks from memo and name fields before export.
Cause: the DATE field isn't in a format QuickBooks recognizes, or it's in a format that's ambiguous. MM/DD/YYYY is the safe form. A spreadsheet that exports 2026-03-15, or 3/15/26 interpreted as 1926, or a date serial number like 46096, will either fail or post to the wrong period.
Fix: format the date column as text in MM/DD/YYYY before export. Then check the first and last transaction dates in the text file, not the spreadsheet.
Cause: the transaction date is on or before the closing date set in Company > Set Closing Date. The import respects the closing date and the password.
Fix: if the entries genuinely belong in the closed period (prior-year adjustments from the preparer, say), temporarily move the closing date, import, and set it back, with a note in the file. If they don't, the date column is wrong; see error 4.
Cause: the NAME field on a transaction line references a name that exists in QuickBooks, but as a different type. "Smith Construction" is a vendor in the file and the IIF line treats it as a customer, or the name exists as an Other Name. Desktop keeps one name space across all lists, so the same string can't be both.
Fix: decide which list the name belongs in. For imports that need both (a customer who is also a vendor), convention is to suffix one, like "Smith Construction (V)." Journal-entry imports often don't need a name at all; leave NAME blank unless the line hits A/R or A/P, which require one.
Cause: the header rows are wrong. Every transaction import needs the three header lines, !TRNS, !SPL, and !ENDTRNS, with the column names in the same order the data rows use. A header that says !TRNS TRNSID TRNSTYPE DATE ACCNT while the data rows are ordered TRNSTYPE DATE ACCNT maps every field wrong. A file saved with a UTF-8 byte-order mark puts invisible characters before the first !, and QuickBooks doesn't see a header at all.
Fix: copy the header block from a known-good file or from a QuickBooks IIF export. Save as plain tab-delimited text, ANSI or UTF-8 without BOM, with the .iif extension.
Cause: a transaction block isn't terminated. Without the ENDTRNS line, QuickBooks reads the next TRNS line as another split of the current entry, which then fails the balance check or posts as one giant entry.
Fix: count TRNS lines and ENDTRNS lines; they must be equal. Build the file so ENDTRNS is generated as part of each entry, not added by hand.
Cause: a value exceeds the field's length limit. Names top out at 41 characters, account names at 31 per level, memos at a few hundred depending on the transaction type. QuickBooks may reject the row or silently truncate.
Fix: add a length check column in the spreadsheet. Shorten at the source rather than letting QuickBooks decide what to cut.
Cause: curly quotes, em dashes, accented characters, or non-breaking spaces pasted from Word or a web page. Some show up as garbage in the memo; some break the row entirely. The ampersand and colon are fine in memos but a colon in an account or name field is read as a sub-level separator.
Fix: keep names and accounts to plain letters, numbers, spaces, and a small set of punctuation. Run a find-and-replace for curly quotes and dashes before export. If a vendor's legal name has a colon in it, it can't be a QuickBooks name as-is.
Desktop writes an error log when an import fails (the dialog offers to show it, and it saves alongside the IIF file). Line numbers in the log count from the top of the file, including header rows, so "line 14" is the eleventh data row if you have three headers. Open the IIF in a text editor with line numbers, not in Excel, which renumbers and reformats.
And the log only covers the rows that threw errors. Always compare the count of transactions in the file to the count that posted (run a Journal report filtered to the import date range) and confirm the totals tie. Silent partial imports are the expensive kind.
The habit that fixes it permanently: never hand-type an IIF. Build it in a spreadsheet with lookups for account names, a balance check per entry, and a length check per field, and generate the header and ENDTRNS lines from the template. The errors above are almost all typing errors wearing a technical name.
The IIF Import Field Guide & Checker validates a file against all ten checks above before it touches QuickBooks: balance per entry, account name matching, column alignment, dates, names, lengths, and headers. The IIF Toolkit bundles it with the Journal Entry Generator that builds clean files in the first place.
Inside each TRNS/SPL/ENDTRNS block, the amounts must sum to exactly zero, with debits positive and credits negative. A sign error, a rounding difference from a spreadsheet formula, or a deleted split line breaks it. Round amounts to two decimals before export and add a check column that sums each entry.
The ACCNT field must match the account's full name exactly, including parent levels separated by colons (for example, Expenses:Utilities:Electric). Trailing spaces, capitalization, and punctuation differences all fail. Export the chart of accounts to IIF and build the account column from those exact names.
No. There is no undo for an IIF import. Back up the company file before importing, test with a single transaction first, and verify the count and totals that posted against the file.
Desktop can partially import a file, posting the rows it could read and skipping the rest without a complete error list. Common causes are a missing ENDTRNS, a shifted column in some rows, or names that conflict with existing list entries. Compare the number of transactions in the file to the number that posted in a Journal report for the import dates.
MM/DD/YYYY as text is the safe choice. ISO dates, two-digit years, and spreadsheet date serial numbers can fail or post to the wrong year. Check the dates in the exported text file, not in the spreadsheet.
No. IIF is a QuickBooks Desktop format only. QuickBooks Online imports CSV or Excel files through its own import tools, or through third-party import apps.
General guidance on QuickBooks Desktop IIF imports, not accounting, tax, or legal advice. Field limits and import behavior vary by Desktop version and release; test on a backup before importing into a live file.
Practitioner guides on controller-grade books, the close, and cleaner reporting. One email per guide. Unsubscribe in a click.