What if the data in Dockflow is wrong?
Sometimes it is. Dockflow builds a transport plan out of carrier feeds, terminal feeds and vessel tracking, and any of those can arrive late, arrive wrong, or disagree with each other. When the result is wrong, we want to hear about it.
You can report it straight away - nothing below is a precondition. The first table is there only because several of the most-reported cases already have a full explanation, and it may save you the wait.
First: is it one of the known explanations?
| What you are seeing | Where it is explained |
|---|---|
| Dockflow and the carrier show different dates for what looks like the same event | Data differs from carrier |
| A confirmed date appeared and then changed back | Data differs from carrier, section 6. Carriers publish an actual and retract it; Dockflow records what was received |
| A transhipment or a leg in the plan that never happens | Data differs from carrier, section 7. A carrier can drop a call it previously published |
| Containers on the shipment that you did not upload | Containers on a B/L |
| A completed shipment picking up new events, or a container's next journey attached to the old one | Containers on a B/L, section 3. Containers are reused, and this is usually not an error |
| The tradeflow is empty rather than wrong | No tracking data |
| A milestone arrived later than you expected | Event timing and freshness. Feeds update on a cadence; late is not the same as wrong |
If one of those fits, you have your answer. If none of them does, the rest of this page applies.
Just the reference is enough
Send the reference and what you saw. That is a complete report.
There is no need to attach a screenshot or work through a checklist first - Dockflow keeps the readings it received for your shipment with their source and timing, so support opens the same history you are looking at, and more.
The single most useful thing you can include is the reference. Everything else can be reconstructed from it.
What is genuinely worth reporting
1. A value that never catches up
Dockflow polls carriers at intervals, so a value trailing the carrier's own page for a while is the normal refresh gap rather than a defect - that case is explained here. What is worth reporting is a value that stays behind across several days and successive refreshes, because that is the shipment no longer being updated at all rather than waiting for the next poll.
2. A confirmed time changes by a lot after the event
A confirmed actual can still be revised. The confirmed value is drawn from several sources, and a later source can supply a different time for the same event. Revisions of a few hours after confirmation are common and are not a fault.
Report it when the change is large - days rather than hours - or when a confirmed arrival ends up dated in the future. Those are not ordinary.
3. A date alternates between the same two values
Not a carrier revising its own estimate, which is normal, but the same event reading 24/03, then 30/03, then 24/03 again across successive updates, without converging.
4. The container is shown in the wrong place
Carriers send location codes and names that do not always agree, and some codes are valid identifiers for a completely different place. A leg routed through somewhere implausible for the trade lane is worth reporting; the correction applies to every shipment that carrier codes the same way.
5. A milestone the carrier published is missing
The carrier's own page shows an event, the rest of the shipment tracks normally, and that one event is absent.
6. Anything the Console already classes as an anomaly
Merged shipments, milestones in an impossible order, a plan that starts and ends at the same port, or a transhipment appearing after the final port. These have names and a definition - see anomaly classification - and reporting them with the reference is the right move.
How to report it
Send this to support, or say it in the in-app chat:
- the reference - the tradeflow reference, container number, B/L or booking number
- what you see - the value in Dockflow and which event it is against
- what you expected instead, and where that came from if it was not Dockflow
Three lines is a complete report. If you only have the reference, send that.
See which reference numbers Dockflow accepts for the formats, and how to tell a container number from a B/L.
What happens after you report it
Support reads the stored readings for that shipment: what was received, from which source, and when. That is normally enough to say in one reply whether the value was wrong, what produced it, and whether it is already corrected.
Where it turns out to be a platform defect it is logged as one. Where an upstream feed sent us bad data, we raise it with that source. Either way we tell you which of the two it was.
Related topics
- Data differs from carrier - when two numbers disagree and both are correct
- No tracking data - when the tradeflow is empty rather than wrong
- Reference numbers - container, B/L, booking and house B/L
- Dates and milestones - what ETS, ETD, ETA, ATS, ATD and ATA mean
- Anomaly classification - what the Console flags automatically
- Source precedence - which source wins when two disagree
Need help?
- Email support - [email protected]
- In-app chat - click the chat icon in the bottom right
Last updated: August 17, 2026