The NetSuite Import Assistant loads sales orders from CSV all day long.
PDF, JPG, PNG, BMP, HEIC, TIFF
Submit your purchase orders
Drop documents here, or choose a file
Up to 50 files per batch
Uploading...
The NetSuite Import Assistant loads sales orders from CSV all day long. What it will not do is read the purchase order your customer emailed as a PDF. Upload that document here and get the PO number, the customer, the ship-to address and every line with quantity and price back as a CSV shaped for the import.
NetSuite is happy to take a spreadsheet. The work that eats the day is turning a stack of customer PDFs into that spreadsheet, one order at a time.
A retail chain, a contractor and a corner shop all send a purchase order that looks nothing like the others. Template-based capture breaks the moment a new customer signs on.
Customers order by their own codes. Every line has to be matched to a NetSuite item before the file will load, and that mapping is where most keying errors start.
The Import Assistant expects the customer as an internal ID, not the trading name printed on the PO. A name keyed straight off the document fails the row.
Monday morning after a weekend of emailed orders is not a steady trickle. The queue has to clear before the warehouse can pick anything.
Upload the purchase order your customer sent. The AI reads it and returns the header and every line as structured data, in the column shape the NetSuite Import Assistant expects, so the load is a mapping step rather than a typing step.
No template to build per customer. The extraction works from the document itself, including scans and photographed pages.
A 60-line restocking order comes back as 60 rows with item code, description, quantity, unit of measure and unit price.
Header fields and line fields come out separately, which is exactly how the multi-file sales order import wants them.
The buyer reference stays in its own column so it can go to the PO # field rather than being confused with the NetSuite order number.
The route is Setup, Import/Export, Import CSV Records, with Transactions as the import type and Sales Order as the record type. Oracle documents two shapes. You can put everything in a single CSV, or you can split it: header data in one file, item lines in another, and the shipping address in a third. The multi-file example Oracle publishes uses exactly those three files, joined by External ID.
The required fields are smaller than people expect. On the header file: External ID, Customer, Date and Status. On the items file: line ID or item, and the item has to already exist in the account. On the shipping address file: Country. The Sales Orders feature has to be enabled on the account before the record type appears at all.
Oracle is explicit about this and it is the detail most people get backwards. For imports of new data you use External ID, and on the Field Mapping page you map that External ID column to the NetSuite Order # field, which serves as the transaction ID for sales order records.
Read that again with a customer purchase order in your hand. It is very tempting to drop the customer PO number into External ID, because it is the unique reference sitting right there on the page. Do that and the buyer reference becomes your NetSuite order number. Your own order numbering is gone, and two customers who both use a simple numbering scheme will collide the first time they each issue an order numbered 1001. You will see This record already exists, which is what NetSuite returns when an External ID has been used before.
The customer purchase order number belongs somewhere else. On a NetSuite sales order it goes in the PO # field, whose internal ID is otherrefnum. That is a different field from tranid, which holds the sales order number NetSuite assigns. Keep your own key in External ID, put the buyer reference in PO #, and both stay searchable. Because the extraction returns the customer PO number in its own column, that split is a mapping decision rather than a cleanup job.
Oracle states that the unique ID should be included in every line of the CSV files. That single sentence is the difference between one sales order with forty lines and forty sales orders with one line each. The import has no other way to know which rows belong together, so a file where External ID appears only on the first row of each order gets read as a long list of one-line orders.
The failure is quiet. Nothing errors out. The import reports success, the count looks plausible because forty rows did load, and the problem surfaces later when someone in the warehouse finds forty pick tickets for one customer. Repeat the key down every row of the order before you import.
The same item twice on one order. If a customer orders the same SKU on two lines, for two ship dates or two locations, an update import throws an ambiguity error because NetSuite cannot tell which line you mean. The documented fix is to add an Items: Line ID column, leave it blank for existing lines, and number new lines above the highest existing ID, with Data Handling set to Update.
Sales rep contribution over 100 percent. If your customers are assigned to sales teams, importing without checking Overwrite Sublists in Advanced Options makes NetSuite combine the existing team assignment with whatever is in the CSV, and the total tips past 100 percent. One checkbox, and it is not on by default.
One smaller trap for anyone updating rather than creating: the Commitment Confirmed field is available only when updating a sales order record, not when adding a new one. Mapping it on a create import will not work no matter how the column is formatted.
PurchaseOrders reads the customer document and returns clean structured data. It does not create, approve or fulfil sales orders in NetSuite, and it does not replace the Import Assistant or your integration. Those stay exactly where they are. What it removes is the transcription between a PDF in an inbox and the CSV that NetSuite is perfectly capable of loading. The output is the same data whether you take it as a CSV file or as an Excel workbook for review first, and accuracy on long orders comes down to purchase order line item extraction.
A US wholesale distributor, manufacturer or supplier running NetSuite who receives customer purchase orders as PDF attachments and keys them in as sales orders. Usually a customer service rep or an order desk, often ten to a hundred orders a day, a large share of them from buyers who will never send EDI. If that is the shape of your day, sales order entry automation covers the wider workflow and purchase order extraction for wholesale distribution covers the industry side. When a weekend of orders lands at once, bulk purchase order upload clears the backlog in one pass, and teams that would rather skip the file entirely can post straight through the purchase order API.
The orders you send to your own suppliers are a different import with different field rules, and those are covered on the NetSuite purchase order import page, including the External ID behavior on the purchasing side and the SuiteTalk REST route. For the document distinction itself, purchase order versus sales order is the short version. If your books are on QuickBooks rather than NetSuite, the same inbound workflow is described on import sales orders into QuickBooks.
What comes off the customer document, and where it belongs in the import. Field names follow the Oracle NetSuite sales order import documentation.
| NetSuite field | Internal ID | Where it comes from | Required |
|---|---|---|---|
| External ID | externalid | Your own unique key for the order. Not the customer PO number. | Yes, or Internal ID or Order # |
| Customer | entity | The buying company, matched to an existing NetSuite customer by internal ID. | Yes |
| Date | trandate | The PO date printed on the document. | Yes in the multi-file example |
| PO # | otherrefnum | The customer purchase order number. This is the field that reference belongs in. | No, but you want it |
| Status | orderstatus | Pending Approval or Pending Fulfillment, set by your own policy. | Yes in the multi-file example |
| Sales Order Items: Item | item | The customer part number, mapped to your NetSuite item. Must already exist. | Line ID or item |
| Sales Order Items: Quantity | quantity | Ordered quantity on each line. | Per line |
| Sales Order Items: Amount | amount | Line value, or use Price Level to let NetSuite price it. | Optional |
| Shipping Address: Country | country | Ship-to country from the delivery block on the PO. | Yes on the address file |
Four steps from the email attachment to a sales order sitting in NetSuite.
Drop in the PDF, the scan or the emailed attachment. No template setup, and no per-customer configuration to maintain.
Tip: Forwarded email attachments work as they arrive.
Check the header and the lines on screen, then apply your cross-reference from customer part numbers to NetSuite items and from trading names to customer internal IDs.
Tip: Keep the mapping in one sheet and reuse it every load.
Take one flat file, or the header, items and shipping address split into the three-file shape Oracle documents. Repeat your External ID down every line of the order.
Tip: Missing that repeat is what splits one order into many.
Setup, Import/Export, Import CSV Records. Import type Transactions, record type Sales Order. Map External ID to Order #, and the buyer reference to PO #.
Tip: Save the mapping so the next batch is one click.
Go to Setup, Import/Export, Import CSV Records. Choose Transactions as the import type and Sales Order as the record type, upload your file, then map your columns on the Field Mapping page. You can use one combined file or split header, item and shipping address data across separate files.
A unique identifier such as External ID, the Customer, the Date and the Status on the header, plus a line ID or item on each item row. The customer and the item both have to exist in NetSuite already. If you import a shipping address file, Country is required on it.
In the PO # field, whose internal ID is otherrefnum. That is separate from tranid, the sales order number NetSuite assigns, and separate from External ID. Putting the buyer reference in External ID overwrites your own order numbering, because External ID maps to the Order # field on import.
Because the unique ID was not repeated on every row. Oracle requires the unique identifier on each line of the CSV, and it is the only signal that tells the import which rows belong to the same order. Copy your External ID down all the lines of an order and reimport.
The External ID on that row has been used by an earlier transaction. Each one has to be unique across the account. You can confirm it with a saved transaction search filtered on External ID. It happens most often when the customer PO number is used as the key and two buyers reuse the same number.
Yes, but an update import needs help telling the lines apart or it throws an ambiguity error. Add an Items: Line ID column, leave it blank for lines that already exist, and give new lines a number above the highest existing line ID, with Data Handling set to Update.
Oracle publishes a multi-file example rather than a downloadable template: a sales order file, a sales order items file and a shipping address file, all joined by External ID. The column set you need depends on which fields your process populates, so build the file from the required fields and add optional ones as you need them.
Yes. SuiteTalk REST exposes a salesOrder record on your account-specific domain, and the same extracted data can be posted to it rather than written to a file. That suits a steady stream of orders. CSV import suits batches and gives you a file to review before anything reaches NetSuite.
No. PurchaseOrders reads the customer purchase order document and returns structured data. It does not create, approve or fulfil sales orders, and it does not replace the Import Assistant or your ERP. It removes the typing between an emailed PDF and the file NetSuite loads.
Customer POs into Oracle Order Management.
The same workflow on SAP Business One.
The same workflow on Epicor Kinetic.
The same workflow on Odoo.
The same workflow on Business Central.
The same workflow on SAP.
Choose your plan