Claims Document Intake at a Regional Insurer
An example project: an insurer turns 2,500 incoming claim documents a day into validated records in its claims system, with an open model on one dedicated GPU and people reviewing only the documents that fail checks.
This is an example project, not a customer story. The company is made up, and every number on this page is an assumption stated so you can replace it with your own.
Document intake costs about $676,000 a year less, and the build pays back in about two months
Build cost assumes engineers at $180,000 a year fully loaded. Time from other staff, such as reviewers labeling examples, is not counted. Payback is counted from go-live. See the arithmetic.
Twenty people retyping documents into the claims system
A regional property and casualty insurer handles about 70,000 claims a year. Each claim collects around nine documents: repair estimates, contractor invoices, police reports, medical bills and letters. That is roughly 2,500 documents every business day.
Today an indexing team of about 20 people, partly outsourced, opens each document, decides what it is, and types the key fields into the claims system: claim number, document date, amounts, payee, and line items for estimates and invoices. It takes about four minutes per document. When volume spikes after a storm, the backlog grows to two days, and adjusters work claims without the latest paperwork.
The goal is to have every document classified and its fields in the claims system within 15 minutes of arrival, and to move the indexing team from typing to reviewing.
A pipeline with the model in two steps
The model classifies and extracts. Everything around it is ordinary code the insurer already knows how to run.
Text extraction
existing OCRScans and PDFs go through the OCR tool the insurer already uses. The output is page text with layout. This step is not served on the endpoint.
Classify the document
model, first page onlyThe model reads the first page and picks one of seven document types, or other. Each type has its own schema, so this decides what to extract next.
Extract fields to a schema
model, whole documentThe model receives the full text and the JSON schema for that document type, and returns one JSON object. Output is constrained to the schema, so it always parses.
Validate in code
insurer's codeChecks the model cannot be trusted to do: line items add up to the total, the claim number exists and the policy was active on the loss date, the payee matches a known vendor, dates are not in the future.
Route
insurer's codeDocuments that pass go straight into the claims system. Documents that fail any check go to the review queue with the extracted fields already filled in, so the reviewer corrects them instead of typing from scratch.
This workload needs one GPU
The arithmetic we would start from. Profiling on real traffic replaces these estimates before anything goes into a contract.
| Documents per business day | 2,500 |
|---|---|
| Input tokens per document (three pages of text at about 700 tokens each, plus about 900 tokens of instructions and schema) | 3,000 |
| Output tokens per document (the JSON record) | 350 |
| Classification call per document (first page plus the list of types) | 1,000 in, under 10 out |
| Tokens per day | 10M in, 0.9M out |
| Busiest hour, if 15% of the day’s documents arrive in it | 375 documents, about 420 input and 40 output tokens per second |
| Starting configuration to profile | Qwen3-30B-A3B on one RTX PRO 6000 (96 GB) |
| Backfill: 1.26M documents, if one GPU processes 2 documents a second | 175 GPU-hours, about 22 hours on 8 GPUs |
The daily load is small. A 15-minute target is generous, so documents can wait in a queue and the endpoint can be set to favor throughput over latency. One GPU covers the busiest hour with room to spare. A second worker is only worth paying for if the 15-minute target has to hold while a worker restarts.
The 30B model’s weights are about 61 GB in 16-bit precision, which leaves room on a 96 GB GPU for the cache that holds documents being processed.
The backfill is a different shape: a large one-off batch. The endpoint’s maximum workers can be raised for a day and lowered again afterwards. The rate of two documents a second per GPU is the assumption to check first during profiling. If it is half that, the backfill takes twice as many GPU-hours.
How the numbers add up
| Keying cost today, at $1.20 a document | $756,000 a year |
|---|---|
| Documents that pass every check and go straight through (the target; the shadow phase tells you the real rate) | 80% |
| Review of the other 20%, at 1.5 minutes instead of 4 ($0.45 a document) | $56,700 a year |
| Full re-keying of a 2% sample of straight-through documents, as a quality check | $12,100 a year |
| One RTX PRO 6000 running all year, at our reference price of $1.25 per GPU-hour | $11,000 a year |
| Ongoing cost with the model | about $80,000 a year |
| Saving a year | about $676,000 |
| One-time build: two engineers for four months, at $180,000 a year loaded | $120,000 |
| Payback on the build, from go-live | about 2 months |
At these assumptions the ongoing cost falls from about $756,000 to about $80,000 a year. The first year also carries the build, about $120,000, which the saving covers in about two months.
The result does not depend much on the straight-through rate. At 50% instead of 80%, review costs about $142,000 a year and the total is still about $160,000. The saving comes mainly from correcting fields the model has filled in, which takes far less time than typing them.
The GPU is the smallest line. Choosing a larger model to raise accuracy by a few points would cost little extra in GPU-hours. Measure whether it raises the straight-through rate before paying for it.
The benefit that does not show in the table is the backlog. Adjusters see documents within minutes, including the week after a storm.
How the project would run
Build the evaluation set
weeks 1 to 2The insurer already has the right answer for every document it has keyed. Pull 2,000 recent documents with their keyed fields, spread across all seven types, and hold back 500 that no prompt or fine-tune ever sees.
Compare models on the held-out set
weeks 3 to 4Run three or four candidate models with the same prompts and schemas on a trial endpoint. Score field-level accuracy per document type, and the share of documents that would pass validation. Pick the smallest model that meets the bar.
Shadow mode
weeks 5 to 8The pipeline runs on every new document while the indexing team keeps typing as before. Every difference between the two is logged. This is where the real straight-through rate comes from, and where the validation rules get tightened.
Model first, one document type at a time
week 9 onwardStart with the type that scored best, usually contractor invoices. Documents that pass go straight in; the rest go to review. Add the next type when the first one’s spot-check error rate holds steady for two weeks.
Backfill
after go-liveRun the historical documents through the same pipeline with the endpoint scaled out for a day, so that analytics and fraud models have structured data for past claims.
What to measure
Field accuracy by document type
Measured on the held-out set before launch, then on the weekly spot-check sample after it. A single average across types hides the weak ones.
Straight-through rate
The share of documents that pass every check without review. It sets the review team’s workload, so track it per type and per week.
Time from arrival to indexed
The p95, not only the average. It is the number adjusters notice, especially after a storm.
Corrections per reviewed document
How many fields reviewers change. If it rises, look at the prompts, the OCR output or a new layout from a large vendor.
Models to test first
Candidates from our catalog, not a ranking. The project picks one by testing them on its own labeled examples.
Qwen3-30B-A3B-Instruct-2507
The starting choice. A mixture-of-experts model that activates about 3B of its 30B parameters for each token, so it processes batches quickly. Apache 2.0, with a long context for the occasional 40-page police report.
Mistral-Small-24B-Instruct-2501
A dense 24B model that Mistral describes with native function calling and JSON output. A second candidate at a similar size; its 32K-token context covers almost all claim documents.
Qwen2.5-72B-Instruct
A larger model to test against the smaller ones. If it does not raise the straight-through rate on the held-out set, it is not worth the extra GPUs.
gemma-3-27b-it
Accepts images as well as text, so it can read a page directly when the OCR output is poor, for example on handwritten repair estimates. Tell us if you need image input so we can confirm it for your deployment.
Sizes are total parameters as listed in our catalog. Mixture-of-experts models use only part of them for each token. Check each model's license for your use. Several, such as the Llama and Gemma licenses, carry their own terms.
When fine-tuning helps
Extraction suits fine-tuning because the labels already exist: years of documents the indexing team keyed by hand. A smaller model fine-tuned on those may match a larger general model on this insurer’s documents, at a lower serving cost. Measure that on the held-out set before switching.
Fine-tune after shadow mode, not before. Shadow mode shows which document types the prompted model gets wrong, and those are the ones worth training on. Separate adapters per document type can run on one endpoint.
When the data has to stay put
Claim files contain names, addresses, policy numbers, bank details and medical bills. Insurance regulators and reinsurance contracts often limit where that data is processed. The pipeline can run inside the insurer’s own network, next to the claims system and the OCR tool it already uses.
Tell us about your project
Bring us your volumes and a sample of your data. We will tell you which models to test, what the endpoint would need, and what a performance commitment would cover. Self-service accounts can create inference endpoints to try the platform, but not on our top-tier GPU capacity.