Implementation reference

EDI 856 example: read the hierarchy, then test the exact bytes

Reviewed 2026-09-09 Independent research

On this page

Sample documents are useful because they show how segments relate, but copying an example into production is unsafe. Delimiters, identifiers, hierarchy, partner usage, and physical packing all need to come from the actual transaction and current implementation guide.

Direct answer: Use an 856 example to understand the envelope and hierarchy, not as a universal template. Replace every identity and operational value from authoritative sources, regenerate controls and counts, validate the parent tree, and reconcile the completed file with the shipment before sending it.

Annotated EDI 856 example nested inside ISA and IEA, GS and GE, and ST and SE envelopes, with callouts for matching controls, segment count, and HL parent order. — A useful sample exposes the three envelope levels, matching controls, inclusive SE count and parent-first hierarchy instead of presenting unexplained X12 text.

Download the accepted 856 samplePlain X12 fixture executed by the application test suite. Download the rejected 856 samplePlain X12 fixture executed by the application test suite.

A pallet of cartons is shown beside a branching illustration of pallet, carton, and item relationships. — The packing model supplies the relationships that an ASN must preserve.

Compact structural example

ISA*00*          *00*          *ZZ*SENDER         *ZZ*AMAZON         *260717*1200*U*00401*000000001*0*P*>~
GS*SH*SENDER*AMAZON*20260717*1200*1*X*004010~
ST*856*0001~
BSN*00*SHIP-1001*20260717*1200*0001~
HL*1**S~
TD1*CTN25*1****G*10*LB~
REF*BM*BOL-1001~
DTM*011*20260717~
HL*2*1*O~
PRF*PO-1001~
HL*3*2*P~
MAN*GM*000123456789012343~
HL*4*3*I~
LIN**UP*012345678905~
SN1**6*EA~
CTT*4~
SE*14*0001~
GE*1*1~
IEA*1*000000001~

This is illustrative test data. The MAN value, counts, qualifiers, version, and hierarchy must be validated against the actual partner guide and shipment.

How to read it

The ISA/IEA pair wraps the interchange, GS/GE wraps the functional group, and ST/SE wraps the 856 transaction. BSN identifies the notice. The first HL establishes Shipment; Order points to Shipment; Pack points to Order; Item points to Pack. PRF supplies the PO, MAN identifies the logistics unit, and LIN/SN1 carries item identity and quantity.

The example is intentionally small so its parentage is visible. Real files can contain many branches, and the correct SE01 is based on emitted segments rather than the apparent number of business objects.

Rejected variations worth testing

HL*4*9*I~             # parent appears nowhere earlier
MAN*GM*000123456789012340~  # altered value / check-digit risk
SN1**-6*EA~           # negative shipped quantity
SE*13*9999~           # wrong count and transaction control

The free preflight reports these as separate findings with locations and fixes. It does not silently rewrite the file, because automatic “repair” can hide a source-system defect.

Run this check on your own 856 or API payload

Before adapting any sample

Confirm the X12 version and partner guide.
Generate unique interchange, group, transaction, shipment, and container identifiers through controlled allocators.
Build the actual packing tree before assigning HL IDs.
Populate PO, item, quantity, and transport values from source systems.
Regenerate trailers after serialization.
Compare the outbound MAN/container values with label scans.
Run both accepted and rejected fixtures through automated tests.

Common questions

Can I send this exact example to Amazon’s test environment?

No. It contains illustrative identities and may not match your version, account, shipment type, or required hierarchy. Use it to understand and test your mapping.

Why do public examples disagree?

X12 defines a flexible transaction set and each trading partner publishes usage constraints. Two valid partner implementations can require different levels, qualifiers, or segments.

Start with the shipment model before writing segments

An advance ship notice explains what is on the way and how it is packed. The most useful starting point is therefore a packing record, not a text editor. Record the shipment reference, the orders being fulfilled, the physical containers, the items inside each container, and the quantities in the agreed units. Only then decide which X12 segments express those facts. A file can look tidy while describing a carton that never existed.

Four connected folders represent a purchase order, acknowledgment, shipment notice and invoice. — References link related documents; each document still records a different business event.

Imagine one purchase order for twelve units of an item. The warehouse packs six units in carton A and six in carton B. The operational record contains one order line and two allocations to containers. An outbound ASN may need two item occurrences under two pack levels. Flattening the order line into a single item occurrence loses the receiving relationship, even though the total quantity remains twelve. This is a common reason an EDI 856 mapping appears correct in a spreadsheet but fails a warehouse check.

