A supplier’s “completed” status does not necessarily prove that a dropshipping parcel has left the warehouse. Some systems use that label when an order is accepted, sent to picking, invoiced or exported to a carrier platform. Before telling the customer that an order is on its way, the store should identify exactly which event has occurred and whether there is independent evidence of a handover.
Separate order completion from physical dispatch
A useful order timeline has at least four milestones: supplier acceptance, goods packed, carrier label created and parcel handed to the carrier. A fifth milestone, the first carrier scan, may arrive later. These events are not interchangeable. If a supplier’s feed supplies only a single field called complete, ask for its definition rather than building delivery promises around the word.
For example, a supplier may have closed the warehouse task at 16:00, while the day’s collection happened at 15:30. The parcel could remain on site until the next collection. The gap between label creation and carrier acceptance is discussed in tracking created before the carrier receives a parcel, but a missing dispatch event can happen even before a label exists.
What evidence is useful?
Start with the supplier order identifier, the original store order, the affected items and the latest status timestamp. Then compare the information in three places: the supplier portal or API, the carrier’s tracking service, and the store’s own fulfilment record. Screenshots can help with a dispute, but consistent machine-readable event times are better for routine monitoring.
| Supplier says | What it proves | What it does not prove |
|---|---|---|
| Accepted | Supplier received an order instruction | Stock is packed or dispatched |
| Completed | Supplier finished a process it defines | Carrier has the parcel |
| Label created | A shipment reference exists | A parcel was collected |
| Carrier collected | Handover is recorded | Final delivery or arrival date |
A warehouse scan may be delayed, so one missing update should trigger investigation rather than an automatic fraud accusation. The store must still avoid showing an unverified “shipped” message.
Prevent customer emails from getting ahead of reality
Review what triggers the dispatch email in the webshop or integration. If the trigger is the supplier’s complete flag, the customer could receive tracking information before the goods are available to the carrier. Consider a distinction between “supplier processing”, “prepared for collection” and “dispatched”. Tell customers what is confirmed; avoid inventing a collection time or guaranteed arrival date.
When a supplier’s approval workflow already needs manual checks, a controlled queue is often safer than immediate automated fulfilment. setting up a supplier-approval queue explores how a supplier approval stage can be reflected in the store’s order workflow.
A practical escalation sequence
First, check the last successful API synchronisation and rule out a stale status cache. Second, ask the supplier for a handover manifest, collection scan or written confirmation of the dispatch date. Third, confirm whether all line items are in one parcel or whether the order is split. If the supplier cannot prove dispatch, request a realistic next update and define who will contact the carrier.
Keep your support team informed so they do not promise different dates across email, chat and the order page. If a second tracking number appears, link both records to the original order instead of overwriting the first. a change of tracking number after dispatch explains the consequences of changing tracking references after dispatch.
What if the customer wants to cancel?
The answer depends on whether the parcel has actually been handed over and on the applicable consumer rules and agreed order terms. Do not tell the customer cancellation is impossible just because the supplier system says “complete”. Equally, do not issue a replacement without checking whether the first parcel could still leave the warehouse. Obtain a definitive supplier instruction and keep the record of who confirmed the action.
A refunded order can also be dispatched if the supplier never processes the cancellation. The failure mode is examined in a refunded order that ships anyway and is a reason to maintain a separate acknowledgement for cancellation requests.
Prevent the problem from recurring
Define the meaning of each supplier status in an integration specification. Record the source system, UTC timestamp where supported, event identifier and raw message for each transition. Retry failed API calls safely, avoiding duplicate orders or emails. If a supplier cannot provide a reliable dispatch event, consider holding the store’s “shipped” status until the carrier confirms possession.
Measure the share of orders where complete precedes first carrier acceptance by an unusually long interval. The goal is not to blame the supplier for every gap, but to find whether status mapping, collection schedules or missing event feeds make delivery promises unreliable.
Is a tracking number proof of shipment?
No. A number may exist before the carrier receives the parcel. Check the carrier event and the supplier’s handover evidence.
Should every order be held until the first scan?
Not necessarily. A documented carrier collection or reliable warehouse handover may be sufficient for a dispatch update. The key is to distinguish evidence from an ambiguous administrative status.