EDI 856 advance ship notice: What it is and how it works

EDI 856 is the X12 transaction set used to send a ship notice/manifest, commonly called an advance ship notice or ASN, from a supplier to a buyer before goods arrive. It is a structured electronic data interchange document that tells the buyer what has shipped, how it is packed, which carrier is moving it, and how the shipment connects back to the original purchase order.

X12 defines the 856 as the Ship Notice/Manifest transaction set for communicating shipment contents, order information, product details, packaging, carrier information, and the configuration of goods in transit.

In supply chain operations, the EDI 856 is not just a shipment notification. It is a data event. A timely, accurate ASN allows the buyer to prepare receiving teams, pre-stage inventory workflows, reconcile open orders, and keep fulfillment systems aligned before the truck reaches the dock.

That makes the 856 one of the most operationally sensitive EDI transactions. If the ASN is late, malformed, inaccurate, or disconnected from the systems that need it, the issue does not stay inside the EDI layer. It can cause receiving delays, inventory discrepancies, invoice-matching failures, and exposure to retailer compliance issues.

What EDI 856 is and why it matters in the supply chain

An EDI 856 is typically sent after the supplier confirms what is shipping, often at or shortly after shipment, and before the goods arrive at the buyer’s receiving location. It gives the buyer advance visibility into the shipment so their systems and operations teams can prepare.

A typical EDI 856 communicates:

• What was shipped
• Which purchase order or order numbers the shipment fulfills
• Which items are included
• The quantity shipped
• How goods are packaged into cartons, pallets, or other handling units
• Carrier information
• Tracking numbers
• Ship dates and expected delivery dates
• Ship-from and ship-to locations

The buyer uses this data to plan receiving, update order records, reconcile inventory, and validate the physical shipment upon arrival. In high-volume retail, distribution, manufacturing, and logistics environments, this data is essential because receiving teams often rely on ASN details to process goods efficiently.

The 856 is also a reference point for downstream transactions. Shipment data may later be compared against the original EDI 850 purchase order, the supplier’s EDI 855 purchase order acknowledgment, receiving records, and the EDI 810 invoice. If the ASN does not match the actual shipment or the buyer’s purchase order, the discrepancy can ripple across the entire order-to-cash workflow.

EDI 856 structure and key segments

EDI 856 follows the ANSI X12 structure and uses defined segments to carry shipment, order, packaging, item, carrier, reference, and summary data. The standard provides the transaction framework, but each trading partner may specify exactly which segments, loops, qualifiers, and codes they require.

That partner-specific layer is where many 856 implementations become complex. Two retailers may both require an EDI 856 ASN, but one may require carton-level detail while another may require pallet-level hierarchy, SSCC labels, department references, or specific carrier codes.

Core segments in an EDI 856 document

The following segments are especially important because they connect shipment data to receiving, inventory, and order reconciliation systems.

BSN — Beginning segment for ship notice

BSN establishes the shipment notice itself. It typically includes the shipment identification number, transaction purpose, and shipment date or time. Receiving systems use this information to identify the ASN and connect it to a specific shipment event.

HL — Hierarchical level

HL defines the structure of the ASN. It organizes shipment, order, pack, item, and sometimes tare-level information into a parent-child hierarchy. This is one of the most important parts of an EDI 856 because it tells the buyer how the electronic data relates to the physical shipment.

DTM — Date/time reference

DTM communicates dates and times associated with the shipment, such as ship date, delivery date, or estimated arrival. These dates help buyers plan dock appointments, receive labor, and track inventory availability and downstream fulfillment commitments.

TD1 — Carrier details or packaging information

TD1 can communicate packaging, lading, weight, or handling-unit information. Depending on the trading partner’s implementation guide, it may be used to describe cartons, pallets, packages, or shipment weight details.

TD5 — Carrier routing details

TD5 communicates carrier and routing information, such as transportation method, carrier identification, or routing instructions. Buyers use this information to understand how the shipment is moving and which carrier is responsible.

REF — Reference information

REF provides additional reference numbers, such as tracking numbers, carrier reference numbers, bill of lading numbers, appointment numbers, or other shipment identifiers. These references help connect the ASN to transportation and receiving processes.

N1 — Name or party identification

N1 identifies parties involved in the shipment, such as the ship-from location, ship-to location, buyer, supplier, or other relevant parties. This is important when shipments move across multiple facilities, warehouses, stores, distribution centers, or 3PL locations.

PRF — Purchase order reference

