Every pitch for document automation leads with a time saving and never shows you the arithmetic. So here it is, including the part where it does not work, because that part is most of the market.
The honest sum
Take a document that needs a person to open it, read it, and type a handful of fields into another system. Insurance renewals, invoices, applications, loss runs, remittance advices — the shape is the same everywhere.
Three numbers decide everything, and you already know all three:
How long one takes. Time yourself on ten of them, right now, including finding the file and switching screens. Most people guess low by about half. Use the real figure.
How many per month.
What an hour of that person's time costs you — fully loaded, so salary plus employer costs, not the number on the payslip.
Multiply. That is the annual cost of the queue, and it is the only figure that matters, because it is the ceiling on what automation can be worth.
Now the other side of the ledger, which pitches tend to leave out:
Setup. Defining the fields, mapping them, handling the formats, connecting to wherever the data lands. This is the real cost and it is mostly one-off.
The parallel run. A few weeks where the machine extracts and a person still does the work, so you can compare. Skipping this is how people end up trusting a system nobody measured. It costs you nothing extra in labour — you were doing the work anyway — but it delays the saving.
Ongoing review. Automation does not go to zero. Low-confidence fields go to a person. Budget somewhere around a tenth of the original time, permanently, and be pleased if it comes in lower.
Maintenance. Carriers change their forms. A format you handled last year stops parsing. Someone has to notice and fix it, and "someone notices" is doing a lot of work in that sentence.
Set the annual saving against the setup, and you get a payback period. That is the whole decision.
So where is the line?
In my experience the honest threshold sits around a hundred documents a month, and I want to be precise about why rather than just asserting a number.
Below that, two things go wrong at once. The annual saving is small enough that setup takes a long time to pay back — and the volume is too low to teach you anything. You cannot tell whether extraction is reliable on a handful of documents a week, because the edge cases that break it arrive monthly. You end up with a system you cannot evaluate, attached to a saving you cannot feel.
Above it, the sum usually works, the error cases show up fast enough to fix, and the queue is genuinely somebody's job rather than an annoyance.
But the count is the weakest of the three tests. These matter more:
Is it somebody's job, or somebody's irritation? If removing the queue would visibly change how a person spends their week, you have a business case. If it would just make Tuesday nicer, you do not.
Do the documents repeat in shape? The same handful of senders and forms, recurring. Variation within a form is fine. Genuinely novel documents every time is a reading problem, and extraction does badly at reading problems.
Can you tell afterwards whether a field was right? If an error surfaces next week when something does not reconcile, good. If it surfaces in three years as a dispute nobody can reconstruct, the bar is much higher and the human review has to be real rather than a tick-box.
Miss any of those three and the document count does not rescue you.
The case against, stated properly
Here is what I would want to hear if I were buying, and rarely do.
Accuracy on a vendor's demo set is not accuracy on your documents. It is a different number, usually worse, and the gap is largest exactly where your documents are unusual — which is the reason you wanted help. The only honest figure comes from the parallel run on your own queue.
A confident wrong value costs more than a blank. A system that leaves a field empty creates visible work. A system that fills it with something plausible creates an error that surfaces later, at the worst moment, with no trace of where it came from. Insist on the first behaviour and treat a vendor's "high accuracy" as a non-answer until you know what happens to the rest.
You are taking on a dependency. Something new can break, and when it breaks the queue does not pause. Ask what the manual fallback is and make sure somebody still knows how to do the job.
The saving arrives slowly and the cost arrives immediately. Plan for that, and do not stake the business case on a saving in the first quarter.
None of this means don't. It means the sum should survive being done pessimistically.
What I would actually do
Pick the single highest-volume document type — one sender, one form. Not the queue. Run it in parallel for a few weeks and compare against the person doing it by hand. That comparison is cheap, it is the only real evidence, and it tells you the number no vendor can.
If it holds up, expand one document type at a time, keeping the confidence threshold high until you have earned the right to lower it.
If you want the sum checked rather than performed at you, an AI Reliability Audit is $2,500 and about a week — it is the right tool when you have already built or bought something and cannot answer how you would know if it were wrong. An LLM Integration Sprint, one production feature end to end in two to four weeks, starts from $7,500.
And if the arithmetic says wait, I will tell you that, which costs you nothing and saves you the setup.
Start cheaper than either: my website check is free and needs no signup. Worth a minute even when documents are the real problem, because a business losing enquiries at the front door has a cheaper fix available first.
Then the 30-minute Operations Audit, also free: bring the three numbers from the top of this post and I will do the sum with you, including the version where the answer is no. Get in touch.
