Why are there unexpected or missing containers on my B/L?
A tradeflow can end up with containers you did not upload, or lose ones you did. There are three causes, and they are easy to tell apart once you know what to look for.
1. More than one booking reached the same tradeflow
The most common cause. If two bookings or two B/Ls arrive on the same file, Dockflow tracks both, and the containers from each are attached to the tradeflow.
The symptoms are recognisable:
- containers appear that belong to a different file
- the destination looks wrong, because the second booking has a different port of discharge
- the vessel or ETA does not match what you expect, because it belongs to the other booking
A related variant: a container is removed from a file, but the booking it came in on stays active. A newly added container then attaches to the shipping information from the old booking, and the tracking follows the wrong journey.
What to do: identify which reference is correct and remove the other. Once the incorrect booking or B/L is gone, Dockflow retrieves tracking for the remaining one. If the tradeflow was created with one reference and corrected to another shortly after, both may still be present.
2. The container does not belong to the booking according to the carrier
Dockflow checks the containers you supply against what the carrier reports for that booking or B/L. When a container is not on the carrier's list, it is marked with the container not in booking/BL flag.
That container gets no tracking data, because there is nothing to retrieve. The carrier does not recognise it as part of that shipment.
Two things can be true when you see this flag:
- The link is wrong. The container belongs on a different file. Correct it yourself.
- The link is right and the carrier disagrees. Tell support, and the reason the carrier reports differently gets investigated.
An automation is available that notifies you when a container is attached to a tradeflow that the carrier does not associate with the booking or B/L. Ask support to enable it if you want these surfaced as they happen rather than found later.
3. The same container appears in more than one shipment
This one is usually not an error. Containers are reused across journeys, and the platform supports the same container number existing in several shipments. In most cases the earlier shipment is already deactivated and therefore not shown.
Where it does cause confusion is when a shipment is tracked by container number alone, with no booking or B/L. Tracking by container number has no natural end point, so the container stays active after it has arrived, and events from its next journey can attach to the old shipment.
What to do: supply a booking or B/L reference wherever you have one. It scopes the tracking to that journey and closes it out when the journey completes. If you are tracking by container number because no other reference exists, expect to deactivate the tradeflow once the container arrives.
Telling the three apart
| What you see | Most likely cause |
|---|---|
| Extra containers, and a destination or vessel that belongs to another file | Two bookings on one tradeflow |
| A container with no data at all, carrying a flag | Container not in booking per the carrier |
| The same container in two shipments, one of them stale | Container reuse, usually with container-only tracking |
Related topics
- No tracking data - when nothing is tracking at all
- Data differs from the carrier - when the container is right but the dates are not
- Bulk import - supplying references correctly on upload
- Deleting containers - removing a container from a tradeflow
Need help?
Send the tradeflow reference, the container numbers you expect on it, and what the carrier shows for the booking or B/L. That is enough to identify which of the three cases applies.
- Email support - [email protected]
- In-app chat - click the chat icon in the bottom right
Last updated: July 31, 2026