Your forwarder emails on Tuesday to say the container got rolled. You open the carrier's tracking page and it still shows the original vessel, the original sailing, the original ETA. The carrier feed does not catch up until Friday. For three days your planning team is working from a date that stopped being true before the week started, and your customer service team is quoting it to customers.
This is not a broken feed. Both systems are working exactly as designed. They are just answering different questions, and nobody joined the answers together.
Why rollovers are the exception that exposes the gap
Carriers spent this month rationing space. Roughly 79 blank sailings are scheduled across the major east-west trades between week 38 and week 42, out of about 721 planned departures, and carriers are prioritising contract and premium bookings ahead of China's National Day holiday. Global schedule reliability is sitting somewhere between 42% and 48%.
When space is that tight, the rollover becomes the dominant exception. And a rollover is the single worst event for split tracking, because it is a commercial decision before it is a physical one. Someone at the carrier decides your box does not sail. That decision reaches your forwarder as a booking amendment almost immediately. It reaches container tracking only when the box is physically not loaded, or when the next vessel assignment is confirmed. The schedule change itself can be caught early if you are watching for it, but only if you are watching the system that learns about it first.
Most shippers are not. They are watching the one that learns last.
What each side actually knows
Once a forwarder books on your behalf, the shipment exists twice.
The carrier knows the master bill of lading, the container, the vessel and voyage, the terminal events, and the discharge. It is event data, mostly automated, mostly reliable once it arrives. What it does not know is who the cargo belongs to. A single master bill may cover six of your consignments and four other shippers' as well.
The forwarder knows the house bill of lading, which purchase orders and SKUs are inside the box, the commercial terms, the booking history, and any amendment made to it. It knows the rollover on Tuesday. It knows the customs entry status. But much of that knowledge lives in email threads and a portal, and the milestone set is shallower and updated by hand more often than anyone admits.
Neither record answers the only question your operators are actually asking: is purchase order 44819 going to arrive when we promised, and if not, what do we do about it. Answering that means joining both, which is a different problem from consolidating tracking across carriers. That one is about normalising many feeds that describe the same kind of thing. This one is about reconciling two feeds that describe the same shipment from different altitudes.
Start with the join key, not the feed
The mistake is to begin by adding a data source. Teams add a carrier API, then a forwarder file, and end up with two lists they cannot line up. It also assumes both sides can send a feed at all, which is not true for the long tail of partners who have no API and still work in email and PDF.
Begin instead with identity. Decide what uniquely identifies a shipment in your business, and make every incoming record carry it.
Container number is the obvious candidate and the wrong one. Containers get restuffed, consolidated shipments put several of your orders in one box, and the same container number is reused within weeks. The house bill is closer, because it maps to your commercial relationship, but it will not join to carrier events, which are keyed to the master bill. So you need the pairing: house bill to master bill to container to purchase order. The forwarder is the only party who can reliably give you that mapping, which makes it the first thing to ask for and the thing most shippers never request.
Get the mapping as data, on every booking, not as a line in a confirmation email. Once you hold it, carrier events and forwarder milestones resolve to the same object, and a vessel departure can finally tell you which of your orders just left.
This is the work a command center like Orkestra does before anything else: it takes carrier feeds, forwarder files and your own ERP order data, resolves them onto one normalised shipment record, and keeps that record current. With more than 200 pre-built connectors across carriers and ERP, TMS and WMS systems, the join stops being a quarterly integration project and becomes a connection made in days. The record is the product. Everything useful downstream depends on it existing.
Decide who wins when the two disagree
They will disagree, often, and a system that has no rule for it will simply show your team both numbers and let them pick. That is how you end up with twelve logins and no shared version of the truth.
Write the precedence rules down. A workable default:
- Physical events go to the carrier. Gate-in, loaded, departed, discharged, available. The carrier's terminal data is closer to the metal and more consistently timestamped, and these are the same events that expose a rollover before the vessel leaves origin.
- Commercial and status changes go to the forwarder. Rollovers, booking amendments, customs holds, release status, documentation. These begin as decisions, and the forwarder is in the room.
- Cargo content goes to your own systems. What is in the box, what it cost, who ordered it, what it is worth if it is late.
Then add the rule that matters most: when the forwarder reports a change the carrier has not confirmed yet, treat it as true and flag it as unconfirmed. Do not wait for corroboration. Three days of lead time is worth far more than three days of certainty, and if the carrier later contradicts it you have lost nothing. Most teams have this backwards, holding the forwarder's warning until it is confirmed, which converts their only early signal into a late one. One further case needs a rule of its own: a source that has stopped publishing altogether is not agreeing with the other one, so telling a quiet shipment from a broken data feed keeps a dead connection from passing as consensus.
Score the difference, then fix the worst gap
Once both streams land on one record you can measure something you could not measure before: how far ahead of the carrier your forwarder actually is, event by event.
Log the timestamp at which each party first reported each milestone. After a few hundred shipments you will have a lead-time profile per forwarder and per lane. Some will be four days ahead on rollovers and two days behind on customs release. That profile turns a vague complaint about communication into a specific request with evidence behind it.
It also feeds directly into ETA accuracy, because an arrival date built from whichever source knew first is meaningfully better than one built from whichever source is easiest to query.
Make the joined record do something
A unified record that only sits on a dashboard has not paid for itself. The point of knowing on Tuesday rather than Friday is the three days of action it buys, and those days get spent only if the change triggers work automatically.
A rollover detected on the forwarder side should open a case, attach the affected purchase orders, notify the planner who owns them, and tell customer service which promises are now at risk. Not an alert. A task, with an owner and a clock. Across the industry, 62% of supply chain exceptions are still detected after they have already reached the customer, and the gap between the two systems is one of the places that delay hides.
This is where the joined record earns its keep. Orkestra's exception management watches both streams against the same shipment, raises the discrepancy the moment it appears rather than when it is confirmed, and routes it with the order context already attached. OIA Global, a global forwarder running this on their own operations, saw a 60% reduction in exception resolution time in Q1.
Where to start Monday
Pick your top forwarder and your busiest lane. Ask for the house bill to master bill to container mapping as a data field on every booking, going forward rather than retroactively. Then take four weeks of shipments and record which party told you about each milestone first, and when. That single table will tell you whether your problem is coverage, latency, or precedence, and those three have completely different fixes.
Close the loop on the worst one first, and do not start by buying a feed. The feed was never the missing piece. The join was.
Seeing both halves of the shipment in one place, early enough to act, is what a supply chain command center is for. Get full visibility across carriers and forwarders.
