---
title: "Ghost shipments: labels created but never scanned by the courier, and how to find them"
description: "A ghost shipment is a parcel whose shipping label exists but which the courier never scanned at pickup, while the customer has already been told the order shipped. We find ghost shipments by asking the courier, not our own records, for the last event of every label older than a few days, treating a missing answer as a failed read rather than a status, and sending every case to a person instead of remaking labels automatically."
date: 2026-10-11
lang: en
canonical: https://goingstellar.ro/methods/ghost-shipments-labels-never-scanned/
author: Going Stellar
publisher: GOING STELLAR S.R.L.
topic: E-commerce / Shipping
license: CC BY 4.0
alternate_ro: https://goingstellar.ro/ro/metode/colete-fantoma-etichete-nescanate/
---

# Ghost shipments: labels created but never scanned by the courier, and how to find them

*A ghost shipment is a parcel whose shipping label exists but which the courier never scanned at pickup, while the customer has already been told the order shipped. We find ghost shipments by asking the courier, not our own records, for the last event of every label older than a few days, treating a missing answer as a failed read rather than a status, and sending every case to a person instead of remaking labels automatically.*

> E-commerce · Shipping · 2026-10-11 · https://goingstellar.ro/methods/ghost-shipments-labels-never-scanned/

## Key points

- A ghost shipment is a label that exists but was never scanned by the courier, while the customer has already received a shipping confirmation.
- Take a parcel's status from the courier's last tracking event, because order records and fulfilment dates cannot tell a parcel that left from one that did not.
- A tracking API that returns no answer for a parcel has failed to read it; retry the missing ones and report the rest as uncertain, never as not picked up.
- A label cancelled at the courier is often someone's decision, so it should go to customer service with context rather than be remade automatically.
- Once labels have been sent to a warehouse, any later cancellation leaves paper that looks valid; re-check every file already sent against the courier.

## What a ghost shipment is

A ghost shipment is a parcel whose shipping label was created, and usually printed, but which the courier never scanned at pickup. The order is marked shipped and the customer has received a "your order has shipped" email, while the parcel is still in the warehouse or was never packed. You find ghost shipments by asking the courier, not your own order records, for the last event of every label older than a few days, and treating "label registered, never scanned" as a ghost.

Ghost shipments produce the angriest "where is my order" tickets, because the customer has a shipping confirmation and a tracking page that does not move. Monitoring for delays in transit misses ghost shipments completely, since they never entered transit.

We look for two signals. The first is a label that exists, with the courier status "shipment data received" (registered, no physical scan), older than a threshold: our default is **3** days, and past **7** days the parcel is almost certainly forgotten and needs a reshipment or a refund with an apology, not just a message. The second is an order marked shipped with no label at all, so the customer has nothing to track.

## Step 1: take the parcel status from the courier, not from your records

Our order records could not tell a parcel that left from one that did not. We compared orders on the "not left" list with orders outside it, field by field, and every field was identical: aggregated status, shipment status, printed flag, waiting-since date, tracking number. One status sat on "waiting for courier" for hundreds of orders long after they had moved. Asked how many parcels had not left for one product, the stale mirror said **152**; the order system that polls the courier said **85**.

Two shortcuts give wrong answers. The date an order was marked fulfilled is when someone clicked, not when the parcel left. And a "not downloaded" print queue is a list of labels not yet printed: a label leaves that queue when it is downloaded, so the queue cannot say afterwards what physically left.

**Test the source with a known answer.** When we first checked whether courier tracking separated the two cases, we compared two labels that were in fact both unshipped and concluded that tracking did not help. The correct control is an old label you know was delivered. Ours came back delivered and proved the tracker worked. Also check how recently each label was polled; a status is only as fresh as its last poll.

## Step 2: a silent API is a read failure, not a status

We built a "what still needs printing" list by querying courier tracking in batches of **20**. For some labels the response simply did not contain the parcel, and our code stored an empty status and classified it as "no event", which means not picked up. The result was **36** labels for parcels that had already been delivered, in the file sent to the warehouse. A second query returned "delivered" for the same parcels.

The fix is to count what is missing. After every batch, compute requested minus received and retry only the missing labels, in smaller batches of **10**, for up to **4** rounds with a pause between them. With retries, **525** of **525** labels answered. Whatever still does not answer goes into a third category, *uncertain*, which is reported and never merged into "left" or "not left".

Empty text is not a status either. The first version of a queue for labels unshipped after **7** days returned 6,858 labels; 6,764 of them had an empty last-status text but a computed status of delivered. Check the derived state as well as the raw text.

## Step 3: compare label sets between systems

A ghost can also be a label that exists in one system and not in the other: our records hold a label number that the shipping-label integration does not have, or the integration holds a different, newer label for the same order. The test that works is set membership: the label number, with spaces removed, is not in the set of labels the integration holds. Three tests that do not work: a stored integration ID (ghosts had one too), comparing order names (the order existed in both), and the integration's "dispatched" flag, which gave 6,191 false positives.

Build the integration's label set by listing orders in date windows, then compare in memory, instead of looking up labels one by one. If listing fails for any store, emit nothing, because a partial set turns every missing label into a false ghost. On the first run about **1**% of candidates were ghosts, and the backlog reported was **162**.

**Cancel with a gate.** For a **30**-day backlog we found **291** suspects and **215** that could be cancelled after confirming with the courier that the parcel had never moved; none was older than **20** days. The sequence per order is: void the label at the courier, cancel the fulfilment, cancel the order without a refund when nothing was paid. The job cancels **2**, verifies them, and continues only if both succeeded. Verify the void through the courier's tracking, because the cancel call returned the same empty acknowledgement for a label that did not exist. After the backlog, alert only on new cases, once per label.

