EDI 856Electronic Data Interchange 856 (Advance Ship Notice)

EDI 856 is the X12 transaction set known as the Advance Ship Notice. It is sent by the shipper to the receiver — almost always a retailer or a retailer's distribution centre — before, typically at the moment of, truck departure. It describes the shipment hierarchically: what is being shipped, on which pallets, in which cases, of which items, in which lots, in what quantities, against which purchase order, on which carrier, on which BOL.

The retailer uses the ASN to plan receiving labour, validate the shipment on arrival, and book product into inventory the moment the pallets clear the dock. Without it, every pallet has to be opened, counted manually, and reconciled to the paper packing list — a process that turns a 30-minute dock turn into a four-hour exercise and creates inventory variance every time.

EDI 856 is paired with the SSCC (Serial Shipping Container Code) printed as a GS1-128 barcode on every pallet. The two together — the electronic manifest and the physical pallet label — are what enables one-scan receiving. Scan the SSCC, look it up in the ASN, book every line on the pallet against the PO in one event. No 856 means no one-scan receiving, no matter how good the SSCC label is.

An 856 is built as a hierarchical loop (HL) that mirrors the physical structure of the shipment. Each HL segment carries a level code that tells the receiver what kind of node this is in the tree.

Most retailers want pallet-level ("SPT" — Shipment / Pack / Tare) or full pack-level ("SPI" — Shipment / Pack / Item) detail. The retailer's EDI specification document tells you which hierarchy they accept and which fields are required at each level. A few specify even deeper hierarchies (SOPI — Shipment / Order / Pack / Item) when a single shipment carries multiple POs interleaved at the case level.

Within each HL the X12 message uses a defined sequence of supporting segments: TD1/TD3/TD5 for transport detail, REF for reference numbers (PO, BOL, ASN ID), DTM for dates, FOB for terms, N1/N3/N4 for parties, MAN for the SSCC itself, LIN/SN1 for the item lines, PID for product description, and PO4 for pack characteristics. Every retailer pins which of these are mandatory, conditional, or not used at all.

The SSCC printed on the physical pallet must match the SSCC carried in the tare loop of the 856. The pallet label is the physical key; the ASN is the electronic record; the link is the 18-digit SSCC carried in the MAN02 element under each T-level HL.

When the receiver scans the pallet at the dock, the system looks up the SSCC in the ASN and pulls every GTIN, lot, quantity, and PO line on that pallet without re-entering anything. Match → book → done. No match → exception, manual count, chargeback risk.

This is the entire reason the SSCC exists. Without the SSCC-to-ASN tie, the ASN is just a list of products and the retailer cannot reconcile what physically arrived to what was electronically promised. A perfect ASN with the wrong SSCC on the pallet, or the right SSCC on the pallet with no matching ASN line, both fail receiving.

The GS1-128 pallet label is the physical anchor for the ASN. The label structure pins the data the ASN references:

Build the label and the ASN from the same data source or they will drift. Every chargeback story starts with "the label said one lot, the ASN said another."

Although the 856 transaction is a published X12 standard, every retailer adds its own implementation guide that defines which fields are mandatory, which conditional codes apply, the hierarchy level required, the label format, the SSCC structure, the timing window relative to truck departure, and the response transaction (824 or 997) you should expect.

Walmart, Target, Kroger, Costco, Sam's Club, Albertsons, Publix, Amazon, Whole Foods, HEB, Wegmans, Meijer — every one of them has its own variant. ASN systems either model these explicitly or fall over the first time a new retailer is onboarded.

Examples of where the variants bite:

• Hierarchy depth — some retailers reject SPI when they want SPT and vice versa.
• Mandatory SSCC structure — some retailers want your GS1 prefix in a specific position.
• Lot/expiry conditionality — perishable categories require it; non-perishable may forbid it.
• Country of origin at item level — required for some categories, optional for others.
• Timing window — some want ASN at truck departure, some at 24h before delivery, some at any point as long as it lands before the truck.
• Response transactions — some send a functional ack (997) only, others send a detailed application-level ack (824) on errors.

Chargebacks of $50–$500 per ASN error are routine; some retailers run into thousands per truck for repeat offenders. A bad ASN program at a mid-sized food manufacturer can give back the entire margin on its top-three retail account in a quarter.

FSMA 204 doesn't require an 856 specifically, but it does require capture of the Key Data Elements (KDEs) at the Shipping CTE for any food on the Food Traceability List (FTL): Traceability Lot Code (TLC), TLC source reference, quantity, UoM, ship-from, ship-to, ship-date, reference document type and number, traceability product description. Most of these are already in a well-built 856.

