Tracking statuses and what they do not tell you

Tracking data is the most visible part of any courier integration and the least standardised. Each carrier defines its own statuses, updates them at its own granularity, and means slightly different things by the same words.

For customer communication that is tolerable. For anything operational — detecting failures, triggering follow-ups, recognising revenue — it needs normalising first.

What varies between carriers

Vocabulary. In transit, on the way, in progress, processing at facility. Different words for states that may or may not be equivalent.

Granularity. One carrier reports every facility scan; another reports collected and then delivered with nothing between. Both are valid and they support completely different processes.

Timing. Some update in near real time; some in batches, so a status change can be hours behind the physical event.

What delivered means. Handed to the recipient, left at a guard house, dropped at an access point, or signed for by someone else. All reported as delivered, all meaning different things if a dispute follows.

Failure detail. Some carriers explain why an attempt failed — nobody home, address not found, refused. Others report only that it failed, which removes the information you most need — see failed deliveries and what they cost.

That last difference is worth weighing when choosing carriers, because the presence of a reason code is what turns failures from a cost into something you can reduce.

Normalise to your own states

The design principle: never let a carrier's vocabulary reach your business logic.

Define a small set of internal states that mean something to your operation, and map each carrier's statuses onto them.

Created — consignment booked, parcel not yet collected.

Collected — with the carrier.

In transit — moving, with whatever detail the carrier provides.

Out for delivery — final leg, if the carrier reports it.

Delivered — with a note of the delivery type where available.

Attempt failed — with a reason where available.

Returning — coming back to you.

Exception — anything that does not map, which is a category that must exist.

Then your processes react to your states. Adding a carrier means writing a mapping rather than changing your logic, and a carrier renaming a status breaks the mapping rather than the business — see what a courier API actually gives you.

The statuses worth acting on

Most tracking updates need no action. Four do.

Attempt failed. Act the same day. A parcel that failed once is recoverable while it is still local, and the window closes when it starts travelling back.

Returning. Expect stock and expect a return-to-sender charge on the next invoice. Also a refund decision.

Delivered, on a cash-on-delivery order. Money has been collected and is now owed to you by the carrier. This is the point the receivable starts ageing — see cash on delivery remittance and your cash.

Nothing at all for too long. The most useful signal in tracking and the one nobody builds. A parcel with no status change for longer than normal is stuck or lost, and it is invisible unless something is watching for silence rather than for events.

That fourth one deserves emphasis. Systems are built to react to events, so a parcel that stops generating events generates no reaction. Ageing consignments by their last status change is a few lines of logic and it finds lost parcels weeks before a customer complaint does.

Where tracking is not evidence

Two situations where the status is insufficient and something else is needed.

A delivery dispute. A customer says the parcel never arrived; tracking says delivered. Neither is necessarily lying — it may have been left at a guard house, taken by a neighbour, or delivered to a similar address. What resolves it is proof of delivery: a signature, a photograph, a recipient name. Whether your carrier provides it, and whether your integration stores it, decides whether you can answer the question — see courier claims for lost and damaged parcels.

Revenue recognition. Delivered is a courier's assertion, not an accounting event you should depend on for anything material. It is useful information and it is not proof. Where the distinction matters — high-value goods, disputed orders — proof of delivery is what you need on file.

What to store

Not just the current status. The history.

Every status change with its timestamp, the carrier's own wording alongside your normalised state, and any proof-of-delivery detail the carrier provides.

Three reasons this matters. A dispute months later needs the full sequence, not the final state. Delivery time by carrier and region can only be measured from the history — see choosing couriers by destination. And when a carrier changes its status vocabulary, having the original wording stored lets you correct a mapping retrospectively rather than losing the period.

Storage is cheap. A tracking history you did not keep cannot be reconstructed, because the carrier's own retention is finite and outside your control.

Common questions

Why do courier tracking statuses need normalising?

Because every carrier defines its own vocabulary, reports at its own granularity, updates on its own timing, and means different things by the same words — delivered can mean handed to the recipient, left at a guard house or dropped at an access point. Business logic built on raw statuses breaks whenever a carrier is added or renames something.

Which tracking statuses should trigger action?

A failed attempt, which is recoverable the same day while the parcel is still local; a returning parcel, which means incoming stock, a return charge and a refund decision; delivered on a cash-on-delivery order, which starts a receivable from the carrier; and no status change for longer than normal, which usually means the parcel is stuck or lost.

What is the most overlooked tracking signal?

Silence. Systems are built to react to events, so a parcel that stops generating updates generates no reaction. Ageing consignments by the time since their last status change is simple to implement and finds stuck or lost parcels weeks before a customer complaint does.

Is a delivered status proof of delivery?

No. It is the carrier's assertion, and it is useful information rather than evidence. Where a customer disputes receipt or the goods are high in value, what resolves it is proof of delivery — a signature, photograph or recipient name — which means checking whether your carrier provides it and whether your integration actually stores it.

Related: what a courier API actually gives you · failed deliveries and what they cost · courier claims for lost and damaged parcels