EDI 856 (ASN): Why Retailers Reject It

You’re a supply chain, finance, or IT lead at a $10M–$500M CPG supplier, and a remittance just came in short. A shortage code, a few hundred or a few thousand dollars pulled off the check, tied to a shipment you’d swear went out clean. The PO matched. The pick sheet matched. The truck left on time.

So you go looking for what actually failed, and there’s nothing to find. No error message pointed you here. No alert flagged the shipment when it moved. By the time the deduction lands, the shipment is six weeks gone. It’s one of several near-identical lines your team has stopped disputing, because chasing a $150 deduction costs more in labor than it recovers. That’s the real cost: not one bad chargeback, but a recurring monthly loss that rarely gets traced back to its source.

The source is almost always the EDI 856 Advance Ship Notice, the transmission you send describing exactly what’s in the truck before it arrives. An 856 doesn’t fail like a form field fails. There’s no red banner. No alert telling your shipping coordinator that carton 14 of 22 is missing its SSCC label. The transmission goes out. The retailer’s system accepts it, or it doesn’t. If it doesn’t land clean, you find out weeks later. A deduction code shows up on a remittance thirty to sixty days after the fact, and by then the team rarely remembers which shipment it was.

The 856 is the middle document in the standard chain: the retailer sends you an 850 purchase order, you ship it and transmit an 856 describing exactly what moved, then you bill for it with an 810 invoice. The 856 is the only one of the three that describes the physical shipment in real time. When it’s wrong, your 810 and the retailer’s receiving count disagree with each other, and that disagreement is what a deduction code actually is.

What follows is what you’re actually transmitting, the six most common ways it breaks, and what each failure turns into on your remittance.

What the 856 actually carries

The 856 is built around a hierarchical loop, or HL, structure.

The same shipment gets described at multiple levels of detail, nested inside each other. A typical retailer implementation runs shipment, order, pack, item.

Some require an extra tare, or pallet, level between order and pack.

Each HL segment carries a level code: S for shipment, O for order, P for pack, I for item.

It also carries a pointer back to its parent loop. That pointer is the trick.

It’s what lets one transmission describe a multi-pallet, multi-PO shipment without repeating the whole document per carton.

Inside those loops, a handful of segments do the real work:

• BSN: the beginning segment. Carries the shipment’s reference number and ship date.
• TD1 / TD3 / TD5: packaging, carrier, and routing detail. How it’s packed, who’s hauling it, by what route.
• REF: reference numbers. Most importantly the bill of lading and the retailer’s PO number.
• MAN: marks and numbers. Where the SSCC-18 carton barcode lives, the number a warehouse scan checks against.
• SN1: item-level shipment detail. The quantity of each item in that carton.

That SN1 quantity gets compared against the PO.

Later, it gets compared against what the receiving dock actually counts. Almost every shortage-code deduction traces back to a disagreement in this one field.

When does an ASN count as late?

Most retailers want the 856 transmitted before the shipment physically arrives. Not before it leaves your dock.

An ASN sent the same afternoon the truck pulls up is late by most retailers’ definitions.

Even if the delivery itself hit its appointment window.

The retailer’s system uses the ASN to pre-stage receiving. It tells the DC what to expect.

The physical count gets checked against a known quantity instead of counted cold.

Miss that window, and the shipment often arrives as an unexpected, un-ASN’d delivery.

Some retailers treat that as its own compliance violation. Independent of whether the count was accurate.

A correct, on-time 856 can still leave you exposed if the shipment itself arrives with no delivery appointment booked. Several retailers run a separate scheduling system for the receiving dock, on top of the ASN. A shipment that shows up without a reserved slot gives the retailer grounds to treat the delivery as unconfirmed, regardless of what the ASN declared. Where a carrier books its own appointments, confirm they are actually doing it. An accurate 856 and a signed POD do not always settle a shortage dispute on their own if there is no appointment record behind either one.

Six reasons an 856 gets rejected or comes back wrong

The unit-of-measure row is the easiest one to misdiagnose.

