Your 856 Is Lying: Why ASNs Must Come From the Pack, Not the Plan
If your Advance Ship Notice (EDI 856) is built from the planned pack on the purchase order—or from an ERP shipment that never saw a carton scan—it is not describing the load. It is describing an intention. Retailer receiving systems treat the 856 as a receipt document: scan the GS1-128, find the SSCC in the ASN, and trust the contents. When intention and reality diverge, scan-based receiving breaks, and ASN-related chargebacks follow.
That gap is where suppliers, warehouse leads, and 3PLs bleed margin. The fix is not "send the ASN earlier." It is the physical-pack rule: generate the 856 from carton and pallet scan data after pick/pack, with GS1-compliant SSCCs locked to the hierarchy, then validate against that retailer's guide before transmit.
The planned pack is a forecast; the ASN is a receipt document
A purchase order tells you what the retailer ordered. A pick plan or ERP ship-confirm often still reflects what the system expected to ship—ordered qty, standard case pack, assumed cartonization. The ASN is different. It is the electronic packing list the DC uses to plan labor, allocate space, and receive by scan.
Industry writeups on ASN failures converge on the same point: the most common quantity mismatches happen when the 856 is generated from PO quantities instead of actual pick-and-pack confirmation (Productiv, 2026). Short picks, substitutions, split cartons, and last-minute pallet rebuilds are normal warehouse life. A planned-pack ASN freezes the wrong snapshot.
Treat the planned pack as a forecast. Treat the ASN as a receipt document that must match what is on the trailer.
Where planned-pack ASNs fail
Three failure modes show up again and again across retailer compliance programs:
SSCC mismatch. The Serial Shipping Container Code (SSCC-18) on the physical GS1-128 label must match the SSCC in the ASN pack level (typically the MAN segment). When labels and ASNs are generated from different systems or different moments—or when a label is reprinted without updating the 856—the DC scans a carton the ASN cannot find (Productiv; SignalEDI, 2026).
Quantity and hierarchy variance. The ASN reports 500 units because the PO said 500; the floor shipped 498 after a short. Or the ERP ships "one line" while the physical order is one sellable unit across multiple cartons—so pack-level quantities and HL nesting do not match what the retailer expects (Acumatica Community thread on multi-box ASN compliance, 2024).
Late after gate-in. Timing is part of accuracy. Walmart's Supplier Quality Excellence Program (SQEP) treats ASN defects under PO Accuracy, including No ASN Received, ASN Error, and Late ASN when the notice arrives after the PO arrives at the DC (SPS Commerce community; iNymbus Walmart ASN guide). Target's Perfect Order Program expansion (May 2025) made ASN Availability a formal metric: an error-free 856 must be available before the in-yard date/time for the delivering trailer (Distribution Alternatives Target compliance guide, 2026; SupplyPike/SPS Help on Target Perfect Order). An ASN that is "technically correct" but arrives after the yard clock is still a compliance miss.
Planned-pack ASNs invite all three: they freeze early, they invent hierarchy the floor never built, and they leave little room to correct rejects before gate-in.
Generate from pack-out: WMS/3PL as source of truth
The physical-pack rule is simple: the warehouse management system (or the 3PL's WMS) is the source of truth for what was picked, packed, labeled, and staged.
Best-practice flows look like this:
- Pick and pack against the order.
- Assign unique SSCCs as cartons/pallets are built.
- Capture contents per SSCC from scan events—not from estimates or pick tickets alone.
- Ship-confirm when the load is complete.
- Generate the 856 from that confirmation (or from a 3PL Warehouse Shipping Advice / EDI 945 that itself came from scan-confirmed pack data).
3PL and fulfillment guides are blunt about the anti-pattern: generating ASNs before shipping is complete, or building the 945 from pick lists rather than scan-confirmed packing, is a primary driver of ASN chargebacks (G10 Fulfillment EDI–3PL guide, 2026; Shiporo EDI fulfillment guide, 2026). Event-driven ASN generation—after cartons are sealed and the shipment is confirmed—keeps the electronic notice aligned with the trailer.
If your ERP cannot express carton hierarchy cleanly, do not paper over it by guessing packs in the EDI layer. Capture hierarchy where packing happens, then map it into the retailer's required HL structure.
SSCC, GS1-128, and carton hierarchy lockstep
Retail ASNs use Hierarchical Level (HL) segments to nest shipment → order → (tare/pallet) → pack/carton → item. The pack level carries the SSCC that must match the GS1-128 (UCC-128) label on the physical carton or pallet (OrderSync 856 guide; SignalEDI).
Lockstep means one workflow, one data set:
- The SSCC assigned at pack-out is the SSCC encoded on the label and the SSCC in the ASN.
- Item quantities live under the correct pack parent—not rolled up in a way that invents extra units.
- Pallet (tare) levels, when the retailer requires them, reflect actual pallet builds, not spreadsheet estimates.
When multi-carton shipments outrun what the ERP can express, teams often fall back to fulfillment portals and manual rekeying. That pattern is documented in ERP communities—for example, Acumatica users discussing multi-box products and non-compliant 856s, with portal workarounds called out when native packaging data is incomplete (Acumatica Community, 2024). Portal rekeying can clear a single PO; it does not scale, and it recreates the planned-pack problem with a human in the middle.
Cegedim's ASN FAQ states the root cause plainly: standard ERP sales-order screens often have no packaging layers, so box/pallet allocation is unknown until a portal or WMS captures it. The durable answer is WMS (or 3PL) pack capture into the ASN—not heroic data entry at ship time.
3PL handoffs: who owns the 856
When a brand owns the retailer relationship and a 3PL owns the dock, ownership of the 856 must be explicit.
Common models:
- 3PL transmits the 856 on the supplier's trading-partner identity (supplier remains accountable to the retailer).
- 3PL sends a 945 / ship confirmation; the brand's EDI platform builds and transmits the 856.
- Hybrid: 3PL owns labels and pack data; brand owns retailer maps, validation, and monitoring.
What fails is ambiguity. Labels printed in one place, ASN generated in another, and neither side watching 997s or application advice before the truck is in the yard. Walmart guidance is clear that suppliers remain accountable even when a 3PL ships and transmits on their behalf (iNymbus). Target-oriented 3PL playbooks likewise stress that the 856 must match the physical shipment—carton-level content, SSCC data, carrier/BOL detail—before in-yard (ShipCalm; DA Target guide).
Contract the data contract: scan-confirmed pack data, near-real-time ship advice, and a named owner for rejects. Batch 945s once a day are a silent ASN-timing risk (Shiporo).
What good looks like: ship-confirm → validate → transmit → 997
A clean ASN loop is operational, not ceremonial:
- Ship-confirm from WMS/3PL after pack-out and carrier tender/pickup rules your retailer expects.
- Validate before send: quantities vs. confirmation, SSCCs vs. labels, PO references and required segments vs. that partner's guide, hierarchy (SOPI / SOTPI / etc.) vs. spec, and timing relative to departure and appointment.
- Transmit the 856 on the agreed connection (AS2, VAN, SFTP—whatever the partner mandates).
- Watch the 997 (and retailer application advice such as an 824 where used). A rejected or failed acknowledgment is not "done later"—it is a stop-the-line event until corrected and retransmitted before gate-in / in-yard.
Productiv's pre-transmission checklist mirrors this discipline: match WMS confirmation, match SSCCs, confirm departure where required, and hold bad ASNs rather than transmitting hope. Walmart suppliers are routinely advised to review 997/824 traffic and correct before arrival (iNymbus). That closed loop is what "good" looks like—not a green "file sent" icon.
How managed EDI keeps the loop closed
Wiring this correctly is less about owning another translator and more about owning the loop: WMS/ERP connectivity so pack-out events become ASN data, partner-specific mapping so hierarchy and qualifiers match each retailer's guide, pre-send validation so bad documents never leave, and monitoring so rejects surface while there is still time to fix them.
IDXE is EDI Partners' proprietary managed EDI platform (Azure-native). For suppliers and 3PLs fighting ASN chargebacks, the practical value is a managed setup that wires the ASN to real shipment events—not the planned PO pack—and watches rejects before the trailer hits the yard. That means connecting the systems that already know what was packed, mapping 856s to partner specs, validating against those rules, and keeping visibility on acknowledgments and exceptions as part of day-to-day managed operations.
If your 856 still reads like a forecast, it is time to rebuild it from the pack.