EDI 856, Explained: The Advance Ship Notice

What EDI 856 is, how its HL hierarchy works, and how it differs from EDI 214 and 945 — with a worked retail ASN example.

Share

Every EDI implementer eventually gets a call about a shipment that showed up at a distribution center with no warning. The 856 is the document that's supposed to prevent that call. EDI 856 is the ANSI X12 Ship Notice/Manifest transaction set, sent by a shipper to a buyer before freight arrives, describing what shipped, how it's packed down to the carton and pallet, which carrier is moving it, and which purchase order it fulfills. EDI 856 is the X12 transaction set used to send a ship notice/manifest, commonly called an advance ship notice or ASN, from a supplier to a buyer before goods arrive, telling the buyer what has shipped, how it is packed, which carrier is moving it, and how the shipment connects back to the original purchase order.

For readers working outside North America, for businesses using the EDIFACT standard, the equivalent of the EDI 856 is the DESADV, or Dispatch Advice Message, and EDIFACT DESADV, plus VDA and Odette ship-notice messages, serve the same role in European automotive programs. We've covered DESADV in its own right elsewhere on this blog, so this post stays focused on the X12 side.

What a typical EDI 856 actually communicates

The 856 isn't a single data field, it's a bundle of shipment, packaging and carrier information wrapped around a purchase order reference. A typical EDI 856 communicates what was shipped, which purchase order or order numbers the shipment fulfills, which items are included, the quantity shipped, how goods are packaged into cartons, pallets, or other handling units, carrier information, tracking numbers, ship dates and expected delivery dates, and ship-from and ship-to locations. The standard provides the transaction framework, but each trading partner may specify exactly which segments, loops, qualifiers, and codes they require, which is why two retailers' 856 specs can look structurally similar and still reject each other's files.

EDI 856 vs EDI 214, EDI 945 and EDI 810

These four get lumped together constantly because they all touch the same shipment, just at different moments and from different senders.

DocumentSent bySent toWhat it actually does
EDI 856Supplier or warehouseBuyer / retailerAnnounces shipment contents, packaging and PO match before arrival
EDI 214CarrierShipper and receiverReports real-time transit status after pickup
EDI 945Warehouse / 3PLGoods ownerConfirms shipment execution back to the party that owns the inventory
EDI 810SupplierBuyerBills for the goods after the fact

On the 214: the EDI 214 is the Transportation Carrier Shipment Status Message, the document carriers send to report pickup confirmations, checkpoint arrivals, delays with reasons, exceptions and final delivery. The 214 complements the order side: it tracks the truck, while the 856 Ship Notice/ASN tells the buyer what is in the shipment. On the 945, the confusion runs the other direction: the EDI 945 is sent from the warehouse to the supplier to confirm a shipment was made, while the EDI 856 is sent from the supplier to the customer to notify them that goods are on the way. And on the 810, an 850 is a purchase order, an 856 is an advance ship notice, an 810 is an invoice — three separate documents, three separate moments in the order lifecycle.

How the EDI 856 HL hierarchy actually works

The structural backbone of the 856 is the hierarchical level loop, and it's the part people new to EDI mapping tend to get wrong first. An 856 has three parts: a heading that identifies the shipment, a detail section built from hierarchical levels, and a summary that closes the transaction, around the standard X12 envelope. The BSN segment opens that detail section: BSN carries the beginning ship notice: purpose code, shipment ID, date, time, and a hierarchical structure code, where 0001 means shipment, order, pack, item, and 0004 means shipment, order, item with no pack level. That code matters because it tells the receiving system how many HL levels to expect before it even parses them.

From there, each HL segment nests inside the one above it: shipment contains orders, orders contain packs (cartons or pallets), packs contain items. The pallet or carton identifier lives in the MAN segment, and this is the field that connects the electronic document to the physical label on the dock: the serial shipping container code (SSCC) printed on each pallet or carton label must appear in the ASN's MAN segment, the quantities must add up through the hierarchy, and the ASN must arrive before the truck. Carrier and routing detail sits in a separate family of segments: TD1 and TD5 carry packaging counts, weight, routing, carrier SCAC, and mode of transport.

Not every trading partner implements the full four-level tree. Some skip the pack level entirely and ship item data directly under the order, which is exactly why the implementation guide for a specific retailer matters more than the base X12 standard. Reading the standard tells you what's possible; reading the guide tells you what that retailer will actually accept.

Worked example: PO to pallet label to dock scan