PRF links the shipment back to the buyer’s original purchase order. This reference is critical because the receiving system must know which open order the ASN is fulfilling. Missing or mismatched purchase order references are a common source of rejection and reconciliation issues.

MAN — Marks and numbers

MAN identifies cartons, pallets, or other handling units. In many retail and distribution environments, it is used for carton IDs, pallet IDs, or SSCC-style identifiers that connect the ASN to physical shipping labels.

LIN — Item identification

LIN identifies the products in the shipment using item numbers, SKUs, UPCs, GTINs, vendor item numbers, buyer item numbers, or other product identifiers. This is the bridge between the ASN and the buyer’s item master.

SN1 — Item detail shipment

SN1 communicates item-level shipment quantities and units of measure. Receiving teams and inventory systems use this data to compare what was expected, what was shipped, and what was physically received.

CTT — Transaction totals

CTT summarizes counts and quantities in the transaction. It supports validation by helping systems confirm that the transaction is complete and internally consistent. In many 856 implementations, CTT is used to summarize the number of hierarchical levels or line details, depending on the trading partner’s implementation guide.

These segments are not just technical labels. Each one supports a downstream business action. If PRF is wrong, the shipment may not match the purchase order. If LIN identifiers do not match the buyer’s item master, inventory updates can fail. If SN1 quantities are wrong, receiving and invoice matching may break. If MAN values do not match physical carton or pallet labels, scan-based receiving may fail.

Hierarchical levels: HL loop explained

The HL loop is the structural backbone of the EDI 856. It organizes shipment data into a hierarchy so one ASN can describe complex shipping structures in a single transaction.

A common HL structure is:

Shipment

└── Order

└── Pack

└── Item

The required hierarchy can vary by trading partner and implementation guide. Some partners may use shipment-order-item. Others may require shipment-order-tare-pack-item or other structures.

At the shipment level, the ASN describes the overall shipment: shipment ID, carrier, tracking numbers, ship date, and delivery information.

At the order level, the ASN identifies the purchase order or order numbers included in the shipment.

At the pack level, the ASN describes cartons, pallets, or other packaging units.

At the item level, the ASN identifies the products and quantities inside each package.

This hierarchy allows a supplier to communicate more than just “these items shipped.” It allows the supplier to say, “This shipment contains these orders; each order is packed into these cartons; each carton contains these items in these quantities.”

That structure is essential for buyers who use scan-based receiving, carton-level validation, warehouse automation, or retailer compliance programs. The physical shipment and the electronic ASN need to describe the same reality.

How EDI 856 fits into a broader EDI workflow

EDI 856 does not operate in isolation. It sits in the middle of a broader X12 order workflow.

A common sequence is:

EDI 850: Purchase order from buyer to supplier

↓

EDI 855: Purchase order acknowledgment from supplier to buyer

↓

EDI 856: Advance ship notice from supplier to buyer

↓

EDI 810: Invoice from supplier to buyer

X12 defines the 850 as the purchase order transaction set, the 855 as the purchase order acknowledgment, and the 810 as the invoice transaction set.

The 856 is the shipment notification event that bridges fulfillment, receiving, and invoicing. It tells the buyer what is physically on the way before the invoice arrives. That matters because invoice matching often depends on comparing the invoice against the purchase order, ASN, and receiving records.

Trading partners may also exchange a functional acknowledgment, such as an EDI 997 or EDI 999. After the supplier sends the EDI 856, the buyer may return a functional acknowledgment confirming whether the ASN was received and accepted or rejected at the EDI validation level.

This does not confirm that the physical shipment was received at the dock. It only confirms the status of the EDI document exchange.

A fuller workflow looks like this:

Buyer sends EDI 850 purchase order

↓

Supplier sends EDI 855 purchase order acknowledgment

↓

Supplier fulfills and ships the order

↓

Supplier sends EDI 856 advance ship notice

↓

Buyer sends EDI 997 or 999 functional acknowledgment

↓

Buyer receives goods and reconciles shipment

↓

Supplier sends EDI 810 invoice

When an 856 is missing or delayed, downstream systems lose their early signal. Receiving teams may not know what is coming. Inventory records may not be updated in time. Warehouse teams may need to inspect shipments manually. Finance teams may struggle to match the invoice against the order and receipt.

That is why EDI 856 generation should not depend on manual file handling. The ASN should be triggered from trusted fulfillment and shipment data, validated against trading partner requirements, and transmitted with monitoring in place.

Common errors and compliance requirements in EDI 856