If you are already sending 856s for retail, every shipment of an FTL item already contains most of the KDEs in structured form. The remaining work is making sure the captured data is sortable into the FDA-required sortable spreadsheet within 24 hours of an FDA electronic-export request. A well-built ASN is the easiest FSMA 204 capture path for shipping CTE; missing one means parallel capture, which is where most non-compliance gaps appear.

Sending the 856 is not the same as the retailer accepting it. Two response transactions matter:

• 997 — Functional Acknowledgement. Confirms the EDI envelope was received and the syntax parsed. Does not confirm the business content was accepted. Should land within minutes; absence after a few hours means the EDI link is down.
• 824 — Application Advice. Sent by some retailers (notably Walmart and Target) on application-level errors — mandatory field missing, GTIN unknown, hierarchy mismatch. Triggers a re-send window before chargebacks fire.

Sites that monitor only the 997 and assume "acknowledged means accepted" routinely discover the chargebacks weeks later. The 824 must be ingested, parsed, and routed to whoever owns ASN quality, with a defined re-send SLA.

• Building the ASN from the picking ticket rather than the actual pallet build — the two diverge whenever pick exceptions happen on the floor.
• Holding the retailer implementation guide as a PDF on a SharePoint nobody reads — when the retailer issues v3.2 of the spec, nothing updates the translator until the chargebacks land.
• Letting the EDI VAN translator handle the SSCC generation independently of the WMS — guaranteed drift.
• No automated retailer-spec validation before transmission — the EDI translator passes anything that's syntactically valid X12 even when it will fail the retailer's business rules.
• Treating the 997 as the success signal and ignoring 824s.
• No per-retailer dashboard tracking ASN error rate, chargeback dollars and root cause — the program degrades silently.
• Pallet label printed on a different system than the ASN built — two sources of truth, eventual drift.

Three transport options dominate retail EDI for the 856. Each one carries the same X12 envelope; the choice is operational rather than functional.

Most regulated manufacturers shipping to retail end up with a hybrid: a primary VAN handling the long tail, AS2 connections to the top three retailers, and an API integration for newer channels. The translator (in-house or vendor) is the same regardless of transport — what changes is the envelope wrapper and the acknowledgement pattern.

Adding a new retail customer to an existing EDI programme is a 6 to 12 week effort in most cases, longer for the largest retailers with the strictest spec. The sequence:

1. Retailer issues their EDI Implementation Guide — typically 100–300 pages covering 850 / 855 / 856 / 810 / 997 plus retailer-specific extensions.
2. Field-level mapping workshop — map every mandatory field, every conditional rule, every code-list value to your existing data model. Gaps become work items.
3. SSCC structure agreed — your GS1 prefix, the serial-number range, the check-digit convention.
4. Test transactions exchanged in the retailer's certification environment — usually 20–50 round-trips covering happy-path and exception scenarios.
5. Retailer signs off certification — a written approval is required before any live ASN is accepted.
6. Soft-launch with a single PO, manual review of every 997 and 824 response, rapid feedback loop with the retailer's EDI team for the first 30 days.
7. Move to production volume only when error rate is below the retailer's chargeback threshold for two consecutive weeks.

Skipping certification or rushing soft-launch is the most common source of first-quarter chargeback shocks — sites that ship full volume on day one and discover the spec compliance is 92% instead of 99% end up paying tens of thousands in correctable errors before the loop tightens.

Chargebacks are the feedback loop that tells you the EDI programme is degrading. A site without a chargeback dashboard discovers issues only when finance reconciles the retailer remittance against the invoice — typically 30 to 60 days after the error. By that point, the same error has repeated across dozens of shipments and the cumulative cost dwarfs any single avoidance action. The programme that works:

1. Ingest the chargeback notification (824, retailer portal export, or remittance deduction line) automatically into a single dashboard.
2. Categorise by root cause: SSCC mismatch, late ASN, missing field, qty short, lot/expiry missing, hierarchy depth, GTIN unknown, ACH timing.
3. Trend per retailer, per category, per week. A spike in one category at one retailer is usually a single spec change you missed or a single workflow regression.
4. Dispute chargebacks where the error is the retailer's — wrong receipt count, GTIN that was announced in time, ASN sent inside the window. Dispute rates of 15–30% are normal at mature programmes; 0% means you're paying things you shouldn't.
5. Feed corrected root cause back into the build / validation layer within one week — the cost of a single fix scales linearly with the number of shipments that hit it before correction.
6. Report monthly to the commercial team — chargebacks per retailer per shipment, total dollar value, dispute success rate, top three root causes. Without this loop the chargebacks become a silent margin tax.

A well-run programme operates at 0.5–1.5% chargeback rate by dollar value across retail accounts. A neglected programme runs 4–8% and the cost is visible in finance only at quarter-end. The difference is the dashboard and the weekly root-cause loop.