An EDI 940 is an X12 warehouse shipping order: an instruction from the owner of the goods — usually a brand, manufacturer or distributor — to the warehouse or 3PL that holds them. It carries the order number, the ship-to, the lines with quantities and item IDs, the ship date, and routing instructions. The warehouse answers with a 945 shipping advice once the shipment leaves.
Who sends it, who receives it, and what comes back
The 940 sits in the middle of the retail fulfillment chain. The buyer sends an 850 purchase order to the seller. The seller — or the seller's distribution arm — sends a 940 to the warehouse that holds the goods. The warehouse picks, ships, and sends a 945 warehouse shipping advice back, reporting what actually went out. Downstream, the shipment itself is announced to the receiver with an 856 advance ship notice, and the money side closes with an 810 invoice.
Two operational facts shape everything about this document. First, the 940 is an order document with physical consequences: a wrong ship date is a missed truck, a wrong ship-to is a rerouted load. Second, the receiver of a 940 is almost always a 3PL running someone else's inventory, which means the warehouse must validate the 940 against a master it does not own — the shipper's item and location data. That validation gap is where the rejection catalog below comes from.
The segments that matter, and what a wrong value does
The 940 is a short document. Five segments carry most of the meaning, and each has a characteristic way of failing.
W05 — shipping order identification
The header identity of the document. The second element is the shipper's shipping order number; the first is a purpose code that distinguishes an original from a change. The order number must be unique per partner and per shipment: a duplicate W05 number is rejected by any warehouse system that has seen the number before, and a changed order that reuses the number silently collides with the original.
W01 — line item
Quantity, unit of measure, and the product ID with its qualifier. Three independent failure modes live in one segment: the quantity, the UOM, and the item reference. The item reference has to resolve against the warehouse's item master, and the UOM has to match how the warehouse stocks the item. An order for 100 cases of an item the warehouse picks in eaches passes syntax and fails operations.
G62 — date and time
A date plus a two-digit qualifier that says what kind of date it is: 10 is requested ship, 02 is delivery requested. The trap is the qualifier, not the date. Partners differ in which qualifiers they send and which they expect; a warehouse that schedules on requested-ship and receives an unqualified or unsupported G62 either rejects the document or schedules on a wrong date without knowing it. When a partner's guide revision changes a date qualifier, the breakage looks like a scheduling bug three days later.
N9 — reference identification
A key-value pair: a reference qualifier and the reference itself. The classic use is carrying the purchase order number behind the shipping order. The qualifier list is long and partner-specific, and partners add references — promotion IDs, department numbers — by changing the guide, not by changing the standard. An N9 with a qualifier your map has never seen is either ignored data or a failed validation, depending on how strict your translator is configured.
NTE — notes and special instructions
Free text with a note reference code. Operationally the most human segment in the document: dock numbers, appointment constraints, delivery windows. Operationally also the least automated: most warehouses route NTE text to a human to read, which means the instruction only works if someone is watching. If a delivery constraint matters, it belongs in a structured field; an NTE is where it goes when no structured field exists.
W66 — warehouse carrier information
The routing block: who arranges the carrier, how the shipment moves, and special handling the warehouse must respect. Values are defined by the partner's guide rather than by intuition, and the segment is where "ship via our contract carrier" and "ship via yours" get encoded. A misread W66 is a tendered load on the wrong carrier — discoverable, but only after the trailer is sealed.
Why your 940 was rejected
Syntactic validation is the easy gate: segment structure, required elements, data types. Almost every rejection that reaches a human is the other kind — syntactically valid, business-rule invalid. Six causes cover most of what we see in retail programs, drawn from production experience on the 3PL side of the wire.
1. Unknown ship-to. The N1 ship-to code is not in the warehouse's location master. The partner assumes a store or DC is set up; the warehouse has never heard of it. Fix is master data, not mapping: the location gets created, and the re-send works unchanged.
2. Item not in the partner's item master. The W01 product ID does not resolve. New items are the usual cause — the shipping order runs ahead of item setup. This rejection is per line, so a 40-line order with one new SKU becomes a 39-line question about what to do with the remainder.
3. A G62 qualifier the warehouse does not accept. The date arrives with a qualifier outside the warehouse's scheduling logic — or with none. Either the document is rejected, or it is scheduled on a guessed date. The second outcome is worse, because it fails silently.
4. Quantity and UOM mismatch. The order says cases; the item master for this partner only carries eaches, or vice versa. The conversion factor has to exist somewhere, and when it does not, the line cannot be picked as specified.
5. Duplicate shipment order ID. The W05 number already exists in the system — a re-send, a retry after a timeout, or a partner system that renumbered nothing. De-duplication has to be deliberate: reject the duplicate, or update the original, and the choice must be the same every time.
6. Syntactically valid, business-rule invalid — the umbrella. Dates in the past, ship-bys before ship-not-befores, a quantity of zero, routing for a carrier the warehouse does not tender to. The translator passes them; the warehouse logic should not. If your acceptance gate is the translator, these become physical problems instead of rejections.
The pattern underneath all six: the 940 was validated against the standard, but it is executed against a master. Rejection handling is not an error path; it is the normal operating surface of the document.
4010 vs 5010, and what an upgrade breaks
The version lives in ISA12 and GS08 — 00401 and 004010 versus 00501 and 005010. ISA11, from version 00402 onward, carries a repetition separator instead of U. Those are the visible differences. The expensive difference is invisible: most partners used the version migration to revise their own implementation guides at the same time, tightening element formats, reordering or re-requiring segments, and changing qualifier lists.
The practical consequences:
- A map validated against the old partner guide passes its tests and fails in production after the upgrade.
- 5010 guides enforce element formats more strictly than 4010 guides did in practice — dates, lengths, mandatory fields that were tolerated before.
- Testing against your VAN's or translator's idea of the standard proves almost nothing. The only spec that matters is the partner's new guide, tested end to end.
If you are onboarding a new partner today, build to the version in that partner's guide; many large retailers still run 4010.
940 vs 945 vs 943/944
The three W-documents get conflated because they share a vocabulary. They describe three different moments:
| Document | Direction | Meaning |
|---|---|---|
| 940 | Shipper → warehouse | Instruction: ship these goods to this destination |
| 945 | Warehouse → shipper | Confirmation: this is what actually shipped, per line |
| 943 / 944 | Depositor → warehouse / warehouse → depositor | Inbound: stock on its way to the warehouse (943), and what the warehouse actually received (944) |
The 940/945 pair is where reconciliation lives: the 945 should match the 940, and the difference between them is the operational truth. A 940 is also not an 850: the 850 is a buyer ordering from a seller; the 940 is a shipper instructing a warehouse that already holds the goods.
What a broken 940 costs
A rejected or mis-executed 940 costs three things: the delay while it is corrected and re-sent, the downstream documents it holds up (the 945, the 856, eventually the 810), and the relationship capital with a partner whose measurement of you starts with document quality.
At program level the difference between hand-built maps and a maintained layer is measurable. In one retail-focused 3PL engagement, trading-partner onboarding fell from 8–10 weeks to 12 days once the 940 and its four sibling documents were prebuilt and configured per partner (case C05). The 940 is where that chain starts.
If yours is failing
Run your 940 flow through the two-week diagnostic: the partner's guide, your maps, and the gap between them, with a findings document you keep. Fixed price, $7,500. If the verdict is that your current setup is fine, that is a cheap answer to an expensive question.
Written by the CrunchCode engineering team — the people who ran these integrations in production.