## What to do with a ghost shipment: route it to a person

Unshipped labels go back to the warehouse. Labels printed more than a day ago and still unscanned after **7** days return to the print queue as a separate station called "unshipped", split by the real warehouse station. Those rows are re-queried with the courier every **30** minutes, so a parcel that leaves drops out of the list.

A label cancelled at the courier is not remade automatically. When we announced a new label for **16** orders whose labels had been cancelled, the business owner stopped it: **13** of the **16** had been cancelled in the same minute, which is a decision by someone, not an expiry. These cases now go to a list and to the customer-service queue with the context. The outcomes are: never left and still valid, make a new label now; the customer asked to cancel, cancel the order; paid, or unclear, ask customer service a precise question. An order placed more than **7** days ago does not get a new label.

Split courier cancellations by when they happened. Of **101** tickets about labels cancelled at the courier, **73** were parcels stopped *after* pickup, which are effectively returns, and **27** were cancelled *before* pickup. Of those **27**, **4** were test orders and **23** were real orders, all of them printed. The first explanation offered was "those are test orders"; it covered **4** of **101**.

## Where we were wrong

**Dead labels in the warehouse.** We sent **56** labels to the warehouse, then cancelled and remade them in a content fix an hour later, and did not resend the replacements. The warehouse had **56** cancelled labels for a day; printed and stuck on, they would have shipped parcels on dead tracking numbers. Paper gives no sign that a label has died. Now we send only after the whole cancel-and-remake cycle is finished, announce any cancellation of a label already sent, and check the sent files by extracting the order numbers from them and asking the courier. On some labels the tracking number is printed with spaces, so normalise before matching.

**A deliberate "shipped without tracking".** Orders for products in a market test are marked fulfilled without a label on purpose. We read "fulfilled, no tracking, no label" as a defect, reversed **17** markings, and **12** orders received real labels before we had to reverse everything. All **17** of **17** had test products. The absence of a shipment does not tell you whether a shipment was expected. That detector now only reports.

**Cancelled orders reported as ghosts.** A label voided on an order that had itself been cancelled looked exactly like a ghost. The daily check now skips cancelled orders.

## Limits of the method

Finding a ghost does not find the parcel: a person still has to look in the warehouse. A parcel that the courier has already picked up cannot be cancelled through the courier's interface; it has to be stopped by the courier. A courier's cancellation record does not say who cancelled it, and for the **23** real orders cancelled before pickup we still do not know who did it. A label made outside the integration, by hand, will always show up as a ghost, which is a useful process signal but not a lost parcel.

## Checklist

**1. Ask the courier.** Use the last courier event, with its poll time, not the status in your own records.

**2. Count the missing answers.** Retry them, then report the rest as uncertain.

**3. Compare label sets.** Label number not in the integration's set, built completely or not at all.

**4. Route to a person.** No automatic new labels for cancelled ones; split before and after pickup.

**5. Check the paper.** Re-query the labels in every file already sent to the warehouse.

## Questions and answers

### What is a ghost shipment in e-commerce?

A ghost shipment is an order whose shipping label was created, and usually printed, but which the courier never scanned at pickup. The store shows the order as shipped and the customer has a shipping email, yet the parcel is still in the warehouse or was never packed. Ghost shipments cause angry where-is-my-order tickets and are missed by in-transit delay monitoring, because they never entered transit.

### How do I find parcels that were labelled but never picked up by the courier?

Query the courier's tracking for every label older than a few days and flag those whose only event is the label registration, with no physical scan. Do not rely on your own order status or the fulfilment date, which can be identical for parcels that left and parcels that did not. Retry labels the tracking API did not return, and check that each status was polled recently.

### Why does my tracking check show delivered parcels as not shipped?

Usually because a missing answer from the tracking API was stored as an empty status and read as no event. Batch tracking requests can silently omit some parcels. Compute requested minus received after every batch, retry the missing labels in smaller batches, and put whatever still does not answer into a separate uncertain category. Also check the derived delivery state, not only the raw status text.

### Should I automatically create a new label when the courier cancels one?

No. A cancellation at the courier is often a deliberate decision about stock, the customer or the product, and several cancellations in the same minute are a strong sign of that. Send the order to customer service with context. Make a new label only when the parcel never left and the order is still valid, cancel when the customer asked to, and do not relabel old orders.

### How do I cancel ghost shipments safely?

Void the label at the courier, then cancel the fulfilment, then cancel the order without a refund if nothing was paid. Run the first few cancellations, verify them, and continue only if they succeeded. Confirm each void through the courier's tracking, because a cancel call can return the same empty acknowledgement for a label that does not exist. Never cancel a parcel the courier has already scanned.

## How to cite

**Cite this as:** Going Stellar (2026). *Ghost shipments: labels created but never scanned by the courier, and how to find them*. GOING STELLAR S.R.L.. https://goingstellar.ro/methods/ghost-shipments-labels-never-scanned/

```bibtex
@misc{goingstellar2026ghost,
  title  = {Ghost shipments: labels created but never scanned by the courier, and how to find them},
  author = {{Going Stellar}},
  year   = {2026},
  url    = {https://goingstellar.ro/methods/ghost-shipments-labels-never-scanned/},
  note   = {2026-10-11}
}
```

Licence. Free to quote with attribution.

## Also available

- This page as HTML: https://goingstellar.ro/methods/ghost-shipments-labels-never-scanned/
- Same article in Romanian: https://goingstellar.ro/ro/metode/colete-fantoma-etichete-nescanate/