IIF File QuickBooks Desktop: Purchase Order Import Format
Aug 23, 2026
Aug 23, 2026
Convert a purchase order to Excel, CSV, or JSON
Submit your purchase orders
Drop documents here, or click to file
Up to 50 files per batch
Uploading...
An IIF file is a tab delimited text file, and it is the only built in way to import a purchase order into QuickBooks Desktop. A purchase order is not one row in that file. It is a block: one TRNS row that opens the transaction, one SPL row per item line, and an ENDTRNS row that closes it. Building it as a flat table is the single most common reason an IIF purchase order import fails or, worse, succeeds quietly with the wrong data.
Last updated August 2026.
This is a field level reference rather than a walkthrough. It covers what the row types mean, which columns a purchase order actually needs, the transaction type keyword, and the handful of failure modes that cost people the most time, including the ones QuickBooks does not warn you about.
IIF stands for Intuit Interchange Format. It is a plain text file with tab separated values that QuickBooks Desktop can read to create list records and transactions. Rows beginning with an exclamation mark are header rows that declare the column order, and the data rows that follow are matched to those columns by position. It is an old format, and it shows: there is no schema validation, no type checking, and very little error reporting.
Two properties matter more than anything else in this article. The first is that IIF is positional, so a column in the wrong place lands its value in the wrong field without complaint. The second is that IIF import does only limited error checking, which means a malformed file can import incorrectly and report no error at all.
Every transaction in an IIF file is written as a block of three row types. The header rows are declared once at the top of the file, then each transaction repeats the pattern.
| Row type | What it is | How many |
|---|---|---|
!TRNS / TRNS | Opens the transaction and carries the header level values: type, date, vendor name, document number, total. | Exactly one per transaction |
!SPL / SPL | A split, which for a purchase order is one ordered item line with its quantity, price and item name. | One or more per transaction |
!ENDTRNS / ENDTRNS | Closes the block. Nothing follows it for that transaction. | Exactly one per transaction |
The header rows are the schema. If your !SPL header declares twelve columns, every SPL data row must supply twelve tab separated fields, even where several are empty. Trailing empty fields are the thing spreadsheet exports strip and IIF files need.
Here is the shape of a two line purchase order. The gaps between values are single tab characters, not spaces, which is the detail that breaks most hand built files.
!TRNS TRNSID TRNSTYPE DATE ACCNT NAME AMOUNT DOCNUM MEMO
!SPL SPLID TRNSTYPE DATE ACCNT NAME AMOUNT MEMO QNTY PRICE INVITEM
!ENDTRNS
TRNS PURCHORD 07/15/2026 Purchase Orders Acme Supply Co -1250.00 PO-4471 July restock
SPL PURCHORD 07/15/2026 Purchase Orders Acme Supply Co 900.00 60 15.00 Widget-A
SPL PURCHORD 07/15/2026 Purchase Orders Acme Supply Co 350.00 14 25.00 Widget-B
ENDTRNSThree things in that block are worth reading closely. TRNSTYPE is PURCHORD, which is the keyword for a purchase order. The ACCNT value is the non posting Purchase Orders account, not an expense or inventory account. And the TRNS amount carries the opposite sign to the sum of the splits, which is the balancing rule IIF applies to every transaction type.
Intuit documents a long column list, but only a few are genuinely required. The rest are optional and safe to leave empty as long as the tab positions are preserved.
| Column | Row | Required | Notes |
|---|---|---|---|
TRNSTYPE | TRNS and SPL | Yes | PURCHORD for a purchase order. The same value repeats on the split rows. |
DATE | TRNS | Yes | Use the format your Windows regional settings expect, usually MM/DD/YYYY. A mismatched locale silently shifts day and month. |
ACCNT | TRNS and SPL | Yes | The Purchase Orders non posting account. See the warning below about what happens when the name does not already exist. |
AMOUNT | TRNS and SPL | Yes | Signed. The TRNS amount equals the sum of the SPL amounts with the sign reversed. |
NAME | TRNS | In practice | The vendor. Must match a Vendor list entry character for character. |
DOCNUM | TRNS | No | Your purchase order number. Leave it out and QuickBooks assigns its own. |
QNTY | SPL | For item lines | Quantity ordered. |
PRICE | SPL | For item lines | Unit cost. AMOUNT should equal QNTY multiplied by PRICE. |
INVITEM | SPL | For item lines | The item name, which must already exist on the Item list. |
TRNSID / SPLID | Both | No | Leave blank on import. QuickBooks assigns these. |
MEMO | Both | No | Free text, useful for carrying the supplier reference. |
Because a purchase order is non posting. It records an intent to buy, so it does not touch the general ledger, does not affect expenses, and does not change inventory quantities until you receive against it. QuickBooks tracks these in a dedicated non posting Purchase Orders account.
That is why an IIF purchase order points its ACCNT at Purchase Orders rather than at the expense or inventory asset account you might expect. People who copy an invoice or bill template and swap the TRNSTYPE usually get this wrong, and the result is a transaction that posts to the ledger and double counts the expense once the actual bill arrives.
Open the company file as the Admin user, switch to single user mode, then go to File, then Utilities, then Import, then IIF Files, and select your file. Newer QuickBooks Desktop versions route you through an improved importer that writes a log of rows it could not read, which is a real improvement over the older behavior of failing silently. Back up the company file first. There is no undo.
Import the supporting lists before the transactions. Vendors and items should exist as list records before any PURCHORD block references them, because the alternative is QuickBooks inventing them for you, which is the next section.
These are ordered by how much cleanup they cause, not how often they happen.
| Symptom | Actual cause | Fix |
|---|---|---|
| A new bank account appeared in the chart of accounts | The ACCNT value in the file did not match an existing account. QuickBooks does not reject the row, it creates the account, and it defaults the new account to a bank type. | Create the account first, or correct the spelling. Then delete the account QuickBooks invented before it collects transactions. |
| The import ran, no error, but the data is wrong | IIF does only limited error checking. A column count mismatch shifts every later value one field to the left or right and nothing warns you. | Count the tabs on a data row against its header row. Then check the imported transaction on screen against the source. |
| Duplicate vendors or items with near identical names | List names must match character for character including spacing, punctuation and case. Acme Supply Co and Acme Supply Co. are two vendors. | Export the existing lists first and build the file from those exact strings rather than from what the supplier wrote. |
| Amounts rejected or the transaction refuses to balance | The TRNS amount does not equal the sum of the SPL amounts with the sign reversed, or a currency symbol or thousands separator crept into the value. | Write amounts as bare signed decimals. Recompute the TRNS total from the splits rather than copying it from the PDF. |
| Dates land in the wrong month | IIF reads dates using the Windows regional setting on the importing machine, so a file built as DD/MM/YYYY imports as MM/DD/YYYY on a US machine. | Standardize on MM/DD/YYYY and spot check any order dated on or before the twelfth of a month. |
The first one deserves emphasis because it is quiet and it compounds. An account created by an IIF import is a bank account, it appears on the balance sheet, and if a later import references the same misspelling it keeps using it. By the time anyone notices, several months of transactions may point at an account nobody meant to create.
No. IIF is a QuickBooks Desktop format and QuickBooks Online neither imports nor exports it. QuickBooks Online also has no native purchase order import of any kind, so a purchase order there is either keyed into the form by hand or created through the QuickBooks API by a third party app. Files that claim to convert IIF for QuickBooks Online are really converting it into something an app or the API can post.
This trips people up during a Desktop to Online migration, because the purchase orders are usually the records that do not come across. Open orders normally have to be re entered or recreated through an app.
Intuit publishes an IIF import kit containing sample files and a header reference, and it is the right starting point because the samples show the exact column order QuickBooks expects. The more reliable trick is to build the template from your own company file: create one purchase order by hand in QuickBooks, export it to IIF, and use the resulting header rows as your template. That guarantees the account names, item names and column set match the file you are importing into.
There is no undo for an IIF import. QuickBooks does not group imported records into a reversible batch, so backing out a bad import means deleting the transactions one by one or restoring the backup you took before running it. Take the backup. On a batch of a few hundred purchase orders, restoring is minutes and manual deletion is an afternoon.
The safe pattern is to import two or three orders first, look at them in the Purchase Order form, confirm the vendor, dates, quantities and the item lines, and only then run the full batch.
The format is the easy half. The harder half is that the source purchase order is usually a PDF from a supplier or a customer, and someone has to turn it into the exact columns above. That is where the hours go, and it is also where the transcription errors that later look like import bugs are introduced.
Extracting the header and every line item first, then building the block structure from clean columns, removes most of the risk: quantities and prices are read once rather than retyped, and the line count can be checked against the document before anything reaches the company file. The QuickBooks purchase order import page covers the routes into Desktop and Online in full, and converting a purchase order PDF to Excel is the usual first step. Because IIF needs one row per item, accurate purchase order line item extraction is what makes the SPL rows reliable, and a migration backlog is faster through bulk purchase order upload. If the destination is a different system entirely, importing purchase orders to an ERP follows the same header and line pattern.
IIF is not the only legacy Intuit format that causes this kind of trouble. On the banking side the same era produced QIF, and getting an old Quicken export into a form QuickBooks will actually accept means converting the QIF file into a balanced QBO file rather than editing it by hand. Same lesson: these formats are positional and unforgiving, so generate them rather than typing them.
PURCHORD. It goes in the TRNSTYPE column on the TRNS row that opens the block, and it repeats on each SPL row inside that block. Using a different keyword, for example BILL or INVOICE, creates a posting transaction that hits the general ledger instead of a non posting purchase order.
Tab delimited. IIF uses a single tab character between fields, which is why saving one from Excel means choosing Text (Tab delimited) rather than CSV. Saving as CSV produces commas and QuickBooks will read the entire row as a single field, so the import either fails outright or creates a garbled record.
You can, but it is the main source of corrupted files. Excel strips trailing empty columns, reformats dates to its own locale, converts long numbers to scientific notation, and may add quotation marks on save. A plain text editor is safer. If you must use Excel, import as text, keep every column as Text, and save as Text (Tab delimited).
There is no documented limit, and files with several thousand transactions import routinely. The practical constraint is error recovery rather than size: a single malformed block in a large file can be awkward to locate. Splitting a large migration into batches of a few hundred, with a backup between them, makes a bad batch cheap to roll back.
Most often the transaction imported against the wrong account, so it exists but not as a purchase order. Check that TRNSTYPE is PURCHORD and that ACCNT is the non posting Purchase Orders account. Also confirm the vendor name matched an existing vendor, because a mismatch can file the order under a newly created name you are not looking at.
Stop retyping purchase orders
Upload a PDF, scan, or photo of any PO and get clean Excel, CSV, or JSON line items in seconds.
Try it free25 pages free. No credit card required.