Here's how the pieces actually move in sequence for a consumer-goods supplier shipping against a big-box retailer purchase order:

  1. The supplier picks and packs 12 pallets against the PO and builds carton and pallet labels. A compliance engine tied to the WMS calculates optimal carton splits, prints retailer-compliant GS1-128 labels with SSCCs, and generates EDI 856 ASNs.
  2. The 856 is transmitted referencing the PO number at the order level and the SSCCs at the pack level, ahead of the truck leaving the yard.
  3. At the retailer's distribution center, each label is scanned and matched to the ASN. Matches go straight to stock. Mismatches create an exception, a manual count and usually a chargeback.

Those chargebacks aren't hypothetical. According to a 2026 EDI chargeback database, Walmart assesses a $500 penalty per shipment for a late or missing 856, with SSCC-18 labels required on every carton, while Target charges $0.75 per carton with a $100 minimum for ASN violations effective May 2025, requiring the ASN to match the physical shipment down to the item level. Automotive OEMs push the timing even harder: in an AIM case study, Gil-Mar Manufacturing described a Ford requirement to send shipment notification within 15 minutes of a shipment leaving its dock, while Gil-Mar was shipping nights and weekends.

Why the ASN's carrier data matters beyond compliance

Most of the attention on 856 accuracy goes to SSCCs and quantities, but the TD5 carrier and tracking fields are only as good as the system that booked the shipment. If a planner is re-keying a SCAC code or a tracking number by hand into the EDI mapping tool, that's a manual step sitting in the middle of a document that's supposed to be automated end to end, and it's a predictable place for errors to enter the file. The cleaner pattern is to let a transportation management or multi-carrier booking platform generate that data once and feed it straight into the 856 mapping. That's the role played by TMS platforms like MercuryGate, Descartes, Transporeon, Oracle Transportation Management, SAP TM and Alpega, digital freight platforms like Uber Freight, and multi-carrier connectivity tools such as Cargoson, ShipStation/ShipEngine and Sendcloud. None of them replace the 856 mapping itself, but they're the systems that should be the source of truth for the carrier and routing segments rather than a spreadsheet.

Who requires EDI 856, and who sends it on your behalf

The ASN is used to advise the receiving party of a shipment and is required by many major retailers to be sent in a specific timeframe before the product arrives at the retailer's distribution center or store. Costco's vendor requirements are typical of the category: the 856 Advance Ship Notice details packing structure, pallet SSCCs, carton counts, UPCs/GTINs, and carrier/trailer info, and Costco enforces receiving rules through chargebacks for non-compliance, including late ASNs, incorrect labeling, and inconsistent case counts. If you're shipping fresh produce under FSMA 204 traceability rules or automotive parts tracked by cumulative shipped quantity, the same 856 document often does double duty as compliance evidence, which is worth a dedicated look on its own.

Most suppliers don't build 856 mapping from scratch. EDI providers like SPS Commerce, TrueCommerce, Cleo and IBM Sterling generate and translate the transaction set on behalf of suppliers who don't want to maintain X12 mapping logic in-house, which is usually the right call for anyone without a dedicated EDI team.

EDI 856 frequently asked questions

What's the difference between an ASN and EDI 856? None. ASN is the common industry name; EDI 856 is the X12 transaction set number behind it. They're the same document, commonly called an advance ship notice from a supplier to a buyer before goods arrive.

When should an EDI 856 be sent? Typically after the supplier confirms what is shipping, often at or shortly after shipment, and before the goods arrive at the buyer's receiving location. Retailer-specific windows (hours, not days) are set in the trading partner's routing guide, not the X12 standard.

What causes an EDI 856 chargeback? Missing, late, or inaccurate advance ship notices that disrupt warehouse receiving top the list, alongside SSCC/MAN mismatches and quantities that don't tie out against the PO or the prior 855 acknowledgment.

Does EDI 856 require GS1 labeling? The X12 standard itself doesn't mandate it, but the SSCC is an 18-digit GS1 identifier generated from the shipper's GS1 company prefix plus a serial number, printed in a GS1-128 barcode on the label, and sent in the ASN's MAN segment so the retailer can scan the unit against the document — and virtually every major retailer's vendor manual requires exactly that.

Can EDI 856 be replaced by an API? For new trading relationships, yes, increasingly. Many retailer B2B portals and marketplace integrations now accept the same shipment, carrier and SSCC data over a REST API rather than a flat X12 file. The underlying data requirements barely change. What changes is the transport layer, and that's usually the easier half of the migration.