Different ETAs are usually a systems problem before they are a transport problem
A shipment can be on the same truck, on the same route, with the same driver, and still show three different ETAs by 9:15am.
That is not unusual. It usually means each system is answering a different question. The TMS is often holding the planned arrival. The carrier portal is showing the carrier’s latest predicted arrival. The customer dashboard is usually displaying whatever its integration layer last accepted, then reformatted for the customer.
When people ask why ETAs differ across systems, the real issue is rarely “which one is right?” It is “which one is right for this moment, and which one is safe to show?”
That distinction matters because a bad ETA is not just a data annoyance. It creates call volume, rework, missed appointments, and awkward conversations with customers who can see the mismatch before your team does.
Why the numbers split in the first place
The most common cause of an ETA mismatch is that each system is using a different input set and a different refresh rhythm.
A TMS might calculate ETA from linehaul transit time, service level, origin and destination postcode pair, and a planned dock schedule. A carrier portal may recalculate from live GPS pings, driver status, traffic, and the last scanned milestone. A customer dashboard may cache the last successful update, apply a rules engine, and then suppress changes until the variance crosses a threshold.
So the same shipment can show:
- an appointment time in the TMS
- a predicted arrival in the carrier portal
- a customer-facing ETA rounded to the nearest hour or held back until the next scan
That is why tracking discrepancies keep appearing even when nobody has entered bad data. The systems are not broken in the same way. They are designed differently.
If you are trying to work out how to reconcile ETA exceptions, start there. Do not assume the carrier is wrong because the TMS disagrees, and do not assume the dashboard is wrong because it looks stale. First confirm what each system is actually displaying.
Which ETA do you trust first
Start with the most recent operational signal, not the prettiest screen. In practice, that usually means the carrier portal or direct carrier status feed gets first look, but only if it has a real milestone behind it.
The signals that justify overriding the TMS are specific:
- a departed scan after the TMS still shows “at origin”
- a geofence arrival or departure event from telematics
- a driver status change, such as “delayed”, “loaded”, or “held at dock”
- a missed appointment or tender rejection recorded by the carrier
- a new ETA from the carrier that is tied to a fresh milestone, not just a recalculation
If the carrier portal ETA is based on live movement and the TMS is still showing the original plan, trust the carrier first for operational coordination. If the carrier ETA has changed twice in 20 minutes with no movement, treat it as a forecast, not a fact.
A useful rule: actual event beats forecast, forecast beats plan.
| Source | Best use | Weak point |
|---|---|---|
| TMS ETA | Planning, load sequencing, internal promise dates | Can lag real movement |
| Carrier portal ETA | Current movement and carrier-side exceptions | Can recalculate too often |
| Customer dashboard ETA | Customer communication | Often filtered, cached, or rounded |
That hierarchy is the foundation of how to reconcile ETA exceptions without creating a second problem in customer service.
Key takeaway: Trust the freshest milestone first, then decide whether the ETA is an operational fact or just a forecast that has changed.
The root cause when the same lane keeps drifting
When ETA mismatches keep happening on the same lane after master data has been cleaned up, the problem is usually not the postcode, the service level, or the consignee name. It is the lane logic.
I see this most often in lanes where one of these is true:
- the carrier routinely misses the same pickup window
- dwell at the origin or destination is not being modelled
- the transit profile is set to a standard linehaul time that no longer matches reality
- the carrier’s milestone timing is late by design, so the ETA is always behind the actual movement
- the TMS is using a lane template that never got updated after a route, depot, or carrier change
In other words, the lane is lying to the system more than the system is lying about the lane.
If the same freight moves Melbourne to Albury every Tuesday and the ETA is always 2.5 hours optimistic, that is not an exception to chase each week. That is a lane profile problem. Fix the transit assumption, the dwell assumption, or the tender timing. Otherwise you are just reconciling the same miss over and over.
This is where How Do I Start Route Optimisation for Small Delivery Teams? becomes relevant. Even if you are not optimising a local delivery fleet, the principle is the same. Bad route assumptions create bad ETA behaviour downstream.
What to check first when ETAs diverge after a status update
If ETAs diverge right after a carrier status update or milestone change, the first thing to check is the integration mapping, not the shipment itself.
Look at these settings in order:
- Which event is triggering the ETA refresh
- Is it a departed scan, an arrived scan, POD, driver status, or a generic webhook?
- Which ETA field is being written
- Planned ETA, estimated arrival, appointment time, or customer promise date?
- Whether the TMS is set to overwrite or merge
- Some setups accept carrier data, then overwrite it on the next planning sync.
- Whether timestamps are being converted correctly
- Time zone mistakes still cause ugly disagreements, especially around daylight saving changes.
- Whether the carrier feed is delayed or out of order
- A late scan can arrive after a newer ETA and still overwrite it if the integration does not sequence events properly.
If the carrier portal ETA is clearly more current but the TMS keeps overwriting it on the next sync, that usually means the TMS is still treated as the system of record for ETA. In that setup, you need a rule change. Either:
- stop the TMS from overwriting carrier-derived ETA fields, or
- store carrier ETA separately and display it only when it is fresher than the plan
Do not let a planning refresh wipe out a live carrier update. That is how you end up explaining to a customer why the ETA moved backwards.
Appointment time, predicted arrival, and customer ETA are not the same thing
A lot of confusion comes from teams using those terms as if they mean the same thing. They do not.
Appointment time
This is the booked delivery or pickup slot. It is usually fixed, negotiated, and often tied to a dock booking or customer receiving window.
Predicted arrival
This is the current operational estimate. It changes with traffic, dwell, missed handovers, and route progress.
Customer-facing ETA
This is the version you choose to expose. It may be the predicted arrival, a promised range, or a buffered time that protects the customer experience.
If one system is using appointment time, another is using predicted arrival, and the dashboard is showing something else entirely, you are not looking at one ETA mismatch. You are looking at three definitions that were never aligned.
The cleanest fix is to label the fields properly in your TMS and integration layer. If the dashboard says “ETA” but the underlying value is actually the appointment slot, customers will assume the carrier is late when the shipment is simply early or waiting for a dock. That is how trust gets damaged for no operational gain.
Which exceptions are worth escalating
Not every ETA change deserves a call to operations. Some are just noise caused by update cadence, and escalating them only creates fatigue.
Escalate when the ETA change is tied to a real operational event:
- missed tender
- dwell beyond threshold at origin or destination
- vehicle breakdown or driver unavailability
- failed delivery attempt
- linehaul connection missed
- appointment window now at risk
Do not escalate every recalculation, especially when:
- the carrier portal refreshes every few minutes
- the dashboard is holding back updates until a threshold is crossed
- the TMS is still waiting for the next scheduled sync
- the ETA moved by 10 to 15 minutes with no new event
That difference matters when you are working out how to reconcile ETA exceptions at scale. If planners chase every small swing, they stop trusting the alerts that matter.
A practical threshold helps. For example, many teams only escalate if:
- the ETA shifts by more than 30 minutes on a metro delivery
- the appointment window is now inside the risk threshold
- the destination is a dock with strict receiving hours
- the customer has already called once
That is not a universal rule, but it is better than letting everyone invent their own.
How to stop customer ETAs bouncing around
Customer-facing ETAs should not twitch every time a carrier sends a new scan. If they do, the dashboard becomes a live feed of uncertainty instead of a useful promise.
The fix is usually in the display rules, not the carrier data.
Use a buffer or holdback rule so the customer ETA only changes when one of these happens:
- the new ETA differs by more than a set threshold
- a confirmed milestone has been missed
- the shipment enters a defined risk state
- the latest ETA has been stable for a set period
That means a 12-minute recalculation at 8:40am does not trigger a customer alert, but a missed pickup at 9:10am does.
You also want to separate internal ETA from customer promise. Internal teams need the most current forecast. Customers need a stable, credible message. If those are the same field, the dashboard will bounce around and your service team will spend the afternoon explaining why the system keeps changing its mind.
This is where The Hidden Costs of Poor Transport Visibility becomes very real. The cost is not just late freight. It is the noise created by over-updating people who do not need every recalculation.
Dwell, layover, and missed tender events need different responses
When ETAs differ because of dwell, layover, or missed tender events, do not treat them as the same problem.
Dwell
If the truck is sitting at origin or destination longer than planned, ask whether the delay changes the shipment plan or only the displayed ETA. If the freight is still moving on time for the customer window, update the ETA and leave the plan alone. If the dwell pushes the load into a missed appointment, the plan needs intervention.
Layover
Layover often affects linehaul connections and cross-dock timing. If a shipment misses a connection at a distribution centre, the ETA may only need adjusting if the downstream appointment is at risk. If the layover means the freight will miss a same-day receiving window, you need to rebook or reroute, not just update the screen.
Missed tender
This is usually operational, not cosmetic. A missed tender often means the shipment never moved when it should have. That should trigger a plan review, carrier contact, and possibly a customer update.
For teams managing more than one site, this is where Transport Risk Management: How to Prevent Delivery Disruptions fits into the workflow. ETA exceptions are often the first symptom of a bigger failure in handover or capacity control.
The playbook that stops three teams giving three answers
If planners, customer service, and carrier reps are all giving different answers, the issue is not just data quality. It is that nobody has a shared operating rule.
A workable playbook looks like this:
-
Define the source hierarchy
- Planned ETA in the TMS
- Carrier-derived ETA from the latest valid milestone
- Customer-facing ETA after display rules are applied
-
Define the override rules
- Which carrier events can overwrite the TMS?
- Which changes are informational only?
- Which ones trigger escalation?
-
Define the refresh cadence
- How often does each system sync?
- What happens if a late event arrives out of sequence?
-
Define ownership
- Who owns the lane profile?
- Who approves a customer ETA override?
- Who contacts the carrier when the feed looks wrong?
-
Log the exception reason
- Dwell
- Layover
- Missed tender
- Appointment change
- Integration delay
When you standardise those five points, how to reconcile ETA exceptions becomes repeatable instead of emotional. The team stops debating whose screen is “right” and starts working from the same rules.
For recurring misses, fold the learnings into What to Include in a Distribution Contingency Plan and 7 Ways to Improve Goods Handling Across the Distribution Chain. A lot of ETA pain starts before the truck leaves, in how freight is staged, tendered, and handed over.
The source of truth changes by moment, not by department
The biggest mistake I see is teams trying to crown one permanent ETA source of truth.
That does not work. The TMS is usually the source of truth for the plan. The carrier portal is often the source of truth for live movement. The customer dashboard should be the source of truth for what you are prepared to promise externally.
If those roles are blurred, different shipment ETAs will keep appearing and nobody will know which one is defensible.
So use this test:
- If you are planning capacity, trust the TMS.
- If you are reacting to movement, trust the carrier’s latest valid milestone.
- If you are speaking to the customer, trust the controlled dashboard value, not the raw feed.
That is the practical answer to why ETAs differ across systems. They differ because each system serves a different job. The job of the transport coordinator is to stop those jobs from talking past each other.
The next time a customer says, “Your site says tomorrow, the carrier says today, and your team says Friday”, do not start by defending the system. Check the milestone, check the mapping, check the display rule, then decide whether you need to change the plan or just the promise.
That sequence saves time, protects trust, and gives your team one answer that holds up under pressure.
