A supplier sends you an invoice. It arrives in under a second.
Eight days later it is in your accounting system. Somewhere in between, it was a PDF in an inbox, a forwarded email, a printout on a desk, a line typed by hand, and a question about which job it belonged to.
Nothing about that week was anybody’s fault, and all of it was expensive.
The eight days, broken down
Trace one invoice backwards and the pattern is the same in nearly every business that has not deliberately fixed it.
- It lands in an inbox that is not a queue. Invoices arrive in the same place as newsletters, customer replies and internal chatter. There is no list of what is outstanding, so the only record of what has arrived is whether somebody remembers seeing it.
- It waits to be read by a person. Somebody opens the PDF and pulls out the supplier, the date, the total, the tax, the reference. Every one of those numbers is already written down. They get typed again.
- It waits to be coded. Which job? Which cost centre? That question frequently needs the person who ordered the thing, and that person is on site.
- It waits for approval. Someone has to say yes. The saying takes seconds; the getting-round-to-it takes days.
- It waits to be entered. The details get typed a second time, into the accounting system this time.
- Then somebody chases the ones that never arrived at all.
Six stops. And the last one is the one that should worry you most, because it is the only one with no evidence trail. An invoice that never arrived leaves no trace anywhere in your process.
What the delay actually costs
Three costs, and only one of them is obvious.
The typing. Count your invoices per month and multiply by an honest estimate of minutes each — reading, coding, entering, filing. Do that arithmetic with your own numbers and it usually lands somewhere between a day and a week of someone’s month.
The early-payment discounts you did not take. If any of your suppliers offer terms for paying early, an eight-day internal delay eats the window before anyone has decided anything. That is money left on a table nobody is looking at.
The picture being out of date. This is the one that matters. If invoices reach your books a week late, then every figure you look at is a week stale, and you are making decisions about cash on a picture of last Tuesday. Not wrong exactly — just always behind, in a way that is invisible because the numbers still look authoritative.
The document is messy, and that is the actual problem
Here is why this has stayed manual longer than most office work.
Every supplier’s invoice looks different. The total is in a different place, the tax is broken out differently, the reference number is called something else, and one supplier sends a photo of a docket taken at an angle. A human handles that variety without thinking about it. Software historically could not.
That has genuinely changed, and it is worth knowing what changed and what did not. Reading a messy document and pulling structured fields out of it is now something machines do well. Knowing whether the number it pulled is right is a different question, and that one still needs a person — which is exactly why the useful design is not “the computer does invoices” but “the computer does the reading and hands you the ones it is unsure about.”
What I learned typing other people’s numbers
I spent a stretch of my career as a database administrator and project manager, which meant a lot of hours reconciling records that disagreed with each other. Here is the part worth passing on, because it cost me time to learn.
The errors were almost never typos in the amount. People concentrate on the money. The errors were in the boring fields — the date, the reference, the job code — because attention had already been spent on the number that felt important. Then a month later something did not reconcile, and finding out why took an afternoon.
So if you are checking your own process, do not just spot-check totals. Check the fields nobody thinks are interesting. That is where the week you lose next quarter is being created right now.
Measure your own week
- Take twenty recent supplier invoices. For each, find the date the supplier issued it and the date it was entered into your books.
- Write the gap in days. Then look at the spread, not the average — the average hides the ones that took three weeks.
- For the three slowest, find where they sat. Inbox, desk, approval, entry. One stage will dominate.
- Count how many needed a question answered before they could be coded. That count is what a better intake step would collect at the door.
- Now the hard one: how would you know if an invoice never arrived? If the honest answer is that a supplier eventually calls, nothing in your process is watching for absence.
If your gap is one or two days across the board and nothing goes missing, you have a working process. Do not spend money on it. Go and measure something that is actually costing you.
What to do next
Measure the gap on twenty invoices this week. Look at the spread and find the stage that dominates — that stage is your whole problem, and it is usually smaller than the conversation around it.
If the reading step is where yours stalls, the honest comparison of document tools covers what machines do well and where a person is still required.
If you want the whole picture instead of one workflow: tell us what’s still manual. You get a map of every point where your business stops and waits for a person, what that costs you in hours, and which of those an engine would take over first. Free, yours to keep, and useful even if you never hire us — including on the days the honest answer is that you should not build anything yet.
Common questions
Can’t we just tell suppliers to send invoices to one dedicated address?
Yes, and do it — it is cheap and it helps. What it fixes is the arriving-in-the-wrong-place problem. What it does not fix is that the address is still an inbox rather than a queue: nothing is tracking which invoices are outstanding, which are waiting on a question, and which never came. A dedicated address is a good first move and a poor last one.
How accurate is automated reading of an invoice, honestly?
Good on clean documents and less good on photographed dockets, handwriting and unusual layouts — which is the correct way to think about it rather than as a single accuracy number. The design that matters is what happens when it is unsure. A system that gives you a confidence signal and routes the doubtful ones to a person is safe. One that quietly guesses and posts is not, and no accuracy figure makes that difference go away.
Our bookkeeper does this and does it well. Why change it?
Then the question is not quality, it is concentration and coverage. Ask what happens during the two weeks they are on leave, and ask how you would know today if an expected invoice never came. If both answers are comfortable, leave it alone. A good bookkeeper on a small volume is a genuinely fine answer.
What about approvals — doesn’t a machine approving payments sound risky?
It would be, which is why nothing here suggests it. Approving money is a decision that stays with a person, permanently. The work worth removing is everything that happens before the approval: reading the document, pulling the fields, matching it to a job, checking it against the order, and putting it in front of you complete. You approve. You just stop assembling.