Somewhere in your business, a person is reading a number off a PDF and typing it into a system. Possibly hundreds of times a week. It is dull, it is error-prone, and it is the single most reliable place to get value out of AI — which is why it rarely makes the keynote.
Why this works better than most AI use cases
Three reasons, all boring and all decisive:
- The right answer exists. The invoice total is a fact on the page. Unlike "write a good email," you can measure correctness exactly.
- Errors are catchable. Totals should reconcile, dates should be plausible, a PO number should match an existing order. Validation rules catch most mistakes automatically.
- The savings are countable. Documents per month multiplied by minutes each. You can calculate the return before you commission anything.
What modern extraction can do
The current generation of models handles things that defeated older OCR-and-template systems:
- Layouts it has never seen. Traditional extraction needed a template per vendor. Modern models read a new supplier's invoice without one, which is what makes this viable for businesses with hundreds of suppliers.
- Tables and line items, including multi-page ones and awkward column structures.
- Handwriting, imperfectly but usefully — delivery notes, signed forms, annotations in a margin.
- Judgement calls. "Which of these three dates is the service date" is a question a template cannot answer and a model usually can.
What still causes trouble
- Bad scans. Skewed, low-resolution, or heavily compressed images degrade everything downstream. Fixing the capture process is often cheaper than compensating for it.
- Ambiguity that is genuinely ambiguous. If two humans would disagree about which number is the total, the model will too.
- Silent arithmetic. Never let the model sum a column. Extract the line items, then have ordinary code do the maths and check it against the stated total. A mismatch is a flag for review.
- Very long documents. A 200-page contract needs chunking and retrieval, not one pass. That is a bigger build.
Set the accuracy target honestly
Aim for the right shape rather than a fantasy number. In practice a good system:
- Extracts most documents correctly with no human involvement.
- Flags the rest for review, with the uncertain field highlighted and the source image beside it.
- Never silently guesses on a field it is unsure about.
The metric that matters is not raw accuracy — it is how much human time is left. A system that handles 80% cleanly and makes the remaining 20% fast to review can cut the workload by more than 80%, because reviewing a pre-filled form is much quicker than typing one.
Design the review step, not just the extraction
The half of this project that determines whether people actually use it is the screen where a human confirms an uncertain field. Get it wrong and staff will keep the old process running alongside the new one, which is worse than not building it.
Three things make the difference:
- Show the source image beside the extracted value, cropped to the region the value came from. A reviewer who has to open the original PDF separately is doing most of the original work.
- Pre-fill everything, flag only the uncertain. The reviewer's job should be confirming three fields, not checking twenty.
- Make corrections feed back. Every time a person fixes a field, that is a labelled example. Collect them; they become the evaluation set that tells you whether accuracy is improving or drifting.
Sizing the return
Count documents per month, multiply by minutes each, multiply by loaded hourly cost. Compare against a build in the range covered in our custom AI cost breakdown, plus running costs.
If you process a few hundred documents a month, the payback is usually comfortable inside a year. A few dozen, and it probably is not — and a vendor who will tell you that is worth keeping.
Where it goes once extracted
The extraction is half the project. The other half is getting the result into your accounting or line-of-business system reliably, with an audit trail and a sensible path for the exceptions. That integration work is usually the larger share of the build, and it is why this sits under application development rather than being a product you switch on.
Tell us what you are retyping and roughly how often — that is enough for a realistic estimate.