A mid-sized shipper uses six carriers. A large one uses forty. Each carrier has its own portal, its own tracking data structure, its own update cadence, and its own definition of a "milestone." A logistics manager checking the status of last night's dispatches jumps between six or forty screens, mentally translating each carrier's dialect into a common language.
Every serious supply chain leader has thought about consolidating this. Most have tried. Most have shipped a dashboard that looks impressive in the demo and does not survive contact with production. The problem is not integration; every carrier has an API or an EDI feed. The problem is normalization.
Why "integrate all the carriers" is not enough
Connecting to a carrier is the easy 20 percent of consolidation. Getting the connection to produce useful, apples-to-apples data across carriers is the hard 80 percent.
Consider a single milestone: "delivered." Carrier A sends a status update with an event code at the timestamp of the driver scan. Carrier B sends its own status at the timestamp of the paperwork upload, which can be six hours later. Carrier C sends nothing until the invoice is generated the next day. If you naively concatenate the three feeds, you have three different definitions of "delivered" and any downstream metric (OTIF, delivery cost, cycle time) is meaningless.
Real consolidation means defining a canonical milestone model, mapping each carrier's data into it, and resolving inconsistencies. That is data engineering, not integration. Related reading: monitoring carrier performance in 5 steps.
The canonical milestone model
The consolidation efforts that succeed start with a canonical model of milestones the business actually cares about. A reasonable starting set:
- Order placed - Booking confirmed - Pickup complete - In transit - Border/customs cleared - Out for delivery - Delivered - POD available
Every carrier's raw feed gets mapped into these. If a carrier does not emit a specific milestone, it is flagged as "unavailable" rather than silently missing. That way the downstream OTIF or lead-time metric is honest about what it does not know.
Handle the freshness mismatch
The second consolidation failure is freshness. Carrier tracking updates on different cadences: ocean carriers update once or twice a day, LTL every few hours, parcel every scan, truckload variably. If the consolidation surface shows all of them side by side, the operator cannot tell which "last updated 3 hours ago" is normal and which is a stale feed.
Well-consolidated tracking exposes the freshness of each source alongside the data. The operator knows an ocean container "8 hours since last update" is normal; a truckload "8 hours since last update" is a broken feed. Our post on real-time data in supply chain covers this dimension. Forwarder-sourced milestones run on a different cadence again, and reconciling them with carrier events is a separate join worth handling deliberately.
Resolve conflicts on write, not on read
The third failure mode is conflict resolution. When two sources disagree, an ocean carrier says "arrived" and the port authority says "not yet," someone has to decide which one to believe.
Weak consolidation surfaces both and expects the operator to figure it out. Strong consolidation applies a defined precedence rule (e.g., port authority beats carrier for port events, carrier beats port authority for on-vessel events) and writes the resolved value to a canonical record. The operator sees the resolved answer with a link to the underlying sources. That is the difference between a dashboard and an operational record.
Instrument the exception path
Tracking that only reports current status leaves half the value on the table. Consolidated tracking that raises exceptions, this shipment is behind its promise date, this container has been at the port for 3 days, this carrier's lane performance is drifting, is what actually reduces cost. The inland leg is where those exceptions cluster, because that is where the record usually stops after a container arrives at the port.
Every carrier feed has to be processed against the shipment's promised outcomes. Exceptions become cases with named owners and documented resolutions, not red icons on a dashboard. Our post on strategies to improve on-time performance covers what this looks like in operational practice.
Where to start
Pick the five carriers that move 80 percent of your critical volume. Map their milestone models. Choose canonical milestones. Define freshness expectations. Define conflict rules. This is a four to six week project done right. Do not try to onboard all forty carriers on day one. If the scale of that normalization work is making you reconsider owning it at all, weigh up build vs buy for supply chain visibility first. Related read: platform integrations.
How Orkestra fits
Orkestra normalizes ocean, air, road, and rail carrier data into a canonical shipment record with defined milestone semantics, freshness metadata, and conflict resolution, then wraps it with exception management, analytics, and AI agents so anomalies become owned work with cost and root cause tracked. If you are running a consolidation effort, book a workshop and bring your top five carriers.
