Ask three operations coordinators which identifier they use to track a shipment, and you will get three different answers. Booking number, Bill of Lading, container number — every team has a default, and every default fails in different situations.
The reason has nothing to do with discipline or tooling. It is that each identifier represents a different layer of the shipment, becomes available at a different point in the lifecycle, and is treated differently by every carrier’s tracking systems. Choosing the wrong one is not a small inconvenience — it is the difference between catching a rollover before the customer notices and explaining to the customer why your ETA was wrong.
This guide is a phase-by-phase decision system, grounded in how the major carriers actually accept and publish identifier data — including the cases where carriers behave differently from each other.
What each identifier actually represents
Before phase logic, the three identifiers need clean definitions. They are not interchangeable, even when the same shipment has all three.
Booking number — the plan
The booking number is the carrier’s reference for an intended movement. It is created when space is reserved and exists before any container is assigned. It points to a planning record: the carrier, the service, the planned vessel and voyage, the cutoffs, the equipment commitment.
Because it represents a plan rather than a physical movement, it is the most volatile of the three. If the plan changes — a rollover to the next vessel, a service split, a rebooking — the booking number can change with it, depending on the carrier. DCSA explicitly classifies booking reference as optional in event outputs in the Track and Trace standard, which tells you something about its reliability as a long-term tracking key.
Bill of Lading (B/L) — the contract
The B/L is the transport contract. Once issued, it is the most stable shipment-level reference: it represents the legal commitment to carry specific cargo from origin to destination, and it persists through transshipment, vessel changes, and most operational disruptions.
Two complications matter operationally. First, the B/L does not exist until documentation is issued, which is typically after cargo loading and sometimes days after departure. Second, House B/L (issued by a forwarder to the shipper) and Master B/L (issued by the carrier to the forwarder) reference different parties — and only the Master B/L is recognized by the carrier’s tracking systems.
Container number — the equipment
The container number is the unique ISO 6346 identifier for a physical box: four-letter prefix, six digits, one check digit. It is the most granular identifier and the one tied to actual events — gate-in, loading, discharge, gate-out — because those events happen to physical equipment, not to bookings or documents.
Container numbers are stable once assigned, but they have two failure modes. They do not exist in the early phase of a booking, and they only represent what is true for that one box — which becomes a problem on multi-container shipments where containers can diverge across legs.
What major carriers accept on their tracking portals
The first place this gets practical is identifier acceptance. Most major carriers accept all three identifiers on their public tracking portals, but the user experience and the depth of information returned varies — and that affects which identifier you should reach for first when working with a given carrier.
| Carrier | Booking | B/L | Container | Notable |
|---|---|---|---|---|
| Maersk | ✅ | ✅ | ✅ | Public portal lists B/L and container; booking is supported via account login |
| MSC | ✅ | ✅ | ✅ | myMSC tracking accepts B/L, booking, or container number |
| CMA CGM | ✅ | ✅ | ✅ | All three on public tracking |
| Hapag-Lloyd | ✅ | ✅ | ✅ | “Tracing by Booking” returns all containers under that booking |
| ONE | ✅ | ✅ | ✅ | Cargo Tracking accepts all three |
| Evergreen | ✅ | ✅ | ✅ | All three supported |
| HMM | ✅ | ✅ | ✅ | All three supported |
| Yang Ming | ✅ | ✅ | ✅ | All three supported |
| ZIM | ✅ | ✅ | ✅ | All three supported |
| COSCO | ✅ | ✅ | ✅ | Not a DCSA member; uses proprietary event labels |
What separates carriers operationally is not whether they accept an identifier, but how complete the response is. Account-authenticated views generally return more milestones and reference cross-links than public lookups. For pre-loading visibility — when only a booking number exists — the public portal usually returns enough to confirm the booking and check cutoffs, but deeper detail (assigned containers, document status, schedule changes) often requires account access or an EDI feed.
DCSA Track and Trace adoption: who publishes which events
Beyond identifier acceptance, the second question is event coverage — what milestones each carrier actually publishes. The Digital Container Shipping Association (DCSA) Track and Trace standard defines a common event vocabulary across carriers (gate-in, load, discharge, transshipment, available for pick-up, gate-out, and others). DCSA member carriers have committed to implementing this standard, but at varying scope.
Per the DCSA Conformance dashboard as of 2026:
| Carrier | T&T standard implemented | Also implemented |
|---|---|---|
| MSC | T&T 1.2 and 2.2 | Operational Vessel Schedules 3.0, Commercial Schedules 1.0 |
| Maersk | T&T 2.2 | Booking 2.0 Beta, OVS 3.0 Beta, Bill of Lading 2.0 (Transport Document) |
| CMA CGM | T&T 2.1 and 2.2 | OVS 3.0, JIT Port Call 1.1, Commercial Schedules, B/L 2.0 |
| Hapag-Lloyd | T&T 2.2 + Reefer Events 1.0 Beta | JIT Port Call 1.1, OVS 3.0, B/L 3.0 Beta, Commercial Schedule 1.0 Beta |
| ONE | T&T 2.2 | OVS 3.0, B/L 3.0 (ISS), Commercial Schedule 1.0, Booking 2.0 Beta |
| Evergreen | T&T 2.2 | OVS 3.0, B/L 3.0 Beta (Shipping Instruction), Commercial Schedules 1.0 |
| HMM | T&T 2.2 | Booking 2.0, B/L 3.0 (full: SI, TD, Issuance, Surrender) |
| Yang Ming | T&T 2.2 | B/L 3.0 Beta, OVS 3.0 |
| ZIM | T&T 2.2 | OVS 3.0 |
| PIL | T&T 2.2 | — |
| COSCO, OOCL, Wan Hai | Not listed on DCSA conformance dashboard | Use carrier-specific event vocabularies |
This matters for identifier choice in two ways. First, carriers with full T&T 2.2 implementation publish a richer event stream — gate-in, load, transshipment legs, discharge, available for pick-up, gate-out — making container-level tracking more actionable on those carriers. Second, carriers with B/L 3.0 implementation (Hapag-Lloyd, ONE, HMM, with Yang Ming and Evergreen on Beta) treat the B/L as a first-class digital object, which tends to make B/L-based lookups more reliable on those carriers in our experience compared to carriers still on B/L 2.0 or no B/L standard.
For COSCO, OOCL, and Wan Hai, none of this applies — they are not currently listed on the DCSA conformance dashboard, and any tracking workflow has to handle their events as a separate normalization layer.
The phase-based decision logic
With identifier acceptance and event coverage established, the phase logic becomes concrete: which identifier is primary at each stage, and what to watch for.
Phase 1 — Pre-loading (booking confirmed, no container yet)
Primary: Booking number
Caveat: Public portal lookups are usually enough to confirm the booking, but deeper detail (container assignment, document status, schedule changes) typically requires account access or an EDI feed.
This is the cutoff-management phase: SI, VGM, gate-in deadlines, document readiness. The container has not been assigned yet, and the B/L does not exist. Booking is the only identifier that points to anything actionable. The risk in this phase is not tracking accuracy — it is missing a cutoff.
Phase 2 — Post-loading, B/L not yet issued
Primary: Container number (once assigned)
Secondary: Booking number
Caveat: If the booking has been rolled or rebooked, the booking reference may now point to an outdated plan.
This is a transitional phase that catches teams out. The container has been assigned and gate-in events are starting to flow, but the B/L has not been issued yet. Container number gives you the most reliable view of physical movement, and booking number is the fallback if you only have the planning reference.
The dead end here: continuing to track on booking after a rollover. If the carrier reissues the booking number on rollover (some do, some do not), your tracking will silently point to a stale plan. The fix is to refresh the container assignment list whenever you suspect a rollover, rather than trusting the booking reference to update.
Phase 3 — In-transit, B/L issued (the stable middle phase)
Primary: B/L (Master B/L) for shipment-level status
Secondary: Container number for granular events
Caveat: Multi-container shipments require all container numbers, not just one.
This is the longest and most stable phase. The B/L exists as a contract, the carrier publishes shipment-level milestones against it, and container-level events are accumulating against each box. For most operational questions (“is the shipment on track?”, “when does it arrive?”), B/L is the right reference. For granular questions (“which leg is the delay on?”, “did all containers transship together?”), container number is the right reference.
Carriers with B/L 3.0 implementation (Hapag-Lloyd, ONE, HMM, with Yang Ming and Evergreen on Beta) tend to give the cleanest B/L-level lookup experience based on our observed usage. For other carriers, the B/L is still functional as a tracking key, but expect the container-level data to be more reliable than the shipment-level abstraction.
Phase 4 — Transshipment leg
Primary: Container number(s)
Secondary: B/L for context
Why: Transshipment is where containers from the same B/L can diverge.
Transshipment is a substantial share of global container shipments and the phase where tracking data is most likely to go silent. Containers from the same B/L can be split across different connecting vessels. Tracking only the B/L will tell you “the shipment is in transshipment” without telling you which containers made the connection and which did not.
This is also where carrier event-naming becomes a problem. The same milestone label can mean different physical states across carriers — for example, “Vessel Arrival” is treated differently across carrier event taxonomies, which can cause apparent transshipment delays that are actually terminology mismatches. (For a carrier-by-carrier event label reference, see The Same Event, Twelve Different Names.)
Phase 5 — Arrival, discharge, and pickup
Primary: Container number
Secondary: B/L (for customer-facing status)
Caveat: Carriers vary in whether they publish a distinct “Available for Pick-up” event (DCSA code AVPU). Not all carriers expose this milestone, so for many shipments, discharge is the last carrier-reported event before terminal data takes over.
The bottleneck shifts from ocean transit to terminal handling: discharge, customs holds, release status, gate-out. These are container-level realities — the B/L tells you the cargo is at destination, but only the container number tells you whether it has gated out or is still sitting at the terminal accruing demurrage.
If you are managing demurrage and detention exposure, the discharge-to-gate-out window is where the money is, and that window is only visible at container level. Where the carrier does publish AVPU, you get an explicit availability signal; where it does not, you typically need terminal-level data or your forwarder’s pickup confirmation to fill the gap.
The decision matrix
| Situation | Primary identifier | Backup | Notes |
|---|---|---|---|
| Booking confirmed, no container yet | Booking | — | Account access or EDI gives deeper detail than public portal |
| Container assigned, B/L not issued | Container | Booking | Watch for booking changes on rollover |
| B/L issued, single-container shipment | B/L | Container | Cleaner B/L lookups on Hapag-Lloyd, ONE, HMM |
| B/L issued, multi-container shipment | All container numbers | B/L | Containers can diverge at transshipment |
| Suspected rollover or rebooking | Latest B/L | Container | Booking may point to old plan |
| Transshipment leg active | Container(s) | B/L | Watch for event-label differences across carriers |
| Approaching pickup window | Container | B/L | AVPU not published by all carriers |
| Customer-facing status update | B/L + state | Container detail if asked | Use shipment-level abstraction |
Three failure modes that are mostly about identifier choice
“We tracked by booking and lost the shipment”
Almost always: the booking was rolled or rebooked, and the carrier reissued the reference. The booking number you have now points to an obsolete record. The fix is to capture the B/L the moment it is issued and switch primary tracking to it, while keeping the booking number as a historical reference.
“B/L tracking returns nothing”
Three common causes. The B/L has not been issued yet (most likely if the shipment is recent). The reference being used is the House B/L, but the carrier portal needs the Master B/L. Or the format is wrong — most carriers expect a specific prefix or length, and partial references silently fail. Validating B/L format at intake catches most of these.
“Container tracking is fine but customer says shipment is delayed”
Multi-container shipment. The container being tracked arrived; another container on the same B/L did not. The customer is asking about the shipment, not about one box. The fix is structural: if the shipment has multiple containers, track all of them, and report at shipment level — “container 3 of 5 still in transshipment” rather than “shipment arrived” based on a partial signal.
Intake checklist for new shipments
Most identifier disputes can be eliminated by capturing the right fields at intake, before they become urgent. For each new shipment:
- Carrier and service (so identifier acceptance and DCSA implementation are known)
- Booking number (with the carrier’s reissuance behavior on rollover noted)
- House B/L and Master B/L (clearly labeled — the carrier needs Master)
- All container numbers, not just the first one
- Current phase (so primary identifier follows phase logic, not habit)
- Next expected milestone, with date — silence is only meaningful when something was expected
If your team manages tracking across more than three or four carriers, the intake checklist is also where you encode carrier-specific exceptions: which carriers reissue booking numbers on rollover, which use non-DCSA event labels, which publish AVPU and which do not.
If your team is reconciling identifier mappings and milestone events across multiple carriers manually, a 30-minute walkthrough of how this gets normalized in practice is usually faster than rebuilding the carrier-by-carrier logic from scratch.
What to tell customers
If a customer is confused why tracking looks incomplete or inconsistent, three plain explanations cover most cases without overcommitting:
- “Booking references reflect planned movements before the cargo is loaded. Once the B/L is issued, status updates become more stable.”
- “Different carriers publish events at different times and use different labels — we normalize that, but occasionally there is a gap when a carrier has not yet sent an update.”
- “For multi-container shipments, we track each container separately because they can diverge during transshipment.”
None of this requires the customer to understand DCSA or carrier portal differences. It just sets the right expectation: the data is structurally uneven, and the team is managing the unevenness.
Further reading
- DCSA — Track & Trace standards overview
- DCSA — Standard Conformance dashboard (carrier-by-carrier implementation)
- DCSA — How to Track Containers: A Comprehensive Guide
- Tradlinx — The Same Event, Twelve Different Names: How Ocean Carriers Label Container Milestones
- ISO 6346:2022 — Freight containers: Coding, identification and marking
Need help interpreting this disruption or your shipment?
For a quick question, chat with Tradlinx on WhatsApp. For a deeper discussion, book a time below.
Prefer email? Contact us directly at min.so@tradlinx.com (Americas), sondre.lyndon@tradlinx.com (Europe), or henry.jo@tradlinx.com (EMEA/Asia).
Leave a Reply