Keep quantities at their actual scope. A carton count belongs to a packaging statement. A shipped item quantity belongs to an item allocation. Gross shipment weight has a unit and may include packaging. Reusing one convenient number in several fields creates contradictions that segment syntax checks cannot detect. The mapping specification should identify the source record for each value, its meaning, its unit, and how it is reconciled.

Understand HL01, HL02, HL03, and the parent tree

The hierarchy is a set of relationships carried in ordered segments. In the example, HL01 identifies a level within the transaction, HL02 identifies its parent where one exists, and HL03 describes the kind of level. The identifiers are local structural references, not carton numbers, purchase order numbers, or database primary keys. A parent reference must resolve to the intended earlier level under the applicable implementation rules.

Read HL*3*2*P as a pack level identified by 3, attached to level 2. Read HL*4*3*I as an item level identified by 4, attached to that pack. If a second carton is added, it receives another pack level under the order and its own item children. Simply appending the new item beneath the previous carton would produce the wrong packing statement. Line order matters because many parsers maintain the current hierarchical context as they read.

Common hierarchy failures include duplicate level identifiers, missing parents, children attached to the wrong order, and a parent type that is forbidden by the partner's chosen structure. Also check whether a field declaring the overall hierarchy agrees with the levels actually emitted. Do not infer a permitted structure from a public example that uses a different shipment program. Some implementations include tare or pallet levels; others have different grouping requirements.

Draw the tree for a failing file. Put the level identifier, level type, purchase order, container identifier, and item reference beside each node where applicable. The first wrong edge is often easier to see than the corresponding long raw message. Correct the source relationship or mapping rule, regenerate the file, and repeat validation. Editing an HL parent directly without fixing the source usually causes the same defect on the next shipment.

Explain the envelope and control numbers separately

The three envelope levels support different scopes. The interchange carries sender and receiver identities and wraps groups. The functional group wraps transactions of a related purpose. The transaction envelope marks one business document. Their controls help correlate trailers and subsequent acknowledgments. A purchase order reference does not replace these controls, because several documents and transmission attempts can concern the same order.

In the sample, the matching control pairs are ISA13 with IEA02, GS06 with GE02, and ST02 with SE02. Preserve leading zeroes where the format requires them. Keep the original values alongside the emitted artifact so an incoming acknowledgment can be matched to what was actually sent. Recalculating controls later from a shipment name is not reliable evidence of an earlier transmission.

Control allocation should have an explicit scope and concurrency policy. Two workers generating files for the same partnership must not accidentally issue the same active control. A corrected business document and a transport retry also need different handling: the retry may reuse an existing artifact, while a correction may require a new document or control sequence according to partner policy. Store the relationship between the old and new records instead of relying on filenames to explain it.

Calculate SE01 from the serialized transaction

SE01 counts the segments from ST through SE inclusively. It does not count physical text lines, HL levels, cartons, or the ISA and GS envelopes. In the compact example, there are fourteen segments in that range. Adding a reference or date segment inside the transaction increases that count even if the business object count is unchanged. Pretty printing with one segment per line is helpful for reading but must not become the counting algorithm.

A reliable serializer first builds the transaction segments, calculates the inclusive count that will include SE, and then appends the trailer. Group and interchange trailers have their own counts and controls. Avoid maintaining all of these as manually entered fields in a spreadsheet. Whenever the mapping conditionally emits a segment, a manually calculated trailer becomes another opportunity for drift.

Test a file containing more than one transaction as well as the smallest sample. A validator should associate each SE with its own ST and calculate its own count. A total count that happens to match the entire file can hide a broken inner envelope. Also test a missing trailer and an unexpected new ST before closure; the result should identify an incomplete transaction instead of merging unrelated content.

Map PRF, LIN, SN1, and MAN from authoritative records

The order reference should come from the accepted customer purchase order, including its exact representation. Leading zeroes and punctuation can be significant. Where one shipment contains several orders, each relevant order branch needs the correct reference. Do not copy the first order number into every branch just because a carrier manifest has only one reference field. Keep customer line references available for reconciliation even when the selected ASN profile uses a different item layout.

Source documents connect through translucent mapping layers to one organized shipment record. — A mapping should explain where each target value came from and preserve its business meaning.

