Sage X3 imports purchase orders through the POH template in the Imports function, and that template expects a structured file with a header level and line levels already filled in. PurchaseOrders does the part X3 will not do for you: it reads the supplier PO, whatever layout it arrives in, and returns the order number, supplier, dates, products, quantities and prices as clean CSV or Excel you can shape into the POH layout. Upload a real purchase order below.
Submit your purchase orders
Drop documents here, or click to file
Up to 50 files per batch
Uploading...
Sage X3 has a capable import engine. What it does not have is any way to read the PDF a supplier emailed you, and the X3 data model splits a purchase order line across more tables than most people expect.
Sage X3 stores order lines in PORDERQ for quantities and PORDERP for prices. Gross price and net price are on PORDERP, ordered quantity is on PORDERQ, and anyone who assumes a single line table builds the wrong import file on the first attempt.
X3 documents that the import module updates through objects, so every control that fires on manual entry fires on import too. A file that looks correct still fails if the supplier is inactive or the product is not referenced for the receiving site.
Sage publishes help pages for the sales order and receipt import templates but not for the purchase order template. There is no official column list to copy, so teams reverse engineer the layout instead of reading it.
Every one of those import mechanics assumes you already have the data in columns. Suppliers send PDFs, scans and photos, so someone reads each order and retypes it before the import file exists at all.
PurchaseOrders is a data capture layer. It reads a supplier purchase order and returns structured fields you can map into a Sage X3 import file. It does not connect to Sage X3, does not run GIMPOBJ, and does not write to PORDER or any other table. You stay in control of the import itself.
The AI pulls the order number, supplier, order date, currency, requested receipt date and buyer reference, which is the same set the PORDER header carries as POHNUM, BPSNUM, ORDDAT, CUR and DEMRCPDAT.
Every line comes back with the product reference, description, quantity, unit, unit price and discount, so you can populate the PORDERQ quantity columns and the PORDERP price columns from one extraction.
Supplier POs usually name the part the supplier way. That value maps to ITMREFBPS, the supplier product field, which matters when your ITMREF differs from what the supplier prints.
X3 import templates accept fixed length files, delimited files and XML. Start from CSV or Excel and shape it into whichever template format your instance uses.
The tables and abbreviations below are from the Sage X3 version 12 data model. Knowing which table holds which value is most of the work of building an import file.
| Table | Abbreviation | What it holds |
|---|---|---|
| PORDER | POH | Purchase order headers, keyed on POHNUM |
| PORDERQ | POQ | Order line quantities, keyed on POHNUM plus POPLIN plus POQSEQ |
| PORDERP | POP | Order line prices, keyed on POHNUM plus POPLIN plus POPSEQ |
| PORDERC | POC | Cumulative purchase orders before returns |
| PRECEIPT and PRECEIPTD | PTH and PTD | Receipt headers and receipt detail |
| PREQUIS and PREQUISD | PSH and PSD | Purchase requests and their detail |
| BPSUPPLIER | BPS | Suppliers, keyed on BPSNUM |
| ITMMASTER | ITM | Products, keyed on ITMREF |
| ITMFACILIT | ITF | Product-site records, which gate whether a product can be ordered to a site |
The extraction removes the typing. The import stays yours to run in X3, with your own template and your own controls.
Drag in the PDF, scan or photo exactly as the supplier sent it. There is no template to configure and no layout to teach the system first.
Tip: Multi-page orders and mixed suppliers in one batch are fine.
Check the order number, supplier, dates and the line table on screen. Correct anything the source document rendered badly before you export, which is far faster than finding it in an X3 import log.
Tip: Watch the unit of measure, because X3 tracks order, purchase and stock units separately.
Take the CSV or Excel output and arrange it into the level structure your import template expects, with the header group first and the line groups beneath it, then run it through the Imports function in X3.
Tip: Export one manually keyed PO with the Exports function first and use that file as your column map.
Purchase order headers are stored in PORDER, abbreviated POH, keyed on the order number POHNUM. The order lines are split across two tables: PORDERQ, abbreviated POQ, holds the line quantities and dates, and PORDERP, abbreviated POP, holds the line prices. Both line tables are keyed on POHNUM plus the line number POPLIN plus a sequence number.
X3 separates the quantity view of a line from the price view. PORDERQ carries ordered, purchase and stock quantities with their units and expected receipt dates, while PORDERP carries the gross price GROPRI, the net price NETPRI and nine discount and charge slots. A line can also be split into several delivery sequences, which is why both tables carry a sequence component in the key.
The standard purchase order import template code is POH, used in the Imports function GIMPOBJ, with templates themselves defined in the Import and export templates function GESAOE. Sage publishes help pages for the sales order template SOH and the receipt template PTH but not for POH, so the practical way to learn its layout is to export one manually keyed purchase order and read the file it produces.
Key one purchase order by hand in the Orders function, then run the Exports function with the POH template against it. The exported file shows you the exact field order and the group structure the import expects. This export first method is the standard approach precisely because Sage does not publish a POH field list.
An X3 import template is built from groups, each with a level. Level 1 is the main level and a level N plus 1 group is a sub-level of the level above it, so the purchase order header sits at level 1 and the line groups sit beneath it. Each group carries a code of up to five characters that appears in the file as a group header, and when a template has several groups that group separator is mandatory.
Because the import updates through the object layer, so the same validations that run on manual entry run on the import. The most common blockers are a supplier that is inactive or still flagged as a prospect, and a product that exists in ITMMASTER but has no product-site record for the receiving site. When the supplier-site referencing parameter is set to mandatory, X3 blocks the line outright.
Yes, but the sequence number assignment has to allow it. X3 assigns POHNUM automatically at the end of creation unless the sequence is set to manual, in which case you supply the order number yourself. Teams migrating historical orders normally switch that sequence to manual so the original numbers survive the load.
No. PurchaseOrders reads supplier purchase orders and returns the data as CSV, Excel, JSON or API output. It does not connect to Sage X3, does not run the Imports function, and does not write to PORDER, PORDERQ or PORDERP. You run the import in X3 yourself with your own template, which keeps your controls and audit trail intact.
No. Sage guidance is to treat delivered templates as reference only and to copy them before changing anything, naming the copy so it starts with the letter Z. That keeps your custom template clear of anything a Sage update might overwrite, and it leaves the standard template available as a known-good baseline when an import misbehaves.
Sage 100 and its Visual Integrator import.
Sage 50 and Sage Intacct PO imports.
Purchasing transactions into Intacct.
Turn a PO into plain CSV columns.
The general ERP load pattern.
Capture the full line table.
Process many POs in one batch.
