To reconcile conflicting delivery statuses, compare each expected parcel with an identified tracking source, then review the differences before changing the order. The last message received is not necessarily the latest event that occurred. A delivered parcel does not mean the entire order has been delivered.
This method is for a small business shipping products through an online store or ERP. Its output is a reviewable record: affected parcels, observed states, evidence, owner and next action. A spreadsheet can support the first check without rebuilding your integration.
When delivery statuses need reconciliation
A customer sees “in transit” while the carrier shows “delivered”. A two-parcel order appears complete after the first parcel arrives. An older event moves a shipment back to an earlier stage. These symptoms warrant investigation; none proves a system outage on its own.
Start with the available evidence: tracking history, parcel references, message receipt logs and processing results. Separate four cases: an event missing at the source, an existing event that was not received, a received event that was rejected, and a recorded state that is displayed incorrectly. Without those records, leave the cause unconfirmed.
Prepare access and a bounded scope
Gather an export of orders and quantities to ship, the shipment and parcel register, and read access to carrier tracking or the system designated as your reference. Include connector logs when available and an operations person who can confirm which parcels were actually prepared.
Existing exports and a spreadsheet you already use may avoid a new purchase for this exercise. API access, a connector, history retention or specialist support may still require a licence or additional spending. Check your agreement; this guide does not assume a universal price or completion time.
Choose a cut-off time, shipping period and carrier for the first check. Include older open shipments and known exceptions: looking only at today’s shipments would exclude parcels already stuck in the process. Use internal references in the working file instead of copying recipient addresses.
Create one row for each expected parcel
Connect the order to its items and quantities, then to shipments and parcels. Shopify, for example, permits multiple Fulfillment objects for an order, with related line items and tracking information. Check the actual relationships instead of assuming one order equals one parcel. Source: Shopify documentation, consulted November 3, 2026.
Use these fields for your reconciliation record:
- Order reference, internal shipment reference and internal parcel ID.
- Items and quantities covered, including quantities still to ship.
- Carrier, relevant account and tracking number retained as text.
- Each system’s raw status, source event time and time checked.
- Interpreted status, discrepancy, evidence reference, owner and decision.
Do not join records just because their tracking numbers look similar. Confirm the context and shipment relationship. If a number is missing, matches several records or is absent from the register, flag it for review rather than inventing a parcel.
An incomplete parcel register can produce a false conclusion: all known parcels may be delivered while an item was never shipped. Reconcile ordered, shipped, cancelled and outstanding quantities under your business rules as well.
Compare statuses with the same meaning
Keep the raw label before mapping it to your internal terminology. Adapt this working grid to your carrier and software:
| Observation | Meaning to preserve | Conclusion to avoid |
|---|---|---|
| Label created | Label created; physical preparation and carrier possession still need confirmation. | The parcel is already in the carrier’s network. |
| Ready at a pickup point | The recipient can collect the parcel. | The recipient has already collected it. |
| Delivered according to the carrier | Delivery reported for this parcel. | The entire order is delivered without checking its other parcels. |
| Exception, return or unknown state | Keep the reason and open a review. | Force the state into an ordinary progress stage. |
UPS distinguishes label information from carrier possession, and arrival at a pickup point from collection. Its tracking definitions explain its own statuses. Shopify also notes that a fulfilled order is not necessarily in transit or delivered. Source: Shopify order status pages.
A blanket “never move backwards” rule is unsuitable. A return or redirection can follow an advanced stage. Canada Post distinguishes these exceptions in its business tracking tools. The design recommendation is to preserve their meaning and history instead of assigning every status a simple numeric rank. A commercial return using new tracking should remain linked to a separate journey. Source: Intelligence 360 exceptions.
Reconcile read-only before deciding on corrections
- Capture the starting record. Save the values before correction and the time checked. If a system changes during the review, keep both observations; do not present readings taken at different times as a simultaneous snapshot.
- Confirm the parcel and reference source. Consult the authorized tracking source for that parcel. An unavailable source and a parcel with no observation are different outcomes. Neither automatically means “lost”.
- Check event order. For one parcel and a comparable source, use that source’s documented event time or version. Late receipt does not make an older event newer. Incomparable timestamps or conflicting states at the same time require review. Our guide to dates and time zones covers the conversion issues.
- Recognize repeated messages. Use the provider’s documented deduplication key. An identical repeat should not trigger a second action; conflicting contents under one identifier need investigation. Shopify distinguishes a webhook delivery identifier from the identifier of the merchant action. Neither is the parcel number. Source: verifying Shopify webhook deliveries.
- Classify each discrepancy. Useful categories include missing update, late older event, unknown code, ambiguous match and unavailable source. Assign an owner and a next review time based on the service commitment and operational context, not an arbitrary threshold.
- Correct only the approved scope. After review, use a correction or replay function supported by your tools. Retain the before-and-after values and reason. Recheck affected parcels and possible effects on notifications, inventory, invoicing and returns; reconciliation should not accidentally repeat those actions.
Webhooks report changes; they do not prove completeness. Shopify does not guarantee their order or delivery and recommends periodic reconciliation reads. Those reads complement message processing, with a frequency suited to your operations and API limits. Source: Shopify webhook behaviour. For the broader connector architecture, see our ERP and CRM integration guide.
Illustrative example: two parcels, one delivery
A fictional order has two expected parcels, P1 and P2, covering all ordered quantities. The source reports P1 delivered at noon and P2 in transit at 10 a.m. An earlier in-transit event for P1 arrives later, followed by a repeat of its delivery event. These times are comparable within the test dataset.
The expected result remains “partially delivered: 1 of 2 parcels”. P1 does not move back to in transit because an old message arrived later, and the duplicate does not count as a second delivered parcel. If P2 has no observation, the result becomes “incomplete coverage: review required”. If P2 is ready at a pickup point, collection remains outstanding.
This is a synthetic example, not a Services Hamdi client incident or result.
What was tested and how to verify your result
On November 3, 2026, a local Python 3.12.14 exercise completed 14 passing assertions using invented records and events: label creation, pickup readiness, out-of-order arrival, identical duplicate, partial delivery, missing observation, unknown code, simultaneous conflict, later return, unavailable source, ambiguous number, contextual matching, number absent from the register and conflicting reuse of an identifier.
The exercise calculates a proposed status read-only. It assumes a complete expected register and does not test a carrier API, webhook authentication, persistent storage, concurrency or notifications. Its invented fields are not a schema to paste into a real API. A carrier status also does not resolve a dispute about physical receipt.
For your own check, rerun reconciliation on the same captured inputs: the proposal should remain unchanged and create no new external action. Confirm separately that every expected parcel has one unambiguous match, outstanding quantities are explicit and exceptions remain visible. Across comparable checks, track unresolved discrepancies and their age. A decrease is meaningful only if scope and rules have stayed consistent. Add these cases to your user acceptance testing.
Checklist before closing a discrepancy
- The order, its quantities and every expected parcel have been reconciled.
- Raw states, sources and observation times are retained.
- Labels, pickup readiness, delivery and returns remain distinct.
- Repeats cause no second action; ambiguous records remain under review.
- The correction is bounded, recorded and checked in the affected systems.
If your team regularly reconciles these states by hand, our custom application and integration services in Canada can help define a manageable first workflow. An anonymized discrepancy record and a list of the systems involved provide a practical starting point.