Electronic proof of delivery: what counts as evidence
Electronic proof of delivery (ePOD) is the digital record, captured at the door, of what was handed over, to whom, when and in what condition. Moving proof from paper to a phone fixes lost paperwork, but it does not on its own make the evidence trustworthy. This guide explains what ePOD should capture, how capture works without signal, and how evidence becomes something a customer and an auditor will accept.
Updated · Kargentra product team
What electronic proof of delivery is
Electronic proof of delivery (ePOD) is a digital record, captured at the point of delivery, of what was handed over, to whom, when, where and in what condition. It replaces the signed paper delivery note, the traditional proof of delivery, with structured data, photos and a signature that reach the office as soon as the device has a connection.
The value of ePOD is not the signature on glass. It is that each delivery outcome becomes a fact the rest of the operation can use: customer service can answer "was it delivered?" without phoning the driver, the control tower can close a stop or raise a missing-POD risk, and finance can treat the movement as a candidate for billing. Paper does all of that days later, if the delivery note survives the cab.
Electronic POD differs from paper in speed, structure and accountability, not only in format. A scanned delivery note is still paper: it arrives late, it describes the stop rather than each unit, and nobody can tell who wrote on it or when.
The comparison matters most for fleets and carriers that deliver for several shippers, because each shipper asks for evidence in its own way. Carriers and fleets that capture structured evidence once can answer every customer from the same record instead of re-keying delivery notes.
Scroll sideways to see every column.
| Dimension | Paper delivery note | Electronic proof of delivery |
|---|---|---|
| Arrives in the office | When the driver returns, if it survives the cab | As soon as the device has a connection |
| Level of detail | Usually one signature per stop | Outcome per unit, with photos and reason codes |
| Link to the shipment | Matched by hand from a reference | Bound to the shipment, stop and delivery attempt |
| Who captured it | Unknown beyond a scrawled name | Signed-in driver on an enrolled device |
| Use in billing | Searched for when a customer disputes | One recorded condition for billing readiness |
What a proof of delivery should include
A proof of delivery should include enough detail for someone who was not there to decide whether the delivery happened as agreed. The minimum varies by contract and industry, but a defensible ePOD record carries the items below.
- The shipment and stop: references that tie the evidence to the exact shipment, stop and delivery attempt, and where relevant to the bill of lading the goods travelled under.
- Per-unit outcome: what happened to each unit or line (delivered, short, damaged or refused), not only a stop-level tick.
- Recipient: the name of the person who received the goods and, where required, their signature.
- Time and place: a device timestamp and position, labelled as observed rather than inferred. A position near the site supports the record; it never proves delivery on its own.
- Condition: photos of the goods, packaging and any damage, plus notes on anything unusual.
- Exceptions: refusal reasons, shortages and reattempt requirements, each with a reason code.
- Who captured it: the driver identity and the enrolled device that submitted it.
Arrival, delivery attempt, POD and completion are different events
Arrival, a delivery attempt, proof of delivery and completion are four separate events, and treating any two as one causes billing and service errors. A vehicle at the gate has arrived; a driver at the door has attempted delivery; captured evidence is proof of what happened; and completion follows only when that evidence has been accepted.
Scroll sideways to see every column.
| Event | What it proves | What it does not prove |
|---|---|---|
| Arrival | The vehicle reached the site | That anything was handed over |
| Delivery attempt | The driver tried to deliver | That the attempt succeeded or for which units |
| Proof of delivery captured | Evidence of the outcome exists | That the evidence is complete, legible or correct |
| Evidence accepted | Operations reviewed and accepted it | That the shipment is ready to bill |
| Billing ready | All commercial conditions are met | That the invoice has been issued or paid |
How ePOD capture works at the door
ePOD capture works as a short, guided sequence on the driver's phone that records outcomes before evidence, so the photos and signature always describe a known result. A well-designed proof of delivery app keeps the driver on one next action at a time rather than presenting a form.
- Arrive. The driver records arrival at the stop; the app shows the delivery window and what is on board for this stop.
- Record outcomes. The driver answers what happened at the door and what happened to each unit.
- Capture proof. Photos and the recipient's signature are captured against those outcomes.
- Send for review. The evidence is submitted to operations, bound to the current delivery attempt.
- Depart. The driver departs and the app moves to the next stop or the end of the run.
Offline capture and sync
ePOD must work without mobile signal, because loading bays, basements and rural sites are exactly where delivery happens. Does ePOD work without mobile signal? It should: the app queues each action on the phone and sends it when a connection returns, and the driver should never need to repeat a delivery because the network dropped.
Offline capture raises a harder problem than storage. While the phone was offline, the office may have changed the work: a stop reassigned, a window moved, a delivery cancelled. A sound design reconciles queued actions deterministically and tells the driver plainly when an answer is no longer valid, rather than silently applying it to changed work.
- Separate what is still waiting on the phone from what the server has confirmed.
- Let the driver retry or remove a queued action, with a clear explanation.
- Flag work that changed since the driver answered and ask again.
- Namespace the queue by company and device so a shared phone cannot leak another tenant's data.
Partial deliveries, refusals and failed attempts
Partial deliveries, refusals and failed attempts are where proof of delivery earns its keep, because they decide what is billed, what is returned and what is attempted again. A stop-level "delivered" tick hides all three.
Per-unit outcomes let the record say that eight pallets were delivered, one was refused as damaged and one was short. Each outcome then drives its own consequence: a return to process, a claim to open, a reattempt or a reschedule. A failed attempt should keep its own evidence, so the reattempt does not overwrite the record of why the first one failed. These distinctions flow straight into freight audit and billing readiness, where a redelivery or waiting charge needs this evidence behind it.
Who reviews proof of delivery before it counts
Proof of delivery should be reviewed and accepted by operations before it reaches the customer or counts towards billing. The driver's submission is evidence; acceptance is a decision.
Review should be quick for clean deliveries and deliberate for exceptions. A reviewer looking at a delivery with per-unit outcomes, legible photos and a named recipient can accept it in seconds; one with a refusal, a damage photo or a missing signature deserves a closer look and, often, a conversation with the driver or the customer on the shipment record.
Review catches the failures that capture cannot: a photo of the wrong pallet, an unreadable signature, a delivery recorded against the wrong stop. It also matters when carriers deliver on your behalf. A subcontracted carrier may file evidence through a portal or an integration rather than your driver app, and that evidence deserves the same review before your customer sees it. Once accepted, the evidence can be shared with the customer, attached to the shipment and used as one of the conditions for billing readiness.
Electronic signatures and evidential weight
An electronic signature is generally accepted as proof of delivery, but its weight depends on your contracts, the jurisdiction and how well the surrounding record shows who signed, when and on which device. This guide is not legal advice; check the requirements that apply to your trade lanes and customers.
Whatever the legal position, the same practices make electronic evidence stronger. Tie the driver to a real sign-in identity rather than a shared login. Enrol each device to the company so that its submissions can be verified and the device revoked if lost. Keep the evidence immutable once submitted, with an audit trail of review and acceptance. And bind the evidence to the delivery attempt it describes, so it cannot be reused for another stop.
Choosing POD software: an evaluation checklist
Choose POD software by testing the awkward deliveries, not the clean one in the demo. Ask the vendor to walk through a partial refusal at a site with no signal, followed by a reattempt the next day.
- Does the app record per-unit outcomes, or only a stop-level status?
- What happens to queued actions when the work changed while the phone was offline?
- Is evidence bound to a specific delivery attempt?
- Who accepts evidence before the customer sees it, and is that acceptance recorded?
- Can carriers that use their own systems supply evidence into the same record?
- Does the app work if the driver's company uses a different TMS?
How Kargentra handles electronic proof of delivery
Kargentra treats proof of delivery as governed evidence on the shipment record, captured by drivers or carriers and accepted by operations before anyone relies on it. In the Kargentra driver app, the cockpit shows the one thing that needs an answer now. At the door the driver answers What happened to each unit? and What happened at the door?, captures photo and signature proof, and chooses Send this proof for review. The POD is bound to the current delivery attempt, and failed attempts lead to reattempt or reschedule recovery.
Actions queue on the phone without signal. The Sync Center separates All, Needs attention, Waiting and Confirmed, and work that changed reads Changed since you answered, please answer again. Drivers sign in with a real identity, each phone is enrolled to the company with a securely stored signing key, and a lost phone can be revoked. The driver app also runs on its own beside an external TMS, receiving work through Connector Hub and returning signed, deduplicated stop events.
Carriers file delivery evidence as PDF, JPEG or PNG in the carrier portal, and it reaches the customer only after operations accepts it. Customers see delivery progress, delivery attempts and documents in the customer portal. If proof is missing past the tenant's threshold, the transportation management system opens a missing-POD case, and evidence complete is still not Billing Ready.