The examples and architectures in this series are my personal educational, non-commercial experiments; they are not an offer of IT or consulting services.
An approval request is a message in a bottle, written in a very professional font. Post #17 ended on a document that nobody had confirmed. This post follows one of them.
The invoice below is a composite. The company, the supplier, the amounts and the days are invented and illustrative only. They don't describe a real company, supplier, process or system.
One invoice, three tools, no owner
A supplier invoice arrives by e-mail. Every field is right: amount, VAT, bank account, order number. Nothing in it is wrong, and it still sits for two weeks. Here is where it went.
| Step | Tool | What happened | What was missing |
|---|---|---|---|
| Receipt | Spreadsheet | Invoice logged | Nobody confirmed the goods arrived |
| Entry | ERP | Fields and order match | Nobody knew who confirms delivery |
| Reading | AI assistant | Fields read, cost centre found | It flags, it doesn't decide |
| Approval | ERP | Request sent to the cost centre owner | The owner is away, no deputy named |
| Payment run | ERP | Invoice not in the run | Nobody sees that it is waiting |
No step failed. The delay lives between the steps, and in this illustration it was found only when the supplier asked.
Illustrative composite from Post #18. The company, supplier, invoice and days are made-up and do not describe a specific company, process or system.
Five places where it gets lost
None of these is a software defect. They are places where one person or tool is supposed to hand something to the next, and nobody has written down who does it.
| Place | What often happens | Question to ask |
|---|---|---|
| Inputs | The invoice carries no delivery confirmation or cost centre, and nobody is asked for it | Who supplies what the invoice doesn't? |
| Completeness | Every field is filled, but nobody says whether anything is still missing | Who says "this is complete"? |
| Handoff | The request is sent. Sent is not read, and read is not decided | Who knows it was read? |
| Exceptions | The approver is away, or doesn't realise it is theirs | Who owns the silence? |
| Completion | It gets done, but the person waiting is not told | Who confirms, and to whom? |
Why more tools don't close the gap
Each tool does what it is set up to do. The spreadsheet records, the ERP routes, and an AI assistant can read the fields and point out whom a request is waiting on. None of them decides for the approver, and none of them knows that the approver is on holiday unless someone has told it.
Often the cheapest fix is a setting you already have: a named deputy, a deadline, a reminder in the system in use. It is worth checking what the ERP can already do before adding anything. What a setting cannot do is decide who owns the problem. That is a decision about responsibility, not a feature.
| What it looks like | What's actually true |
|---|---|
| The invoice is correct, so it will be paid | Correct is not confirmed. Payment waits for the confirmation |
| The system sent the request | Sent is not read, and read is not decided |
| We have an approval workflow | A workflow routes the request. Somebody still has to own the silence |
| Nobody made the invoice wait | Nobody decided it, which is exactly why nobody sees it |
The same pattern as in the earlier posts
Post #17 ended on a point that belongs here: margin is only as current as the slowest unconfirmed document. The invoice above is that document. The discount or the freight charge on it is missing from the report until someone confirms it.
Post #12 asked who should be chased first. This one asks who should have been asked in the first place. And Post #8 applies again: an alert that fires for every invoice older than two days teaches people to stop reading it. The deadline is a decision, and so is who gets the escalation.
What a handoff check has to contain
| Element | Why it matters |
|---|---|
| A named owner for every step, and a named deputy | Silence needs an address |
| A time limit, with escalation to a named person | Waiting doesn't turn into a habit |
| Visible status: waiting on whom, for how many days | What isn't visible doesn't exist |
| Exceptions with a reason (no delivery, wrong cost centre, dispute) | An exception without a reason can't be resolved |
| A person confirms that it is done | The check approves nothing and pays nothing |
Tools pass data along. Nobody passes responsibility unless someone has written it down.
A test you can run this week
Take the invoices that are still open ten days after receipt. For each one, write down the name of the person it is waiting on. The number of invoices where you can't name anyone is your figure.
There is no script behind this one either. It is a list and a name next to every line, and both are worth having before any tool is involved.
Follow the series
Post #19 looks at the one invoice change that can't be taken back: a supplier whose bank details changed, and why the check that matters happens before the payment, not after it.