EDI integration with your ERP, mapped per trading partner and run for you

What an EDI integration consists of

An EDI integration has four layers. A trading partner sees only the top one, and your order desk only the bottom one.

Transport and translation are solved software. AS2 is specified in RFC 4130, published in July 2005: the payload is signed and encrypted, and the receiver returns a signed receipt. X12 syntax is fixed per release. The work is in the lower two layers. Each partner publishes its own subset of the standard as an implementation guide, and each ERP account has its own items, units, customers and custom fields.

This page is part of our integrations. The documents themselves are listed under EDI document types.

Four ways to connect to a trading partner

There are four routes for an EDI file. Walmart accepts the first three from its drop-ship vendors and describes them on its connection types page.

Walmart names one more connection type: the solution provider, "a third party that provides EDI process capability to its partners". It states that it "does not govern or dictate the data flow between the solution provider and the drop-ship vendor". The partner checks the files, not the route. Kroger's supplier portal describes a VAN as a private network provider "hired by a company to facilitate electronic data interchange".

The route decides how files move. It does not decide who builds the mapping or who owns the ERP side, and those two are where an order is entered correctly or not. We connect over the route each partner prescribes and build the two lower layers to your systems.

The documents, and what they are in your ERP

One order without changes is 4 business documents and 4 acknowledgments, 8 transaction sets. With a 3PL in between, the 940 and 945 and their acknowledgments make it 12. At 300 orders a month that is 3,600 sets, and every outbound one has to be matched to the 997 that answers it.

The mapping is per partner, per document

Three partners that each exchange five documents are 3 times 5, so 15 mappings. They share the ERP side and differ in everything a guide can prescribe. Two published guides, checked on 3 October 2026:

This is one line of an 850 and the sales order line it has to become:

PO1*1*24*CA*150.00**UK*10614141104823*VP*10482~

{
  "item": "10482",
  "quantity": 288,
  "units": "EA",
  "rate": 12.50,
  "customerLine": "1"
}

Four decisions sit between the two. The item is found on VP, the vendor part number, because this partner sends its GTIN-14 in the UK element and the ERP stores the 12-digit UPC. The quantity is 24 cases of 12, so 24 times 12 is 288 eaches. The price is 150.00 per case, which is 12.50 per each. The line number 1 is stored, because the 855, 856 and 810 have to return it. A mapping that copies 24 and EA ships 264 units short.

Other values change form on the way: ISA09 carries the date as 260928 and GS04 as 20260928, and the invoice total in TDS01 has two implied decimals, so 41540 is 415.40. The ship-to arrives as a location code in N104, such as 0007, and has to resolve to an address record in the ERP. The classes of mismatch are described under EDI mapping and units of measure.

What goes wrong quietly

• A resent order becomes a second sales order. The buyer sends the same 850 in a new interchange. The file is valid and gets its 997. Only a check on buyer ID plus PO number stops the duplicate.
• A test file creates a live order. ISA15 is T. A translator that ignores the flag books a certification order as real.
• Cases read as eaches. See the line above: 24 instead of 288.
• The 855 confirms what is not in stock. Every line is acknowledged as accepted, and the 856 ships short against a confirmed order.
• The 856 is built from the order, not from what was packed. The carton count, the SSCC and the quantities come from the pack record. An SSCC in the notice that is on no label fails at the dock scan.
• A partial acceptance is read as accepted. AK9*P*3*3*2 means two of three invoices arrived. The third stays unpaid.
• A price difference goes through unseen. The PO says 12.50 and the price list 12.80. On 24 units the invoice is short-paid by 24 times 0.30, which is 7.20, and the deduction arrives with the remittance.

Each of these passes the syntax check. Retailers price the result per carton, per shipment or as a share of the invoice, and take it off the payment. The schedules that are public are collected under EDI compliance.

Throughput and timing

EDI arrives in batches, and the ERP takes requests one at a time.

A morning batch. A buyer sends one interchange with 400 purchase orders at 06:00. NetSuite's concurrency limit on the Standard tier is 5 requests at the same moment, shared with every other integration on the account; Premium has 15, Enterprise and Ultimate 20. With 2 of the 5 slots and 2 seconds per sales order, 400 orders take 400 times 2 divided by 2, which is 400 seconds, or 6 minutes 40 seconds. The 997 goes back at once and the orders wait in a queue until the ERP has taken them. A request over the limit is refused and tried again.

A ship notice deadline. Kroger requires the 856 at least 90 minutes before the truck arrives. NetSuite WMS writes its ship-notice staging records with a scheduled script that runs every 15 minutes. A truck that leaves at 10:00 for a 2-hour drive arrives at 12:00, so the notice is due by 10:30. The staging record can appear as late as 10:15. That leaves 15 minutes to read it, build the hierarchy, validate the counts and send. A notice that fails validation at 10:20 has to be visible at 10:20.

An acknowledgment window. Kroger tells vendors to call when a 997 or 824 for a ship notice has not come back within 12 hours. The integration keeps a timer per document sent and raises the alert itself.

How the ERP limits work is described under NetSuite concurrency limits and integration throughput.

What your ERP or store does natively

Oracle states the boundary itself in its WMS documentation: NetSuite writes the shipping data, and it is "read by the NetSuite EDI partner, who converts the data into an EDI document". In each row the ERP or store holds the order, the fulfillment and the invoice, and something outside it produces the documents. That part is what we build, also for SAP Business One, Acumatica and Sage.

What you get

We build the integration to your trading partners, your ERP and your rules, host it and run it. The build has a fixed price and running it has a monthly fee.

• Mappings per partner and per document, written against each partner's guide and your item, unit and customer data.
• Validation before sending. Segment counts, control numbers, required segments and the partner's code lists are checked. A document that fails is held with the reason and never sent half right.
• A register of acknowledgments. Every document sent is matched to its 997. A rejection or a missing acknowledgment raises an alert.
• A queue with retries. When the ERP refuses a request or is down, orders wait and are written in the order they arrived. Nothing is dropped silently.
• A dashboard with a login. Per document: the raw file, the mapped record, the status and the log.
• Dry run and approval. A new partner or a changed mapping first runs without writing to the ERP and without sending. Documents can wait for your approval per partner.
• Changes on either side. When a partner publishes a new guide or the ERP changes a field, we change the integration.

Orders that arrive by EDI follow the same rules as orders from a store, described under orders, customers and shipping and ecommerce ERP integration. Buyers that order from inside a procurement system use PunchOut, a different mechanism for the same goal.

Tell us which trading partners ask for EDI and which ERP you run. You get a concrete answer.