From B/L to detention invoice: where the days disappear

A bill of lading (B/L) and a detention (D&D) invoice look like two completely separate documents — one issued when cargo is loaded, the other appearing weeks later, long after the container has been discharged. In reality, it's the same journey, just visible through two different documents' perspectives. And it's precisely between them, at points neither document shows on its own, that the days later billed on an invoice tend to disappear.

A container's journey, four points

The B/L is issued at the loading port — it states the estimated time of arrival (ETA), the carrier, and the route. This is the first point where time tracking could begin, but usually nobody does it, because at this stage the B/L is used only as a title and shipping document, not as a starting point for a clock.

The second point is the actual discharge at the destination port. It's this date — not the ETA, which is often off by several days — that most carriers use to start counting the contractual free time. If a company doesn't record this date immediately, and only learns of it once the invoice arrives, it has already lost the ability to check whether the calculation started at the correct moment.

The third point is when the consignee picks up the container from the terminal (gate-out). Days often pass between discharge and pickup — due to terminal throughput, customs procedures, or simply logistics planning — but the free-time clock is already running by then, regardless of the reason.

The fourth point is the empty container's return. This date, compared against the discharge date, is what the D&D invoice is actually based on. And this is where the discrepancy most often appears: the return date on the invoice can differ from the actual one, because the terminal's logging system and the carrier's billing system aren't always in sync.

Why these four points are rarely seen together

The problem isn't that this data doesn't exist — it's scattered across the B/L, the terminal's gate records, and the carrier's invoice, usually in different formats, different systems, sometimes even different departments of the same company. Until someone manually lines up all four dates in a single row, a discrepancy between them stays invisible — the invoice simply gets paid, because checking it would cost more time than it's worth.

Where the two data streams meet

The Cargo Intelligence Sea module automatically extracts the container number, carrier, route, and estimated arrival date from the B/L at loading time. The D&D audit checks whether the detention invoice received later matches the contract terms and the actual terminal data. When these two data streams meet — B/L data from the start, invoice verification from the end — it becomes possible to see the entire container journey in one place, instead of hoping someone will manually line up four separate points into one timeline.

This doesn't remove the need for actual terminal gate-in/gate-out data — the B/L document doesn't contain that on its own. But it does mean half the journey is already covered automatically, before the invoice even exists.