Supply chain and logistics deep dives
Specific integration patterns, failure modes, and data problems that come up across logistics operations.
Consolidating Logistics Data Across Systems
Logistics data lives in carriers, 3PLs, WMSs, TMSs, and ERPs, with different formats, different event codes, and different definitions of the same events. Here is how to unify it.
ERP, WMS, and TMS Integration: A Practical Guide
ERP, WMS, and TMS overlap in every supply chain but model the same entities differently. Here is how to unify data across the three systems without a rewrite.
Network Design Data: Unifying ERP, WMS, and TMS for Cost Modeling
Modeling cost and service trade-offs requires order data from ERP, inventory from WMS, and transit data from TMS, three systems that never speak the same language.
Warehouse Exception Streams: Sensor Feeds and Error Logs in One View
Conveyor sensors, barcode scanners, and sorting systems each generate their own error formats. Finding the root cause of a fulfillment issue means correlating data across all of them.
How to Consolidate Shipping Data Across Carriers, TMS, and WMS
FedEx uses DL. UPS uses D. Regional carriers use numeric codes. Here is how to unify tracking events from every carrier into one consistent view.
The four-system reality
Almost every logistics operation runs on some combination of four system types, even when the vendors differ.
The ERP holds orders, financials, inventory valuations, and the canonical customer and product masters. It is the system of record for the commercial side of the business.
The WMS runs the warehouse. It tracks bin locations, picking and packing, receiving, putaway, cycle counts, and labor. It knows exactly where every physical unit is at any moment inside the four walls.
The TMS plans and executes shipments. It handles carrier selection, load building, routing, tracking, and freight audit. It is the bridge between the warehouse and the outside world.
The carrier and 3PL layer sits outside the company. Each carrier has its own API, its own tracking event model, its own status codes. Each 3PL has its own WMS and sends data in whatever format its operator chose. None of these sources are under the shipper's control.
ERP
Orders and financials
WMS
Warehouse execution
TMS
Shipment planning
Carrier / 3PL
External partners
Where the data diverges
The four systems describe overlapping realities with non-overlapping schemas. The same sales order is an order header with line items in the ERP, a pick task with license plates and lot numbers in the WMS, a shipment with packed units and carrier assignments in the TMS, and a tracking feed with status codes and timestamps in the carrier system.
Three classes of divergence cause most of the integration pain.
Entity definition. A product in the ERP is a SKU with a cost and a tax classification. A product in the WMS is a physical item with dimensions, weight, and storage rules. A product in the TMS is a shippable unit with packaging constraints. A product in the carrier feed is a barcode reference tied to a tracking number. All of them describe the same thing with different attribute sets.
Event timing and granularity. An ERP sales order is a forward commitment at a single point in time. The WMS pick may split into multiple shipments. The TMS shipment may consolidate multiple orders. The carrier reports events at scan-level granularity. Reconciling across these temporal models requires matching on composite keys rather than a single order ID.
Partner format chaos. For the carrier and 3PL layer, each provider sends data in whatever format their system produces. Status codes differ. Timestamp formats differ. Event definitions differ. The same milestone (delivered, in transit, exception) has different codes, different field structures, and different semantics depending on the source.
Integration architectures
Logistics operations tend to settle on one of three architectures, and the choice scales very differently.
| Architecture | How it works | Where it breaks |
|---|---|---|
| Point-to-point | Each pair of systems has a custom interface built in-house or with EDI maps. | Scales combinatorially. Five systems means ten interfaces, each built at a different time by different engineers. |
| Middleware hub | An iPaaS or ESB sits between systems, handling routing, transformation, and orchestration. | Works for known systems with pre-built connectors. Stops short at the 3PL and custom-format partner layer. |
| Canonical data layer | A consolidated data model receives from all systems. Consumers read from the layer rather than from individual systems. | Works best at scale, but requires real investment in data modeling and mapping infrastructure upfront. |
In practice, the highest-performing logistics operations run a hybrid. Middleware handles known SaaS and packaged-system integrations. A canonical data layer holds the unified view. Intelligent data mapping handles the partner layer where no pre-built connectors exist and formats shift per carrier.
Common failure patterns
Inaccurate ETAs. ETA calculations depend on consistent event definitions across carriers. If "in transit" means the truck leaving the origin for one carrier and reaching a regional hub for another, the model is working with inconsistent inputs. ETA accuracy is capped by data consistency.
Exception blind spots. A failed delivery, a customs hold, or a damaged package is the event that most needs a fast operational response. Exception events are also the events with the least standardized formats across carriers. Teams discover exceptions in customer complaints rather than in the tracking system.
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. Without automated propagation, the drift accumulates until a cycle count or a freight audit turns up the gaps.
Schema changes after upgrades. An ERP upgrade introduces new fields and deprecates others. Every downstream integration needs updating. Teams that have not invested in schema-drift handling spend the post-upgrade month patching scripts.
The carrier and 3PL problem is the hardest
Among the four integration layers, carriers and 3PLs are the hardest because the data is not under the shipper's control.
Carrier status codes, timestamp formats, and event definitions vary across providers. Some carriers use standardized codes; others use proprietary codes documented in a PDF that was last updated years ago. Timestamps may be UTC, local-at-origin, local-at-destination, or ambiguous. Locations may be structured objects, single strings, or opaque facility codes.
Unifying these into a canonical tracking event model is a field-level mapping problem compounded by value-level translation. A platform that can read an arbitrary carrier feed, infer the schema, translate the codes, and normalize the timestamps handles this class of problem without requiring a new connector for every carrier.
Where datathere fits
datathere fits the layer of logistics integration that traditional iPaaS leaves underhanded: partner data from carriers and 3PLs, and any data source that arrives without a pre-built connector.
The platform reads each source directly. AI drafts the mapping to your canonical tracking or shipment schema, along with the transformation rules for status codes, timestamps, and locations. A human certifies the configuration. The pipeline runs on deterministic code, with quality rules that catch missing timestamps, unmapped status codes, and out-of-order events rather than silently dropping them.
For the known-system integrations (ERP to WMS, WMS to TMS), an iPaaS handles it. For the partner layer, datathere handles it. The two tools coexist cleanly.
FAQ
What makes logistics data integration different from general data integration?
Logistics adds two complications on top of general integration. The data describes physical operations, so timing, location, and event sequence all matter. And a significant share of the data comes from carriers and 3PLs whose systems the shipper does not control, which means every data format is someone else's decision.
Do I need separate tools for TMS, WMS, and ERP integration?
No. The integration problem across these three is the same problem in all three cases: schema mapping, event reconciliation, and master data alignment. A single mapping platform can handle all three, which is usually cheaper and more consistent than separate point solutions.
What about EDI?
EDI is still required in many logistics partnerships. Good integration tooling translates EDI transactions into a canonical data model, so downstream systems see structured data rather than raw segments. The EDI format stays where regulators and partners require it.
How do you handle 3PL data where the warehouse is not yours?
This is the classic partner-data-integration problem. The 3PL sends files or API responses in whatever format their WMS produces. No connector exists for every 3PL. AI-driven mapping handles this by reading the source directly and proposing a mapping to your canonical schema.
What breaks first when a logistics integration is under-invested?
Exception handling. Delivery failures, customs holds, damaged packages, missed pickups are the events that matter most and they tend to be the events with the least standardized data across carriers. Operations teams discover the consequences in customer complaints rather than in the tracking system.