
EDI 856 ASN Best Practices: Getting Ship Notices Right
Of the five core retail EDI transaction sets, the 856 Advance Ship Notice generates more chargebacks than the 850, 855, 810, and 997 combined. The reason isn’t that the document format is harder to produce — it’s that the ASN is generated at the intersection of electronic data and a physical, human packing process. The 850 arrives as pure data and your system processes it. The 855 goes back as pure data. The 810 is generated from pricing and quantity data already in your system. But the 856 has to describe what’s physically inside cartons that a human being packed on a warehouse floor — and if the packing process and the data generation process aren’t tightly coupled, mismatches happen. The ASN says carton 1 contains 24 units of SKU A, but the packer put 24 units of SKU B in carton 1 because the pick list and the ASN weren’t generated from the same source. That mismatch is what the DC scanner catches, and that’s why ASN accuracy failures dominate the chargeback landscape.
The Hierarchical Structure — and Why It Matters Functionally
A complete EDI 856 is built as a hierarchy, and each level serves a specific function in the DC’s receiving process:
- Shipment level (carrier, pro number, ship date, ship-from address) — tells the DC what truck to expect and when, so the receiving system can match the inbound freight to the ASN before the truck even opens at the dock.
- Order level (PO number, PO date) — links the shipment to the purchase order in the retailer’s system, so the DC knows which PO this freight satisfies and can update the PO status to "received" automatically.
- Pack level (carton count, SSCC-18 for each carton) — the critical layer. Each carton gets a unique SSCC-18 that the dock scanner reads to match the physical carton to its contents in the ASN. This is the level where automated receiving actually happens — scan the carton, match to the pack record, confirm contents, route to the outbound lane.
- Item level (UPC, description, quantity per carton) — tells the system what’s inside each carton without opening it. When the DC scanner matches a carton’s SSCC-18 to the pack level, it reads the item-level detail to confirm contents. Any mismatch here — wrong UPC, wrong quantity — halts the carton on the conveyor and sends it to manual reconciliation.
The hierarchy must be built correctly at every level. A shipment-level error means the DC can’t match the truck to the ASN. A pack-level error means the scanner can’t identify individual cartons. An item-level error means the system thinks the carton contains the wrong product. Each level’s failure produces a different receiving exception, but they all end the same way: manual processing, labor cost, chargeback.
Timing: Why the Window Exists
Most retailers require the ASN within a specific window relative to shipment or arrival:
- Walmart: Within 30 minutes of carrier pickup — because their cross-dock operation routes cartons directly from inbound to outbound trucks, and the ASN data has to be loaded before the freight arrives or the cross-dock window is missed.
- Target: Before the shipment arrives at the DC — because their receiving system pre-stages expected freight based on ASN data, and a shipment without a pre-loaded ASN goes to manual handling.
- Amazon: Within 24 hours of shipment — because Amazon’s fulfillment centers use the ASN to schedule receiving labor and dock door assignments, and a missing ASN disrupts that planning.
The common thread: the ASN has to be in the retailer’s system before the freight is. If you’re manually creating ASNs through a web portal, you will eventually miss a window — not because you’re careless, but because a manual process depends on a person being available, not busy with something else, and remembering to log in and transmit. Automate the 856 generation at the point of packing or carrier pickup, and the timing takes care of itself.
The Pack-to-Ship Match: Why Mismatches Happen
The most common 856 failure has nothing to do with EDI format or transmission. It happens when the ASN describes different contents than what’s physically in the cartons. The root cause is almost always a disconnect between the packing process and the ASN generation process:
- The warehouse team substitutes an item that was out of stock without updating the pick list that feeds the ASN.
- A 3PL splits cartons differently from how the pick list specified, but the ASN was already generated from the original pick structure.
- Someone manually adjusts quantities in the portal after the ASN was generated, creating a data mismatch with the physical shipment.
- The ASN is generated from the sales order (what should ship) rather than the actual packing record (what did ship), so any deviation in packing creates a mismatch.
The fix isn’t to monitor ASNs more carefully after the fact. It’s to generate the ASN from the same data source that records what was actually packed — your WMS or shipping system — at the moment of packing, so the ASN reflects physical reality by definition. When the packing record and the ASN are the same data, a mismatch is structurally impossible.
What to Actually Do
- Connect your WMS or shipping system to your EDI so the 856 generates from actual packing data, not from a separate data entry step.
- Transmit automatically at the point of carrier pickup so timing windows are met without human intervention.
- Validate SSCC-18 uniqueness — duplicate codes are a structural failure that breaks receiving for every carton sharing the duplicate.
- Audit ASN accuracy monthly by comparing 10 recent ASNs to the corresponding bills of lading. If they don’t match, the problem is in your packing process, not your EDI system.
Spring Systems’ integrated service connects your back-office systems to the EDI network so ASNs are created and sent automatically from packing data — eliminating the manual step where most mismatches originate. For suppliers fulfilling through 3PLs, see our 3PL EDI integration guide for keeping data synchronized across fulfillment partners.
Need Help with EDI Compliance?
Our team has been helping suppliers navigate retailer requirements since 2002. Whether you're onboarding with a new retailer, fighting chargebacks, or looking to automate your EDI process — we can help.
Spring Systems EDI Team
EDI & Retail Compliance Experts Since 2002
Have Questions About EDI?
Our team is available by phone and email to help with any compliance challenge.