To stop retyping purchase orders into NetSuite, use EDI for trading partners that can send it and CSV import for orders that already arrive as clean spreadsheets. For everyone else, use an automation that reads emailed POs and drafts sales orders. Whichever route you pick, match each PO to the right customer, items, units and prices, then hold anything that doesn’t match for a person to approve.
Why purchase orders still get retyped
If a customer doesn’t send EDI or use a portal, the order can arrive as a PDF, a spreadsheet or a few lines in an email, in that customer’s own layout. Someone on your team then does the same routine for every order:
- Open the email and the attachment.
- Find the customer, sometimes by guessing from the sender.
- Translate the customer’s part numbers into your item numbers.
- Convert units, such as cases into each.
- Key each line and check the price against the customer’s pricing.
- Check the ship-to address, the terms and the credit status, then save.
None of it is hard, but it repeats with every order and can pile up at month end. Orders are one of several handoffs between email and the ERP; see the Microsoft 365, QuickBooks and NetSuite handoffs worth automating first for the others.
Your options, compared
| Option | Best for | What it needs |
|---|---|---|
| CSV import | Orders already in a spreadsheet | A clean file with NetSuite IDs |
| EDI | Large trading partners | Setup and testing per partner |
| SuiteScript or RESTlet | Orders already held as data | A developer and OAuth 2.0 |
| Document capture or OCR | PDFs in a few stable layouts | Setup per layout, plus review |
| An AI agent | Emailed POs in many layouts | Matching data, a narrow role, approvals |
These aren’t either/or: choose a route for each customer by how their orders arrive.
CSV import
NetSuite’s Import Assistant can create sales orders from one CSV file or several, for example the order headers in one file and the lines in another. Each order must reference the customer by its internal or external ID rather than its name, and imported orders can default to Pending Approval. Import works when you already have a clean spreadsheet. If someone has to build that spreadsheet from PDFs, you’ve moved the typing, not removed it.
EDI
EDI sends the order as a standard electronic document, the X12 850 purchase order, and the seller can reply with an 855 acknowledgment. Each trading partner needs its own setup and testing, so save it for partners who require it or whose volume justifies the work.
A SuiteScript or RESTlet integration
If another system, such as a web store, already holds the order as data, a developer can push it into NetSuite. A RESTlet is a SuiteScript that outside systems can call to bring data into NetSuite, and REST web services can create records such as sales orders without custom scripts. Both expect structured data, so neither reads a PDF for you. Budget for a developer, and for updating the code when your fields change.
Document capture or OCR tools
These tools read a PDF or scan, pull out the header and line fields and hand them to NetSuite through an import or an integration. Template-based tools need a template for each layout, so they suit customers whose POs look the same every time. You still need matching rules and a screen where a person checks what was read. Don’t confuse them with NetSuite’s Bill Capture, which creates vendor bills from the bills you receive, not sales orders from customer POs.
An AI agent that drafts sales orders
An agent reads each email and attachment in whatever layout it arrives, identifies the customer, matches items through your cross-reference, converts units, checks prices and drafts the sales order for approval. Anything that doesn’t match goes to a person with the difference shown. It needs read access to the order inbox, a narrow NetSuite role, clean matching data and a log of every run. Because it reads content written outside your company, it must treat that content as data, never as instructions. See is it safe to give an AI agent access to your ERP?
Matching customers, items, units and prices
Every route depends on matching. Set these up first:
- Customers. Match on the sender, the bill-to and ship-to and the PO layout, and send unknown senders to a person.
- Customer part numbers. NetSuite’s Customer Part Number feature, part of the Supply Chain Management SuiteApp, stores each customer’s part numbers on your item records so they can be used on sales orders and in imports. It supports only inventory and assembly items, so keep a cross-reference table for anything else.
- Units of measure. With Multiple Units of Measure, each item has default units for purchasing, stocking and selling. If a customer orders cases and you sell each, make the conversion explicit.
- Prices. A customer can carry a price level, and item price levels on the customer record override it. An absolute price for a customer and item overrides any other pricing. Compare the PO price with what NetSuite would charge, not with the last order.
- Credit. If a customer is over its credit limit, past due or on a manual hold, NetSuite can restrict new sales transactions for it, depending on your credit settings. Check before drafting.
- Duplicates. Sales orders have a PO Number field for the customer’s PO number. Check it before creating an order, since the same PO can arrive twice.
A worked example
For example, with illustrative numbers: a PO asks for 10 cases of the customer’s part BX-44 at $42.00 a case. Your cross-reference maps BX-44 to your item 7731, which you sell by the each, 12 to a case. The customer’s price level gives $3.50 each, so 120 each at $3.50 is $420.00, the same as 10 cases at $42.00, and the line passes. A second line lists a part number with no match, so the draft waits in Pending Approval with that line flagged for a person.
Approvals, permissions and testing in NetSuite
- Make new orders wait for approval. If you use the approval process, set the default sales order status to Pending Approval in Accounting Preferences. Oracle notes that a Pending Approval order needs approval by someone with the right permissions before NetSuite can process it.
- Give the automation its own role. In NetSuite a role is a set of permissions that decides what a user can see and do. Grant what the job needs, such as creating sales orders and viewing customers, items and pricing. Leave out approval: Oracle’s preferences page notes that an order edited by a role with approval permission isn’t set back to Pending Approval, even when re-approval on edit is required.
- Use OAuth 2.0, not token-based authentication. Oracle’s TBA end-of-support notice says that starting in NetSuite 2027.1 you can no longer create new integrations that use TBA for SOAP and REST web services and RESTlets, and that support for existing ones ends later, tentatively in NetSuite 2028.2. With the OAuth 2.0 client credentials flow, an administrator maps the application to an entity and a role. Map it to a dedicated integration user with its own narrow role, not to a person’s record, so the automation never acts as someone on your team.
- Test in a sandbox. A NetSuite sandbox has the same setup, data and customizations as production, and what you do there doesn’t affect production. Client credentials setups aren’t copied from production, so set one up in the sandbox too.
- Keep the trail. For each change, System Notes keep the date, the user, the interface used and the field’s old and new values. Add the automation’s own log, so each order traces back to the email it came from.
- Know how to switch it off. Revoking an OAuth 2.0 authorized application invalidates all of its tokens, and for the client credentials flow you revoke the certificate. Try it once during testing.
How to measure whether it works
Count before you start and again after: orders per week, minutes per order, the share sent to a person and orders corrected after entry. For example, with illustrative numbers: 40 orders a week at 6 minutes each is 240 minutes, or 4 hours. If 38 later arrive as clean drafts that take 1 minute to approve, and 2 need 10 minutes of a person’s time, that’s 58 minutes a week instead of 240.
A checklist before you automate order entry
- Count orders per week, minutes per order and corrections for at least two weeks.
- Sort customers by intake: EDI-ready, clean spreadsheets or emailed POs.
- Merge duplicate customer records and clean up ship-to addresses.
- Build the part number cross-reference, or set up Customer Part Number if you use the SuiteApp.
- Check sale units and case quantities on your busiest items.
- Confirm that price levels and customer-specific prices are current.
- Set new orders to Pending Approval while you test.
- Create a dedicated role without approval permission, connected through OAuth 2.0.
- Write down which exceptions go to a person, and who that person is.
- Run real POs through a sandbox, and practice revoking access.
Kestrel is an AI-native consulting firm in St. Louis. The agent we deploy is designed to handle the emailed part of this: read each PO, match it against your customer, item and price records, draft the sales order for your team to approve and send exceptions to a person, with every run logged. It’s in development; see order entry automation for how it’s designed to work, or request early access.