EDI 856 Advance Ship Notice

What is an EDI 856?

The EDI 856 is the X12 transaction set Ship Notice/Manifest, known in retail as the advance ship notice or ASN. The supplier sends it to the buyer when a shipment leaves, and it lists the contents and the packaging of that shipment: carrier, bill of lading, purchase order numbers, every carton with its SSCC, and the items and quantities in each carton. The EDIFACT counterpart is the DESADV message.

The receiving dock scans the barcode on a carton, finds the matching 856 and books the contents without opening the box. That only works when the document and the physical shipment say the same thing, which makes the 856 the document where most compliance penalties start. It is one of the EDI documents every retail trading partner asks for, and the one with the most partner-specific variation.

Where the 856 sits in the order-to-cash flow

The 856 is the third document a supplier handles on an order, and the first that depends on warehouse data instead of order data.

Each document sent is answered by a 997 functional acknowledgment. Where a warehouse or 3PL ships the goods, its 945 shipping advice is the source of the 856. The invoice quantity has to agree with the 856 quantity, so an error in SN102 comes back a second time on the 810.

The segments of an 856

After ST, the X12 standard defines one mandatory header segment, BSN, and a detail area that is a single HL loop repeating up to 200,000 times. Everything else hangs under an HL level.

The four pack structures

The buyer chooses the hierarchy and announces it in its implementation guide. BSN05 names the order of the levels, and HL03 marks each level.

There is no separate BSN05 code for the pallet level. The X12 name for 0001 is "Shipment, Order, Packaging, Item", and both the T level (shipping tare) and the P level (pack) count as packaging.

A sample 856, with delimiters

This is one transaction set for one purchase order: a single carton that holds two items, 24 units of the first and 12 of the second. Elements are separated by *, segments end with ~.

ST*856*0001~
BSN*00*SH0004821*20261003*0915*0001~
HL*1**S~
TD5**2*ABCD~
REF*BM*BOL7730042~
DTM*011*20261003~
N1*ST*HARBOR RETAIL DC 07*92*0007~
HL*2*1*O~
PRF*4500018236~
HL*3*2*P~
MAN*GM*00006141410000482917~
HL*4*3*I~
LIN**UP*614141104826~
SN1**24*EA~
HL*5*3*I~
LIN**UP*614141104994~
SN1**12*EA~
CTT*5~
SE*19*0001~

The counts are checked before any business data is read. There are 5 HL segments, so CTT01 is 5. From ST to SE there are 19 segments, so SE01 is 19, and SE02 repeats the control number 0001 from ST02. The MAN02 value is 20 characters: 00, then the 18 digits printed on the carton label. Shipping 24 plus 12 is 36 units against this PO; if the 855 confirmed 40, the buyer sees a 4-unit shortage the moment the file is processed.

The envelope around it

The transaction set travels inside a functional group, inside an interchange. For an 856 the functional identifier in GS01 is SH.

ISA*00*          *00*          *ZZ*NORTHFIELD     *01*123456789      *261003*0915*U*00401*000000457*0*P*>~
GS*SH*NORTHFIELD*123456789*20261003*0915*457*X*004010~
ST*856*0001~
SE*19*0001~
GE*1*457~
IEA*1*000000457~

ISA has 16 elements of fixed length, so the sender ID in ISA06 is padded with spaces to 15 characters. The interchange control number in ISA13 (000000457) has to come back in IEA02, the group control number in GS06 (457) in GE02, and GE01 and IEA01 count the transaction sets and the groups. ISA15 is P for production and T for test. A partner that tracks control numbers rejects a repeat: Belk's guide tells vendors to use a unique interchange number for each transmission because its system rejects duplicates from the same sender and receiver ID.

Who requires the 856, and how they differ

Three published specifications, checked on 3 October 2026, show how far the same document varies.

Kroger puts the SSCC at the pallet (MAN*GM) and a case code at the pack level (MAN*UC), reports cases at pack level and eaches at item level, and adds PAL for tiers and blocks. Belk puts the SSCC at the carton, adds REFDP for the department and REFIV for the invoice number under each order, and consolidates every PO that ships to one DC on one day into a single notice. A mapping built for one of them is rejected by the other two, which is why EDI mapping is done per partner and per document. The guides are public: Kroger's 856 map and Walmart's EDI interface page. See also EDI with Kroger and EDI with Walmart.

What goes wrong and what it costs

Kroger publishes the list of conditions its receiving system flags on an ASN. It names 18 violations, and each one is a data mismatch, not a transport failure:

• The receipt number already exists for that PO: the ASN file was sent twice.
• The PO does not exist or is in closed status: PRF01 does not match an open order.
• The UPC is not valid: the LIN value is unknown to the receiving system.
• The load quantity is zero, or greater than TI times HI for that item (cases per layer times layers on the pallet): SN102 or the PAL data is wrong.
• The code date on the ASN is already expired: the DTM expiration date is in the past.

Kroger also requires the ASN to be "100% accurate" on license plates, case codes, quantities and expiration dates, and expects the vendor to call when no 997 or 824 has come back within 12 hours. Retailers price these failures per carton, per shipment or as a percentage of the product cost, and take the amount off the invoice payment. The schedules sit in vendor portals; the ones that can be read are collected under EDI compliance.

Three failures share one cause, a document built from order data instead of from what was packed: an 856 sent after the truck arrived, an SSCC in MAN that is on no label, and a unit count in SN1 that differs from the carton.

Handling the 856 on the ERP side

The 856 is built from three records: the sales order (PO number, ship-to), the shipment or item fulfillment (carrier, bill of lading, ship date) and the pack record (which units went into which carton, and the SSCC printed for it). Most ERPs hold the first two. The third often lives in a warehouse system, a shipping tool or a 3PL, and that is the data the HL loop is made of.

NetSuite shows the boundary. Its WMS has a system rule named "Generate EDI 856 outbound ASNs?" and an "ASN Required?" box on the customer. A scheduled script runs every 15 minutes and writes an ASNC Parent record per order and a Stage Outbound ASNC record per item. Oracle's documentation then states that this data is "read by the NetSuite EDI partner, who converts the data into an EDI document". The X12 file, the hierarchy per retailer and the envelope are outside the ERP. More on that under NetSuite EDI integration.

We build that outside part as an EDI integration to your systems: the pack data is read from wherever it is recorded, the 856 is assembled per partner guide, counts and SSCCs are validated before sending, and every 997 and 824 is matched to the document it answers. A notice that fails validation is held and shown in the dashboard with the reason, so it is corrected before the truck arrives. Tell us which partners you ship to.