Implementation reference
Amazon EDI 856: validate the shipment, not only the syntax
An EDI 856 is the Advance Ship Notice that tells a receiving system what is moving, how it is packed, which purchase orders and items it contains, and which identifiers connect the electronic notice to the physical cartons or pallets.
Direct answer: An Amazon Vendor 856 should pass three different gates before submission: a valid X12 envelope, a coherent Shipment–Order–Tare–Pack–Item hierarchy, and reconciliation between the ASN, accepted PO, warehouse pack output, labels, and transport documents. A file that merely parses can still describe the wrong shipment.
What the Amazon 856 needs to prove
The interchange and transaction controls must agree. ISA13 must match IEA02, GS06 must match GE02, ST02 must match SE02, IEA01 must reflect the number of functional groups, and SE01 must count every segment from ST through SE inclusively. These are deterministic defects; they should never survive into partner testing.
The detail loops then need to describe a real shipment without ambiguity:
- The first HL loop is the shipment root.
- Every later HL02 points to an earlier HL01.
- Purchase-order data appears at the level required by the current account guide.
- Pack and item loops remain connected to the correct PO.
- Container identifiers in MAN or the API payload match the printed logistics labels.
- Quantities, units, dates, BOL, PRO, ARN, carrier, and shipment type agree with the operational source records.
Amazon’s current Submit shipment confirmation tutorial is API-shaped, but it exposes several current business requirements that also matter to an EDI workflow: send the confirmation before receipt, separate materially different shipments, supply shipment-type references, and keep physical SSCC barcodes synchronized with the confirmation.
SOPI, SOTI, and SOTPI hierarchy profiles
The letters name the detail levels: Shipment, Order, Tare, Pack, and Item. Common shapes include SOPI for loose cartons, SOTI for pallet-to-item detail, and SOTPI when both pallet and carton relationships must be represented. They are not interchangeable formatting preferences. The hierarchy must preserve the physical and commercial relationships expected by the trading partner.
HL*1**S~ Shipment
HL*2*1*O~ └─ Purchase order
HL*3*2*T~ └─ Pallet / tare
HL*4*3*P~ └─ Carton / pack
HL*5*4*I~ └─ Item
The sequence S,O,T,P,I is only a quick profile signal. Parent references are the truth. Duplicate HL01 values, missing parents, forward parents, and items connected to the wrong order can all produce a plausible-looking sequence that is still invalid.
The segments operators inspect first
| Segment | Operational purpose | Typical preflight question |
|---|---|---|
| BSN | Notice purpose, shipment ID, creation date/time, hierarchy code | Is this original/replacement identity intentional? |
| HL | Parent-child packing hierarchy | Does every child point to the correct earlier parent? |
| TD1 / TD5 | Packaging, weight, carrier, routing | Do units and carrier references match dispatch records? |
| REF / DTM | Shipment references and dates | Are BOL, PRO, ARN, pickup, and arrival values present where required? |
| PRF | Purchase-order reference | Does each shipped item remain tied to the accepted PO? |
| MAN | Carton/pallet identifier, commonly SSCC | Does the transmitted value exactly match a label scan? |
| LIN / SN1 | Item identity and shipped quantity | Do SKU/UPC and quantity agree with actual pack output? |
The complete EDI 856 segment reference includes valid and invalid examples and links each segment back to the free checker.
A valid syntax result is not Amazon acceptance
Passing envelope and hierarchy checks means the document is internally coherent. It does not prove that Amazon will accept it or that receiving will observe the same cartons, quantities, and identifiers. Current Vendor Central documentation and your account’s implementation guide remain controlling.
Shipment Sentry deliberately labels each finding by evidence class:
- X12 base: deterministic structure, controls, counts, and hierarchy integrity.
- Current Amazon: supported by current public Amazon developer or vendor material.
- GS1: identifier structure and check-digit rules.
- Account-specific: a warning that must be checked against the current partner guide.
That distinction prevents a generic validator from presenting a retailer-specific assumption as universal X12 truth.
Preflight workflow before dispatch
- Parse and validate the exact outbound bytes—not a convenient preview generated earlier.
- Correct envelope and control failures first.
- Correct HL hierarchy and required identifier failures second.
- Reconcile PO lines, quantities, cartons/pallets, and units with warehouse output.
- Scan printed SSCC labels and compare the decoded values to MAN/API identifiers.
- Compare BOL, PRO, ARN, carrier, and dates with transport documents.
- Re-run the preflight and retain the result hash, rule-pack version, and operator decision.
Frequently asked questions
Does a valid 856 guarantee Amazon will accept it?
No. It removes provable structural and public-rule defects. Account-specific requirements, submission timing, duplicate/replacement behavior, and the physical shipment can still cause rejection or receiving discrepancies.
Does Shipment Sentry transmit an ASN to Amazon?
No. It is a preflight sidecar. It checks the payload before your VAN, EDI provider, Vendor Central process, or SP-API integration submits it.
Which X12 version is supported?
The parser is delimiter-driven and the validator targets common 4010-era 856 structure. Partner-specific version and usage rules remain separate, visible evidence classes rather than hidden assumptions.
Primary sources
Public sources cannot establish every account-specific EDI rule. Current Vendor Central documentation and your trading-partner agreement remain controlling.