An 856 advance ship notice is the document that tells your trading partner what is on the truck before it arrives. It is also the transaction set most likely to be rejected, and the reason is structural rather than technical. An 856 is the only document in the order lifecycle that has to agree with two separate things at once: the purchase order that started the shipment, and what the warehouse physically put on the pallet.
Most rejections come from a gap between those two. The cases below come from EDI connections we run for a US consumer electronics brand, including Amazon Vendor Central and other retailers. Here is what each looks like in practice, and how it gets diagnosed.
The ASN has to match the PO and the physical shipment
An 850 purchase order states what the partner asked for. The 856 states what you are sending. Between those two documents sits a warehouse, and warehouses make reasonable operational decisions that never reach the order record: a substitution when a SKU is short, a different carton count because of how the product packs, a carrier change because of what was on the dock that afternoon.
None of those are mistakes on the floor. They become mistakes only when the ASN still describes the original plan instead of the shipment that left. When you are diagnosing a rejection, the first question is not what the file said. It is what actually shipped, and whether anything about it changed after the order was confirmed.
Carrier mismatch
On one retailer connection we run, not Amazon, a purchase order specified UPS Ground, the warehouse shipped FedEx Ground, and the ASN carried the wrong carrier. The retailer’s system rejected it on arrival, because the carrier on the notice did not match the shipment it was expecting.
What makes this case instructive is where the fix has to go. Correcting the shipment through the partner portal clears the immediate rejection, but if the automated feed is still generating the wrong value, the next shipment repeats it. The portal handles the exception. The source record is what stops it recurring.
Pack structure and carton labels
An 856 describes a hierarchy: shipment, then order, then pack, then item. That structure has to reflect how the cartons are actually built. If the file describes one pack configuration and the pallet is built another way, the receiving end finds the discrepancy at the dock rather than in the data.
Carton labels are part of the same problem. The label on the box and the pack structure in the ASN are two statements about the same thing, and they are produced by different steps in your process. Amazon’s labeling and pack requirements are documented per program and they do change, so treat the current spec as the authority rather than whatever was true at your last onboarding.
Appointment and routing mismatch on collect shipments
On a collect shipment, the retailer arranges the freight, which adds a routing exchange before the goods move. The 753 routing request and 754 routing instructions belong to Wholesale collect shipments, not to Direct Fulfillment, and they are where appointment problems surface.
On the Amazon Vendor Central connection, the pattern looked like this: the appointment slot on the transaction did not match what was actually scheduled, and Amazon rejected it on that discrepancy. Diagnosing it means comparing the slot on the document against the booking rather than re-reading the file, and once the appointment is corrected the resend is accepted.
This is worth knowing because the rejection message points at the document while the problem lives in the scheduling. For more on where each of these documents sits in the sequence, see EDI transaction sets explained, and for how Amazon uses them across its two Vendor Central programs, see what Amazon EDI is.
The invoice has to match the ASN, line for line
An 810 invoice that disagrees with the ASN is a separate rejection with the same root cause. On one retailer connection we run, not Amazon, the SKU billed on the invoice did not match what physically shipped. It was a recurring pattern where a substitution at the warehouse never made it back into the order record.
The invoice is where the money is, so this rejection costs more attention than an ASN rejection does. It is also preventable: the invoice has to reflect what actually shipped, not what was ordered. If invoice lines follow the order instead of the shipment, substitutions will keep producing mismatches.
When nothing comes back at all
Sometimes there is no rejection, because there is no response. No 997 arrives. That is usually a connection or file-naming problem rather than a data problem, and it is a different investigation entirely: the file may never have reached the partner.
Having the raw outbound file stored is what makes this a five-minute check instead of a day. You can confirm what was sent, when, and in what form, without reconstructing it from the order record and hoping the reconstruction matches.
Why storing raw files changes the work
Every case above is a comparison. What did the PO say, what did the file say, what did the warehouse do, what did the partner receive. If your integration stores only the parsed result, you are missing one side of most of those comparisons, and a dispute about what was sent becomes an argument rather than a lookup.
Storing both the original file and the parsed result means a rejection starts from evidence. This is also why we build EDI integration inside the ERP rather than behind middleware: the order record, the shipment record and the transaction that went out all sit in the same system, so the comparison is a query instead of a support ticket to a third party.
For Amazon specifically, the document set depends on the program you are in. Vendor Central wholesale orders run on EDI, with the collect-shipment routing exchange described above, and we cover that program in detail on Amazon Vendor Central wholesale EDI. What is required, and which fields are validated, is set by the partner’s implementation guide and changes over time, so check the current spec before assuming a rule still holds.
A practical diagnostic order
When an 856 comes back rejected, work in this order. Confirm what physically shipped, from the warehouse record rather than the order. Compare the carrier, the pack structure and the quantities on the file against that. If it is a collect shipment, check the appointment against the booking. Then look at whether the value that was wrong came from the order record or from a manual correction that never went upstream.
That last step is the one that stops the problem repeating. Most recurring EDI rejections are not new failures. They are the same failure, corrected downstream each time, in a system where nobody has yet changed the field that generates it.
If rejections are taking longer to diagnose than they should, the fastest improvement is usually visibility rather than mapping changes. We build this work directly into the ERP so the raw file, the parsed transaction and the order it came from are all in one place. See Amazon EDI integration for how that applies to Amazon’s programs, or get in touch with the transaction sets and partners you are running today.
Common questions
Should I resend a rejected 856 straight away?
Not until you know which value was wrong. A resend built from the same order record reproduces the same rejection. Find the field that did not match, correct it at the source, then resend.
Does a 997 mean my 856 was accepted?
No. A 997 confirms the file arrived and could be read. Acceptance of the content is a separate response, which is why an 856 can be acknowledged by a 997 and still be rejected afterwards.
Why do 856 problems repeat every few weeks?
Usually because the correction was made in the partner portal but not in the system generating the file. The portal fixes one shipment. The feed keeps sending the original value until the source record changes.