What is EDI?

EDI in two sentences

EDI is the computer-to-computer exchange of business documents in a standard format. A retailer's purchasing system produces a purchase order as a structured file, and the supplier's system turns that file into a sales order without a person reading or typing it.

The standard fixes the syntax: which segments exist, in which order, with which codes. It does not fix what a given partner sends. Each buyer publishes its own subset as an implementation guide, and that guide is the contract. Large retailers make it a condition of supply: Walmart lists Electronic Data Interchange among its supplier requirements, in the same sentence as a federal tax ID number and liability insurance.

One purchase order line, 24 units at 12.50, looks like this in the two main standards:

X12 850       PO1*1*24*EA*12.50**UP*614141104826~

EDIFACT       LIN+1++0614141104826:SRV'
ORDERS        QTY+21:24'
              PRI+AAA:12.50'

The same facts, two syntaxes. In X12 the elements are separated by * and the segment ends with ~. In EDIFACT the separators are + and : and the segment ends with an apostrophe. Qualifiers say what a value is: UP marks a UPC, 21 an ordered quantity, AAA a net price.

How does EDI work?

One inbound order passes five steps.

1. The buyer's system creates the document. A purchase order in its ERP becomes an 850, with the buyer's item numbers, location codes and units.
2. The file is wrapped and sent. The envelope names sender and receiver, and the file travels over AS2, SFTP or a network mailbox.
3. The receiver checks the syntax and answers. Counts and control numbers are verified, and a 997 functional acknowledgment goes back.
4. The content is mapped. The buyer's item number becomes your SKU, its location code 0007 becomes a ship-to address, cases become eaches. This is EDI mapping, and it is specific to each partner.
5. The record is created in your system. The 850 becomes a sales order in the ERP or an order in the store platform, and the documents that answer it are built from what happens to that order.

Outbound documents run the same steps in reverse: the shipment in your warehouse system becomes an 856, the invoice in your ERP becomes an 810.

EDI standards: X12, EDIFACT and their subsets

X12 is the standard of North American retail. Its committee has been chartered by ANSI for more than 40 years, and the list of transaction sets on x12.org holds more than 300 of them, from the 100 to the 999. A supplier meets a handful. Each release has a version number: Walmart's drop-ship guides are written for 004010, Kroger specifies 5010. The version is part of every partner setup: GS08 carries it, and the partner's guide is written against it.

UN/EDIFACT is the international standard and the common one in Europe. EANCOM, which GS1 has published since June 1989, keeps the EDIFACT message elements that business applications need and leaves out the optional ones. The current EANCOM despatch advice is based on the EDIFACT directory D.01B.

Next to these there are XML formats that do the same job with different syntax, such as GS1 XML and, in procurement, cXML. Whether a flow counts as EDI depends less on the syntax than on the arrangement: fixed document types, a partner-specific guide and a formal acknowledgment.

The envelope: three levels that have to match

An X12 file is three envelopes around the business data.

ISA*00*          *00*          *01*123456789      *ZZ*NORTHFIELD     *260928*1410*U*00401*000001203*0*P*>~
GS*PO*123456789*NORTHFIELD*20260928*1410*1203*X*004010~
ST*850*0001~
...
SE*16*0001~
GE*1*1203~
IEA*1*000001203~

The ISA segment has 16 elements of fixed length, 106 characters with its terminator, which is why the sender ID is padded with spaces. ISA05 and ISA07 say what kind of ID follows: 01 is a DUNS number, ZZ is mutually defined, and the 004010 standard lists 38 such qualifiers. ISA15 is P for production and T for test. ISA16 declares the component separator.

Three pairs are checked before anything else: ISA13 against IEA02, GS06 against GE02 and ST02 against SE02. SE01 counts the segments from ST to SE, here 16. GE01 counts the transaction sets in the group and IEA01 the groups in the interchange. One interchange can carry several groups, and one group several orders, so a single file can hold 50 purchase orders, each with its own ST and SE.

Types of EDI: four ways to exchange the files

"Types of EDI" refers to how the files move and who does the work, not to the format.

AS2 is defined in RFC 4130 of July 2005: the payload is signed and encrypted, sent over HTTP, and answered with a receipt, the MDN, which can be signed as well. SFTP is file transfer over SSH; Walmart adds a mandatory file naming convention for it. A VAN holds the files in a mailbox and routes them to the partner's network.

Web EDI satisfies the partner's requirement and leaves the data entry. At 40 orders a day with 12 lines each, that is 480 lines to key in daily, and the ship notice and invoice for each order have to be keyed back into the portal.

The documents in an order-to-cash cycle

The X12 and EDIFACT pairs are industry convention; neither standards body publishes an official crosswalk. All EDI documents with a page of their own are listed in the overview.

The example order on our document pages shows how the documents depend on each other. The 850 for PO 4500018236 orders 24 plus 16 units, 40 in total. The 855 confirms 24 and 12, so 36. The 856 reports 36 units shipped in one carton, and the 810 bills 300.00 plus 105.00 minus a discount of 8.10 plus freight of 18.50, which is 415.40. Every later document has to agree with the one before it, and the buyer's system checks that.

The volume follows from the same cycle. One order is one 850 in and three documents out, and each of the four is answered by a 997: 8 files per order. At 40 orders a day that is 320 files a day, 160 of them acknowledgments that have to be matched to the document they answer. An 856 that never received its 997 is found by that matching, or by the retailer.

Where EDI goes wrong

A document is checked at three levels, and passing one says nothing about the next.

The 997 answers the first level only. A partner-guide failure comes back as a rejection in an application advice (the 824 at Walmart and Kroger) or in a portal. A business-rule failure comes back later, as a deduction on the payment. The usual cause is a mismatch between two documents, and the ship notice is the one built from warehouse data instead of order data.

What this means for your integration

A trading partner that requires EDI asks for four things: its documents, in its version, over a transport it accepts, with content that matches what you ship and bill. The first three are settled once per partner. The fourth is settled per order, and it depends on how well the EDI layer is connected to the ERP, the warehouse and the store.

We build that connection as an EDI integration to your systems and your partners' guides: inbound orders are validated, acknowledged and created through the ERP's API, outbound documents are built from the fulfillment and invoice records, and every acknowledgment is matched. A document that fails validation is held in a queue and shown in the dashboard with the reason. Tell us which partner asked you for EDI.