Fixing QuickBooks IIF Import Errors
QuickBooks IIF import failures are frustrating because the error messages are almost always vague — "Some transactions could not be imported" with no indication of which ones or why. Understanding the specific structural requirements of IIF files lets you find and fix problems before you attempt the import rather than after.
Validate before you import: Run your IIF file through the validator to catch structural errors, column mismatches, and encoding issues instantly.
Open IIF Validator →Table of Contents
Column Count Mismatch
Symptom: Transactions silently skipped or import aborts partway through.
Cause: A data line has a different number of tab-separated fields than its header line defined. If your !TRNS header declares 10 columns but a TRNS data line has 9 or 11 fields, QuickBooks will reject that record.
Common source: Fields containing tabs or that were incorrectly split during export. Memo fields are the most frequent culprit — if a memo contains a tab character, it will appear to the parser as an additional field, pushing every subsequent field out of position.
Fix: Open the file in a text editor that shows tab characters. Count the fields on the header line and verify every data line matches exactly. Strip or replace tab characters inside field values.
Unclosed Transaction Block
Symptom: Import fails entirely or stops after a certain point with no transactions imported.
Cause: A TRNS line is not followed by ENDTRNS before the next TRNS begins, or the file ends before the final ENDTRNS.
Fix: Search the file for all occurrences of TRNS (not !TRNS) and count that each one is followed by at least one SPL and one ENDTRNS before the next TRNS appears. The IIF Validator reports the exact line number of any unclosed block.
Missing Header Line
Symptom: An entire record type is skipped — for example, no accounts or no items are imported.
Cause: Data lines of a given type appear in the file before their corresponding !-prefixed header line. The header must come first.
Fix: Ensure every record type's header line (!TRNS, !SPL, !ACCNT, etc.) appears in the file before any data lines of that type. It is common to declare all headers at the top of the file as a block, then write all data. Some generators write headers inline immediately before each batch of records — that is also valid as long as the header precedes its data.
Missing Required Fields
Symptom: Specific transactions are silently skipped.
Cause: A TRNS line is missing ACCNT, AMOUNT, or DATE. A SPL line is missing ACCNT or AMOUNT. These fields must be present and non-empty.
Fix: Check that your export or generator is populating these fields for every record. A field that is included in the header but left empty in a data line still counts as present — the column exists, it just has no value — and QuickBooks will reject the record for the empty required field.
Invalid Date Format
Symptom: Transactions are rejected or imported with a date of 1/1/1900 (QuickBooks default for an unparseable date).
Cause: Date fields are not in the expected M/D/YY or M/D/YYYY format. ISO format (2024-03-15), European format (15/3/2024), zero-padded months (03/15/2024), and long-form dates (March 15, 2024) all fail.
Fix: Reformat dates to match QuickBooks' expected format. In Excel, use TEXT(A1,"M/D/YYYY"). In Python, use date.strftime("%-m/%-d/%Y") (Linux/Mac) or date.strftime("%#m/%#d/%Y") (Windows). In SQL Server: FORMAT(date_col, 'M/d/yyyy').
Invalid Amount Format
Symptom: Amount fields fail validation; transactions skipped or imported with zero amounts.
Cause: Amount fields contain currency symbols ($), thousands separators (1,500.00), parentheses for negatives ((150.00)), or non-numeric text.
Fix: Strip all formatting from amount fields. Amounts must be plain numeric: 1500.00, -150.00, 0. Negative values use a leading minus sign only.
Encoding and BOM Issues
Symptom: First line of the file is misread; first record type is not recognized; import fails immediately.
Cause: The file was saved with a UTF-8 BOM (byte order mark — the three bytes EF BB BF prepended by some editors and programming environments). QuickBooks' IIF parser reads the BOM as part of the first token, turning !ACCNT into !ACCNT, which it does not recognize.
Fix: Save without BOM. In Notepad++: Encoding menu → "Encode in UTF-8 (without BOM)". In Python: open files with open(path, 'w', encoding='utf-8') rather than 'utf-8-sig'. In Excel: save as CSV and convert — Excel does not write BOMs to CSV. The IIF Validator detects BOM presence and flags it explicitly.
Also watch for null bytes, which indicate binary data has been mixed into the file — typically caused by reading from a source with incorrect encoding and writing raw bytes as text.
Account Not Found
Symptom: Transactions are rejected with an error referencing an account name that cannot be found.
Cause: A transaction references an account by name (ACCNT field) that does not exist in the QuickBooks company file. IIF import does not create accounts on the fly from transaction data.
Fix: Either create the accounts in QuickBooks manually before importing transactions, or include an ACCNT section at the top of your IIF file that defines all referenced accounts. Import the account list section first if it is in a separate file. Account names are case-sensitive and must match exactly — including spacing and punctuation.
Diagnostic Workflow
When an IIF import fails, work through this sequence:
First, run the file through the IIF Validator. It will report structural problems — unclosed blocks, column mismatches, missing required fields, bad dates, bad amounts, and encoding issues — with specific line numbers. Fix those before attempting any import.
Second, try importing a minimal version of the file — a single transaction — to confirm the format is accepted. If one transaction imports successfully, the problem is in specific records rather than the overall structure.
Third, if certain records still fail after passing validation, check that all referenced accounts, items, customers, and vendors already exist in the company file. IIF validation cannot cross-reference against a live QuickBooks data file — only QuickBooks itself can verify that referenced names exist.
Fourth, check the QuickBooks error log after import. QuickBooks Desktop writes import results to a log file (iif_import_log.iif in the same directory as the imported file on older versions, or accessible through the import dialog). This log identifies which specific transactions were skipped.
