Business Central loads sales orders from a configuration package or the API without complaint.
PDF, JPG, PNG, BMP, HEIC, TIFF
Submit your purchase orders
Drop documents here, or choose a file
Up to 50 files per batch
Uploading...
Business Central loads sales orders from a configuration package or the API without complaint. It will not read the purchase order your customer emailed as a PDF. Upload that document here and get the customer PO number, the ship-to, and every line with quantity, unit and price, ready for Sales Header and Sales Line.
The import tools are fine. The hours go into turning a pile of customer PDFs into the rows those tools expect, one order at a time.
A distributor, a contractor and a hospital system all format a purchase order differently. Anything built on a fixed template breaks the first time a new account orders.
Customers order by their own codes. Each line has to land on one of your items before the package applies, and that lookup is where keying errors start.
The Sales Order Agent is documented for up to 15 item lines per document. A restocking order with 60 lines still needs another route.
Orders pile up over a weekend and all need entering before the warehouse can pick. A queue of PDFs is the bottleneck, not Business Central.
Upload the purchase order your customer sent. The AI reads the header and every line and returns them as structured data shaped for Sales Header and Sales Line, so loading becomes a mapping step instead of a typing job.
No template to build per customer. Works on digital PDFs, scans and photographed pages.
A 60-line order comes back as 60 rows with part number, description, quantity, unit of measure and unit price.
Header fields and line fields come out separately, which matches the Sales Header and Sales Line tables in a configuration package.
The customer PO number sits in its own column so it maps straight to External Document No., never to your order number.
Business Central gives you three standard routes for creating sales orders in bulk, and none of them reads a PDF on its own. The first is a configuration package built on table 36 (Sales Header) and table 37 (Sales Line). You export the package to Excel, fill in the rows, import the workbook, and then run Apply Package. Importing the workbook only updates the package; nothing lands in your company data until you apply it.
The second route is the API v2.0. You POST a salesOrder to /companies({id})/salesOrders with a customerNumber and an externalDocumentNumber, then POST each salesOrderLine with a lineType of Item, the item number and the quantity. The third route is the Sales Order Agent, which watches an Exchange shared mailbox and builds a sales quote from the email and any PDF attached to it.
All three need the same thing in front of them: the header and every line of the customer purchase order as clean, structured data. That is the part this page is about. You upload the PO, and you get rows you can drop into a configuration package, post to the API, or check against what the agent produced.
The buyer reference goes in External Document No. on the Sales Header, which the API exposes as externalDocumentNumber. It is not the sales order number. Business Central assigns that from your number series, so leave the No. column to the series unless you have a reason to control it. If Sales and Receivables Setup has Ext. Doc. No. Mandatory turned on, a missing reference will block posting later, which is one more reason to capture it from the document instead of typing it.
Because the extraction returns the customer PO number in its own column, mapping it to External Document No. is a single column assignment. It never gets confused with your own order numbering.
Most customer POs list the buyer part number, sometimes with your number beside it and often without. Business Central handles this with Item References: add a reference of type Customer, pick the customer, and store their part number against your item. Once those references exist, the lookup is a join rather than a judgment call.
The extraction keeps the part number printed on the PO exactly as written, along with the description, quantity, unit of measure and unit price. You map it against your Item References before you load, so an unknown code shows up as a gap in the spreadsheet instead of a failed line in the package.
If your orders arrive by email, are short, and come from customers whose contact cards already hold the sending address, the agent Microsoft ships is a reasonable first stop. Microsoft documents its limits plainly: up to 15 item lines per sales document, PDFs of 20 MB and 50 pages at most, contacts matched only by the sender email address, no new items or customers, no variant codes, and item lines only. It always creates a quote first. We cover the credit math in detail in Business Central Sales Order Agent pricing.
Orders that break those limits are where a capture layer earns its keep: a 60-line restocking order, a PO downloaded from a customer portal rather than emailed, a batch forwarded from a shared ops inbox (the agent looks up the forwarder, not the customer), or an on-premises Business Central with no agent at all. Those go through bulk purchase order upload, up to 50 files in one pass, and come back as one consistent file.
If part of the business runs on another ERP, the pattern repeats with different field names. See NetSuite sales order import for the Import Assistant route, SAP sales order upload for VA01 and the F4293 app, and QuickBooks sales order import for the Desktop and Online paths. For the buying side of Business Central, where you are the one issuing the PO, use purchase order to Business Central instead.
What comes off the customer document and where it goes. Field names follow the Business Central Sales Header and Sales Line tables and the API v2.0 salesOrder resource.
| Business Central field | API v2.0 property | Where it comes from | Notes |
|---|---|---|---|
| Document Type | n/a (salesOrders endpoint) | Always Order for this workflow. | Set once in the package |
| Sell-to Customer No. | customerNumber | The buying company, matched to your existing customer card. | Must already exist |
| External Document No. | externalDocumentNumber | The customer purchase order number printed on the PO. | Can be mandatory for posting |
| Order Date | orderDate | The PO date on the document. | Defaults to work date if blank |
| Requested Delivery Date | requestedDeliveryDate | The need-by or delivery date the buyer asked for. | Optional |
| Ship-to Name and Address | shipToName, shipToAddressLine1 | The delivery block on the PO. | Overrides the customer default |
| Sales Line Type | lineType | Item for product lines. | Item in almost every case |
| Sales Line No. | lineObjectNumber | The customer part number, mapped through Item References to your item. | Item must exist |
| Quantity and Unit of Measure | quantity, unitOfMeasureCode | Ordered quantity and unit on each line. | Per line |
| Unit Price | unitPrice | The price the buyer printed, useful for checking against your price list. | Business Central can price it instead |
Four steps from the customer attachment to a sales order in Business Central.
Drop in the PDF, the scan or the email attachment. Up to 50 files per bulk upload, with no per-customer setup.
Tip: Portal downloads and forwarded attachments work the same way.
Check the header and lines on screen, then map customer part numbers to your items through Item References and customer names to customer numbers.
Tip: Keep the mapping sheet; it is reused on every order from that account.
Take Excel or CSV with header and lines split, or pull JSON through the API if you post to Business Central directly.
Tip: Line No. usually steps by 10000 so lines can be inserted later.
Paste into the configuration package workbook for tables 36 and 37, import, then Apply Package. Or POST each order and its lines to API v2.0.
Tip: Validate the package before applying; errors are listed per table.
Use a configuration package with table 36 (Sales Header) and table 37 (Sales Line). Export the package to Excel, fill in one header row per order and one line row per item, import the workbook, validate, then choose Apply Package. Importing the workbook alone does not create any orders. The API v2.0 salesOrders endpoint is the programmatic alternative.
Yes, through a configuration package. The Excel file is the package export, not a free-form sheet, so the columns must match the fields you added to tables 36 and 37. Document Type, Document No. and Line No. link each line to its header.
In External Document No. on the Sales Header, exposed in the API as externalDocumentNumber. The sales order number itself comes from your number series. If Ext. Doc. No. Mandatory is turned on in Sales and Receivables Setup, posting fails without it.
Yes. It processes PDF and image attachments on emails in its monitored Exchange shared mailbox, with PDFs up to 20 MB and 50 pages. It creates a sales quote first and supports up to 15 item lines per document, according to Microsoft documentation.
Create Item References of type Customer. Each reference stores the customer, their part number and your item number, so an imported line with the buyer code can be resolved to the right item before the package is applied.
Yes. POST a salesOrder to companies({company id})/salesOrders with at least the customerNumber, then POST salesOrderLines with lineType Item, the item number and the quantity. The salesOrder resource also has a shipAndInvoice bound action.
Usually because the workbook was imported but the package was never applied, or because validation errors on table 36 blocked the headers. Open the package, review the error count per table, fix the rows, then run Apply Package again.
Yes. The extraction runs outside Business Central and returns a file, so the version does not matter. Configuration packages exist on both online and on-premises, while the Sales Order Agent relies on Copilot Credits and the online service.
No. PurchaseOrders reads the customer purchase order and returns structured data as Excel, CSV or JSON. It does not install in Business Central, does not apply packages and does not post or release orders. You load the rows through your own package, API call or integration.
The same workflow on D365 Supply Chain.
The same workflow on Odoo.
The buying side: POs you issue.
The same workflow on NetSuite.
The same workflow on SAP.
The same workflow on QuickBooks.
Choose your plan