The 3PL EDI Integration Playbook: Orders, Shipments and Inventory Without Surprises

• A documented map between your order, product and inventory data and the 3PL's EDI documents.
• Working transport (AS2, SFTP or a VAN) with acknowledgments.
• Outbound shipping orders and inbound transfer notices sent automatically.
• Shipment confirmations, receipts, inventory and adjustments posted back to your system.
• Alerts for missing acknowledgments, rejected documents and overdue confirmations.
• A daily reconciliation report that catches what alerts miss.

Octacer note: Before writing any mapping, put your order system's export next to the 3PL's sample files and walk one real order from creation to shipment on paper. The gaps you find in that hour (missing fields, different SKU codes, kits, units) are the ones that otherwise show up as stuck orders after go-live.

X12 is the EDI standard used across most North American supply chains, maintained by the X12 organization (X12, Transaction sets). For a 3PL, these are the usual documents (descriptions from the X12 reference published by Stedi):

Some setups also use the 856 Ship Notice/Manifest (856) when your own customers (for example, retailers) require advance ship notices from you. In that case the 3PL's 945 data often feeds the 856 you send to the retailer.

• The 3PL's EDI implementation guides (often called companion guides) for each document, plus sample files.
• Your EDI capability: an EDI platform, an integration service, or a partner who handles translation and transport.
• Clean product master data: SKUs, units of measure, case packs, weights, and barcodes.
• An order system or ERP that can export orders and accept updates through an API or files.
• A named contact at the 3PL for EDI testing, and a test environment or test mailbox on their side.

Hold one working session with the 3PL and document:

1. Identifiers: which order number travels on the 940 and comes back on the 945; whether the 3PL uses your SKU or its own item code.
2. Units of measure: each, case or pallet, and how case packs are expressed.
3. Kits and bundles: who explodes them into components, and how they come back on the 945.
4. Partial shipments and backorders: does the 3PL ship partials, how they report them, and whether a second 945 follows.
5. Cancellations and changes: how to cancel or change an order after the 940 is sent, and the cut-off time.
6. Carriers and service levels: codes for each shipping method, and who buys labels.
7. Inventory timing: how often the 846 is sent and whether it shows on-hand, available, or both.
8. Acknowledgments: expected 997 turnaround, and what happens when a document is rejected.

For each document, build a field map with three columns: your field, the EDI segment and element, and the transformation (format, code list, default).

Pay special attention to:

• Addresses: length limits, country codes, and how to send a second address line.
• Dates and times: formats and time zones.
• Code lists: carrier codes, units of measure, and reason codes for adjustments.
• Line numbers: keep your line identifiers on the 940 so you can match 945 lines back exactly.
• Required versus optional: follow the 3PL's guide, not just the X12 standard. A field optional in X12 may be mandatory for them.

EDI files travel inside interchange envelopes with sender and receiver IDs and control numbers. Agree on:

• Transport: AS2, the HTTP-based standard for secure business document exchange with signed receipts (RFC 4130), SFTP, or a value-added network (VAN).
• IDs and qualifiers for both sides, in test and production.
• Control numbers: unique and incrementing. Duplicate control numbers are a common reason files are rejected.
• Certificates or keys, and who renews them before they expire.

• Trigger the 940 when an order is ready to fulfill, not when it is created, so payment checks and edits happen first.
• Validate before sending: valid address, known SKUs, quantities in the agreed unit.
• Store what you sent: the order ID, document control numbers, and the raw file, so you can prove what the 3PL received.
• Mark the order as "sent to warehouse" only after the file is delivered, and as "accepted" only after the 997 arrives.
• Send the 943 when a purchase order or transfer ships to the warehouse, with expected quantities per SKU.

• 945: match to the order and lines, record shipped quantities, carrier and tracking, and update the order. Handle partials and short shipments explicitly.
• 944: compare received quantities to the 943. Flag overages, shortages and unknown SKUs for review.
• 846: compare the 3PL's inventory to your system. Do not overwrite blindly. Decide which system is the source of truth for available stock and how to handle differences.
• 947: post adjustments with their reason codes so finance and operations can see why stock changed.
• Make every inbound process idempotent. If the same 945 arrives twice, it must not ship the order twice in your system or send two shipping emails. We wrote about the same trap in printing: the label that printed twice.

A 997 tells you a file was received and passed syntax checks. It does not mean the order was accepted operationally.

• Alert if a 997 does not arrive within the agreed window.
• Alert on 997s that report rejected transaction sets, and route the details to someone who can fix the data.
• Separately track business-level acceptance: an order with a 997 but no 945 after the expected shipping window is a problem.
• Send 997s back for every inbound document you receive, as agreed.

