A supplier ships a truckload of product, everything scans fine at the dock, and three weeks later a $500 chargeback shows up on the deduction report with a code that just says "ASN error." The truck was never the problem — the EDI 856 that was supposed to describe it was. Advance ship notices are one of the most unforgiving documents in retail EDI: unlike a purchase order, where a mismatch just means a phone call, a bad 856 triggers automated deductions with no human review. Here's what actually goes wrong in an 856, and how to catch it before the shipment leaves your dock.
What an 856 is, and why retailers are strict about it
The 856 (Advance Ship Notice, or ASN) is sent before a shipment physically arrives, telling the receiver's warehouse management system exactly what's in every carton on the truck — down to the pallet, case, and item level — so receiving can be scanned in rather than manually counted. Big retailers automate receiving almost entirely around the ASN: a warehouse worker scans a carton's UCC-128/SSCC barcode, the system looks up that exact carton in the 856 that was transmitted ahead of time, and receiving completes in seconds. When the ASN doesn't match reality — or doesn't arrive, or doesn't parse — that automation breaks, someone has to intervene manually, and the retailer passes the cost of that intervention back to the supplier as a chargeback. This is why ASN compliance is graded far more harshly than purchase order or invoice accuracy: an 850 or 810 error is inconvenient; an 856 error stops a conveyor belt.
The HL hierarchy, and where it breaks
The 856's structure is built entirely from HL (Hierarchical Level) segments, each declaring its
own ID, its parent's ID, and a level code — S shipment, O order, P pack, I item:
HL*1**S~
TD1*CTN*4~
TD5**2*UPSN*M*GROUND~
HL*2*1*O~
PRF*PO-100234***20260710~
HL*3*2*P~
TD1*CTN*2~
HL*4*3*I~
LIN*1*VP*SKU-88213*UP*04963000123~
SN1**60*CA~
HL*5*3*I~
LIN*2*VP*SKU-77410~
SN1**40*CA~
Read as a tree: shipment 1 contains order 2 (referencing PO-100234 via PRF), which contains
pack 3, which contains two items — 4 and 5 — each with its own LIN product ID and SN1
shipped quantity. This tree is the entire ASN; there's no separate "line items" table like a
purchase order has. Which means the most common source of chargebacks isn't a wrong value in a
field — it's a broken tree:
- A child HL points to a parent ID that doesn't exist, or a level code that doesn't match the actual nesting (an item HL claiming to be a direct child of the shipment, skipping the order and pack levels). The parser either drops the node or attaches it in the wrong place, and the receiver's system ends up looking for a case that, as far as it's concerned, isn't on the truck.
- A pack or carton in the ASN has no matching physical label, or vice versa — the UCC-128 barcode on the actual carton doesn't correspond to any HL node in the file. This is the single most common ASN chargeback reason at most big-box retailers.
- Quantity mismatches between the 850, the 856, and what's physically on the truck. The
SN1shipped quantity should reconcile with what was ordered and what's actually packed; silent substitutions or partial shipments that aren't reflected in the ASN are a frequent cause. - Missing or duplicated HL IDs. Every
HL01in a transaction set must be unique; a duplicate (often from a bug in the sender's ASN-generation code, not a data-entry mistake) corrupts every parent/child link below it. - The ASN doesn't reference the right PO. The
PRFsegment's PO number has to match what the buyer actually issued — a typo or a stale PO number here breaks the automated three-way match before it starts. - Late transmission. Most retailer EDI guides require the ASN to be sent within a fixed window before or after the truck leaves — not a content error, but graded and charged back the same way.
How to catch these before you ship
Fixing an ASN chargeback after the fact usually means a deduction dispute with limited odds; the economical fix is catching the structural problem before transmission. Paste or drop your 856 into the free EDI viewer and it renders the full shipment → order → pack → item tree from the HL segments, labels every field in plain English, and flags control-number and count mismatches automatically — so a broken parent link or a missing item node is visible at a glance instead of buried in fifty lines of raw segments. It runs entirely in your browser, so nothing about your shipment data is ever uploaded.
That said, a generic viewer can show you the structure — it can't yet tell you that carton 4's UCC-128 label doesn't exist, or that this PO was already fully shipped on an earlier ASN. That's the specific, retailer-aware validation I'm building next, purpose-built to catch the exact errors that trigger chargebacks before the ASN ever gets transmitted. If that's a problem you deal with regularly, there's a quick early-access signup right on the EDI viewer page.