Digitizing proof of delivery so waiting time and extra stops end up on the invoice

"The driver signed it off in the app. So why does the invoice only go out next week?" Ask that in a freight forwarding office and the answer usually starts with "because" and ends with a photo. The app covers your own trucks, not the subcontractor's. One big customer insists on its own stamped delivery note. The waiting time at the ramp lives in a voice message to dispatch. Digitizing proof of delivery therefore means more than dropping photos into a folder. Every proof has to be matched to the right order, somebody has to read what it actually says, and the charges that came up on the road have to be added before the invoice is written. That is a job for an agent.

The example below is made up. It shows how we would build such an agent and does not describe a client.

Digitizing proof of delivery at a forwarder with three kinds of proof

Picture a forwarder in the Rhineland running groupage and part loads with around 40 trucks of its own plus a dozen subcontractors, about 120 deliveries a day between them. The company's own drivers sign off in a driver app that reports arrival, departure and signature to the TMS. Subcontractors do not have the app and post a photo of the stamped consignment note into the driver chat. A few large customers insist on their own delivery note with a goods-in stamp, which the driver takes back and leaves in a tray at the depot. Waiting time, extra stops and pallet exchange reach dispatch by phone or voice message, when the driver remembers.

In the office, a clerk spends the next morning collecting proofs: app signatures in the TMS, photos in the chat, paper from the tray. For each one she looks up the order, checks that everything was signed for, and writes the invoice. What she cannot find stays open, and what nobody reported never makes it onto the invoice.

Our example delivery is stop 9 on a 14-stop route: six pallets of tiles to a tiling contractor, driven by a subcontractor, the shipper's delivery note stamped on receipt. The driver waits at the ramp from 10:05 to 11:50 because the customer's forklift is busy elsewhere. One pallet is accepted with the note "2 boxes damaged". Of four euro pallets due for exchange, the customer hands back two. At 12:10 the driver posts a crooked photo of the delivery note in the chat and a voice message: "Stood there almost two hours, and they only had two pallets to swap."

Six steps from photo to draft invoice

1. Every proof on one list

The agent collects everything that counts as proof during the day, from all three sources: app signatures through the TMS interface, photos and voice messages from the driver chat through its API or export, paper notes through the scanner at the depot, where dispatch empties the tray each evening. Voice messages are transcribed. Each proof starts on a list called "no order yet". App signatures are the easy case because they carry the order number. The photos are the reason the agent exists.

2. Which order does it belong to?

On the photo from stop 9 the agent reads the shipper's name, the delivery note number, the date, the tiling contractor's stamp and a handwritten remark. The forwarder's own order number is not on it, because the shipper does not print it. So the agent works the other way round. The driver who sent the photo drove one particular route today, and on that route there is exactly one stop with this consignee. Delivery note number and date match the order. The match is unambiguous and the proof is attached to the order.

A crooked photo with a corner missing is no obstacle to reading it. If the stamp is missing or the note number is unreadable, the agent drafts a message to the driver in the chat: "Stop 9, tiling contractor, please photograph the delivery note again, the stamp is not legible." Dispatch sees it and sends it, or has decided beforehand that messages like this may go out directly. A proof that could belong to two orders, for instance because the same consignee was delivered twice that day, stays on the list with a suggestion but no match.

3. What does the proof say?

A proof attached to the order does not yet mean the order can be invoiced. The agent checks that the quantity on the note matches the order, that a stamp or signature is present, and whether a reservation was written down. In the example, "2 boxes damaged" sits next to the third pallet. The agent sets the order to "signed with reservation" and passes the remark to claims handling. This does not block the invoice. A delivery with two damaged boxes is still a delivery. But the reservation is visible on the file, so the customer's complaint three days later surprises nobody.

4. Waiting time, extra stops, pallets

This is where the part of the invoice that most often goes missing today gets created. The agent has three sources for extra charges: the timestamps from the app for the company's own trucks, the driver reports in the chat, and the remarks on the proof itself.

For stop 9 there are no app times, because a subcontractor drove it. The voice message says "almost two hours", and the photo time of 12:10 together with the planned arrival at 10:00 fits. The agent looks up the customer's terms. The framework agreement with the shipper allows 30 minutes of free waiting time, then a rate per started half hour. The agent proposes waiting time for 1 hour 15 minutes and attaches the voice message as evidence. If the customer had no waiting time rate in the system, the agent would still create the line, flagged "rate missing", rather than guess an amount.

The pallet difference of two it reads from the remark on the delivery note and posts to the customer's pallet account, or as an invoice line, depending on what was agreed with that customer. An extra stop that dispatch gave the driver by phone in the morning appears in none of these sources. So at the end of the day the agent compares the route actually driven, from telematics, with the planned stops. A stop that was driven and belongs to no order goes on the list for dispatch. The agent cannot replace a human report here, but at least it asks.

5. The draft invoice

In the TMS invoicing module the agent creates the invoice as a draft: freight as per order, waiting time 1 hour 15 minutes, pallet difference. Every line notes where it came from, and the proof is attached as an image. Nothing goes to the customer yet. If the invoicing module has no draft status, a separate review list outside the TMS does the job. That is one of the things we settle before building.

6. Release

The clerk sees two lists in the morning. The first holds invoices where proof, quantity and terms all line up, on the example day roughly 110 of 120 deliveries. She goes through them and releases them. The second holds the flagged cases: the reservation at stop 9, two proofs still missing, three extra charges with no rate, one unexplained stop on a route. Those take her morning, and that is the work she was hired for. Released invoices go out the same day. The agent hands the posting data to the accounts system. What that removes from month end is covered in a separate article.

Subcontractors, in reverse

The same flow runs the other way for settling with subcontractors. Their proofs are already attached to the orders, and the agent drafts the credit note with the same lines: freight as agreed, waiting time the subcontractor is entitled to, pallet difference. Whether the two hours at the ramp really were two hours is still settled by a person. The person just settles it with a timestamp in hand.

What needs to be in place first

Three things we settle together before the agent is built. The terms, meaning waiting time rate, free time and pallet rule per customer, have to be in the TMS and not in the dispatcher's head. Driver reports need a channel that software can read, and a chat with an API or an export is enough. And the drivers themselves belong in the conversation, because the timestamps from app and telematics are their data. That goes on the table beforehand, with the works council where there is one, and with a clear rule on what the agent uses the data for and what it does not. We bring the data processing agreement.

Sophera Consulting builds this agent for a fixed price and without a subscription. Building it takes one to two days, and the test with your real proofs of delivery runs in the same week. Which of your proof channels holds up the most invoices is something we work out beforehand in the free automation check.

The recommendation

Start with the matching, not with the app. The temptation is to force every driver and subcontractor onto one app first and abolish paper. That drags on, fails at the one big customer with its stamp, and meanwhile the invoices keep waiting. An agent that takes photos, app signatures and paper as they come and matches them to the order moves the invoice run forward immediately. Let it create drafts only for the first few days, and count how many invoices are released unchanged and how often waiting time appears on an invoice where it never did before. The second number is revenue you have been giving away.