Item identifiers require both a value and a meaning. A vendor SKU, customer item number, UPC, and GTIN are not interchangeable strings. The qualifier tells the receiver how to interpret the value. If a source export supplies an internal SKU but the receiver expects a different identifier, use an approved item crosswalk. Unknown items should create a mapping exception rather than silently borrowing the identifier of a similar description.

SN1 shipped quantity must represent the allocation under the current hierarchy and use the agreed unit. Six cases and six eaches are different business statements. If conversion is required, record the pack-size source and effective date, and verify that the resulting quantity is representable under the chosen rules. Avoid rounding away fractional quantities merely to make a validator pass; determine whether the original unit or source record is wrong.

MAN identifies a marked logistics unit in the chosen profile. When an SSCC is required, compare the value with the actual label data. Check length and check digit, but also ownership, uniqueness within the intended lifecycle, and association with the correct carton or pallet. A mathematically valid SSCC attached to another container still produces an inaccurate ASN. See the SSCC generator and label guide for the distinction between number validation and a usable logistics label.

Work through a two-carton example without inventing data

Use a small fixture with one order, one item, and two cartons. Give each carton a distinct identifier and allocate six eaches to each. In your expected normalized result, assert that the order total is twelve, the container count is two, and each allocation is six. Then inspect the generated hierarchy to confirm that each item occurrence belongs to the intended pack. These assertions test the meaning of the file rather than only its appearance.

Hands position an illustrative logistics label on a carton beside a scanner and ruler. — Illustration only: generate identifiers deterministically and verify the printed label with the receiving workflow.

Next change the scenario to a short shipment: carton A contains six and carton B contains four. The ASN must describe ten shipped units. Whether the remaining two are backordered, cancelled, or expected later is a separate order-management decision. Do not emit twelve in the ASN to match the original order. Reconciliation should explain the difference and preserve the outstanding quantity under the customer's rules.

Finally, split the remaining units into a later shipment. Give that shipment its own operational identity and packing records. Verify that cumulative shipment reconciliation reaches the expected total without counting a retransmitted first ASN twice. This sequence is a stronger implementation test than a single large example because it exposes mistakes in allocation, identity, and replay behavior while the arithmetic remains easy to inspect.

Diagnose an EDI 856 rejected after successful delivery

Separate the evidence into layers. Transport evidence answers whether the remote endpoint received the bytes. A functional or implementation acknowledgment answers a technical processing question. A retailer's application response can reject business content that was technically readable. Warehouse receiving can then reveal physical mismatches that were absent from every earlier check. “Sent successfully” is therefore an incomplete status for an ASN workflow.

An operator compares a transport document with a separate processing checklist beside a loading dock. — Transport delivery and downstream processing require separate evidence.

Preserve the original file, the exact rejection response, the partner profile version, the mapping version, and the relevant packing evidence. Locate the first actionable error in the applicable scope. A bad delimiter or broken envelope can cause many downstream symptoms, so fix structural failures before interpreting every missing-element message as an independent business defect. Once the file parses reliably, investigate quantities, identifiers, dates, and hierarchy against source records.

Use the 997 and 999 guide to understand acknowledgment correlation. If the rejection cannot be matched to one exact outbound transaction, resolve that ambiguity before making a correction. Resending a guessed file can create duplicate notices while leaving the original issue unresolved. Record the correction reason and preserve the previous attempt so support can explain what changed.

Build reusable test fixtures for your mapping

A useful fixture set covers the ordinary shipment, a mixed-item carton, multiple cartons, a multi-order shipment where supported, a partial shipment, and a correction. Add deliberate failures for duplicate container IDs, an unknown item crosswalk, a missing order reference, incompatible units, invalid dates, and a broken hierarchy. Keep each fixture small enough that a reviewer can state the expected business outcome without executing the mapper.

Warehouse analyst compares a structured EDI document with a highlighted validation finding. — Review validation findings against the source document before approving a correction.

Assertions should cover normalized meaning and serialized structure. Confirm the item allocations and totals, then the envelope controls, counts, permitted segments, and exact partner-specific requirements. Keep expected error codes or locations for rejected fixtures. If every malformed fixture merely asserts “validation failed,” a regression can fail for an unrelated reason while the intended protection disappears unnoticed.

Version the fixtures with the mapping and partner profile. A changed guide may require new expected output, but that change should be reviewed explicitly. Retain historical fixtures for replay of older documents. Generated illustrations on this page explain concepts; the downloadable fixtures and deterministic tests are the appropriate assets for exercising software.