Electronic Proof of Delivery: Photos, Signatures and Codes

What ePOD is and why it matters

Electronic Proof of Delivery (ePOD) is digital confirmation that goods were handed to the recipient. Instead of a signed paper note, the driver records the handover in a mobile app, and the system stores the evidence together with time, location and order contents.

What it changes for the business:

• the "delivered" status appears instantly, not when the driver brings paperwork back;
• disputes with customers are settled with photos and signatures, not memory;
• closing documents and invoices can be issued the same day;
• paper notes stop getting lost.

Confirmation methods

In practice, methods are combined: for example, piece scan + signature + photo for B2B and code + photo for courier delivery. Set the rule by customer type and cargo value rather than one rule for the whole company.

The driver app workflow

A typical flow at a stop:

1. The driver opens the job — address, contact, order lines, required confirmation methods.
2. The app checks that the driver is inside the address geofence and warns if not.
3. The driver scans pieces or ticks off lines.
4. Collects evidence: signature with the recipient's name, photos, code.
5. Picks the outcome: delivered in full, partially, or refused.
6. Data goes to the server; without a connection it is stored and sent later.

Key technical requirements:

• Offline mode. Warehouses, basements and highways often lack coverage. The app should store confirmations locally with the original timestamp and send them from a queue.
• Tamper resistance. Photos from the camera only, not the gallery; time and order number stamped on the image; device time checked against server time on sync.
• Photo compression. Full-size images quickly eat data and storage — a resolution where the label is readable is enough.

Refusals and partial deliveries

This is where paper processes break most often. Build into the app:

• A list of refusal reasons: not home, goods rejected, damaged, wrong items, wrong address. Free text only as a supplement.
• Line-level confirmation: the accepted quantity per line. The remainder automatically becomes a return.
• Mandatory photos for damage or broken packaging.
• Recipient signature on the discrepancy, so both sides acknowledge the record.
• Re-delivery: for "not home", the order goes back to the dispatcher for rescheduling instead of sitting in "in transit".

Returns should appear in the warehouse system as expected inbound stock right away — otherwise goods are physically back but missing on the books.

Syncing with accounting and CRM

ePOD pays off only when a confirmation moves processes forward.

• Accounting / ERP: on delivery, a sales document or an adjustment for the accepted quantity is created; returns get a separate document.
• CRM: the account manager sees status, photos and signature on the customer record; a refusal creates a follow-up task.
• Customer notifications: a link to the confirmation via SMS or messenger.
• Storage: evidence lives in object storage; accounting receives links, not files.

Build the exchange on events (webhooks or a message queue) with idempotency: resending the same confirmation over a bad connection must not create a second document.

Common mistakes

• Introducing signatures only and ignoring refusals.
• Not enforcing photo rules — images end up blurry or without the goods.
• Ignoring offline use, which pushes drivers back to paper.
• Passing data to accounting by hand, keeping the same time gap.