Watch for a suspiciously round ratio: half of what was invoiced, or off by exactly the case pack size.

Check the UOM field first. It usually isn’t a physical count problem.

There’s a more severe variant of the SSCC row worth calling out on its own: the carton-level label is entirely correct, but it’s placed on units whose individual UPC labels are wrong. The receiving scan doesn’t fail cleanly here, because the wrong UPC still matches a real item in the retailer’s catalog. It’s just not the one on the PO, and sometimes it’s not even an item that’s been sold in years. That combination, correct carton label, wrong unit label, shows up most often right after an ERP or WMS migration. Label templates and item cross-references get rebuilt then, and a bad remap can slip through onto physical inventory before anyone catches it. It reads as a shortage on the PO that was actually shipped, and it carries a second risk the other five rows don’t: the mislabeled units can potentially be received and resold under the wrong item entirely.

What each failure becomes on your remittance

An ASN failure never shows up on your remittance as “EDI 856 error.”

You see a shortage code. A compliance chargeback. Occasionally a pricing deduction.

Always weeks after the shipment is gone and the paperwork trail has gone cold.

A quantity mismatch that under-declares what shipped becomes a shortage claim on your remittance.

That happens once your receiving count gets compared against the 856, not the physical carton.

A late or missing 856 becomes its own compliance line on your check, separate from whatever the receiving count shows.

The deduction code lookup covers what a specific code on your remittance is claiming, and what evidence reverses it.

But the ASN is almost always the earlier point where the dispute actually got decided. A single bad 856 can cascade beyond the shortage code into five separate chargeback categories from one shipment: ASN accuracy, shortage, OTIF, routing, and invoice mismatch. When you see multiple codes on the same remittance pointing to the same PO, start with the ASN.

Preventing it: a pre-transmission validation checklist

The fix for all six ASN failure modes above is the same shape: catch the mismatch before you transmit the 856, not after a deduction arrives on your remittance.

• Validate HL hierarchy and required segments against the retailer’s implementation guide before every transmission, not just at initial EDI setup. Guides change, and a passing test file from onboarding doesn’t mean this week’s shipment still matches.
• Confirm every carton in the physical pick has a matching MAN/SSCC entry, and that the barcode was actually applied to the carton, not just generated in the WMS.
• Reconcile SN1 quantities against the confirmed pick, not the order quantity, right before transmission. The order quantity is what should have shipped. The confirmed pick is what actually did.
• Check unit of measure explicitly. A UOM correct for one retailer’s guide is routinely wrong for another’s.
• Transmit against the retailer’s arrival-based timing rule, not your own ship-date convention. Build the buffer into your process instead of treating it as a stretch goal.

Running NetSuite specifically? NetSuite EDI 856 failures covers five ERP-specific gaps behind this checklist: item cross-references, unit-of-measure conversion, pick-confirm timing, subsidiary mapping, and kit explosion. It also covers the saved-search and workflow validations that catch each one. Running Business Central instead, the Business Central version covers a different five: item references, unit of measure, posting timing, ship-to mapping, and assembly kits.

This is the specific gap a data-bridge assessment is built to find: where the ASN your ERP generates and the shipment your warehouse actually built stop agreeing with each other.

The data-bridge calculator gives a rough sense of what that gap is worth, before you commit to finding it.

If your ERP says the shipment posted in full but the retailer deducted for shortage anyway, the problem is usually between four quantities from four systems. The root-cause trace walks through the full chain. If you want a structured weekly check that catches these gaps before they become permanent write-offs, see the Monday morning deduction triage.

Sources

• “EDI 856 Transaction Set,” Stedi, for segment structure (BSN, HL, SN1, MAN, REF, TD1/TD3/TD5) and the 850 → 856 → 810 document flow.
• “The Structure of EDI 856 ASNs,” SupplierWiki / SPS Commerce, for hierarchical loop levels and shipment/order/pack/item nesting.

Segment names and structure are the public X12 standard. If a retailer-specific detail here doesn’t match your own guide, tell us and we’ll correct it.