QuickBooks Desktop imports purchase orders through an IIF file. QuickBooks Online has no native purchase order import at all, so the order has to be keyed in by hand or posted by a third party app through the QuickBooks API. Both routes need the order sitting in clean columns before anything can be loaded. PurchaseOrders handles that part. It reads the supplier purchase order in whatever layout it arrived in and returns the PO number, vendor, dates, item codes, quantities and rates as Excel or CSV. Upload a real purchase order below.
Submit your purchase orders
Drop documents here, or click to file
Up to 50 files per batch
Uploading...
Most accounting imports are a spreadsheet upload. Purchase orders in QuickBooks are not, and the reason catches out finance teams who have imported customers and vendors without trouble.
The built in import tools in QuickBooks Online cover customers, vendors, products and services, chart of accounts and bank data. Purchase orders are not on that list. Inside QuickBooks Online the only supported route is typing each order into the Purchase Order form, which is why so many searches for this end in a third party app.
The desktop editions do import purchase orders, but through the IIF format rather than a CSV or Excel upload. IIF is a tab delimited text file with its own header rows, and it is unforgiving: a column in the wrong order or a name that does not already exist in the company file will break the load.
A purchase order with eight items is not eight spreadsheet rows. A TRNS row opens the order, one SPL row follows for every item line, and an ENDTRNS row closes the block. Teams who build the file as a flat table find QuickBooks either rejects it or posts something that does not match the supplier document.
None of the above matters until the data is actually in columns. The order arrives as a PDF attachment, a scan or a photo from a phone, and every value the import needs has to come out of that document first. In most AP and purchasing teams that step is still done by retyping.
PurchaseOrders is a document data capture layer. It reads a purchase order and returns structured fields you can shape into an IIF block, hand to an import app, or push through your own integration. It does not connect to QuickBooks, does not run the import, does not write to your company file and does not post through the QuickBooks API. The load stays yours to run.
The AI pulls the PO number, vendor, order date, expected delivery date, ship to address, payment terms, currency and totals, which covers the header values any QuickBooks purchase order needs before the lines are dealt with.
Each line comes back with the item code, description, quantity, rate and amount. Those are exactly the values that become the SPL rows in an IIF block or the line array in an API payload, so one extraction covers the whole order.
Supplier documents print the vendor part number, not the item name sitting in your QuickBooks item list. Keeping that value is what lets you map it to your own item before the import, and a missing map is the most common reason an otherwise clean file fails.
A one time cleanup is easiest from Excel. An IIF build wants tab delimited text. An import app usually wants CSV. A scripted daily feed wants JSON. The same extraction feeds all four, so the route can change later without redoing the capture.
Which of these applies depends almost entirely on whether you run QuickBooks Desktop or QuickBooks Online. The split is the single most useful thing to establish before you start.
| Route | Works with | What it takes | Watch out for |
|---|---|---|---|
| IIF file | QuickBooks Desktop | A tab delimited file using the TRNS, SPL and ENDTRNS row structure | There is no undo. Back up the company file before every import |
| Manual entry | Desktop and Online | Typing the order into the Purchase Order form | The only route Intuit supports natively in QuickBooks Online |
| Third party import app | Mainly QuickBooks Online | An app that posts purchase orders through the QuickBooks API | A per record or monthly cost, plus a column mapping step of its own |
| qbXML and Web Connector | QuickBooks Desktop | A request built against the QuickBooks Desktop SDK | Developer work rather than a finance team task |
| Extract then load | Desktop and Online | Capture the PO data first, then feed whichever route above applies | Still needs one of the routes above to actually post the record |
The extraction removes the retyping. The import itself stays inside QuickBooks, under your own user permissions and your own audit trail.
Drag in the PDF, scan or photo exactly as the supplier sent it. There is no template to build first and no layout to teach the system in advance.
Tip: Multi page orders and a batch of mixed vendors are both fine.
Check the PO number, vendor, dates and the line table before exporting. Correcting a quantity here takes seconds. Finding it after an IIF import has already posted to the company file takes far longer, because IIF imports cannot be rolled back.
Tip: Check the unit of measure. A case against each mismatch posts a valid but wrong order.
Download Excel or CSV. For QuickBooks Desktop, shape it into the IIF block structure and import it from the File menu. For QuickBooks Online, hand the same file to whichever import app you use.
Tip: Run the first pass on two or three orders before loading a full batch.
Not through the built in import tools. QuickBooks Online can import customers, vendors, products and services, the chart of accounts and bank transactions, but purchase orders are not a supported import type. The two working options are entering each order manually in the Purchase Order form or using a third party app that posts purchase orders through the QuickBooks API.
Through an IIF file. Build a tab delimited file that opens each order with a TRNS row, follows it with one SPL row for every item line, and closes it with an ENDTRNS row, then import it from the File menu. Back up the company file first, because an IIF import cannot be undone once it posts.
IIF, which stands for Intuit Interchange Format. It is a plain tab delimited text file rather than a spreadsheet, and it uses header rows beginning with an exclamation point to define the columns for each row type. Intuit publishes an IIF import kit with sample files and header references for building one.
Not directly. QuickBooks will not read an .xlsx or .csv file as purchase orders. Excel is still the practical place to assemble and check the data, but the file has to be saved out as tab delimited IIF for QuickBooks Desktop, or handed to an import app for QuickBooks Online.
Usually because the block structure is wrong. Every order needs exactly one TRNS row, at least one SPL row, and a closing ENDTRNS row. Building the file as a flat table with one row per line item is the most common mistake, and it produces either a rejected file or orders that do not match the supplier document.
Yes on QuickBooks Desktop. A single IIF file can hold many purchase orders, one TRNS to ENDTRNS block per order, and QuickBooks processes them in sequence. Test with two or three orders before running a full batch, because a failure partway through leaves the earlier orders already posted.
At minimum the transaction type, the date, the vendor name, and a line for every item with its quantity and rate. Names matter more than anything else: the vendor and every item have to already exist in the company file, spelled exactly as they are stored, or the row will not match.
No. PurchaseOrders reads purchase order documents and returns the data as Excel, CSV, JSON or through an API. It does not connect to QuickBooks, does not write to your company file and does not post through the QuickBooks API. You take the extracted file and run the import yourself through whichever route your edition supports.
No. IIF imports post straight into the company file with no batch level rollback, so the only real safety net is the backup you take beforehand. Restoring that backup is the supported way to reverse a bad import, which is why testing on a small batch first is worth the extra few minutes.
The CSV Import Assistant route for NetSuite.
The same job on the Xero side.
Sage import formats for PO data.
Turn a PO into a plain spreadsheet.
Delimited output for file builds.
Clear a backlog in one pass.
The general ERP load pattern.
Same fields as JSON for a scripted feed.