Run a structured test plan in the test environment, then a controlled pilot in production:

1. A simple single-line order.
2. A multi-line order with a partial shipment.
3. A kit or bundle.
4. An international address, if relevant.
5. A cancellation before cut-off and one after.
6. An inbound transfer with a shortage.
7. An inventory snapshot with a known difference.
8. A deliberately bad file to confirm rejections are reported and alerted.

Sign off each scenario with the 3PL in writing.

Alerts catch failures you predicted. Reconciliation catches the rest. Every day, compare:

• Orders sent versus 997s received (anything unacknowledged).
• Orders acknowledged versus 945s received after the expected ship window.
• Inbound transfers versus 944s.
• Your available inventory versus the latest 846, with differences above a threshold flagged.

Our silent integration failure triage playbook and no silent drops workflow playbook cover alerting and reconciliation patterns that apply directly here.

• [ ] Implementation guides and sample files for every document
• [ ] Operating rules agreed: identifiers, units, kits, partials, cancellations, carriers, inventory timing
• [ ] Field maps for 940, 943, 945, 944, 846, 947 and 997
• [ ] Transport, IDs, control numbers and certificate renewals set up
• [ ] Outbound validation and storage of sent files
• [ ] Idempotent inbound processing
• [ ] Alerts for missing or rejecting 997s and overdue 945s
• [ ] Test scenarios signed off with the 3PL
• [ ] Daily reconciliation report with an owner

• Treating a 997 as success. It only confirms syntax.
• Mapping from the X12 standard instead of the 3PL's guide.
• Different SKU or unit conventions on each side with no translation table.
• Overwriting inventory from every 846 without checking for open orders and in-transit stock.
• Non-idempotent 945 handling, causing duplicate shipment emails or double inventory deductions.
• No owner for rejected documents, so errors sit in a log nobody reads.

What EDI documents does a 3PL usually need?

Most use the 940 shipping order, 945 shipping advice, 943 and 944 for inbound stock, 846 for inventory, 947 for adjustments, and 997 acknowledgments. The exact set depends on the 3PL's guide.

What is the difference between a 940 and an 856?

A 940 is an instruction to a warehouse to ship an order. An 856 is a ship notice sent to a customer or trading partner describing a shipment's contents, often required by retailers.

Do I need a VAN for 3PL EDI?

Not necessarily. Many 3PLs accept AS2 or SFTP directly. A VAN can help if you trade with many partners who use different connections.

How long does a 3PL EDI integration take?

It depends on your data quality, the 3PL's responsiveness and the number of documents. Testing with the 3PL usually takes longer than building the maps, so plan for it.

Can I use an API instead of EDI with my 3PL?

Many modern 3PLs offer APIs. The same rules apply: agree on identifiers and units, acknowledge and reconcile. Choose whichever the 3PL supports best and your systems can monitor.

Who should own the integration after go-live?

Name an operations owner who reviews the daily reconciliation and rejected documents, and a technical owner who fixes mappings and transport issues.

We build and fix integrations between order systems, ERPs and logistics partners, including EDI, APIs and the monitoring around them. See our work in logistics and supply chain, CRM and ERP integration, and our integration architecture.

Ask your 3PL for their implementation guides and sample files, and walk one real order through them on paper. If you want help with mapping, testing or monitoring, book a call.

• X12, Transaction sets: https://x12.org/products/transaction-sets
• Stedi X12 reference, 940 Warehouse Shipping Order: https://www.stedi.com/edi/x12/transaction-set/940
• Stedi X12 reference, 945 Warehouse Shipping Advice: https://www.stedi.com/edi/x12/transaction-set/945
• Stedi X12 reference, 943 Warehouse Stock Transfer Shipment Advice: https://www.stedi.com/edi/x12/transaction-set/943
• Stedi X12 reference, 944 Warehouse Stock Transfer Receipt Advice: https://www.stedi.com/edi/x12/transaction-set/944
• Stedi X12 reference, 846 Inventory Inquiry/Advice: https://www.stedi.com/edi/x12/transaction-set/846
• Stedi X12 reference, 947 Warehouse Inventory Adjustment Advice: https://www.stedi.com/edi/x12/transaction-set/947
• Stedi X12 reference, 997 Functional Acknowledgment: https://www.stedi.com/edi/x12/transaction-set/997
• Stedi X12 reference, 856 Ship Notice/Manifest: https://www.stedi.com/edi/x12/transaction-set/856
• IETF RFC 4130, AS2: https://datatracker.ietf.org/doc/html/rfc4130