Four things on one piece of paper #
A delivery note is usually asked to do four jobs at once, and it does some of them badly.
-
That the goods arrived
The claim the customer is disputing.
-
When they arrived
The fact that decides invoicing and, in some cases, when payment becomes late.
-
What arrived, in what condition
The fact that decides whether a credit is owed.
-
That somebody with authority accepted them
The weakest link, because deliveries are signed for by whoever is nearest the door.
Why the request always comes late #
Nobody asks for a POD on the day. They ask when an invoice is queried, and invoices are queried when a customer's own approval process cannot match three documents: their purchase order, their goods received note and your invoice. Their goods received note was written by the same kind of person, at the same kind of moment, with the same kind of care as your delivery note.
So the request arrives at your credit controller, weeks after the event, phrased as a question about paperwork but functioning as a delay. Every day spent finding the document is a day the invoice is not paid, which is why POD chasing and credit control are really one job rather than two.
The dates that carry weight #
Two published rules make the delivery date more load bearing than it looks.
GOV.UK states that where nothing else has been agreed, payment is late 30 days after either the customer gets the invoice or you deliver the goods, whichever is later. So the delivery date is one of the two facts that starts the clock on statutory interest.
If your own record of that date is a signature with no time on it, or a note keyed in from a driver's recollection on Monday morning, the clock you are relying on is approximate.
Separately, an invoice must show the date the goods or service were provided, the supply date, alongside the invoice date. When the delivery record and the invoice disagree about when something was supplied, the customer has found a reason to hold the payment that costs them nothing to use.
What short delivery does to the record #
Section 30 of the Sale of Goods Act 1979 deals with delivery of the wrong quantity. If the seller delivers less than contracted, the buyer may reject the goods, but if they accept them they must pay for what was delivered at the contract rate.
The practical consequence is that the delivery record has to establish quantity, not just arrival, because the quantity accepted is what is payable.
Which parts run on rules #
Runs on rules
- Capturing a delivery record at the point of delivery
- Stamping it with a date and time nobody had to remember
- Filing it against the order and the invoice
- Finding a specific POD from a customer reference or a date range
- Sending it back in the format the customer asked for
- Noticing that one customer requests PODs far more than the rest
Finding one is a search, and searches are cheap.
Needs a person
- Deciding whether a disputed delivery is worth arguing about
- Judging whether a repeat requester is stalling rather than checking
- Deciding what to do about a driver whose paperwork is always thin
The number that tells you most #
Count POD requests for a month, by customer. Then look at the shape of the list.
A spread of single requests across many accounts is a records problem, and the fix is in how deliveries are captured.
A concentration of requests in two or three accounts is not a records problem at all. It is a payment behaviour problem wearing a records costume, and no improvement to your paperwork will change it.
HMRC guidance requires business records for VAT purposes to be kept generally for at least six years, so the volume is not going to shrink. The chasing payment tool puts a cost on the days lost while a POD is being found, and the depot inbox page covers what happens to these requests when they land in the same stream as everything else.