Series 3 — Solution · Paper 2
An Invoice
James runs a small architecture practice. Four people, project-based work, invoices that go out when a phase completes. He has been doing this for eleven years. In that time he has learned which clients pay promptly, which ones need a reminder, and which ones he quietly factors into his cash flow projections as a variable he cannot control.
His invoices go out as PDFs. They include his bank details — sort code, account number, a payment reference — and a payment term of thirty days. The average payment arrives in forty-seven.
He knows why. Paying an invoice requires the recipient to open their banking app, navigate to the transfer screen, type in the sort code and account number, add the reference, check the amount, and confirm. It is not difficult. It takes about three minutes. But three minutes of deliberate administrative action, for something that feels like someone else’s priority, is the kind of task that gets moved to later in the day, and then to tomorrow, and then to next week.
James has a template for the chasing email. He has refined it over the years to be firm without being awkward.
Six months ago James added a QR code to his invoices.
It sits in the corner of the PDF, alongside the bank details. When a client points their phone at it, their screen shows them: James’s practice name, the amount, the payment reference. Everything is already filled in. There is one thing left to do.
Sophie is James’s client. She receives his invoice on a Tuesday afternoon, opens it on her phone while she is waiting for a meeting to start, points her camera at the QR code, confirms with her fingerprint, and puts her phone away. The meeting starts.
James receives a notification before the meeting ends. Invoice settled. The amount, the reference, the time.
He does not send a chasing email. He does not follow up. He does not add Sophie to the column in his spreadsheet that tracks outstanding payments. Sophie is not in that spreadsheet at all.
What has happened underneath is straightforward. Sophie’s bank received an instruction to pay James’s practice the invoiced amount. It verified that Sophie authorised the instruction — the fingerprint confirmation — and moved the money. James’s account received the payment. Both of them have a record of the same transaction.
The difference from a conventional invoice payment is in how the request reached Sophie.
With a conventional invoice, Sophie would have opened her banking app, typed in the sort code and account number, added the reference, checked the amount, and confirmed. Three minutes of deliberate administrative action for something that felt like someone else’s priority.
With the QR code, the payment request already existed — created by James’s practice, sitting in the scheme, waiting. Sophie’s scan was the moment she approved it. Everything after that happened in the background while her meeting started.
James’s average payment time is now nineteen days. He has not sent a chasing email since April.
He still has the template. He has not deleted it because it took him a long time to get the wording right and he is not entirely confident he will never need it again. But it has been four months, and the clients who used to appear in the outstanding column of his spreadsheet are paying in the same week the invoice goes out.
The invoices themselves have not changed. The work has not changed. The payment terms have not changed. What changed is that the path from receiving an invoice to paying it became short enough that it happens when the invoice arrives, rather than when the recipient gets around to it.
Three minutes of deliberate administrative action became one tap at a convenient moment. That is the difference between forty-seven days and nineteen.