EDI 856 Advance Ship Notice: ASN Structure and Implementation Guide

An EDI 856 is the X12 Ship Notice/Manifest transaction set, commonly called an advance ship notice or ASN. A supplier sends it to describe a shipment before or as goods move through the receiving process.

An EDI 856 can connect shipment, order, packaging, and item information in one hierarchical document. That structure can help a receiving organization understand what is coming, which purchase order it relates to, and how products are arranged in pallets or cartons. The precise requirements depend on the trading partner’s implementation guide.

What does an EDI 856 contain?

Depending on the partner and X12 version, an EDI 856 may carry a shipment identifier, ship date and estimated delivery information, carrier and transportation details, purchase order references, package identifiers, item identifiers, quantities, and ship-to or ship-from parties. Some programs also connect carton information to shipping-label identifiers.

How the EDI 856 hierarchy works

The defining feature of the 856 is its hierarchical loop. The HL segment identifies a level and can point to its parent. A common shipment-order-pack-item structure is abbreviated as SOPI:

  • Shipment: information applying to the overall shipment, such as carrier or shipment identification.
  • Order: the purchase order represented within the shipment.
  • Pack: a pallet, carton, or other handling unit, when required.
  • Item: the products and quantities associated with an order or package.

Not every partner uses the same hierarchy. Some guides use shipment-order-item, while others require detailed pack loops. Build and validate the tree described by the current partner guide rather than assuming one universal ASN layout.

Common EDI 856 segments

  • ST and SE: open and close the transaction set.
  • BSN: begins the ship notice and commonly carries shipment identification, date, time, and hierarchy-related information.
  • HL: identifies each hierarchical level and its relationship to a parent level.
  • TD1 and TD5: can describe packaging, carrier, or transportation information.
  • REF: supplies qualified reference identifiers.
  • DTM: carries dates or times whose meanings are defined by qualifiers.
  • N1 loops: identify parties and locations.
  • PRF: can reference the related purchase order.
  • MAN: can carry marks and numbers, including package identifiers when the guide requires them.
  • LIN and SN1: can identify an item and state shipment quantities.
  • CTT: can provide transaction totals.

This list is an orientation, not a production map. Segment use, qualifiers, repetitions, and code values vary by X12 version and trading partner.

A simplified EDI 856 hierarchy example

ST*856*0001~
BSN*00*SHIP123*20260712*1200*0001~
HL*1**S~
HL*2*1*O~
PRF*PO12345~
HL*3*2*P~
MAN*GM*000123456789012345~
HL*4*3*I~
LIN**SK*ITEM123~
SN1**10*EA~
CTT*4~
SE*11*0001~

This illustrative snippet shows shipment, order, pack, and item levels. It omits envelopes and many details, and it is not a reusable production message. Use the exact hierarchy, identifiers, counts, and validation rules agreed with the receiving partner.

Where EDI 856 fits in order-to-cash

  1. The buyer sends an EDI 850 Purchase Order.
  2. The supplier may return an EDI 855 Purchase Order Acknowledgment.
  3. The supplier sends an EDI 856 Advance Ship Notice for the shipment.
  4. The supplier sends an EDI 810 Invoice.
  5. Technical or business acknowledgments may be exchanged according to the partner agreement.

The 856 describes a shipment; it is not an invoice and does not by itself prove that the buyer received or accepted the goods.

EDI 856 implementation checklist

  • Pin the partner guide: record its revision, X12 version, hierarchy, required segments, qualifiers, and code lists.
  • Confirm timing: define when the ASN must be transmitted relative to shipment departure and receiving.
  • Model hierarchy explicitly: verify every HL identifier, parent reference, and level code.
  • Reconcile documents: test purchase order numbers, items, quantities, units, and destinations against the source order and actual shipment.
  • Coordinate labels: where package identifiers or GS1-128 labels are required, ensure the physical label and MAN data match.
  • Test packing patterns: include single- and multi-order shipments, mixed cartons, multiple cartons, partial shipments, and over- or under-shipments where permitted.
  • Validate duplicates and corrections: define how repeated shipment identifiers, cancellations, replacements, and late ASNs are handled.
  • Monitor exceptions: separate syntax failures from business-rule failures and assign an owner for each exception class.

Why partner-specific testing matters

Current sampled guides demonstrate that active EDI 856 programs still use different X12 versions and receiver-specific operating rules. Kroger describes prerequisites and receiver sign-off for its ASN program; SAP documents hierarchical X12 4010 processing; and other partner guides specify their own timing, packaging, and validation profiles. Passing a generic syntax test is therefore not the same as passing partner certification.

The practical takeaway

An EDI 856 gives a receiving partner structured shipment visibility, but reliable implementation depends on an accurate hierarchy and the current partner guide. Pin the version, reconcile the ASN to the order and physical shipment, test realistic packaging scenarios, and monitor both technical and business exceptions.

If you are planning an EDI 856 or ecommerce fulfillment integration, contact Neutron Development to discuss the workflow and operational requirements.

Sources

You may also like...

Popular Posts