A Proof of Delivery You Can Edit Is Not Proof of Anything

A customer says four cartons arrived, not five. The driver says five. The proof is a photograph on a phone, a signature captured in an app that allows it to be re-taken, and a delivery note in a folder in a cab. Somebody in the office decides, usually in the customer's favour, because arguing costs more than the carton.

Three apparently separate complaints in a transport operation turn out to be the same complaint: delivery disputes that cannot be won, detention that is argued instead of invoiced, and trip costing that nobody can produce a number for. In each case the evidence existed at the moment it mattered and was not captured as evidence — it was captured as a convenience, editable afterwards, held on a device, attached to nothing. The remedy is not a better app. It is that the delivery record, the timestamps and the trip are system objects, immutable once written, and joined to the job that caused them.

Three things follow from it, and they are the rest of this piece: what immutable has to mean in practice, why the trip belongs in a record separate from the vehicle, and how waiting time becomes a line on an invoice instead of an argument.

The three properties a proof of delivery needs

All three are properties of the record rather than of the app that captures it, which is why buying a better driver app so rarely settles anything. They are also the point at which a transport operation stops being a service somebody performs and starts being a business with evidence behind it — the same shift the warehouse and the forwarding desk each have to make in an operation that stores, moves or clears other people's goods.

It survives no signal. A large share of deliveries in this region happen where coverage is poor — inside a warehouse, in a basement loading bay, on a site. A system that requires connectivity at the moment of delivery will be worked around: the driver will complete it in the car park afterwards, from memory, and the timestamp will be a lie of a few minutes that becomes a lie of an hour on a bad day. Capture has to work fully offline and replay exactly once on reconnect. The "exactly once" is not pedantry: replays that duplicate produce two delivery records for one delivery, and replays that drop produce none.

It cannot be altered afterwards. Not by the driver, not by the supervisor, not by the person handling the dispute. A correction is a new record carrying a reason and a reference to the original. This is the whole difference between a document and a piece of evidence, and it is the property that decides whether you can use it in a commercial conversation. An editable POD proves that somebody's phone had a photograph on it.

It is joined to the job. Not stored in a folder named by date, not sitting in a chat thread, not in the driver's gallery. Attached to the delivery, which is attached to the order, which is attached to the customer and the invoice. The test is whether a person in accounts, handling a short-payment three weeks later, can reach the evidence in one step without asking anyone. If the answer involves a WhatsApp search, you have the problem set out in what happens to a business that runs its approvals and its disputes through chat, with the added difficulty that the evidence is on a personal device belonging to somebody who may not work here next year.

The trip is not the vehicle

This one is a data-model decision and it quietly determines what the operation can do.

In a great many transport systems, the trip and the vehicle are the same record: a truck has a route, the route has stops, and the work is described in terms of the asset performing it. It is intuitive and it is a dead end. Two things become impossible or manual.

Consolidation. Several transport demands satisfied by one movement. If the demand does not exist independently of the vehicle, there is nothing to consolidate — there is only a route somebody built by hand and will rebuild by hand tomorrow.

Multi-leg. One demand satisfied by several movements, possibly by different vehicles, possibly with a transfer in between. If the demand is a property of a vehicle, the second leg is a new job with a new number and the link between them lives in a person's head.

Separate the two — a transport request that exists in its own right, and vehicles that are assigned to serve it — and both become ordinary rather than special. The same separation is what allows rating from a lane card, a data record the commercial team maintains, rather than from a formula in code that needs a developer every time a customer negotiates. That distinction matters more than it sounds: a pricing model that requires an engineer is a pricing model that gets bypassed in a spreadsheet, and then the spreadsheet is the system. It is also one of the structural arguments for running the warehouse, the fleet and the forwarding desk on one spine rather than in three packages that meet at month end.

Detention and demurrage become measurable or they do not exist

Waiting time is money in every direction: your truck waiting at a customer's dock, your container sitting beyond free time, a customer's vehicle waiting at yours. Almost nobody invoices it properly, and the reason is not commercial reluctance. It is that nobody has a defensible record of when the vehicle arrived and when it left.

The mechanism is unglamorous. Gate-in and gate-out timestamped by the system rather than written on a sheet. A dock appointment that is a real booking on a door that can physically take the load — which also refuses the double-booked door that put your own truck in a queue in the first place. Once those two exist, waiting time is a subtraction rather than an argument, and the conversation with the customer changes from "we were there a long time" to a figure with two timestamps behind it.

The same data closes the loop in the other direction. When your own operation is the cause — a door double-booked, a reefer load sent to a bay with no power, a load planned onto a vehicle that could not carry it — you find out from your own records rather than from the customer. That is worth more than the invoice, because it is the only version of the information that arrives in time to fix anything.

What a trip actually costs

With trips as records and timestamps as facts, the cost question becomes answerable:

• Fuel, driver hours, tolls, permits and maintenance apportioned to the trip rather than absorbed into a monthly fleet cost.
• The waiting time, valued, whether or not it was billable.
• The failed attempt and the redelivery, which in last-mile work is usually the difference between a profitable lane and an unprofitable one.
• Cash on delivery as a liability that posts when it is collected and clears when it is remitted — because cash in a driver's pocket that exists in no ledger is a control problem long before it is a costing problem.
• The return-to-origin policy firing exactly once, which sounds like a detail and is the difference between a clean cost and a recurring phantom.

Then the questions worth asking arrive by themselves: which customers consume disproportionate waiting time, which lanes lose money once attempts are counted, whether the third van is earning its keep. None of them are answerable from a monthly fleet cost divided by deliveries, which is what most operations have, and which flatters exactly the routes that are hurting you. It is the transport version of the same defect that makes a forwarding file's margin arrive after the file is closed: a number averaged across everything tells you about nothing in particular.

Where to start, and what to refuse

The order matters, and it is the same order we use when automating any operation: fix what is recorded before building anything on top of it. Start with the timestamps, because they are cheap and they change arguments into arithmetic. Gate-in and gate-out, and a dock appointment that cannot double-book. Then the POD, captured offline, immutable, joined to the job. Then trips as records separate from vehicles. Then costing on top of all three, which by that point is mostly configuration.

Two things to refuse along the way. Do not accept a proof-of-delivery module that permits editing with a permission, however senior the permission. An editable record is not evidence and adding an approver does not make it one; it only means the dispute becomes about who approved the edit. And do not accept "the driver will sync when he gets back" as an answer to the offline question — that is not offline capture, it is deferred typing, and the timestamps it produces are fiction with the authority of a system behind them.

Both of those are refusals we built into Logix rather than rules we ask anyone to remember. A control that depends on somebody declining to do the convenient thing, on a bad day, at the end of a shift, is not a control. It is a hope with a policy document attached, and the policy document is the part that survives the audit.