EDI 856 errors are especially costly because they affect both digital records and physical receiving. A malformed ASN can be rejected before it reaches the buyer’s receiving process. A technically valid but inaccurate ASN can be even worse because it may cause receiving teams to expect the wrong cartons, items, quantities, or shipment structure.

Major retailers and trading partners often enforce strict ASN requirements because they rely on EDI 856 data for automated receiving, inventory planning, scan-based validation, and supplier compliance tracking.

Structural validation errors

Structural errors happen when the EDI transaction does not conform to the expected X12 or trading partner format. With the EDI 856, these often involve the HL loop.

Common examples include:

• Incorrect shipment, order, pack, or item hierarchy
• Missing parent-child references in HL segments
• Item data placed at the wrong hierarchical level
• Missing required pack-level information
• Missing or invalid MAN segments
• Missing carrier or tracking references
• Summary totals that do not match the detail records

These errors can prevent the buyer’s EDI system from interpreting the ASN correctly. Even if the shipment is physically correct, the electronic data may be rejected.

Data mismatches and shipment discrepancies

Data mismatches occur when the ASN does not align with the purchase order, physical shipment, or buyer’s master data.

Common examples include:

• Purchase order number does not match the buyer’s open order
• Item identifiers do not match the buyer’s item master
• Quantity shipped differs from the physical carton contents
• Tracking numbers are missing or invalid
• Shipment date does not align with the expected ship window
• Carton or pallet labels do not match ASN pack data
• Carrier information does not match the buyer’s routing requirements

These discrepancies can delay receiving, trigger manual investigation, and create downstream invoice matching problems.

Retailer compliance requirements and chargebacks

Retailers often use ASNs to automate receiving and measure supplier compliance. When the EDI 856 is late, incomplete, or inaccurate, the supplier may face operational penalties, payment delays, or chargebacks depending on the trading partner’s compliance program.

The risk increases with manual or ad hoc EDI processes. Manually created ASNs are more likely to contain stale order data, incorrect carton details, missing tracking numbers, invalid labels, or mismatched shipment dates. Even when teams catch errors, manual review can delay transmission past the retailer’s required ASN window.

The solution is automated validation and monitoring. The ASN should be generated from the same fulfillment and shipment data that controls the physical movement of goods. It should be checked against partner-specific requirements before transmission, and exceptions should be visible without requiring teams to inspect raw EDI files.

How Celigo turns EDI 856 into an automated, end-to-end shipment workflow

Celigo helps turn the EDI 856 from a manual document task into an automated shipment workflow. Celigo B2B Manager supports EDI and B2B integrations with components such as EDI connectors, trading partner connectors, EDI profiles with validation rules, EDI parser and file generator capabilities, acknowledgment generation and reconciliation, and an EDI activity dashboard. It also supports communication protocols, including AS2, FTP, SFTP, and FTPS, and can support VAN connectivity.

In a NetSuite-centered workflow, Celigo can be configured to automatically generate an EDI 856 advance ship notice using NetSuite fulfillment and shipment data. Celigo maps shipment, carrier, carton, item, and tracking data into the trading partner’s required ASN structure, applies partner-specific formatting and validation, and transmits the EDI transaction through the agreed channel, such as AS2 or VAN connectivity.

A typical flow looks like this:

NetSuite fulfillment or shipment data

↓

Celigo maps shipment, carrier, carton, item, and tracking data

↓

Celigo validates partner-specific EDI 856 requirements

↓

Celigo generates the ASN

↓

Celigo transmits the EDI 856 to the trading partner

↓

Teams monitor status, acknowledgments, errors, and rejections

Celigo’s role goes beyond EDI translation or point-to-point connectivity. It provides a governed orchestration layer that connects shipment events to EDI trading partner exchange and the broader order-to-cash workflow. Celigo’s EDI integration capabilities enable automation of documents such as purchase orders, invoices, and advance ship notices across retailers, suppliers, and ERP systems.

That orchestration matters because the 856 is only one step in the lifecycle. The purchase order may begin as an EDI 850. The supplier may respond with an EDI 855.

The shipment may generate an EDI 856. The buyer may return a functional acknowledgment such as an EDI 997 or 999. The billing process may conclude with an EDI 810. Celigo helps govern that sequence across internal systems and external trading partners, with visibility into transmission status, processing errors, acknowledgments, and rejections.

For teams managing high-volume EDI operations, this means less manual file handling, fewer shipment data errors, faster ASN transmission, and clearer visibility into exceptions.

→ Get a demo of B2B Manager to see how Celigo automates EDI 856 ASNs and connects shipment workflows across NetSuite, trading partners, and the full order-to-cash lifecycle.