The EDI 940 is the ship order you send a warehouse or 3PL: what to pick, where it goes, how it ships. AIMS360 sends it as XML, a flat file or an API call, so the warehouse is never an EDI trading partner.
The 940 warehouse shipping order is the document you send a warehouse or 3PL to say pick this, pack it this way, ship it here by this carrier. It is the outbound half of the warehouse cycle; the 945 shipping advice is the answer. AIMS360 sends it to any 3PL as XML, as a flat file, or by API, over an FTP that the warehouse hosts or that AIMS360 hosts, so the warehouse never has to be an EDI trading partner and there are no per document EDI fees on the connection.
The EDI 940 is the transaction set a brand or depositor sends to a warehouse to instruct it to ship goods. It carries the order or pick ticket number, the ship to address, the carrier and service, who pays the freight, the requested ship date, any packing or value added instructions, and every line to ship by UPC or SKU with a quantity. The warehouse picks and packs against it and answers with a 945 warehouse shipping advice.
Three documents get confused here, and keeping them apart is most of the battle. The 850 is what a retailer sends you: a purchase order. The 940 is what you send your warehouse: a shipping order. The 856 is what you send back to the retailer once the goods have shipped. One 850 can become several 940s if it ships from more than one location or in more than one wave, and every 940 eventually needs a 945 to close it.
The 940 belongs to the X12 warehousing series alongside the 943 inbound advice, the 944 receipt, the 945 shipping advice and the 947 adjustment. Those numbers are the industry's shared vocabulary for warehouse messages. They say what the message means. They do not decide what format it travels in, which is the point of the section further down.
A simplified shipping order for one pick ticket with two lines.
ST*940*0001 / W05*N*PT100234*4500123456 / N1*ST*Retailer DC 14*92*DC14 / N3*100 Distribution Way / N4*Reno*NV*89506 / N1*DE*Your Brand*92*BRAND1 / N1*WH*Bergen Logistics NJ / G62*10*20260910 / NTE*WHI*Polybag each unit, hanger on / W66*CC*M***UPSN / LX*1 / W01*12*EA**UP*012345678905 / G69*Cropped tee, black, M / LX*2 / W01*12*EA**UP*012345678912 / G69*Cropped tee, black, L / W76*24*18*LB / SE*17*0001| ST | Opens the transaction set and names it as a 940. |
| W05 | Shipping order identification. The order status code (N for original, R for replace, F for cancel), your order or pick ticket number, and the customer purchase order it fulfills. |
| N1 / N3 / N4 | Party loops. ST is the ship to, DE is the depositor (you), WH is the warehouse, and BT is a bill to when freight is billed elsewhere. N3 and N4 carry the street, city, state and postal code. |
| G62 | Dates. Qualifier 10 is the requested ship date; 02 is a delivery requested date. Retailer routing windows land here. |
| NTE | Free text notes. Packing, value added service and routing instructions the warehouse should read before it touches the goods. |
| W66 | Warehouse carrier information. The payment method (CC collect, PP prepaid, TP third party), the transportation method, and the SCAC or routing. |
| LX / W01 | One LX per line. W01 carries the quantity, unit of measure and the item identifier, usually the UPC with a UP qualifier, or the warehouse SKU. |
| G69 | Item description, so a picker reading a printed order knows what the UPC is. |
| N9 | Line level references: lot, pack code, retailer department, or the ticket number on a value added instruction. |
| W76 | Totals. Units, weight and volume across the whole shipping order, a control check for the warehouse. |
| SE | Closes the transaction set with a segment count. |
In the example the pick ticket ships 24 units to a retailer distribution center by UPS, freight collect on the retailer's account, with a polybag and hanger instruction. That is the whole job of a 940: enough for a warehouse that has never seen your product to ship it correctly. When AIMS360 sends the same message as XML, the same fields are present under different names; the published schema maps every one.
A 940 can represent either a customer order or a pick ticket, and which one you send decides who controls the allocation. Send the order and the warehouse picks whatever it finds in stock, filling it in full if it can. Send the pick ticket and the warehouse picks exactly the units you allocated, which lets you hold stock back for another account even when you could have shipped everything.
In AIMS360 this is a system setting under 3PL Integration, chosen once per warehouse. Most wholesale brands send pick tickets, because the allocation decision belongs with the people who know which retailer gets the last units of a style. Direct to consumer brands with deep stock often send orders and let the warehouse fill them. Either way the choice is made once, and changing it later means shipping and processing the 945 for every pick ticket already exported, so it is worth deciding at implementation.
One behavior follows from it. By default AIMS360 marks a pick ticket as packed the moment it is exported on a 940, which stops anyone creating a second shipment against it inside AIMS360 while the warehouse is working on it. Brands whose warehouse cannot return a 945 can switch that off in System Settings, but for an integrated 3PL it is the setting that keeps two shipments from being built for one order.
No. The 940 is an EDI document by name, and AIMS360 can send it as one, but it can also send exactly the same content as an XML file, a flat file or an API call. The warehouse is never set up as an EDI trading partner. There is no VAN, no interchange envelope, no ISA and GS identifiers to exchange, no 997 acknowledgement to chase and no per document fee. The file lands on an FTP the warehouse already runs, or one AIMS360 hosts for you, and the warehouse imports it the way it imports any other customer's orders.
| How the 940 can travel | What that means for the warehouse |
|---|---|
| XML in the AIMS360 standard schema | The default for the AIMS360 3PL integration. A published XSD, a sample file and a mapping guide are handed to the warehouse. Any WMS that can read XML can consume it, which today is nearly all of them. |
| Flat file, CSV, TXT or XLS | Pick tickets exported in a column layout the warehouse specifies, for warehouses whose import tool wants a spreadsheet rather than XML. |
| Tab delimited on the warehouse platform's template | For 3PLs running on a shared warehouse platform, AIMS360 writes the platform's own import layout, so the warehouse side needs no custom development at all. |
| API call | For warehouses that expose an API, the 940 is a call rather than a file: accepted or rejected on the spot. Bergen Logistics runs this way. |
| Transport | FTP or SFTP hosted by the warehouse, FTP hosted by AIMS360, OneDrive or Dropbox. Nothing in the path charges by the document. |
This matters because of what EDI at the warehouse costs. A conventional setup makes the 3PL a trading partner: it needs its own EDI capability or a provider, a VAN or AS2 connection between you, a translator mapping on each side, a 997 for every file, and per document or per kilocharacter charges on both ends. On a busy DTC account that is thousands of 940s a month, each one billed twice. Taking the warehouse off the EDI network removes every one of those line items, and the message that arrives is the same message.
What EDI still does is the retailer side. AIMS360 receives the retailer's 850 and returns the 855, 856 and 810 on that retailer's routing guide spec, because retailers do require it. The warehouse does not, and treating the two as one requirement is how brands end up ruling out good warehouses, and paying for a trading partner relationship, they never needed. AIMS360 charges no per document or per kilocharacter fees of its own on either side.
The 940 is generated from the pick ticket or order in AIMS360 by selecting the warehouse, tagging what to send and choosing the destination. Customer, ship to, terms, carrier and every allocated unit come from the record, so nothing is re-keyed.
Order notes are combined into one node. Shipping notes cover pickup and routing, packing notes cover how the units are prepared, and VAS notes cover tickets, hangtags and similar services. A COD flag on the order header travels too.
For EDI drop ship programs, AIMS360's automation downloads the retailer's 850s, creates pick tickets and sends the 940s to the warehouse without a person in the loop, then waits for the 945. See DTC and 3PL fulfillment automation.
The 940 opens the loop. The 945 that comes back carries carton level detail and the SSCC on each label, which is what AIMS360 uses to build the retailer 856 so the dock scan matches the notice.
Warehouse setup is a short list: an FTP server record, a warehouse record pointing at the folders for each document, a shipping code cross reference so your ship via codes match the warehouse's service names, and the same product identifiers on both sides, ideally a 12 digit UPC per SKU. The style master is pushed to the warehouse as an 832 before the first 940 goes, so every UPC on the order already exists at the warehouse.
It does not confirm anything. A 940 is an instruction. Until a 945 comes back, AIMS360 knows the order was sent and nothing more, which is why the packed status on export exists.
Cancelling a sent 940 is a warehouse conversation at most partners. The standard allows a cancel status code, and some warehouses accept one, but the reliable process is to contact the warehouse before it picks. AIMS360 publishes which partners accept a cancel through the connection on each partner page.
Switching between orders and pick tickets is not a casual change. Every pick ticket already exported must ship and have its 945 processed before the setting moves, or open work at the warehouse will not reconcile.
Warehouse specific formats may carry a setup charge. The XML schema is standard. Changes or additions a warehouse requires beyond it are scoped work, and a hosted FTP from AIMS360 may carry a charge. Neither is a per document fee.
It instructs a warehouse or 3PL to ship goods. One 940 carries the order or pick ticket number, ship to, carrier and service, who pays the freight, the requested ship date, packing and value added instructions, and every line by UPC or SKU with a quantity. The warehouse picks against it and answers with a 945. It is the outbound half of the warehouse cycle, the way the 850 is the retailer's order to you.
Direction and audience. The 850 comes from a retailer to you and is a purchase order. The 940 goes from you to your warehouse and is a shipping order. An 850 does not tell a warehouse anything; it has to be turned into a pick ticket or order in your system first, and that is what becomes the 940. One 850 can produce several 940s if it ships in waves or from more than one location. Both are covered on the EDI for retailers page.
The 940 is the instruction to ship. The 945 is the warehouse's report that it shipped, with what was packed in which carton, the tracking per carton, weights and the SSCC on each label. Every 940 should be closed by a 945. In AIMS360 the 945 creates the shipment, updates the pick ticket and, for EDI orders, feeds the 856 to the retailer.
No. AIMS360 sends the 940 as an XML file in its published schema, as a flat file in the warehouse's layout, on a shared warehouse platform's own template, or as an API call, over an FTP the warehouse hosts or one AIMS360 hosts. The warehouse is never set up as an EDI trading partner, so there is no VAN, no 997 and no per document fee. Retailer EDI stays in AIMS360 and is unaffected. The Bergen Logistics page is a worked example of a 3PL connection with no X12 anywhere in it.
Pick tickets if you want to control allocation, which most wholesale brands do, because it lets you hold units back for another account even when you could fill the order in full. Orders if you have deep stock and want the warehouse to fill whatever it can. It is one system setting per warehouse in AIMS360, and changing it later requires every exported pick ticket to be shipped and processed first. The Multi Warehouse page covers how allocation works across locations.
Nothing per document. AIMS360 charges no per document or per kilocharacter fees of its own, on the warehouse side or the retailer side. Warehouse setup beyond the standard XML schema and an AIMS360 hosted FTP are scoped items, not usage fees. Compare that with a warehouse set up as an EDI trading partner, where each 940 typically incurs charges at both ends. Details of the connection model are on the 3PL integrations hub.
Yes. In X12 they travel as NTE notes and line level references; in AIMS360's XML they are dedicated nodes. AIMS360 sends order notes, shipping notes for pickup and routing, packing notes such as polybag and hanger, and VAS notes such as price tickets and hangtags, plus a COD flag from the order header. Whether the warehouse acts on them depends on what it offers, which is why each partner page states the apparel services that partner publishes.
Contact the warehouse before it picks. The X12 standard has a cancel status code in the W05 segment and some warehouses honor it, but most connections on our list treat cancellation as a conversation rather than a message, and the partner pages say which. Once a 945 has come back the order has shipped, and the correction becomes a return, handled through the 943 or a manual return authorization depending on the warehouse.
Last reviewed 4 September 2026 by the AIMS360 integrations team. Segment detail reflects the ANSI ASC X12 940 transaction set and is simplified for reading. AIMS360 mechanics are taken from the AIMS360 support documentation for the standard 3PL integration. Warehouse capabilities vary by partner and are stated on each partner page.
Bring a retailer order and the name of your 3PL. We will show the pick ticket leave AIMS360 in the format that warehouse reads, and the 945 come back.
