Who Sends the ASN When Your 3PL Ships It

The advance ship notice is the one EDI document that has to describe physical reality: which SKUs, in which cartons, on which pallets, with the container codes the receiving dock will scan. Only the warehouse knows that, and the warehouse is often not you. The retailer does not care — the vendor agreement is with the brand, so the chargeback lands on the brand. So the 856 is an accountability question wearing a technical costume. Settle it before your first shipment, not after your first expense offset.

Why this document is different

An 850 is a request and an 810 is a claim. Both can be produced from records. The 856 is an assertion about a truck that has already left, and it has to be accurate at carton level, transmitted before the goods arrive.

That creates a specific chain of custody. The pick and pack happen at the warehouse. The carton identifiers are assigned at the warehouse. The pallet build is decided at the warehouse. And then a document describing all of it has to reach the retailer under your vendor ID, inside their window, in their format.

Every failure in that chain is a chargeback category: late ASN, ASN missing, carton count mismatch, unscannable label, quantities restated after receipt.

The Shopify-specific gap: carton labels

Retail DCs scan GS1-128 labels, which carry the application identifiers that encode GTINs, quantities, batch data, and the serialized shipping container code that ties a physical carton to a line on your ASN.

Shopify does not produce these. Shopify’s Retail Barcode Labels app generates Code-128 labels for product and POS use, and GS1-128 comes from third-party apps, a warehouse management system, or your EDI provider. Separately, selling through retailers means official GS1-issued GTINs behind your UPCs in the first place, which is a registration task rather than a software one.

So on a Shopify plus 3PL stack, the carton labels are always somebody else’s job. Deciding whose, explicitly, is the first thing to nail down.

Three architectures, and where each breaks

1. The 3PL sends the ASN

The warehouse holds the EDI connection for shipment documents and transmits the 856 under your vendor ID.

Why it appeals: the data originates where the shipment happens, so the ASN reflects reality with no hand-off.

Where it breaks: you lose visibility of a document you are liable for. You find out about a rejected or late ASN when the chargeback appears on a remittance weeks later. It also couples you to that 3PL — the EDI mapping, the retailer certifications, and the label templates live in their system, so changing warehouses means recertifying with every trading partner. Ask directly which retailers they are already certified with, because “we do EDI” and “we are live with your retailer” are different claims.

Reasonable when: one warehouse, one or two retail programs, and a 3PL with existing certifications for exactly those retailers.

2. You send the ASN from 3PL shipment data

The warehouse reports what shipped — cartons, contents, container codes — and your system generates and transmits the 856.

Why it appeals: you own the document you are accountable for, and you can see and fix failures. Changing 3PLs means changing one inbound feed rather than recertifying with every retailer.

Where it breaks: entirely on the fidelity and timing of the shipment feed. Order-level totals with no carton detail cannot produce a compliant ASN. A nightly batch cannot serve a retailer who wants the ASN before a same-day shipment arrives — you are late by design. And container codes assigned in their system but never sent to yours guarantee that the labels on the cartons contradict the document.

The questions that decide it: does the feed carry carton-level detail with container codes, does it fire on shipment confirmation or wait for the nightly batch, and who owns the code sequence.

Reasonable when: more than one retail program, or any expectation of changing warehouses. This is the architecture most scaling brands should want.

3. An EDI provider bridges between them

A middleware vendor takes shipment data from the 3PL, maps it, and transmits to retailers.

Why it appeals: the vendor owns the mappings and certifications, which is real work you do not have to do.

Where it breaks: nobody owns the whole. When an ASN is rejected, the 3PL says they sent the data, the provider says they sent what they got, and the brand pays. Diagnosing a mismatch across two vendors and a retailer portal is a bad afternoon, and the second failure mode is that inventory truth now lives in a third place.

Reasonable when: you have programs running today and no capacity to build. Treat it as a waypoint, and keep the shipment feed specified well enough that you could leave.

Comparing them

	3PL sends	You send from their data	Provider bridges
Data fidelity	Highest — at source	Depends on the feed	Depends on the feed
Visibility of failures	Poor	Good	Split across vendors
Cost to change 3PL	Recertify every partner	Remap one feed	Remap one feed
Who diagnoses a rejection	The 3PL, eventually	You	Nobody, initially
Inventory truth	In their WMS	In your system	In a third system

The five questions to settle before the first shipment

1. Who transmits the 856, under whose vendor ID, and within how many hours of shipment confirmation? Put the number in writing.
2. Who generates GS1-128 carton labels, and who owns the container code sequence? Two systems assigning codes independently produces duplicates, and duplicates fail at the dock.
3. What granularity does the shipment feed carry? Carton-level with contents and codes, or order-level totals. This single answer eliminates architecture 2 if the answer is wrong.
4. What happens on a rejection or a 997 that never arrives? Name the person who watches for it, not the system.
5. Who pays a chargeback caused by warehouse error? Most 3PL contracts are silent, which means you pay. Negotiate it while you still have leverage.

Where this usually goes wrong in practice

The pattern is a brand on Shopify with a 3PL and a bolted-on EDI tool, where the ASN is assembled from whatever the warehouse emailed over. It works for the first program and stops working at the second, because now two retailers want different carton rules and different windows, and the shipment feed was never specified to carry the difference.

The fix is to put the shipment record and the EDI document in the same system, so the 856 is built from what the warehouse confirmed. Nobody transcribes anything. On Endless, EndlessEDI is native across all tiers and reads the same fulfillment records as everything else — ASNs generate from the confirmed shipment, chargebacks are attributed back to the partner and the cause, and one 3PL feed replaces a certification project per retailer. For warehouses running this on behalf of brands, OMS for 3PLs covers the same problem from the other side.

Related reading: your first retail PO on Shopify for the full document sequence, the EDI chargeback nightmare for what the penalties actually cost, 3PL transition disaster for what changing warehouses really involves, and the Shopify retail EDI readiness checklist for the vendor conversation.

Sources

The Code-128 limitation of Shopify’s Retail Barcode Labels app and the requirement for GS1-issued GTINs when selling through retailers come from Shopify’s own documentation and retail barcode guidance. GS1-128 application identifiers and serialized shipping container codes follow GS1’s general specifications; transaction set names follow the ANSI ASC X12 standard. Chargeback categories reflect common retailer vendor agreements rather than any single retailer’s schedule — your trading partner packet is the specification, and it wins over anything on this page.