How to track a container by Bill of Lading number

Someone forwards you a document, you need to know where the shipment is, and the only reference on the page is a Bill of Lading number. If you’ve ever pasted that into a carrier site and gotten “no results,” you’ve hit the thing nobody explains up front: a B/L, a booking and a container number are three different references, they enter the shipment’s life at three different moments, and which one works for tracking depends on where the box is in its journey.

Here’s how to tell them apart and actually get an answer.

Three references, three moments

Each reference is created by a different step, and each points at a slightly different thing.

The booking number comes first. You (or your forwarder) reserve space on a sailing; the carrier issues a booking. At this point there may be no physical container assigned yet — the booking is a promise of space, not a box.

The container number is the steel. Four letters (the owner prefix, like MSCU or MAEU) then seven digits, with the last digit a check digit. It identifies one physical box and is stamped on the doors. One booking can spawn several container numbers.

The Bill of Lading number is the contract of carriage — the legal document that says this cargo, on this vessel, from here to there, to be released to whoever holds the B/L. It’s issued around the time the cargo is loaded, and it’s the reference that ties the whole shipment together, often covering multiple containers under one document.

Which one to track with

Rule of thumb: the Bill of Lading is the best all-round tracking reference once the cargo is loaded, because it resolves the whole shipment — every container under that document — in one lookup. If you have a container number, use it when you care about one specific box and want the most precise timeline. Use the booking number only very early, before containers are assigned, when it’s the only reference that exists yet.

The catch that produces “no results”: carriers don’t all accept every reference type at every stage, and some only recognise a B/L after it’s been issued. So a B/L that returns nothing today may simply be too early — the document hasn’t been cut yet. That’s not a dead shipment; it’s the wrong reference for the moment. A good tracking layer handles all three shapes and tells you which stage you’re at, rather than a blank “not found.”

The milestone flow you should expect

Whatever reference you track with, the shipment moves through the same skeleton of events. Knowing the flow tells you instantly whether a status is plausible — and whether a tool claiming “delivered” has any business saying so.

Between “sailed” and “discharged” there’s often a transshipment — the box is discharged at a hub, waits, and is loaded onto a second vessel. That’s normal, but it’s where naïve tracking gets confused and shows “discharged” as if the box had arrived at destination when it’s really mid-journey. A tracker normalising events to the DCSA standard keeps the transshipment discharge and the final discharge straight.

Do it once, get the whole set

The trap is treating these three references as interchangeable and giving up when one returns nothing. They’re stages of the same shipment. Track by the B/L to see everything under the contract; drop to a container number when you need one box in detail; accept the booking is only useful at the very start.

That’s how TrackingMCP handles it: hand it a container number, a Bill of Lading or a booking and it resolves to the same clean, DCSA-normalised timeline — with the milestone advanced only when a carrier event actually fired, never assumed. Paste a reference into the public tracker with no login, or call add_container from your own system. For the deeper point on why a milestone must be earned by an event before a tool is allowed to claim it, read why your tracking says “100% complete” on a box that hasn’t sailed.