Skip to main content

Why does Dockflow show something different from the carrier?

Two numbers that disagree are not automatically two numbers where one is wrong. Dockflow, the carrier and the terminal each publish a different measurement, or publish the same measurement at a different moment, and three numbers for one shipment can all be correct at once. This page explains the cases where that is what is happening.

It is not automatically fine either. If none of the cases below fit what you are seeing, the data is wrong, and that is covered separately in what if the data in Dockflow is wrong.

The short version​

Before treating a difference as wrong, check what each number is actually measuring:

SourceWhat its "arrival" usually means
TerminalThe berth ETA. When the vessel moors at the quay.
Carrier portalOften the port of discharge arrival, sometimes the moment the container is available after discharge. These are different events on the same screen.
DockflowThe best current estimate for the event you are looking at, drawn from carrier feeds, terminal data and vessel tracking.

Three numbers for one shipment can all be correct at once.

1. Three sources, three different events​

A worked example from a real shipment. The customer saw three arrival times and asked which one was right. All three were.

  • Terminal, 24/07 13:00 - the berth ETA. The moment the vessel moors.
  • Carrier, 25/07 05:30 - the carrier's "Final Destination Hub" time, meaning the container is available after discharge. On that same carrier screen, the port of discharge was listed as 23/07 10:00.
  • Dockflow, 25/07 02:00 - the estimate held for the event shown in the tradeflow.

Nothing here is contradictory. Berthing, discharge and container availability are three points on the same timeline, hours or days apart.

tip

In the tradeflow, hover over a date that carries the Predicted label. You get the history per source, with the terminal feed and the carrier feed shown separately. That is the fastest way to see where a number came from.

2. Vessel arrival and discharge are not the same event​

This is the most frequent single cause of a "wrong ATA" report.

At the port of discharge there are two distinct datapoints:

  • Vessel arrival (ATA) - the ship arrives
  • Discharge - the container comes off the ship

These are typically one day apart. Some carriers publish both explicitly. Others publish only the discharge date on their portal, in which case the vessel arrival shown in Dockflow comes from vessel tracking rather than from the carrier feed.

In the API they arrive as two separate messages: the vessel arrival as the final port of discharge arrival, and the discharge as a separate container milestone.

If you are integrating

If your integration maps ATA to the discharge milestone, every shipment will look one day out against the carrier. Confirm which field your integration reads before reporting a discrepancy.

The same principle applies elsewhere in the journey. A carrier may publish only "import discharged from vessel" and no arrival at all, in which case Dockflow derives the arrival from vessel tracking and terminal data.

3. The transhipment port is not the port of discharge​

If a tradeflow shows an ETA you did not expect, check whether it belongs to a transhipment port rather than the final destination.

Dockflow shows the transhipment ETA when it has one, so you are not left without any arrival indication while the final leg is still unconfirmed. It is labelled as a transhipment, not as the port of discharge.

The reverse case also occurs: if a carrier initially declares a port as the destination and later changes it, an actual arrival may already have been recorded against the first port. The destination then updates, but the earlier arrival stays attached to the port it happened at.

4. Which source wins when they disagree​

Not the one you happen to be looking at. Dockflow resolves competing readings by three rules, in order:

  1. An actual beats an estimate, whichever source it came from. A confirmed event is never overridden by a prediction.
  2. Among estimates, the more recent reading wins. The newest information supersedes a stale prediction.
  3. Agreement raises confidence. A time several independent sources concur on carries more weight than an isolated single-source reading.

So the outcome can differ from any one portal without any of them being wrong. A terminal figure can be the one shown, because it was the most recent. Vessel tracking can move an arrival before the carrier updates their own page, for the same reason.

The full mechanism, including the guards against a bad reading winning, is in source precedence.

5. The carrier changed it, and the next refresh has not run​

Dockflow polls carriers at intervals rather than continuously. If a carrier revises an ETA shortly after a refresh, Dockflow carries the previous value until the next one.

This is visible as a lag of a few days in the worst case, and it explains differences where the carrier's page is simply newer than the last retrieval.

6. The carrier published an actual and then withdrew it​

Carriers occasionally publish an actual arrival or departure and retract it later the same day. Dockflow records what was received at the time, so a value can appear, then change back.

If a date looks like it moved backwards, this is usually why.

7. A transhipment that was planned but skipped​

A routing can list a transhipment that the carrier later drops. The carrier's own site sometimes keeps showing the original call for a while. A tradeflow can therefore show a leg that no longer happens, or show a routing that no longer matches the carrier page.

The same pattern occurs when a container is first assigned to one booking and later moved to another shipment.

8. "Discharged at POD" does not show every discharged container​

A view-level distinction that is easy to misread. The Discharged at POD view shows containers that are discharged and not yet picked up. Containers already returned empty have moved on and correctly drop out of it.

If a container is missing from that view, check whether it has already been collected.

If none of the above explains it​

Then the value is wrong rather than different, which is a defect on our side. Report it with:

  • the tradeflow reference, or the container, B/L or booking number
  • the value you see and which event it is against
  • what you expected instead

The reference alone is enough - Dockflow stores every reading received for the shipment with its source and timestamp, so support reads the full history from it. See what if the data in Dockflow is wrong.

Need help?​

  • Email support - [email protected]
  • In-app chat - click the chat icon in the bottom right

Last updated: July 31, 2026