NetSuite and EDI
NetSuite EDI integration
NetSuite does not write or read X12. Its native part is a set of WMS staging records for ship notices that Oracle says are read by a NetSuite EDI partner. We build the rest to your account: 850s into sales orders, and 855, 856 and 810 out of your orders, fulfillments and invoices, mapped per trading partner, hosted and run for you.
What NetSuite does natively
NetSuite has no X12 or EDIFACT translator. What Oracle ships sits in NetSuite WMS and covers one document in one direction, the outbound ship notice. Oracle's own description: NetSuite WMS "creates custom records with the required shipping data", and that data "is then read by the NetSuite EDI partner, who converts the data into an EDI document and sends the ASN to the customer".
| Native part | What it is | Where it stops |
|---|---|---|
| System rule "Generate EDI 856 outbound ASNs?" | Switches the staging on, per account or per warehouse location | Produces records, not an 856 |
| "ASN Required?" box on the customer | Marks which customers get staging records | One flag; no partner guide, no hierarchy |
| Scheduled script, every 15 minutes | Writes an ASNC Parent record per shipped order and a Stage Outbound ASNC record per item | No segments, no envelope, nothing is sent |
| SSCC-18 generation | An 18-digit code from your DUNS number (9 digits) or company prefix (7 to 10 digits) plus a serial reference of 6 to 9 digits | Printed on the label; the 856 still has to carry the same number |
| Electronic Invoicing SuiteApp | XML or JSON from templates, inbound XML | "Does not include native support for any country-specific requirements or e-document standards" |
Oracle adds one warning to the SSCC setup. The GS1 barcode holds 20 characters, the application identifier 00 plus the 18-digit SSCC, and a receiver whose scanner returns all 20 will not match an ASN that carries 18. Oracle's advice is to verify that the receiver's scanning system reads only the 18 digits. Until that is settled, the notice and the label disagree on every carton. The sources are Oracle's EDI integration page for NetSuite WMS and its page on UCC code formats, checked on 3 October 2026.
Everything else in a trading relationship is outside the product: the inbound 850, the 855, the 810, the 997s and the mapping per partner. This page is the NetSuite side of our EDI integration; the account itself is described on the NetSuite system page.
What sits between NetSuite and your trading partner
Each document maps to a NetSuite record.
| Document | Direction | NetSuite record | Source of the content |
|---|---|---|---|
| 850 | In | Sales order | The partner's file |
| 855 | Out | Sales order | Committed and back-ordered quantity per line |
| 856 | Out | Item fulfillment, WMS staging records | Status Picked, Packed or Shipped, packages, SSCCs |
| 810 | Out | Invoice | Lines, tax, freight, terms |
| 846 | Out | Item and location quantities | Available quantity per location |
| 997 | Both | None | Kept in the integration per document |
The inbound order is where most of the mapping sits. Field IDs are those of the sales order record:
| 850 element | NetSuite field | Rule |
|---|---|---|
| Sender ID, N1*BY | entity (Customer) |
From a partner table; never created from the file |
| BEG03 | otherrefnum (PO #) |
Unique per customer; a repeat is held |
| N1*ST, N104 | Ship-to address of that customer | The partner's DC or store code resolves to an address |
| PO1 product ID | item on the line |
UPC against upccode, or the partner's part number through a cross-reference |
| PO102, PO103 | quantity |
Cases converted to the item's sale unit |
| PO104 | rate, set by the price level |
Compared; a difference is held or follows your rule |
| DTM 010 | shipdate |
Requested ship date |
The write is an upsert on an external ID built from the partner and the PO number:
PUT /services/rest/record/v1/salesOrder/eid:EDI-123456789-4500018236
With eid: in the URL and the PUT method, NetSuite creates the record when the external ID is new and updates it when it exists. A retry after a timeout, or a purchase order the buyer sends twice, ends in one sales order.
The technical reality of this pair
Governance units. When the order is written by a RESTlet, every call has a budget of 5,000 usage units. Creating a transaction record costs 10 units and saving it 20, so one sales order is 30 units and one call carries at most 5,000 divided by 30, which is 166 orders. With two lookups of 10 units each to resolve the customer and the items, an order costs 50 units and a call carries 100. A buyer's morning interchange with 400 purchase orders is therefore at least 4 calls.
Concurrency. The account processes 5 requests at the same moment on the Standard tier, 15 on Premium and 20 on Enterprise and Ultimate, plus 10 per SuiteCloud Plus license. Every integration shares that pool. With 2 slots for EDI and 2 seconds per order, 400 orders take 400 times 2 divided by 2, which is 400 seconds, or 6 minutes 40 seconds. The 997 goes back to the buyer when the file is read; the orders wait in a queue until NetSuite has taken them. The note on NetSuite concurrency limits has the detail.
The 15-minute script. The staging records for the 856 are written by a scheduled script that runs every 15 minutes. Kroger, as an example of a partner rule, requires the ship notice at least 90 minutes before the truck arrives.
A truck that leaves at 10:00 for a 2-hour drive arrives at 12:00, so the notice is due at 10:30. The script can write the records as late as 10:15. That leaves 15 minutes to read them, build the HL hierarchy the partner prescribes, validate the counts and send. For a 1-hour drive the notice would be due at 09:30, before the truck has left, and the 856 has to be built from the pack data at the moment the last carton closes, without waiting for the script.
What NetSuite and X12 store differently
- Units. The 850 orders 24 cases. NetSuite commits stock in the item's sale unit. With 12 eaches per case the order line is 24 times 12, so 288, and the 855 and 856 have to convert back to cases for a partner that counts in cases.
- Item identity. The partner sends a UPC, a GTIN-14 or its own item number. NetSuite's
upccodefield holds one value per item. A 14-digit case GTIN is a different string from the 12-digit UPC, so case-level IDs need a cross-reference. - Customer and subsidiary. One retailer is one customer with a ship-to address per distribution center, or a customer per banner. In a OneWorld account the customer belongs to a subsidiary, and that decides which subsidiary's sales order, stock and invoice the PO becomes.
- Price. The rate on the line comes from the customer's price level. PO104 is the price the buyer will pay. At 12.80 against 12.50 on 24 units, the invoice is short-paid by 24 times 0.30, which is 7.20, unless the difference is caught before the 855 goes out.
- Cartons. An item fulfillment knows what shipped. Which units went into which carton, and under which SSCC, is recorded at packing. The HL loop of the 856 is built from that data. See the SSCC label.
What NetSuite teams report
Administrators who run EDI on NetSuite describe the same three problems in public forums, and each one maps to a check that can be made before a document leaves.
| Reported problem | What it is technically | The check |
|---|---|---|
| A mapping changed without notice and documents started failing | A qualifier or code in an outbound map no longer matches the partner's guide | Every outbound document is validated against the partner's rules before sending, and held when it fails |
| Orders arrived without a ship-to address and were fixed after the ship window had passed | N1*ST or its location code did not resolve | An order that fails a lookup is held with the reason, the same hour it arrives |
| The administrator ended up reading raw X12 to compare test data with the retailer's guide | No view of the file next to the record | The dashboard shows the raw segments beside the NetSuite record they became |
The penalty for a late or wrong document stays with the supplier whoever made the mapping. That is why the checks sit before the send, and why a failed document is shown instead of skipped.
When it goes wrong
| What happens | What the integration does |
|---|---|
| NetSuite refuses a request over the concurrency limit | The order stays in the queue and is retried with a growing pause |
| A write times out after NetSuite created the order | The retry is an upsert on the same external ID: one sales order |
| An item in the 850 has no match | The order is held with the PO1 line; the rest of the batch is written |
| The partner answers an 856 with a rejection | AK3 and AK4 from the 997 are shown with the segment and element in error |
| No 997 within the partner's window | An alert, with the control number of the document that is waiting |
We build the integration to your NetSuite account and your trading partners, host it and run it, for a fixed build price and a monthly fee. It runs under its own role with the permissions its flows need. A new partner starts as a dry run that writes nothing to NetSuite and sends nothing, and you approve the first documents. When a partner publishes a new guide or Oracle changes the API, we change the integration. The store side is covered under Shopify EDI integration and Shopify NetSuite integration. Tell us which partners you trade with.
Frequently asked questions
Does NetSuite have native EDI?
No. Oracle's documentation describes the EDI capability of NetSuite WMS as custom records with shipping data that are "read by the NetSuite EDI partner, who converts the data into an EDI document and sends the ASN to the customer". There is no X12 translator, no envelope handling and no inbound purchase order processing in the product.
Is there a SuiteApp for EDI?
Yes. EDI networks and integration platforms publish SuiteApps in Oracle's SuiteApp marketplace. A SuiteApp connects the account to the vendor's own service, where the X12 translation happens. The account-specific parts, such as your units, price levels, subsidiaries and custom fields, still have to be mapped per trading partner and per document.
Can EDI orders respect our price levels and subsidiaries?
Yes. An EDI order is created as a normal sales order for the customer record of that trading partner, so the customer's subsidiary and price level apply as they do for any order. The integration compares the price in the 850 with the rate NetSuite calculates and holds the order or follows your rule when they differ.
Do we need NetSuite WMS to send an 856?
No. WMS supplies the staging records and the SSCC-18 generation. Without WMS the 856 is built from the item fulfillment and its packages, with carton contents and SSCCs from the pack station, the shipping tool or the 3PL that packed the order.
Does the Electronic Invoicing SuiteApp cover the EDI 810?
No. Oracle describes that SuiteApp as a framework that generates XML or JSON documents from templates and states that it "does not include native support for any country-specific requirements or e-document standards". An X12 810 with its envelope and control numbers is produced outside it, from the NetSuite invoice.
Does EDI count against our NetSuite concurrency limit?
Yes. Every request that creates a sales order or reads a fulfillment uses one of the account's concurrent request slots: 5 on the Standard tier, 15 on Premium, 20 on Enterprise and Ultimate, plus 10 per SuiteCloud Plus license. The slots are shared with every other integration on the account, so an EDI batch is queued and written at a pace that leaves room for them.
Tell us what you need
Tell us which systems you use and what needs to work better. We reply personally within one working day. We help you define the work, then agree the price and timing before you commit.
- You know the price and the timeline before you commit to anything
- We work out the connection that takes the work off your hands
- We handle the build, hosting, monitoring and maintenance
- Your team has less information to retype and fewer discrepancies to chase