Does an EDI 940 Confirm a Warehouse Shipment?

Does an EDI 940 Confirm a Warehouse Shipment?

No. An EDI 940 is a request, not a record of what happened. The EDI 940 Warehouse Shipping Order is the ANSI X12 transaction set a depositor, the company that owns the inventory, sends to a third-party warehouse to request that goods be shipped. Nothing in that document tells you the warehouse picked it, packed it, or put it on a truck. The EDI 945 warehouse shipping advice is the document that reports what actually left the building, and it's the only one of the two you should trust when you're deciding whether to fire off an 856 ASN or an 810 invoice.

This distinction trips up more teams than it should, usually because the 940 looks complete. It has a PO number, quantities, a ship-to address, a requested carrier. It feels final. It isn't.

What's the difference between an EDI 940 and an EDI 945?

The 940 goes from the brand to the warehouse before anything ships; the 945 goes from the warehouse back to the brand after it does. The EDI 940 Warehouse Shipping Order is the X12 transaction set a depositor sends to a third-party warehouse to request that goods be shipped, while the EDI 945 Warehouse Shipping Advice is the transaction set a third-party warehouse sends to the depositor to confirm that an order was shipped. The segment structure reflects the direction. A 940 carries a W05 Shipping Order Identification segment with order status code, depositor order number and purchase order number, and a W76 Total Shipping Order segment as a control total. A 945 instead opens with a W06 Warehouse Shipment Identification segment carrying reporting code, depositor order number, ship date, shipment identification and purchase order number, followed by a W07 Master Receipt Information segment summarizing total shipped quantity and weight, LX line sequencing, and W12 Warehouse Item Detail covering shipped quantities, product IDs, and discrepancies.

Does a 997 acknowledgment mean the warehouse will ship the order?

No. A 997 only confirms the file arrived and parsed correctly, nothing about fulfillment. An EDI 997 is an EDI-level functional acknowledgment that confirms whether the EDI transaction was received by the EDI process and passed syntax validation, but it does not confirm that the business transaction was approved, fulfilled, shipped, invoiced, or accepted at the business level.

This is where a lot of ops teams get burned. The 997 comes back fast, often within minutes, and it's tempting to treat "accepted" as "order confirmed shipping." It isn't. A 997*A on an 850 means the order file was readable, not that the brand accepted the order, and a 997*A on an 856 means the ASN parsed, not that the retailer's receiving scan will match it. The same logic applies to a 940: an accepted 997 means the warehouse's translator could read the file. It says nothing about whether the stock is even in that building.

What must the 945 include before you build the 856 ASN from it?

Before you generate the 856, the 945 needs an actual ship date, the real carrier, verified carton or pallet counts, and matched shipped quantities against ordered quantities, not the quantities from the original PO or 940. Building the ASN off anything upstream of the 945 is how you end up declaring freight that's still sitting on a dock.

The required fields trace directly to the 945 segments:

• Actual ship date and shipment identifier, carried in the W06 segment along with the depositor order number and PO reference
• Carrier and party detail, found in the N1 loop identifying the consignee, contact information through PER segments, and the carrier assigned to transport the shipment
• Ship status per line item: W12 element 01 carries the Ship Status Code, where 'CC' marks a complete ship and 'CP' marks a partial ship, alongside quantity ordered versus quantity shipped
• Lot or serial detail where the retailer or automotive partner requires it, typically riding in the W20 line item miscellaneous segment

If the W12 shows a partial ship (CP) and your mapping logic assumes CC by default, you'll invoice for cartons that never left the dock. That's not a hypothetical edge case, it's the single most common cause of ASN/invoice disputes when teams automate the 945-to-856 handoff without checking the status code first.

Can you skip the 940 and send the PO straight to a 3PL?

Technically yes, but you lose the structured fields a WMS needs for picking and you lose the built-in change mechanism. A purchase order wasn't designed for warehouse operations. It doesn't carry pick-by-location data, carrier routing instructions, or a formal revision process. The 940 solves that second problem specifically. An EDI 940 is the X12 Warehouse Shipping Order a depositor sends to tell a warehouse to ship, confirm, change or cancel a shipping order, using purpose codes in the W05 segment to flag whether the transmission is original, a modification, or a cancellation. Route a raw PO to a 3PL instead and you have no clean way to retract or amend it once it's in the warehouse's queue, you're emailing someone and hoping they catch it before the pick ticket prints.

How does the 940/945 pair fit with 943/944 for 3PL inventory moves?

The 940/945 pair governs outbound shipments to a customer; the 943/944 pair governs inventory moving between your own facilities. If the 940 and the 945 are about goods leaving a warehouse for a customer, the 943 and 944 are about goods moving sideways, from one warehouse to another, from a manufacturer to a 3PL, or between facilities that both hold your stock. If you're reconciling a shipment and there's no customer order anywhere in sight, you're probably looking at a 943/944 transfer, not a 940/945 fulfillment, and building an 856 off it would be a mapping error, not just a timing one.

Which systems actually translate 940/945 without manual rekeying?

Most mid-market EDI platforms, including SPS Commerce, TrueCommerce, and Cleo, handle 940/945 translation and WMS integration natively, so the mapping logic described above runs automatically instead of requiring a human to check status codes line by line. Where this document pair tends to break down is after the 945 triggers the 856 and 810, once goods are confirmed shipped and need to be booked with an actual carrier. That's a separate problem, and it's the gap that carrier-connectivity and TMS platforms like Cargoson, MercuryGate, and Transporeon are built to close, since EDI translation and carrier booking are rarely the same system. If your 945-to-856 handoff is solid but tracking numbers still get keyed in by hand, that booking layer is usually where the gap sits.