How to Set Up EDI 940/945 With a 3PL Warehouse
Step-by-step guide to mapping, testing, and reconciling EDI 940 and 945 with a 3PL warehouse, including segment detail and error handling.
Why the 940/945 Cycle Breaks More Often Than It Should
Most EDI teams treat the 940/945 pair as a solved problem because it's an old transaction set. It isn't solved, it's just under-documented. Getting EDI 940 945 integration right means understanding two X12 transaction sets that sit at the exact point where your ERP hands off control to a partner's warehouse management system, and where a single wrong quantity field cascades into a chargeback three documents later.
Here's the mechanical version. An EDI 940 is different from an EDI 850 Purchase Order, as it goes from the supplier (not the retailer) to the warehouse, though typically the supplier will receive an EDI 850 and then create an EDI 940. Once the 3PL fulfills that order, the 945 is returned to the seller by the warehouse once the order has shipped, providing the information needed for the seller to reconcile quantity shipped against order quantity, create an invoice, and generate an 856 Advance Ship Notice. That last part is the one people forget under pressure: the 945 isn't the end of the chain, it's the input to the next document. A messy 945 doesn't stay contained to your warehouse ops team. It becomes a messy 856, and the 856 is what your retail trading partner scores you against for on-time, in-full compliance.
What You Need Before You Start
You need four things in hand before you write a single segment: connectivity, a companion guide, sample data, and a sandbox. Skipping any one of these turns your first go-live attempt into a debugging exercise with a live trading partner watching.
- Trading partner ID, and ISA/GS qualifier details from the 3PL, confirmed in writing, not inferred from an old spec sheet
- The 3PL's EDI companion guide showing which segments they actually use, since usage of optional segments like W66 or W09 varies enough between 3PLs that identical-looking 940s can fail validation at two different warehouses
- A certified AS2 or VAN connection already tested end to end (if you haven't set this up yet, our AS2 protocol walkthrough covers certificate exchange and MDN handling before you get here)
- Sample 850 and 855 data to derive your 940 test file from, since the seller sends the 940 only after acknowledging the buyer's purchase order
- A test or sandbox endpoint from the 3PL or their EDI provider, whether that's SPS Commerce, TrueCommerce, or Cleo Integration Cloud
The companion guide is the piece teams underrate. Two 3PLs running the same X12 version can still disagree on whether W09 (equipment and temperature) is required, whether N9 references carry your internal PO number or theirs, and how many W12 line items they'll accept per LX loop. Read it before you map anything.
Step-by-Step: Building and Sending the EDI 940
- Pull the confirmed order into your ERP/OMS and identify the ship-from 3PL location. This determines which trading partner ID and companion guide rules apply, since a multi-warehouse network means multiple 940 targets from the same order.
- Build the envelope and transaction shell. A 940 follows the standard structure: ISA interchange header, GS functional group, ST transaction set header, the detail loops, then SE and IEA trailers. A minimal working example looks like ISA*00* *00* *01*BIGETP *01*035230000 followed by GS*OW*053980000*035230000, ST*940*0001, and closing with SE and IEA segments.
- Populate the N1/N3/N4 loops. Ship-from warehouse, ship-to buyer location, and bill-to party each need their own N1 loop with correct qualifier codes, not a single shared address block.
- Set the W66 carrier segment. This is the segment that actually instructs the 3PL who moves the freight. The W66 segment controls how the carrier should handle the shipment: payment terms (prepaid vs. collect), transport method code, pallet exchange instructions, and FOB point. If you run a single dedicated carrier, hardcode it here. If you rate-shop across carriers, point this segment at your TMS's carrier-selection output instead of a static value, more on that below.
- Add W01 line-item detail. Pull SKU, quantity, and unit of measure straight from the 850/855 rather than re-keying, since the W01 segment contains quantity ordered, unit of measure, UPC code, and vendor part number, for example a line reading 24 units of a given item.
- Transmit via your certified AS2/VAN connection and confirm a 997 comes back. After receiving the EDI 940, the 3PL will send an automated EDI 997, also known as a Functional Acknowledgement. No 997 within your SLA window means either the transmission failed silently or the 3PL's translator rejected the envelope. Don't assume delivery just because AS2 returned a 200.
Step-by-Step: Validating the EDI 945 Response
Once picking finishes, the 3PL's WMS should fire back a 945 without you having to chase it. Validating that response is where most of the reconciliation risk actually lives.
- Confirm the 945 arrives once picking is complete. The EDI 945 Warehouse Shipping Advice is used by a remote third party warehouse to tell a supplier that a shipment has been sent, following a request previously sent on a 940 Warehouse Shipping Order.
- Match W12 quantities shipped against the original 940 line items. The 945 transaction code provides information about quantities shipped against the quantity ordered, and this is the single most important check in the whole cycle. Automate the comparison; don't eyeball it.
- Check the W27 carrier detail segment against what you requested in the 940's W66. The 945 contains carrier details in the W27 segment and tracking details in the MAN segment. If your 940 named a specific SCAC and the 945 comes back with a different carrier, that's a substitution the 3PL made without telling you, and it needs a flag, not a shrug.
- Reconcile any short-ships or substitutions before generating the downstream 856. Don't let your integration auto-generate the ASN the moment a 945 lands. Build a hold state for discrepancies.
- Feed confirmed 945 data into your ERP to close the fulfillment order and trigger invoicing once everything checks out.
How You Know It Worked
Three signals tell you the cycle is healthy, and all three should be checked programmatically, not manually, once you're past initial testing.
First, your 997 functional acknowledgment comes back within your SLA window, usually minutes, not hours. Second, 945 quantities match 940 quantities line-for-line with zero unexplained W12 discrepancies. Third, and this is the one that actually matters to your retail partner, your downstream 856 ASN generates cleanly and gets accepted without triggering a chargeback flag on the buyer's side. If you're still fighting 856 rejections regularly, that's usually a sign the 940/945 reconciliation step upstream is being skipped or automated too aggressively.
Failure Mode: Quantity Mismatches Between the 940 and 945
This is the break every EDI manager sees eventually: the 3PL ships a partial quantity, or substitutes a similar SKU, and the 945 that comes back doesn't match what the 940 requested. Nobody flags it. It flows straight through to the 856, and the retailer's OTIF scorecard takes the hit weeks later when nobody remembers the original shipment.
The fix is procedural, not technical. Hold 856 generation the moment your reconciliation step (step 2 above) flags a variance. Push the discrepancy back to the 3PL through their exception portal, or use a modified 940. The EDI 940 may also be used to confirm a shipment, modify a shipment or cancel a previous shipping order, which makes it the control document you reach for when a warehouse order needs correcting mid-cycle, not just the original instruction. Only release the ASN once the numbers match.
A second, quieter cause of the same symptom: unit-of-measure mismatches. Your ERP says "12 cases," the 3PL's WMS interprets the 940 as "12 each." Catch this during mapping and testing against companion guide UOM codes, not after go-live when a retailer's chargeback letter shows up.
Where Carrier Connectivity and TMS Fit Into This Flow
The W66 segment is the seam between warehouse EDI and transportation execution, and it's worth treating it that way in your architecture, not just your mapping spec. For a single-carrier shipper, hardcoding the SCAC into W66 is fine. For anyone running multiple carriers out of one or more 3PLs, hardcoding defeats the purpose of rate shopping entirely, since the carrier decision gets locked in before the WMS even knows what the shipment weighs or where it's headed.
The better pattern: have your WMS or 940-generation logic call out to a TMS or multi-carrier layer for the actual carrier decision, then populate W66 with the result. This is the kind of decision layer that platforms like Cargoson, MercuryGate, and Descartes are built to sit in for freight modes beyond parcel, while ShipStation, Sendcloud, or Shippo handle the equivalent decision for small-parcel-heavy operations. None of these replace your 940/945 mapping. They sit upstream of the W66 field, feeding it a carrier decision instead of you baking one in statically. Once that carrier is selected and the shipment tenders, you're into 204/990/214 territory, a separate handoff worth mapping on its own.
Next Steps
Document your full companion guide mapping segment by segment before you touch production, including every optional field your 3PL actually uses versus what the base X12 spec allows. Then test with one live, low-volume SKU and a real 3PL order before scaling to your full catalog. Watch the 997 timing, the 945 quantities, and the 856 acceptance rate on that single SKU for at least a week. If those three checkpoints hold, you're ready to expand. If you haven't yet locked down your AS2 certification or you're still chasing 856 chargebacks downstream, both of those are worth closing out before you add more 3PL trading partners to this cycle.