Sage 100 imports purchase orders through Visual Integrator, which reads a delimited file and writes it into the Purchase Order module as a header record plus its detail lines. Visual Integrator will not open a supplier PDF. PurchaseOrders reads the PDF, the scan, or the phone photo and returns the header fields and the full line-item table as Excel, CSV, or JSON, so the file your import job picks up was built by a machine rather than keyed by a buyer. Upload a real purchase order below and see what comes back.
Submit your purchase orders
Drop documents here, or click to file
Up to 50 files per batch
Uploading...
Visual Integrator is a capable loader and the Purchase Order module is well documented. Neither of them solves the part that actually costs the money, which is that the order arrived as a document and the import wants a table.
Sage documents Visual Integrator as accepting data from spreadsheets, ASCII text, and other accounting products, and recommends saving spreadsheets as CSV before importing. A supplier PDF is none of those. Somebody reads one window and types into another before the job has anything to run against.
A purchase order in Sage 100 is a header record and a set of detail lines, and Visual Integrator treats that as a header-line table pair. A forty-line order is not one row to key, it is one header and forty lines, each with its own item code, quantity, and unit cost.
Sage is explicit about this: any data item that is not imported or assigned a value will be automatically set to blank. A partial source file does not fail loudly, it succeeds quietly and leaves you with orders missing terms, warehouse, or requested-by data that somebody has to go back and fix.
Sage states that if a purchase order is being received or invoiced, it cannot be maintained. Getting the order in wrong is not a five-second correction later in the month, so accuracy at the point of entry is worth more here than in systems that let you edit freely.
Long item descriptions cut off at thirty characters unless the Skip Data Truncation option is selected on the import job. Nothing about the imported order looks wrong on screen until a buyer or an auditor goes looking for the detail that used to be there.
A migration off MAS 90 or MAS 200, an acquired branch on a different system, or a quarter of emailed supplier orders all land together. The Visual Integrator side of that runs in minutes. The keying in front of it runs for weeks.
PurchaseOrders is the capture step in front of your import job. It is not a Sage connector, it does not install in Sage 100, and it does not run Visual Integrator for you. You give it a purchase order document. It gives you back clean field-level data you map once and load with the tools Sage already ships.
A digital PDF from a supplier portal, a scan of a mailed order, or a photo taken at a receiving desk. All go through the same extraction, with no per-supplier template to build first.
PO number, vendor, order date, requested by, ship-to, terms, and the line grid: item code, description, quantity ordered, unit of measure, unit cost, and extended amount, captured across page breaks.
Sage recommends converting spreadsheets to CSV before a Visual Integrator import because older spreadsheet formats do not always save cleanly. Export straight to CSV and skip that step entirely.
Pull the same extraction as JSON and build the header and detail files programmatically, or feed whatever already talks to Sage, whether that is a scheduled script, a middleware job, or your own Business Object code.
Upload a stack of orders at once rather than one at a time. That is what turns a migration or a quarter of emailed POs into a same-day job instead of a temp-staffing problem.
Captured fields are shown on screen so you can correct an odd quantity or cost before you export. Fixing it here costs seconds. Fixing it after the order has been received costs a good deal more.
Sage 100 Purchase Order Entry handles more than one kind of document. Sage lists standard purchase orders, blanket master orders, repeating orders, drop-ship orders, and material requisitions, and the order type is a header field, so it has to be right in your source data rather than assumed. The header carries order number, order date, and order type, then vendor number, requested by, department, customer number, terms code, ship via, FOB, warehouse, and contact details including telephone, fax, and email. Useful detail if you are planning a load: Sage retrieves vendor name, purchase address, 1099 information, sales tax information, and terms code automatically from the Vendor file, so those are fields you generally do not need to carry in the import at all. The Lines tab holds item code, quantity ordered, quantity back ordered, received and invoiced quantities, unit cost, and extension amount, plus job number, cost code, and cost type when the Job Cost module is integrated.
A Sage 100 purchase order is not stored as one flat record. The header lives in PO_PurchaseOrderHeader and the lines in PO_PurchaseOrderDetail, and each detail line carries a LineKey that fixes where it sits in the order. That matters in two directions. When you create new orders, the line keys are assigned for you. When you are updating an order that already exists, you have to know the current line keys, because a job that assigns fresh keys will add new lines rather than change the ones already there. It is the single most common way a Sage 100 purchase order import produces duplicates instead of updates.
Sage describes the assignment sequence plainly, and it is worth internalizing before you build the job: key fields are assigned first, then the remaining fields in the header or standard record, then the line fields are assigned to the line record if the import is a header-line table pair. Practically, that means your source file needs to be at line grain, with the order number repeated on every line, so that the job can tie each line back to the header it belongs to. That is exactly the shape an extraction produces, and it is exactly the shape a human reading a PDF does not naturally type.
Two Visual Integrator behaviors catch people out. The first is the blank rule: any data item that is not imported or assigned a value will be automatically set to blank. Your import does not warn you that terms code was missing, it simply writes an empty one. The second is truncation: extended item descriptions longer than thirty characters are cut unless the Skip Data Truncation option is selected on the job. Both of these fail silently, which is why the quality of the file you feed the job matters more than the job itself. Sage also notes that record perform logic is required to create batch numbers for import jobs in some modules, so if your process depends on batches, check that before your first production run.
Four different products get searched with nearly the same words, and their purchase order handling is genuinely different. Sage 100, formerly MAS 90 and MAS 200, is the midmarket distribution and manufacturing ERP this page is about, with a Purchase Order module and Visual Integrator as its import tool. Sage 100 Contractor is a separate construction product with its own purchase order screens. Sage 50 is the small-business accounting product, and Sage Intacct is the cloud financial platform with its own purchasing module and its own import service. If you are on one of the others, the extraction step is identical but the load step is not: see purchase order to Sage and purchase order to Sage Intacct.
To be plain about the boundary: PurchaseOrders extracts purchase order data from documents into a structured file. It is not a Sage 100 integration, it does not install in Sage, it does not build or run your Visual Integrator job, it does not write to PO_PurchaseOrderHeader or PO_PurchaseOrderDetail, and it does not create, approve, receive, or match purchase orders. All of that stays in Sage 100. We remove the typing that happens before the import, and nothing else.
Distributors whose suppliers send order confirmations as PDFs use it so those figures reach the Purchase Order module the same day. Manufacturers migrating off MAS 90 or MAS 200 use it to build the open-order file rather than keying a year of history. Buyers reconciling a supplier acknowledgment against what was ordered use the purchase order PDF to Excel converter to get both sides into a spreadsheet. Integration teams wiring an orders mailbox into their own Sage tooling use the purchase order API so their code receives JSON rather than an attachment, and row-level accuracy on long material orders is covered in purchase order line item extraction. A migration backlog clears through bulk purchase order upload, and the general load pattern across ERPs is in how to import purchase orders to an ERP.
Sage 100 Purchase Order Entry splits an order across a header and a set of detail lines. This is the grain your source file has to reach before an import job is any use.
| On the supplier PO | Sage 100 Purchase Order Entry field | Header or Lines | Notes |
|---|---|---|---|
| PO number | Order Number | Header | Repeat it on every line row in your source file |
| Order date | Order Date | Header | Order Type sits beside it and has to be set explicitly |
| Supplier | Vendor No. | Header | Name, address, 1099 and tax data are pulled from the Vendor file |
| Buyer or requester | Requested By | Header | Left blank if your file does not carry it |
| Payment terms | Terms Code | Header | Also defaulted from the Vendor file when not supplied |
| Ship-to location | Warehouse | Header | Ship Via and FOB sit alongside it |
| Line item code | Item Code | Lines | One row per line item, not one row per order |
| Line quantity | Quantity Ordered | Lines | Back ordered, received and invoiced are tracked separately |
| Line unit price | Unit Cost | Lines | Extension Amount follows from cost and quantity |
| Line description | Item description | Lines | Cut at 30 characters unless Skip Data Truncation is set |
PurchaseOrders.io extracts purchase order data into Excel, CSV, JSON, or an API response that you map into a Visual Integrator job. It is not a Sage connector, does not install in Sage 100, does not build or run import jobs, and does not create, receive, or match purchase orders.
No templates to build, no changes inside Sage 100.
Drag in PDFs, scans, or photos, one at a time or a whole batch pulled from the purchasing mailbox or a migration folder.
Tip: Mixed suppliers and mixed file types in the same upload are fine.
The AI reads each order and returns the header fields and the complete line grid in seconds, one row per detail line.
Tip: Check the captured values on screen, because a received order can no longer be maintained in Sage.
Download CSV, point your Visual Integrator job at it, assign key fields first and the header and line fields after, then run the job. Every later batch reuses the same mapping.
Through a Visual Integrator import job pointed at a delimited file. Build the file at line grain with the order number repeated on every line, assign key fields first, then the header fields, then the line fields to the line record. Sage recommends saving spreadsheets as CSV first, because older spreadsheet formats do not always save cleanly for import.
The header is PO_PurchaseOrderHeader and the lines are PO_PurchaseOrderDetail. Each detail line carries a LineKey that fixes its position in the order. When you update an existing order, you need the current line keys, because a job that assigns new keys adds lines instead of changing the ones already there.
Yes. Sage treats the purchase order as a header-line table pair, and the job assigns key fields first, then the header record fields, then the line fields to the line record. The usual reason lines do not appear is a mapping or record-creation setting on the job rather than a limit in Visual Integrator itself.
Sage lists standard purchase orders, blanket master orders, repeating orders, drop-ship orders, and material requisitions. Order type is a header field, so an import has to carry it. It is not inferred from the rest of the order.
Because that is the documented behavior. Any data item that is not imported or assigned a value is automatically set to blank. The import does not warn you that terms code or warehouse was absent from the source file, so an incomplete file produces incomplete orders that look fine until someone needs the missing field.
No. Sage 100, formerly MAS 90 and MAS 200, is the midmarket distribution and manufacturing ERP with the Purchase Order module described here. Sage 100 Contractor is a separate construction product with its own purchase order screens. Sage 50 and Sage Intacct are different products again.
No, and we would rather say so than imply otherwise. There is no Sage connector, nothing installs in Sage 100, and we never write to your data files. We turn a purchase order document into clean rows. Your Visual Integrator job, or whatever tooling you already use, does the loading.
Yes, that is one of the common cases. Upload the open orders as a batch, review the captured fields on screen, export one CSV at line grain, and load it with a single import job. The extraction does not care whether the document came from a legacy system, a supplier portal, or a filing cabinet.
The upper-tier Sage ERP: PORDER and POH.
Sage 50 and the wider Sage range.
The Intacct purchasing import.
Build the CSV your job reads.
Capture every detail line.
Clear a migration backlog in batches.
The general ERP load pattern.
Get the same data as JSON.