EDI capable: what a retailer means by it

What EDI capable means

A supplier is EDI capable when it can take a trading partner's purchase orders as structured files and send its own documents back in the same form, in the version and with the codes that partner specifies. In North American retail the format is X12 and the core set is four documents: the 850 purchase order in, and the 855 acknowledgment, the 856 ship notice and the 810 invoice out.

Retailers treat it as an entry condition. Walmart's supplier page lists "Electronic Data Interchange (EDI)" among its requirements, in the same list as a federal tax ID number, a Dun & Bradstreet number and a GS1 membership number. Kroger publishes its version (5010), its interchange IDs and a document list per program on a public portal.

The term has no fixed threshold in the X12 standard. It is always capable for one partner: a setup that passed Kroger's test in version 5010 has proven nothing for a partner whose guide specifies 4010.

The four things a trading partner checks

The fourth row runs on the partner's schedule. The partner sends test orders, the supplier returns each document, and the partner compares them with its implementation guide. Kroger's advance ship notice program, for example, has a testing phase, an evaluation phase and a production phase. A test interchange differs from a live one in a single character:

ISA*00*          *00*          *ZZ*NORTHFIELD     *08*9254110060     *261003*0915*U*00501*000000012*0*T*>~

The T in the fifteenth element marks test data. Kroger's guide gives qualifier 08 and receiver ID 9254110060; the sender side is whatever was agreed. Every document also has to be answered: Kroger states that a functional acknowledgment is required, so each 850 received is answered with a 997, whatever happens to the order itself.

Three ways to be EDI capable

All three produce the same X12 files, so the trading partner cannot tell them apart. What differs is where the documents come from.

The portal has the lowest entry effort: an account, the partner's forms, a login. The other routes are compared layer by layer under EDI software, and the companies that sell them under EDI provider.

What a web portal leaves undone

A portal makes the supplier capable and moves none of the data. Take a supplier with one retailer, 30 purchase orders a week and 8 lines per order.

• 30 orders times 8 lines is 240 order lines a week, read in the portal and keyed into the order system.
• Each order needs an 855, an 856 and an 810: 30 times 3 is 90 documents a week, typed into forms.
• With 6 cartons per shipment, the 856 forms take 180 carton records a week, each with its items and quantities.

The volume is one problem. The other is that hand-typed documents are checked by a machine on arrival:

• SN102 differs from the carton. The 856 says 24 units, the carton holds 20. The receiving dock scans the label, finds the notice and records a 4-unit difference.
• The 856 arrives after the truck. Kroger requires the notice at least 90 minutes before arrival. A form filled in at the end of the day misses that.
• The 810 does not match the 856. The quantities are typed twice, once per form, and a typing error in one of them makes the invoice disagree with the ship notice.
• The 846 cannot be kept up. Walmart's drop-ship set includes the 846 inventory advice. A stock figure typed into a form is only as recent as its last edit.

None of these stops a supplier from being EDI capable. They decide whether it stays in good standing, which is the subject of EDI compliance. The portal route with real volumes is worked out further under EDI for small business.

Is your ERP or store platform EDI capable?

The question comes up for every system, and the documented answer is the same for most of them: the system holds the records, and something outside it produces the X12.

• NetSuite. Its warehouse module writes staging records for outbound ship notices. Oracle's documentation says this data "is then read by the NetSuite EDI partner, who converts the data into an EDI document". More under NetSuite EDI integration.
• Business Central. Microsoft documents an E-Documents framework with Peppol BIS 3, XRechnung, ZUGFeRD, OIOUBL and Factura-E. Those are e-invoicing formats. The 850, 856 and 810 of retail X12 are not on that list.
• Shopify. No X12 translator. Orders come in and fulfillments go out through the Admin API, see Shopify EDI integration.

So "is system X EDI capable" has a practical reading: does it expose orders, shipments with carton detail, invoices and stock in a way that another layer can read and write. If it does, the business can be made EDI capable around it.

What this means for your integration

We build the third route: an EDI integration between your trading partners and the systems that already hold your orders, shipments and invoices. The 850 becomes a sales order, and the 855, 856 and 810 are assembled from your own records per partner guide, validated before they are sent, and matched to the 997 that answers them. We host and run it, and a document that fails a check is held and shown in the dashboard with the reason.

Tell us which retailer asked and which systems you run.