A claim arrives. Sometimes a tidy PDF from a broker, sometimes a photograph of a form taken at an angle on a car bonnet, sometimes an email with three attachments and the important detail in the body text. Somebody opens each one and types the same fifteen fields into a system.
Insurance document automation works well, and the accuracy you get depends far more on your documents than on the software. Anybody quoting a single accuracy figure without having seen your post is guessing, and the figure will be optimistic.
What insurance document automation can actually read
| What arrives | How well it reads | Note |
|---|---|---|
| A digital PDF from a broker or system | Very well. The text is already text, so this is structured reading rather than image recognition. | The easy case, and frequently the majority of volume. Worth separating out first. |
| A clean scan of a printed form | Well, once the layout is known. | Variation between versions of the same form is the usual complication, not the scanning. |
| A phone photograph of a form | Reasonably, with good lighting. Poorly at an angle, in shadow, or crumpled. | The most common real-world input and the most variable. Fixing capture beats fixing recognition. |
| Handwriting | Printed capitals, usually. Cursive, unreliably. Numbers, better than words. | Never trust a handwritten figure without review. This is where the expensive mistakes live. |
| Email body text | Well, and it is often forgotten. The claim detail is frequently in the message rather than the attachment. | Worth including deliberately, because a system that only reads attachments misses real information. |
The practical consequence is to sort your incoming post by type before quoting anything. A business whose volume is mostly the first row has a very different project from one drowning in photographs.
Per-field confidence, not document accuracy
The idea that makes these systems safe, and the thing to insist on.
A claim of ninety-five per cent accuracy sounds reassuring and tells you nothing useful, because it averages a policy number that was read perfectly with a claim amount that was a guess. What you want is a confidence score for every field, so the system can say it is certain about the date, fairly sure about the name, and unsure about the amount.
That changes what happens next. Instead of a person checking every document, or nobody checking any, the confident fields pass through and only the uncertain ones reach a human. The work shrinks to the part that genuinely needs judgement, and the system tells you where that is.
The review queue is the feature
Teams often treat the human review step as an admission that the automation is imperfect. It is the opposite: it is what makes the automation usable.
- Show the document and the extracted value side by side, with the relevant part highlighted. A reviewer confirming a figure should not be hunting for it.
- Order the queue by risk, not by arrival. A low-confidence figure on a large claim matters more than an uncertain postcode.
- Make accepting one keystroke. If confirming is slower than typing, the queue will be abandoned and everyone will go back to re-keying.
- Record every correction. These are the training data for improving the system and the evidence for whether it is getting better. A review step that does not capture corrections wastes its most valuable output.
- Track the correction rate per field over time. It tells you where to improve and when a document type has changed without anyone mentioning it.
Validate against what you already know
The cheapest accuracy improvement available, and it is not about the reading at all.
A policy number can be checked against your policy list. A claimant name can be matched to the policyholder. A date can be checked against the cover period. An amount can be checked against the sum insured. Every one of those turns a possible misreading into a caught error before anyone sees it.
This is ordinary engineering rather than anything clever, and it typically does more for real-world accuracy than changing the extraction model. It also catches genuine problems, such as a claim outside the cover period, which is useful regardless of how the document was read.
Fix the capture before the recognition
The cheapest improvement in this whole area is not in the software at all. If a large share of your documents arrive as poor photographs, the highest-return change is to stop receiving poor photographs.
- Give claimants a way to submit that guides the photograph. An upload page that frames the document, checks it is in focus and asks again if it is not will do more for accuracy than any model change, and it costs a fraction.
- Offer a form instead of a form. A meaningful proportion of people will type into a web form if given one, which removes the reading problem entirely for that share. Nobody prefers photographing a piece of paper.
- Ask brokers for the digital file rather than a scan of a print of a digital file. Frequently they have it and nobody has asked.
- Reject at the point of submission, not later. Telling someone their photograph is unreadable while they are still holding the document costs seconds. Telling them three days later costs a phone call and a delay.
- Separate the streams. Handle the tidy digital majority automatically and route the awkward minority to people deliberately, rather than treating everything as one queue.
Businesses that do this often find the remaining automation project is smaller than the one they were about to buy, because the difficult inputs have largely stopped arriving.
The part that is not about accuracy
You are handling other people's personal and often medical information, so a few things need answering before anything is built.
- Where does the document go to be read, and does it leave your control? Get the answer in writing, including whether anything is retained by a third party.
- How long do you keep the original? Longer than you need is a liability rather than a convenience.
- Who can see what, including support staff at any supplier, and can you prove it afterwards?
- What happens to a document that fails, since a failed queue quietly accumulating personal data in a folder nobody watches is a real exposure.
- Can you delete on request, everywhere, including copies made during processing?
None of these are exotic and all of them are cheaper to answer at the design stage. Our document intelligence work treats them as part of the build, and cloud security covers the wider question.
What it costs
| Scope | Build | Ongoing |
|---|---|---|
| One document type, extraction plus review queue | $25,000 to $60,000 | Per-page processing cost, plus review time |
| Several types, with validation against your records | $60,000 to $150,000 | The above, plus watching the correction rate |
| The above, feeding your claims system end to end | $120,000 and up | A permanent part of operations |
Illustrative ranges from the kind of work we quote, not a price list. The saving to compare against is handling time per claim multiplied by volume, and it should be measured before and after rather than estimated.
If most of the pain is moving the extracted data between systems rather than reading it, that is workflow automation and it is a cheaper project.
Not for you if
Before commissioning anything, do one exercise: take fifty real documents, including the worst ones, and count how many are the tidy digital case. That single number tells you more about what this project will cost and achieve than any demonstration, and it is the first thing we ask for, because a supplier who quotes without seeing your actual post is quoting for a business they have imagined.