Implementation guide
Amazon EDI 856, checked against the shipment—not just the syntax
An 856 can be structurally valid and still be operationally wrong. Use this guide to understand the hierarchy, then preflight the document before it reaches Amazon receiving.
Direct answer
Direct answer
The EDI 856 is an advance ship notice. For an Amazon Vendor shipment, it communicates shipment identity, timing, transport references, purchase orders, packaging hierarchy, items, quantities, and container identifiers. A useful preflight checks the X12 envelope and HL tree, then applies Amazon-documented shipment rules and flags anything that still depends on the vendor account’s current implementation guide.
What an Amazon 856 needs to prove
The file needs to do more than parse. It should describe one physical movement consistently enough that the receiving operation can connect the ASN, purchase order, cartons or pallets, labels, quantities, and transportation references.
Amazon’s current Vendor Shipments API guidance is a useful public expression of the business rules even when your transport is X12. It says confirmations must arrive before the product, separates shipments by delivery, vendor, truck, destination and arrival day, and requires shipment-type-specific data.
- A valid ISA/IEA, GS/GE and ST/SE envelope with matching controls and counts.
- A coherent HL hierarchy rooted at Shipment.
- Purchase-order, item and quantity data at the correct hierarchy level.
- Container identifiers whose SSCC values and physical labels agree.
- BOL, PRO, ARN, carrier and date references required for the actual shipment type.
SOPI, SOTI and SOTPI hierarchy profiles
The letters describe the HL levels: Shipment, Order, Tare, Pack and Item. A loose-carton shipment commonly follows SOPI. A pallet of items can follow SOTI. A multi-PO pallet or palletized case flow may require SOTPI. The order of unique level types alone is not enough—the parent IDs must also form a valid tree.
Shipment Sentry checks that every HL01 is unique, every HL02 points to a previously defined parent, the first level is Shipment, and the detected profile is one of the common Amazon shapes. A profile warning is intentionally labelled account-specific because Vendor Central documentation remains controlling.
Envelope defects that should never reach testing
Control-number mismatches and wrong segment counts are deterministic failures. ISA13 must match IEA02, GS06 must match GE02, ST02 must match SE02, IEA01 must equal the number of functional groups, and SE01 must count ST through SE inclusively.
These checks are X12 base checks, not evidence of Amazon acceptance. Passing them means the document is internally well formed; it does not prove that the identifiers and quantities match the truck.
Run a preflight with evidence on every finding
Paste an 856 or load the accepted and rejected samples. Each result reports a code, severity, exact segment location, remediation, evidence class, source, and rule-pack date. Raw content is not retained for anonymous runs.
Questions
Common implementation questions
Does a valid 856 guarantee Amazon will accept the shipment?
No. Syntax and public-rule validation reduce avoidable defects, but account-specific requirements and the physical shipment can still cause rejection or receiving discrepancies.
Does Shipment Sentry send the ASN to Amazon?
No. The launch product is a preflight sidecar. It validates before your EDI provider, VAN, Vendor Central workflow, or SP-API integration submits the document.
Which X12 version is supported?
The parser handles delimiter-driven X12 and the validator targets common 4010-era 856 structure. Trading-partner-specific rules are identified separately from base X12 checks.
Primary sources
Public sources cannot establish every account-specific EDI rule. Current Vendor Central documentation and your trading-partner agreement remain controlling.