Acumatica creates sales orders from a spreadsheet through an import scenario on the Sales Orders form (SO301000), or through the REST API.
PDF, JPG, PNG, BMP, HEIC, TIFF
Submit your purchase orders
Drop documents here, or choose a file
Up to 50 files per batch
Uploading...
Acumatica creates sales orders from a spreadsheet through an import scenario on the Sales Orders form (SO301000), or through the REST API. Neither reads the PDF your customer emailed. Upload that purchase order here and get the customer PO number, the dates and every line with item, quantity, unit and price as rows your scenario can map.
The import scenario is fast once the spreadsheet is right. Getting a customer PDF into that spreadsheet is where the order desk loses the morning.
A data provider points at an Excel or CSV file. A purchase order that arrives as a PDF from a buyer ERP or a portal has to become rows first, and today someone types them.
If every row carries the same Order Nbr value, Acumatica builds one sales order out of the whole file. The value has to change from one customer order to the next.
Customers order by their own codes. An Inventory ID that does not exist in Acumatica fails the order, so every line needs mapping to your item first.
A 70-line replenishment order is 70 chances to skip a line or swap a quantity. Nothing in the import flags a line that was never typed.
Upload the purchase order your customer sent. The AI reads the header and every line and returns a spreadsheet with one row per line, the header values repeated on each row, ready for the data provider behind your sales order import scenario.
No per-customer template. Digital PDFs, scans and photographed pages from any buyer system come back in the same column layout.
A 70-line order returns 70 rows with part number, description, quantity, unit of measure and unit price, in document order.
The buyer PO number lands in a dedicated column for Customer Order Nbr., and doubles as the value that separates one order from the next in your file.
Order date and the requested delivery date come off the document, so Date and Requested On are filled from the source instead of defaulted.
Acumatica gives you two routes. The first is the import scenario. You define where the data comes from on the Data Providers form (SM206015), map provider columns to fields on the target screen on the Import Scenarios form (SM206025), and run the load on the Import by Scenario form (SM206036), where Prepare reads the file and Import writes the records. For sales orders the target screen is Sales Orders (SO301000). If you upload a file and set up the mapping directly on Import by Scenario, Acumatica creates the matching data provider and scenario for you, which is the quickest way to start.
The second route is the contract-based REST API, where an integration writes the SalesOrder entity of the Default endpoint. That suits a system integrator or an order portal. For an order desk that receives purchase orders by email, the scenario is the practical route, and it assumes the order already exists as clean rows. Most customer POs in the United States arrive as a PDF produced by someone else's ERP, a portal download or a scan. That document is the gap this page fills.
The single most common failure on the Acumatica community forum is a scenario that creates one sales order instead of many. The cause is almost always the order number. If the Order Nbr. mapping holds a fixed value, every row in the file belongs to the same order. The value has to come from the file and change between orders. With automatic numbering on the SO order type the actual number does not matter, because Acumatica assigns its own; the column only has to be identical on every line of one order and different on the next. The customer PO number is a natural choice, since it is already unique per order and already sits on every row we return.
The Sales Orders form has a dedicated field for it, Customer Order Nbr., on the summary area next to the customer. Put the buyer PO number there, not in the description, and your team can find the order when the customer calls with only their own number. It also carries forward to the shipment and invoice documents that follow from the sales order, so the customer sees the reference they expect on your paperwork.
Each row becomes a line on the Details tab, with Inventory ID, Quantity, UOM and Unit Price. The Inventory ID must already exist, and customers order by their own part numbers, so keep a mapping sheet per account from buyer code to your item and apply it to the extracted rows before the import. The extraction keeps the part number exactly as printed next to the description, so an unmapped code shows up as a blank cell you can fix rather than a failed order. Forum threads report that one bad Inventory ID can stop the import, and that Acumatica support has helped customers set scenarios up so only the order with the bad item fails while the rest load. Mapping first avoids the problem entirely. If you leave Unit Price unmapped, Acumatica prices the line from your own price lists, which is often what you want when the customer printed an old price.
Run a single two-line order through Prepare and Import first and open the result on SO301000 before you send a full day of orders. Check the order type, the customer, the Customer Order Nbr. and both lines. When you later update existing orders instead of creating new ones, identify each line by its line order rather than the line number, a detail that trips up many scenarios built for inserts.
If Monday starts with 30 customer POs in the shared inbox, run them through bulk purchase order upload, up to 50 files in one pass, and get one consistent file back for the data provider. Long orders are covered by purchase order line item extraction, which returns every row rather than a summary. Teams that write orders through the REST API pull the same data as JSON from the purchase order API.
If part of the business runs elsewhere, the pattern is the same with different field names. See NetSuite sales order import, Business Central sales order import and Sage Intacct sales order import. For the buying side of Acumatica, where you issue the purchase order to a vendor, use purchase order to Acumatica, and if you are still choosing between the two ERPs, we compared how each handles purchase orders in Acumatica vs NetSuite for purchase orders.
Budgeting the system itself? The Acumatica pricing guide explains editions, the transaction tier that every imported sales order counts toward, and a worked year one cost.
What comes off the customer document and where it lands on the Sales Orders form (SO301000) when your import scenario maps it.
| Acumatica field | Where it sits | Where it comes from | Notes |
|---|---|---|---|
| Order Type | Summary | Set by you, usually SO. | Fixed value in the scenario |
| Order Nbr. | Summary | The customer PO number, used to group rows. | Must change between orders |
| Customer | Summary | The buying company, matched to your customer ID. | Customer must exist |
| Date | Summary | The PO date on the document. | Defaults to the business date if unmapped |
| Requested On | Summary and lines | The delivery date the buyer asked for. | Drives fulfillment follow-up |
| Customer Order Nbr. | Summary | The purchase order number the customer printed. | Carries to later documents |
| Inventory ID | Details tab | The customer part number, mapped to your item. | Item must exist |
| Quantity | Details tab | Ordered quantity on each line. | One row per line |
| UOM | Details tab | Unit of measure on the line. | Must be valid for the item |
| Unit Price | Details tab | The unit price the buyer printed. | Leave unmapped to use your price list |
| Ship-To | Shipping tab | The delivery address on the PO. | Override only when it differs |
Four steps from the customer attachment to sales orders on SO301000.
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 buyer part numbers to your Inventory IDs and the customer name to its customer ID.
Tip: Keep the mapping sheet; the same account sends the same codes.
Download Excel or CSV and attach it to the data provider behind your sales order scenario, or upload it straight on Import by Scenario.
Tip: Keep column names stable so the mapping never needs rework.
On Import by Scenario (SM206036) run Prepare, check the rows, then Import and open the new orders on SO301000.
Tip: Run one two-line order first on any new customer.
Build an import scenario that targets the Sales Orders form (SO301000). Point a data provider at an Excel or CSV file with one row per order line, map the columns to Order Type, Order Nbr., Customer and the line fields, then run Prepare and Import on the Import by Scenario form (SM206036).
Because the Order Nbr. mapping has the same value on every row, often a fixed value typed into the scenario. Map it to a column in the file that changes between orders. With automatic numbering the number itself does not matter, only that it is shared within one order and different across orders.
Not through an import scenario, which reads structured files such as Excel or CSV. A customer purchase order that arrives as a PDF has to become rows first, typed by hand or extracted, before the scenario or the REST API can create the sales order.
In the Customer Order Nbr. field on the summary area of the Sales Orders form. It is separate from your own Order Nbr., which usually comes from automatic numbering on the order type, and it carries forward to the documents created from the sales order.
The order with that line fails to import. Community reports show one bad item can hold up a batch unless the scenario is set up so only the affected order stops. The reliable fix is to map every customer part number to an existing Inventory ID before you run the import.
No. Import scenarios are configured on standard forms by a trained user or partner, with no code. The REST API route is the one that needs a developer, because an integration has to authenticate and write the SalesOrder entity itself.
Yes, but the mapping differs from an insert. You have to identify the existing order by type and number, and identify each line reliably, which community experts recommend doing by line order rather than line number. Build and test update scenarios separately from the ones that create orders.
No. PurchaseOrders reads the customer purchase order and returns structured data as Excel, CSV or JSON. It does not install in Acumatica and does not create, release or ship orders. You load the rows through your import scenario, the REST API or your own integration.
The same workflow on Epicor Kinetic.
The buying side: POs you issue.
The same workflow on NetSuite.
The same workflow on Business Central.
The same workflow on Sage Intacct.
The same workflow on Odoo.
Choose your plan