Three systems, one operation
Almost every supply chain operation runs on three systems of record.
The ERP (Enterprise Resource Planning) is the financial and operational backbone. It holds customer records, purchase orders, invoices, inventory valuations, and the canonical product master. SAP, Oracle, NetSuite, and Microsoft Dynamics are the usual examples.
The WMS (Warehouse Management System) runs the four walls of the warehouse. It tracks bin locations, picking and packing tasks, receiving, putaway, cycle counts, and warehouse labor. Manhattan, Blue Yonder, and HighJump sit in this layer.
The TMS (Transportation Management System) plans and executes shipments. It manages carrier selection, rate shopping, load building, route optimization, tracking, and freight audit. Oracle OTM, MercuryGate, and Descartes are common.
The three systems overlap in every meaningful way. A sales order exists in the ERP, turns into a pick task in the WMS, and becomes a shipment in the TMS. Inventory levels are tracked in the WMS and reconciled in the ERP. Carrier costs are captured in the TMS and posted back to the ERP as accruals.
In theory, the three systems are integrated. In practice, the integration is a web of point-to-point interfaces that each solve part of the problem without solving the whole one.
Why integrating these systems is hard
The three systems have been built, bought, and replaced independently. A company on its third WMS in fifteen years has three generations of integration logic still running somewhere. The underlying data model differences are structural.
Different entity definitions. The ERP thinks of a product as a SKU with a cost, a tax classification, and a set of accounting attributes. The WMS thinks of a product as a physical item with dimensions, weight, hazmat codes, and storage rules. The TMS thinks of it as a shippable unit with carrier-specific packaging constraints. All three are describing the same thing with different attribute sets.
Different event timing. An ERP sales order is a forward commitment. The WMS pick happens later and may split into multiple shipments. The TMS shipment may consolidate multiple orders. The temporal relationship between these events is not one-to-one, and reconciliation requires matching across time windows.
Different granularity. The ERP holds order-level inventory commitments. The WMS holds license-plate and lot-level detail. The TMS holds shipment and stop-level detail. Integration requires aggregating up or disaggregating down, and both directions lose information.
Different masters. The product master, the customer master, and the location master exist in all three systems. They drift. The ERP adds a new SKU and the WMS does not know about it for six hours. The WMS changes a bin location and the ERP still references the old one. Keeping masters aligned is a full-time job at scale.
Three integration architectures
Companies solve the ERP-WMS-TMS integration problem with one of three architectures.
Point-to-point
Each pair of systems has its own interface. ERP to WMS is one set of scripts or EDI maps. WMS to TMS is another. ERP to TMS is a third. Six interfaces for three systems, and the count multiplies when adding carriers, 3PLs, and partners.
Point-to-point works for small operations and fails at scale. The problem is not the first interface. It is the fifth and the tenth, each built at a different time by a different person against a slightly different version of the source system.
Middleware hub
A middleware layer (typically an iPaaS or an enterprise service bus) sits between the three systems. Each system integrates with the middleware once. The middleware handles routing, transformation, and orchestration.
Middleware solves the scale problem but introduces its own. The middleware becomes the single point of failure. Transformation logic lives in the middleware, which means the middleware becomes the implicit system of record for how data flows. Replacing the middleware is a multi-year project.
Data layer with a canonical model
A consolidated data layer sits alongside the three systems. Each system publishes to the layer on change. The layer holds a canonical model of products, orders, shipments, and inventory. Consumers (analytics, reporting, other operational systems) read from the layer rather than from individual systems.
This approach scales better than the other two, but it requires real investment: data modeling, ingestion pipelines, reconciliation logic, and ongoing master data management.
Common integration flows
The flows between these three systems are mostly predictable. Getting them right is mostly a matter of schema handling and timing.
| Flow | Typical direction | What gets exchanged |
|---|---|---|
| Sales order to pick task | ERP → WMS | Order header, line items, ship-to address, requested ship date |
| Pick confirmation | WMS → ERP | Picked quantities, lot and serial data, actual ship date |
| Shipment creation | WMS → TMS | Packed units, weight, dimensions, destination |
| Shipment status | TMS → WMS → ERP | Tracking events, delivered confirmation, exception events |
| Freight cost | TMS → ERP | Carrier charges, accessorials, invoice-ready accruals |
| Inventory adjustment | WMS → ERP | Cycle count discrepancies, damage, shrinkage |
| Product master update | ERP → WMS → TMS | New SKUs, discontinued items, attribute changes |
| Receiving confirmation | WMS → ERP | Received quantities against purchase orders |
Specific challenges worth naming
Three classes of problem cause the most recurring work.
Master data drift. The product master in the ERP diverges from the one in the WMS. The customer master in the ERP diverges from the one in the TMS. The only reliable fix is a single system of record per master with automated propagation, and most operations do not have that.
Event timing and sequencing. A shipment gets confirmed in the TMS before the WMS has finished its post-pick reconciliation. A customer cancels an order after the WMS has already picked but before the TMS has shipped. Every edge case needs explicit handling, and edge cases are where integrations leak.
Schema changes after upgrades. An ERP upgrade introduces new fields, deprecates others, and changes type precision on some. Every downstream integration needs testing and often updating. The update cycle for one of these three systems touches everything connected to it.
Where AI-driven mapping helps
The parts of ERP-WMS-TMS integration that AI data mapping handles well are the schema-level work: mapping new fields when a system is upgraded, identifying equivalents across different vendors (an Oracle ERP speaks differently than a SAP ERP but the underlying concepts are similar), and maintaining master data alignment across schema drift.
The parts AI does not solve are the business logic decisions. When two systems disagree about the canonical state of an order, something has to arbitrate. That is a policy decision, and it belongs to operations, not to the integration layer.
A mapping platform that handles the schema work frees up the team to focus on the business logic questions. That is where the real supply chain intelligence lives.
Where datathere fits
ERP-WMS-TMS integration combines standard problems (mapping fields across vendor-specific schemas, reconciling master data, handling schema drift) with edge-case business logic. datathere handles the standard part: reading source schemas from the data, drafting mappings and quality rules, detecting schema drift, and running production pipelines on deterministic code.
For teams currently maintaining a web of EDI maps, custom scripts, and partial middleware, the platform can replace the schema-handling layer without touching the operational logic that sits above it.
FAQ
Do I need a separate integration platform if my ERP has built-in connectors?
ERP-embedded connectors handle the common case (a supported WMS or TMS from a known vendor). They struggle with the long tail: legacy systems, niche vendors, custom-built components, and anything that changed after the connector was written. Most real supply chains have enough long-tail integration needs that a separate platform pays off.
Can we get rid of EDI?
In global supply chains with regulated partners, EDI is still mandated in many transactions. What changes is where EDI processing sits. A modern integration platform can translate between EDI formats and internal data models, so the ERP, WMS, and TMS see clean data rather than raw EDI segments. The EDI itself stays where compliance requires.
What about 3PLs?
Third-party logistics providers add complexity because their systems are outside the company’s control. Each 3PL has its own data formats, often different per warehouse. This is exactly the partner-data-integration problem: unknown schemas, schema drift, and no option to demand a standard format from the provider.
How long does ERP-WMS-TMS integration typically take?
For a green-field deployment, 6-12 months is typical for the initial integration. Ongoing maintenance usually requires the equivalent of 1-2 full-time engineers. Upgrade cycles for any one of the three systems extend timelines further.
Is a canonical data model worth the investment?
For operations with more than a handful of source systems, the answer is usually yes. The upfront investment pays off in reduced integration maintenance and faster onboarding of new systems. For smaller operations, point-to-point interfaces are often cheaper to maintain.