Why a parcel shows as delivered but the customer says otherwise

Check the proof of delivery, read the scan timeline, then decide whether to re-dispatch or open a carrier claim.

Last updated · Jul 28, 2026Orders & fulfilment

“Delivered” is a scan event, not a fact. It means a device recorded a delivery — by one of your drivers or by a carrier — at a time and a place. When a customer disputes it, your job is to find out what that scan actually captured before promising a refund or a re-dispatch.

Check the proof of delivery first

Open the shipment and go to the Delivery tab. Every completed stop stores the proof the driver app captured at the moment the stop was closed.

Open Shipments and search by tracking ID or customer name.

In the Delivery tab, check the photo — does it show the customer’s door, a neighbour’s, or a depot shelf?

Compare the GPS pin with the delivery address. A pin more than 50 m away is flagged automatically.

Check the signature or PIN if the service level required one.

NoteProof of delivery is retained for 180 days on all plans. Export it from the shipment page if the case may take longer.

Read the scan timeline

The timeline shows every status event with its source device. A delivery scan that arrives out of order — for example after the vehicle already left the area — usually means the driver’s phone synced late from offline mode, not that the events are wrong.

Scan events for shipment 4K-8829-DE — the delivery scan reached 4klyft 42 minutes after it was captured on the device.

If you consume these events over webhooks, the payload carries both timestamps: occurred_at is when the scan happened on the device; received_at is when it reached 4klyft.

json

{
  "event": "shipment.delivered",
  "shipment_id": "4K-8829-DE",
  "occurred_at": "2026-08-05T14:02:11+02:00",
  "received_at": "2026-08-05T14:44:37+02:00",
  "source": "driver_app/android-2.19.4",
  "pod": { "photo": true, "gps_distance_m": 340, "signature": null }
}

CautionAutomations keyed to received_at can fire out of order for drivers who work offline. Key customer notifications to occurred_at instead.

If the driver marked the stop too early

Drivers sometimes complete a stop from the van to keep the route moving. The GPS pin exposes this: it sits on the road, not at the door. Treat these as not delivered.

“A delivery scan without matching geolocation does not constitute proof of delivery for claim purposes.”
— Carrier SLA, section 7.2 — applies to all EU carrier partners

WarningReversing a delivery scan cannot be undone, and it notifies the customer immediately. Confirm with the driver before you reverse.

Re-sending customer notifications

After reversing, the shipment returns to “out for delivery” and re-enters today’s route as an unsequenced stop. The customer gets a corrected ETA the moment a dispatcher re-sequences it.

Good to knowReversed scans are excluded from the driver’s on-time score once you attach a reason code.

Escalating to the carrier

For carrier-injected shipments you can’t reverse the scan — you open a claim instead. 4klyft pre-fills the claim with the scan timeline and your proof-of-delivery export.

Claims must be opened within 14 days of the disputed scan for most EU carriers.

Attach the customer’s statement — a one-line email is enough.

Track claim status from the shipment’s Delivery tab; the webhook event claim.updated fires on every change.

The last three GPS fixes before the delivery scan — the pin sits 340 m from the delivery address.

If the claim is rejected and the customer still disputes, escalate to support with the shipment ID — we can pull the raw device log.

Was this helpful?

Splitting an order across two shipments Capturing proof of delivery offline Re-optimising a route mid-day

Still stuck?

An AI agent answers now; a human can join.