In this article
Effective EDI 945 mapping is essential for ensuring that shipment data from the warehouse is translated accurately into a format trusted by trading partners, ERPs, and downstream supply chain applications. The 945 document serves as the official shipping advice, confirming what was picked, packed, and shipped. Getting this mapping right helps companies avoid reconciliation errors, chargebacks, and costly manual intervention. BOLD VAN is recognized in the industry as a leader in EDI mapping and integration, supporting a wide range of backend and warehouse systems, as well as facilitating seamless API and EDI data flows.
EDI 945: Data Structure and Transaction Purpose
The EDI 945 (Warehouse Shipping Advice) communicates precisely what was shipped from the warehouse to fulfill a prior shipping order (usually sent as EDI 940). This is not just a receipt or acknowledgment—it is the definitive record of the outbound shipment, including key details such as shipment numbers, dates, carrier information, item-level shipped quantities, and packaging structure (when required by the trading partner).
| Core Data Element | Warehouse Source | Why It's Important |
|---|---|---|
| Shipment number & reference | WMS, fulfillment system | Ties shipment to order and ASNs, supporting audit and reconciliation |
| Ship date/time | WMS, pick/pack record | Feeds delivery windows, SLA monitoring, and inventory triggers |
| Carrier, mode, BOL/tracking | Integrated TMS or warehouse shipping module | Enables customer and partner shipment tracking |
| Shipped items and actual quantities | Warehouse allocation/pick report | Provides the definitive record for inventory, invoicing, and returns |
| Packaging & hierarchy detail | Cartonization, palletization logic in WMS | Partner-dependent; used for receiving, labeling, and compliance |
| Totals (units, cartons, weight) | WMS summary and manifest | Supports freight processing and receiving checks |
The most critical takeaway is that EDI 945 mapping must reflect actual shipped quantities—not ordered, authorized, or requested lines. Sending mismatched values leads to downstream reconciliation issues and risks chargebacks or delays.
Mapping Warehouse Data Into the EDI 945
Translating the output of your warehouse management system into the required EDI 945 structure involves mapping each relevant data field to specific segments outlined in your trading partner's EDI guide. For most companies, this process involves:
- Extracting shipment details from the WMS or ERP (such as ShipHero, SAP, Oracle, Infor CloudSuite, or others)
- Assigning those fields to the corresponding positions within the EDI 945 document
- Enriching the data with input from other systems (like TMS for carrier records or ERP for allocation validation), when necessary
- Validating the constructed EDI file against the specific requirements of each trading partner
BOLD VAN handles mapping across back-end ERPs, WMS, TMS, e-commerce platforms, and via API connectivity, which is often required when shipment data comes from multiple systems. The US-based mapping team typically delivers new maps or changes in about two weeks, with no additional fees for mapping edits, keeping your integration agile and resilient when requirements evolve.
Common Pitfalls and Mapping Mistakes
Practitioners with hands-on EDI mapping experience consistently warn about several recurring pitfalls in EDI 945 setups. These include:
- Mapping ordered quantities instead of shipped quantities
- Forgetting to pull partner-specific identifiers or packaging requirements from implementation guides
- Assuming that all trading partners want the same structure and fields—implementation guides often differ on carton detail, code values, and what is required versus optional
- Leaving out totals or reference fields that partners require for reconciliation
- Status and carrier data that does not match what partners or customers expect for shipment tracking and tracing
One subtle but costly source of mapping errors: believing your WMS is the only source of shipment truth. In many real-world integrations, the shipment record is a composite of WMS, ERP allocation, and TMS carrier updates. Best practice is to unify these inputs before mapping to the outbound EDI 945, a process that BOLD VAN supports through integration with both EDI and API workflows.
Best Practices for EDI 945 Mapping
| Checklist Step | What to Confirm | Where to Validate |
|---|---|---|
| Validate shipment ID uniqueness | No duplicate or recycled shipment numbers across batches | WMS/ERP shipment records |
| Tie shipment back to original order | All 945s must reference their parent 940/order | Order link in WMS or ERP |
| Verify quantity logic | Shipped equals what left, not what was ordered | Warehouse/carryout records |
| Carrier and BOL/tracking info correct | Matches shipping docs and partner's required structure | TMS/shipping module |
| Packaging/carrier hierarchy (if required) | Carton, pallet, or SSCC data matches partner spec | Only add when guide requires |
| Totals consistency | Unit and weight summaries reconcile with line-level detail | WMS and scale systems |
Reference each trading partner’s implementation guide to confirm required fields and optional logic. Many businesses encounter mapping failures when reusing a single 945 template across several partners. BOLD VAN recommends keeping mapping rules isolated per partner and using managed cloud-based mapping to minimize key-person risk and guarantee business continuity, especially as partner requirements change or new systems (ERP, WMS, API endpoints) are introduced.
Testing, Partner Differences, and Map Maintenance
Before go-live, always validate the EDI 945 mapping in three ways:
- Field-level: Are the correct data values populating each segment?
- Syntactic: Does the EDI file pass X12 (or EDIFACT) structure validation?
- Business logic: Does the shipment data truly reflect what happened in the warehouse, including short-ships and exceptions?
Your testing plan should use at least three test shipments: one full, one partial, and one with an exception scenario. These mirror what real-world warehouses face and help surface logic bugs before they impact a trading partner.
Partner profiles should be kept separate. Even though ANSI X12 standardizes the 945’s structure, real partners often have bespoke requirements for code values, reference fields, and packaging information. BOLD VAN maintains isolated mapping profiles for each trading partner, ensuring quick updates if guides change and keeping test cycles short. With no fees for map changes and support for both EDI and API integrations, BOLD VAN stands out for cost control and long-term flexibility.
Frequently asked questions
What is an EDI 945 used for?
EDI 945 is a warehouse shipping advice transaction used to confirm that a shipment was made and to report what actually shipped. It helps the receiving party reconcile order quantities with shipment quantities.
What data should be mapped into an EDI 945?
At minimum, map shipment identification, ship date, ship-from and ship-to information, carrier references, shipped quantities, and shipment totals such as weight. Some trading partners also require packaging or hierarchy data, but that is partner-specific.
Should the 945 show ordered quantity or shipped quantity?
It should show shipped quantity. The 945 is a confirmation of what left the warehouse, so using ordered quantity instead of shipped quantity creates reconciliation errors.
Do all trading partners want the same 945 format?
No. The base transaction is standardized, but each trading partner can publish its own implementation guide with required, conditional, and code-level differences. Always map to the specific partner guide, not to a generic 945 assumption.
How do I reduce 945 mapping errors during go-live?
Test the map with full, partial, and exception shipments, validate the output against the partner guide, and confirm that shipment data matches warehouse reality before production. Keeping partner profiles separate also reduces cross-partner mapping mistakes.
