Most people assume invoice entry is slow because there's a lot of it. Some assume they're slow at it, which is usually unfair to themselves.
Neither is really the reason. The work has a few structural properties that make it resist being sped up, and none of them are about how fast anyone types. Worth understanding, because it explains why the obvious fixes don't help much.
It isn't the typing
Six fields off a simple invoice — supplier, date, reference, net, VAT, gross — is maybe thirty seconds of actual keystrokes.
But a straightforward invoice takes three to four minutes end to end. So somewhere north of eighty per cent of the time is going on something other than typing.
That something is retrieval and decisions. Finding the document, working out what it is, deciding how to code it, checking it, filing it. The typing is the one part of the job that's already fast.
This is why buying a better keyboard, or getting a second monitor, or hiring someone who types quickly, moves the number so little.
Every document is laid out differently
A bank statement import is fast because the format never changes. Column three is always the amount. Your eye stops going to column three after the first week.
Supplier invoices have no such standard. If you buy from two hundred suppliers you have something close to two hundred layouts. The invoice number is top-right on one, bottom-left on another, labelled "Document No." on a third. The VAT might be a column, a summary box, or a single line at the foot.
So you re-solve a small visual puzzle on every document. It's quick — a second or two per field — but it never gets quicker, because there's no repetition to get good at. The familiarity you build is per supplier, not per task, and it resets every time a supplier redesigns their template.
Half the information you need isn't on the page
The document tells you what was bought and what it cost. It doesn't tell you the things your ledger actually needs.
Which nominal account this belongs to. Which job or department to allocate it against. Whether this VAT is recoverable. Whether this supplier is on different terms. Whether the invoice relates to a delivery you've already accrued.
None of that is printed on the invoice. It comes from your own records, your own coding conventions, or your own memory. Each one is a lookup or a judgment, and judgments can't be rushed the way typing can.
For a supplier you've coded fifty times, this is instant. For a new one, it's a decision that might need someone else's input — and that's a decision that can stop the invoice for a day.
Most of the time goes on a minority of the documents
In most purchase ledgers the bulk of invoices are straightforward and a minority are awkward. The awkward ones are where the hours go.
The recurring shapes:
- Multi-line invoices that split across several nominal codes or VAT rates
- Photographs taken at an angle, in poor light, by someone on a site
- Statements mistaken for invoices, which double-count everything on them if entered
- Credit notes that need matching to an original you may not have entered yet
- Duplicates, where the same invoice arrived twice from two different addresses
- Foreign currency, needing a rate decision as well as a coding decision
Averaging across the whole pile hides this. If someone tells you invoices take three minutes each, that's an average over a set where many took ninety seconds and a few took twenty minutes. Planning against the average is what makes month-end overrun.
It can't be done at speed, because it can't be done wrong
This is the part that's least visible and probably matters most.
Invoice entry carries an asymmetry: entering something quickly and wrongly costs far more than entering it slowly and correctly. A miscoded invoice surfaces at reconciliation, or in the management accounts, or in a VAT return. A wrong bank detail surfaces as a payment to the wrong account.
So anyone doing this job carefully self-throttles. They double-check the total. They read the bank details twice. They stop and ask about the one they're unsure of.
That caution is correct — it's the job. But it puts a floor under the time per document that no amount of effort gets under, because going faster means being less sure, and being less sure is the thing you're being paid not to be.
It arrives continuously and gets done in gaps
Invoices don't turn up in one batch at a convenient moment. They arrive all week, in email, mixed in with everything else.
So the work is done in fragments — twenty minutes here, ten there — and each restart costs something. Finding your place, remembering the coding decision you made on the last one from that supplier, reopening the right screen.
Forty invoices in one sitting is meaningfully faster per invoice than eight a day across five days. Most people do the second, because the rest of the job doesn't stop.
What actually makes it faster
The fixes that work all attack retrieval or decisions, not typing:
Batching. One or two dedicated blocks a week beats picking at it daily. Fewer restarts, and you stay in the coding context.
Supplier defaults. If your system can remember the nominal code and VAT treatment per supplier, the decision only has to be made once. This is the single highest-value setting in most accounting packages and it's frequently unused.
Fixing it at source. A supplier who emails PDFs to one address is cheaper to process than one who posts paper or sends photos. Asking is free, and a surprising number will change.
Cutting the retrieval. Anything that means you aren't hunting through email threads for the attachment. A dedicated inbox that everything gets forwarded to costs nothing to set up.
Removing the re-keying entirely. If the values come off the document without anyone typing them, what's left is the checking and the coding — which is the part that needed a person anyway.
What doesn't help
Typing faster. It's under a fifth of the time.
Hiring someone junior for it. The typing transfers. The judgment doesn't, and the checking burden goes up rather than down, because now someone senior reviews the work.
Working later. Fatigue and cost asymmetry are a bad combination on exactly this task.
The honest version
Some of this time is irreducible. Coding decisions on unfamiliar suppliers need a person who knows the business. Checking bank details before payment is a control you want to keep. Anything promising to remove all of it is describing a different job.
The reducible part is the retrieval and the re-keying — which, on the numbers above, is most of it. That's worth going after. The rest is the work.
Cribble reads supplier documents as they arrive and posts the data into your ledger, so what's left is reviewing and coding rather than typing. It scores each field separately, so you know which values are worth a second look. Send us your three most awkward documents if you want to see how it handles them.