Dockflow, a tracking vendor, documents a case where a customer saw three arrival times for one shipment and asked which was right. According to Dockflow’s FAQ, all of them were. The terminal showed 24/07 13:00, which was the berth ETA. The carrier portal showed 25/07 05:30 under “Final Destination Hub”, meaning the container is available after discharge, while the same screen listed the port of discharge as 23/07 10:00. Dockflow’s own estimate was 25/07 02:00. Dockflow says only that it is the estimate for the event shown in its tradeflow, without naming the event, and it gives no year or port. It adds that if none of its explanations fit, the data is wrong.
Dockflow’s FAQ puts the rule this way: two numbers that disagree are not automatically two numbers where one is wrong, and not automatically fine either. The first job is to find out what each one measures.
What DCSA standardises
DCSA is the Digital Container Shipping Association. Its Track & Trace page describes the problem: the facts everyone needs (loaded, discharged, gated in or out, transshipped, picked up, dropped off) arrive in different formats, on different timelines, through different channels, if they arrive at all. The standard offers one event model with shared definitions and one API for exchanging them. DCSA event types come in five kinds: shipment, transport, equipment, IoT and reefer.
Vizion’s schema groups the equipment, transport and shipment events into three journey types (IoT and reefer events are not covered on the Vizion page I read):
- Equipment: what physically happens to the container, such as gate in, load, discharge, available for pick-up, gate out.
- Transport: what the vessel, truck or train does. Arrived and departed live here.
- Shipment: the paperwork flow, such as a document issued, confirmed or rejected.
These definitions decide which event a timestamp refers to. In the arrival definition Vizion lists for DCSA event codes, a vessel has arrived once it is berthed at the port terminal. Discharge is a separate equipment event: lifting the container off the vessel.
Dockflow’s page draws the same line without naming DCSA. It says vessel arrival and discharge are typically one day apart, and calls mixing them up the most frequent single cause of a “wrong ATA” report. Some carriers publish only the discharge date. In Dockflow’s words, if an integration maps ATA to the discharge milestone, every shipment will look one day out against the carrier.
One caveat before you assume every portal follows these definitions. The TrackingMCP glossary (TrackingMCP is a Navo product) says member carriers have committed to the standard but expose it in varying degrees, and that coverage and endpoint quality differ by line. Real integrations still blend standard and legacy feeds.
Where the rest of the gap comes from
CargoScope notes that a container number is a key for looking up events that carriers and terminals have already recorded, since the box has no GPS tracker. Status is stitched together from carrier milestones, terminal postings, AIS vessel positions and, inland, rail data. CargoScope adds that terminal timing often leads the carrier by hours.
Terminal49 wrote in December 2024 that every terminal has its own system with no industry-wide standard. One says a container is available explicitly, another implies it by showing no holds. Terminal49 also said a lot of milestones came through EDI, which it called slow and batch-based, so today’s update can be yesterday’s news. Its team argues that carriers have little incentive to volunteer information that could cost them demurrage revenue. Terminal49 sells data quality, so read that as a vendor’s view.
Dockflow lists several mechanical causes. It polls carriers at intervals, so a revision made just after a refresh appears later, with a lag of a few days in the worst case. Carriers sometimes publish an actual arrival and retract it the same day.
Look at the right level
Tradlinx, a freight platform, describes a composite case. It labels the lane and dates illustrative, and its subject is tracking with the wrong identifier. Four containers under one master B/L travel from Ningbo to Norfolk with a Singapore transshipment. One misses the onward connection and rolls six days. The B/L-level summary keeps saying “in transit” because three of four boxes are moving. The customer hears “on track” until three containers arrive and the fourth is somewhere south of Tokyo.
Its fix is to switch the primary identifier as the shipment moves, and to check at container level at risk points such as transshipment hubs.
Questions to ask before you trust a status
When two screens disagree, I ask what each number is before I compare them.
- Which event is it: berth, discharge, availability?
- Is it planned, estimated or actual? DCSA-aligned event models carry that classifier, according to the TrackingMCP glossary.
- Which level is it read at: booking, B/L or container?
- Who published it, and when was it last refreshed?
Dockflow documents its own tie-break. An actual beats an estimate. Among estimates the newer reading wins. Agreement between independent sources raises confidence. That is one vendor’s rule set, and I did not find a comparable rule in the DCSA material I read.
Where Navo fits
My view, and it is an opinion: a tracker is worth trusting when you can see what its status is made of. Navo’s homepage describes a product that is never dark, with one connected data layer under tracking, schedules, rates and loading.
The facts from navo24.com: TrackingMCP covers containers across 240+ carriers, normalised to one standard. Event freshness is 0 to 5 minutes, cross-checked across 2 to 3 sources. You can work in a dashboard, call the REST API, take webhooks or connect an agent through the MCP server. Navo’s tools share the same events, so the lane you priced is the lane you track.
The terminal still posts its berth ETA and the carrier its own arrival, so source differences stay. What changes is that events from 240+ carriers are normalised to one standard. You can follow any box on the container tracking page, and the shipment visibility page shows how the events feed alerts. If you want an agent working on those same events, you can request one at navo24.com/nav/.
Next time two trackers disagree
Write down which of the DCSA event types each number belongs to, then the level, then the time of the last refresh. In the Dockflow example the customer’s question was answered by labelling the times. Where labels do not explain the gap, Dockflow says the value is wrong and should be reported with the container, B/L or booking number.