Nothing grinds shipping to a halt like a rejected ASN when you're already racing to meet your customer's delivery window. According to Octasyn, most of these rejections trace back to a small set of recurring, fixable issues on the 856 — not mysterious system failures.

What is an 856 ASN and why does it get rejected?

Top 12 reasons ASNs fail (in plain language)

1. 01
   SSCC mismatches. The SSCC is the unique number printed as a barcode on your UCC-128/GS1-128 label. If the SSCC in the ASN doesn't match the physical label, or doesn't exist at all, your shipment is dead on arrival at the DC gate. Double-check SSCC calculation, avoid reusing numbers, and verify your label software lines up with the ASN output.
2. 02
   Item count errors (pack vs. ship quantities). The ASN says there are 12 units in the box, but there are only 10, or vice versa. Usually someone packed more or fewer units, or the picking/packing data is out of sync. Best practice is to automate your pack list creation so what's shipped and reported always matches.
3. 03
   Mixed content where not allowed. If you pack more than one item or SKU in a carton or pallet when the retailer doesn't allow mixed contents, the ASN will be rejected. Always check whether your trading partner requires single-SKU packs or allows mixed loads.
4. 04
   Invalid or missing purchase order numbers. A wrong PO number, or an extra space before or after the digits, can prevent matching at the destination. Make sure PO data feeds into your WMS/ASN process cleanly and is validated before transmission.
5. 05
   Incorrect ship-to/buyer's location codes. Ship-to codes are used for routing, and mismatches can stop your shipment from even being received. Confirm these codes with your partner's vendor manual and ensure they automatically populate in your ASN file.
6. 06
   ASN sent before or after the window. Retailers expect the ASN in a specific timeframe after shipment. If it's sent too early or too late, it's flagged and may not be accepted. Set up alerts or automation so ASNs transmit as soon as the load ships.
7. 07
   Carton or pallet details don't match labels. If your ASN says there are six cartons but seven arrive, or the SSCC barcodes on the cartons don't match the ASN, the receiver will reject it. Make label application a scan-and-verify workflow.
8. 08
   Wrong item numbers (GTIN, UPC, or store numbers). Incorrect product identification numbers mean the ASN can't be cross-checked against the customer's PO. Sync your item data, especially for seasonal or promotional SKUs, before picking.
9. 09
   Bad date or time formatting. ASNs need dates (ship, arrival, etc.) in a specific format. Extra slashes, dashes, or using MM/DD/YY instead of YYYYMMDD gets them rejected by parsing software. Lock down your date/time formatting to be EDI compatible.
10. 10
    ASN structure errors (wrong loops, segments, or hierarchy). This is often a software configuration issue. If loops (like shipment, order, pack, item) or required EDI segments are out of order or missing, the whole file is rejected. Work with IT or your EDI solution partner to validate ASN structure using retailer test scripts.
11. 11
    Duplicate ASN (same shipment reported twice). If the same ASN is transmitted more than once, maybe due to a resend or system timeout, it will be rejected as a duplicate. Always track ASN transmission status and avoid urgent resends without checking for acknowledgment (997) or partner response.
12. 12
    Incomplete or missing data elements. The smallest missing detail, like a SCAC code, routing number, or BOL number, can stop your shipment at the receiver. Audit your ASN mapping against each retailer's requirements and automate population of these fields with controls so nothing is skipped.

What do you do when an ASN is rejected?

1. Pull the rejection notice and identify the specific error code first. Guessing at the cause wastes time; the rejection reason usually points directly at the issue.
2. Cross-check the flagged field against the physical shipment. Confirm whether the error is in the data, the label, or a genuine discrepancy in what was packed.
3. Correct the ASN and retransmit promptly. A fast, accurate correction limits the delay to the shipment and the risk of a missed delivery window.
4. Confirm receipt of the corrected ASN. Don't assume the retransmission succeeded; verify with an acknowledgment before considering the issue closed.
5. Log the error type for pattern tracking. A single rejection is a fire to put out; a repeated one is a process gap worth fixing at the source.

How to prevent these ASN errors on your dock

1. Automate label and ASN generation from the same pack data. Most of the 12 errors above trace back to a disconnect between what was physically packed and what the ASN declares.
2. Build a scan-and-verify step into every pack station. Catching an SSCC or count mismatch before shipment is far cheaper than a rejection after transmission.
3. Validate PO, ship-to, and item data before it ever reaches the ASN. Clean upstream data prevents most of the classic matching failures.
4. Tie ASN transmission to the actual ship event. This keeps timing within the retailer's required window automatically.
5. Test new retailer requirements against their EDI test scripts before going live. Structural errors are far easier to catch in testing than in production.

More practical help for warehouse and EDI shipping teams

ASN errors are rarely just a tech problem. In our experience, most are rooted in workflows that rely on manual steps, misaligned data, or hurried dock releases. That's why, at Octasyn, we've helped both warehouse teams and IT leaders tackle these problems at the source. If your operation is growing or you're taking on more EDI customers, it's worth reviewing your approach to store-level ASN and labeling rules and print quality essentials for warehouse labels.

Summary: building a reliable ASN process

• Most ASN rejections trace back to a data mismatch between the physical shipment and the electronic record
• Automating label and document generation from one source closes the gap where most errors originate
• A scan-and-verify habit at packing catches problems before transmission, not after
• Logging every rejection by type turns isolated incidents into a fixable, trackable pattern

Frequently asked questions