EDI 856 ASN Errors: The Four Mismatches Behind Most ASN Chargebacks

Somewhere in a distribution center tonight, a receiver will scan a pallet label and the system will find nothing to match it to. The label scans. The pallet is fine. But the file the brand sent ahead of the truck, the EDI 856, and the label on the pallet disagree about what this pallet is: its number, its PO, or whether it exists at all. The receiver will key it in by hand, the exception will get a code, and weeks later a line will appear on the brand's remittance for a shipment everyone remembers going well.

That is an ASN chargeback. The 856 is a promise about what's on the trailer, made before the trailer arrives, and the receiving system holds you to it word for word: which PO, which items, how many cases, on which pallet, under which label. Where the promise and the pallet disagree, you pay. In Cinderhaven Provisions, a fictional $25M specialty food company whose ledger is a synthetic dataset, invalid deductions tied to ASN quantities alone come to about $17,000 a year, every dollar of it traceable to one wrong field.

The disagreements come in four kinds. The case count in the file against the count on the dock. The item: the GTIN in the file against the GTIN on the case. The identifiers: the PO the file names against the PO the retailer is receiving on, and the SSCC on the label against the SSCC in the file. And timing: an 856 that lands after the truck is, as far as the receiving system is concerned, an 856 that never came. The carrier can be on time and the pallets can be perfect and the fine still arrives, because the file said something the pallet didn't.

I find this oddly reassuring. A problem that lives in one field, in one file, is a problem one person can fix before the next shipment. I built Cinderhaven to trace every chargeback dollar back to the event that caused it, and the ASN fines are the ones I would fix first: the path from the fine back to the field is short, and the field is almost always in a system you control.

What each one costs is set by your retailer's routing guide. What follows is the four mismatches, the field that caused each, and the fix. Start with the one your remittance says is costing you the most.

The 856 carries the whole shipment in up to five levels

The EDI 856 is a hierarchical document with up to five levels. The shipment level carries carrier, tracking, ship date, and estimated delivery. The order level carries the PO reference. The tare level is the pallet. The pack level is the carton: its SSCC-18 barcode, contents, and weight. The item level carries each SKU and its quantity.

The retailer picks the structure. ShipJunction's 856 guide lists the common ones: shipment, order, pack, item (SOPI) for carton shipments, and shipment, order, tare, item (SOTI) or shipment, order, tare, pack, item (SOTPI) for palletized ones. Grocery DCs typically require the tare level; MDI's grocery 856 specification makes it mandatory. The receiving DC plans from the 856 before the truck arrives. When the 856 is wrong, the receiving plan is wrong, and the cost of re-sorting falls on the supplier as a compliance fine.

Each mismatch traces to one field

The count

The 856 says 48 cases. The DC counts 47. Sometimes the 3PL shorted a case. More often the case was never in question: the 856 was built from the pick ticket, which said 48, the packer pulled 47, and the shipment record was never updated. The receiving system compares the file with the pallet, not with the intention, and there is no grace period for one case. The fix is in the WMS: build the 856 from the verified pack count, not the pick ticket.

The item

Each case's GTIN in the 856 has to match the GTIN printed on the case, and the weight the file declares has to match what the DC's scale reads at intake. Weight is where item data goes stale: the case weight in the 856 comes from the product master, and a product master that was not updated after the last formula or packaging change declares a weight the pallet no longer has. Past the retailer's tolerance, the line is flagged. The fix is a product master reconciliation against current production weights and the GTINs on current packaging.

The identifiers

Each carton's SSCC-18 has to map to the right PO in the 856. When a 3PL reuses SSCC sequences, or a multi-PO pallet carries cartons labeled from a previous shipment's label run, the barcode scans clean but points at the wrong order. The DC's system sees an unexpected item on the PO and fines it. The fix is a label protocol: SSCC sequences that never repeat, and labels printed from the shipment record they belong to.

The timing

The retailer's rule is usually "ASN received before delivery." If the truck arrives at 6:00 AM and the 856 transmits at 6:14 AM, the shipment is noncompliant, and the fourteen-minute gap draws the same chargeback as a shipment with no ASN at all. At many brands the 856 transmits when someone clicks "complete" in the warehouse management system, and a manual click drifts with the shift. Late transmission draws the same automated deductions as OTIF non-compliance, applied against the calendar, not the shipment. Catching manual steps like that one before they drift is what process hygiene is for. The fix is a schedule: transmit on truck departure, not on a click.

The 856 leaves the building unread

The 856 is generated by the WMS or ERP and flows to the VAN (value-added network) without anyone reading it or checking it against the physical shipment. The first time anyone at the brand sees its contents is when the chargeback arrives on a remittance weeks later.

By then the shipment is received, the inventory stocked, and the chargeback is a line on an accounts-receivable aging report. The operations team disputes it, requests proof of delivery, and waits. ASN disputes are among the hardest to win, because the retailer's system generated the fine from data that did not match, even when the physical shipment was correct. Each of those fines was predictable from the data state at the moment the shipment left the dock, which is where prevention has room to work.

A faster dispute recovers some of one quarter's fines. An ASN quality layer between the WMS and the outbound transmission stops them: a validation step that checks whether the quantity matches the verified pack count, whether the SSCC sequence is current and mapped to the correct PO, whether the ASN transmitted inside the compliance window, and whether the weight reconciles with the product master.

An ASN audit maps each chargeback to its field

An ASN audit reviews the last ninety days of outbound 856 documents against the matching chargeback data. It maps each chargeback to the field that caused it (count, item, identifiers, or timing) and produces a frequency table: which mismatch, how often, which 3PL or warehouse, which retailer. Run alongside the twelve-month chargeback diagnostic, it names the upstream source for each root-cause category.

Deductions coded as "shortages" can trace back to ASN data rather than missing product, and the audit separates the two. Each mismatch has its own fix: a WMS configuration change for counts, a product master reconciliation for items and weights, a label protocol for identifiers, a transmission schedule for timing. All four are data corrections, not logistics changes. The file is sent before the truck leaves and the fine arrives weeks after it lands, and the audit is the first time anyone at the brand reads one against the other.

Start with an ASN audit

I audit the last ninety days of outbound 856 data against the chargeback register, map every mismatch to its source field, and write the validation spec that stops it recurring. The ASN audit is part of the Trade Spend & Deduction Recovery engagement. If shortage or ASN deductions keep showing up on your remittances, send me twelve months of deduction detail and I'll trace them back to the ASN fields causing them. No call, no obligation.