Batching means handling invoices in groups rather than one at a time — sitting down to a stack on a Thursday rather than dealing with each as it lands.
It's usually described as a best practice. It's really a trade, and it's worth knowing which side of it you're on.
What batching genuinely buys you
Setup costs are paid once. Opening the software, getting into the coding context, remembering this supplier's quirks. Per invoice, that overhead shrinks the more you do in one sitting.
Fewer context switches. Invoice entry done in fragments across the week is slower per document than the same volume in one block, and it's more error-prone at the restarts.
Consistency. Coding decisions made in one session tend to agree with each other. Made across three weeks, they drift.
Payment runs. Genuinely more efficient in batch — one approval, one bank file, one reconciliation, and often lower transaction fees.
Forty invoices in one sitting really is faster than eight a day for five days. That part is true.
What it costs
Delay, and it's the largest queue in most AP processes.
An invoice arriving the day after a weekly session waits six days before anyone looks at it. With monthly entry, an average of about two weeks. During that time it isn't late, isn't overdue, and isn't on any report — because as far as the ledger is concerned it doesn't exist.
That's also where invoices go missing rather than merely being slow. An invoice that has become a record can be late or queried. It can't be lost, because something is counting it.
And under accruals accounting, an unentered invoice is a reporting problem rather than a filing one. If it belongs to March and you're entering March's post in late April, March's accounts were wrong until you got to it.
The distinction that resolves it
Batch the parts that benefit. Don't batch the part that doesn't.
Capture should happen on arrival. It's the stage with the biggest queue and the least benefit from grouping — reading a document doesn't get meaningfully cheaper because you read twenty in a row.
Coding and review batch well. They need context and judgement, and holding that context across a session is a real saving.
Approval shouldn't be batched at all. It's someone else's queue, and holding invoices back to send them in a weekly bundle just adds your delay to theirs.
Payment should be batched. This is the one where batching is straightforwardly correct.
The common setup — capture, code, approve and pay all in one monthly session — batches the three stages that shouldn't be for the sake of the one that should.
Choosing a rhythm
If you're going to batch capture anyway, the frequency is a straight trade between your time and the delay:
| Frequency | Average wait before entry | Suits |
|---|---|---|
| On arrival | Under a day | Any volume, if capture is cheap |
| Twice weekly | ~2 days | Most small businesses |
| Weekly | ~3.5 days | Low volume, stable suppliers |
| Monthly | ~2 weeks | Very low volume only |
Monthly entry is the one worth arguing with. It makes month-end close longer, makes the aged report wrong for most of the month, and is where nearly all lost invoices come from.
A note on "batch processing" in software
The phrase means something different in a product context — uploading a folder of documents to be processed together, rather than a human sitting down to a stack.
Worth separating, because software batch processing removes the capture cost without adding delay, which is exactly the combination the trade above says you want. If reading a document costs nothing, there's no reason to hold it back.
Cribble reads documents as they arrive rather than in a session, so capture stops being the thing that has to be batched. What's left — coding decisions and review — is the part that genuinely benefits from being done in one go.