EDI document types: the X12 documents by number

What an EDI document type is

An EDI document type is a transaction set of the X12 standard, identified by a three-digit number. Each one has a fixed purpose and a fixed direction: the 850 is a purchase order from a buyer to a supplier, the 856 a ship notice from the supplier back. The number tells both sides which segments to expect and in which order.

The standard is large. Release 004010 defines 293 transaction sets, release 005010 defines 318 and release 008050 defines 321. A supplier that trades with retailers, distributors, a warehouse and a carrier meets about 30 of them, listed below, and handles five to ten in daily volume. The work of an EDI integration is in those few, per trading partner.

Three facts apply to every type:

• Inside the file a document is one ST to SE block, and ST01 holds the number.
• Documents of one kind travel together in a functional group, and GS01 names the kind with a two-letter code: PO for the 850, SH for the 856, IN for the 810.
• Every functional group is answered by a 997 functional acknowledgment.

Which documents move between which parties

The buyer set is the one retailers mandate. The warehouse set appears when a 3PL ships for you, and the carrier set when freight is tendered electronically. One order passes through them in this sequence:

1. The buyer sends an 850 purchase order.
2. The supplier answers with an 855 acknowledgment: accepted, changed or rejected per line.
3. A change by the buyer arrives as an 860.
4. The supplier releases the order to the warehouse with a 940, and the warehouse reports what it shipped with a 945.
5. The supplier sends the 856 ship notice before the goods arrive.
6. The supplier bills with an 810 invoice.
7. The buyer pays and explains the payment with an 820 remittance advice.

Count the files for one order without a change: 850, 855, 940, 945, 856, 810 and 820 are 7 documents, and each is answered by a 997, so 7 plus 7 is 14 transaction sets. At 300 orders a month that is 4,200 sets, half of them acknowledgments that have to be matched to the document they answer.

EDI document list: order to cash

The names are the official X12 names. Direction is given from the supplier's side.

The 997 and the 824 are both answers to another document. The 997 reports whether the syntax was accepted, the 824 whether the receiving application accepted the content. The 812 notifies the other party of an adjustment or a billback, and is the document a buyer uses to report a deduction against an invoice.

EDI document list: stock, catalog and planning

The 846 is the document a drop-ship program runs on: the buyer sells what the latest 846 said was available. The quantity in it is the available quantity, not the on-hand count, a difference explained under stock and availability.

EDI document list: warehouse and transport

The 945 is the source of the 856 when a 3PL ships: the cartons and quantities the warehouse reports are the ones the ship notice has to carry. The 753 and 754 are not in release 004010. They first appear in release 004030, so a partner that uses them does not run a pure 004010 program.

The same documents in EDIFACT

Outside North America the same documents travel as UN/EDIFACT messages with names instead of numbers. Neither standards body publishes an official crosswalk. These pairs are the convention, and they hold across sources:

For the 864, the 945 and the 753 and 754 there is no established pair. A partner in Europe that asks for ORDERS and DESADV asks for the same flow as an 850 and an 856, in a different syntax, often in GS1's EANCOM subset. The differences in envelope and structure are under X12 vs EDIFACT.

What a trading partner asks for

No partner asks for the whole list. Each publishes the set per program, and two public ones, checked on 3 October 2026, show the spread.

Kroger's requirements page lists 20 document numbers in total, including the 857 Shipment and Billing Notice, the 867 Product Transfer and Resale Report, the 889 Promotion Announcement and the 894 and 895 for direct store delivery. Which of those apply depends on the program: warehouse replenishment, direct store delivery, vendor-managed inventory or scan-based trading. The sources are Walmart's EDI interface page and Kroger's EDI requirements. Partner pages: EDI with Walmart, EDI with Kroger and EDI with Amazon.

Where document types get mixed up

• 850 and 875, 810 and 880. Same role, different transaction set. A mapping built for the 850 does not read an 875.
• 997 and 855. The 997 says the order file was readable. The 855 says the order will ship. A buyer that has the first still waits for the second.
• 997 and 824. A ship notice can pass the 997 and fail the 824, because the purchase order number in it is closed or the item is unknown.
• 856 and 857. The 857 Shipment and Billing Notice combines ship notice and invoice in one set. A partner that uses it does not want a separate 810.
• 860 and 865. The 860 comes from the buyer, the 865 from the seller. An 860 that is processed as a new 850 creates a second sales order.
• Version. GS08 carries the version, 004010 or 005010. The same number in another version has other codes and element lengths, and a file in the wrong version is rejected with a 997.

What each document is on the ERP side

A document type is a format. The ERP knows records. The mapping between the two is where the work is.

NetSuite, Business Central and the store platforms have no X12 translator of their own. What each one offers natively is on the pages for NetSuite EDI integration and Shopify EDI integration.

We build the part in between as an EDI integration: each document your partners require, mapped to the records of your ERP, validated against the partner's guide before it is sent, with every 997 matched to its document. Tell us which documents your partner asks for.