Insurance & Claims
Claims Document Extraction API
A claims handler spends a surprising amount of their day retyping numbers from a PDF into a form. The PDF was generated from a database.
- Insurers
- Claims administrators
- TPAs
- Health insurers
- Brokers
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Claims arrive as documents, and the documents arrive in every format a supplier felt like using. A repair estimate from a main dealer is a structured PDF with line items. The same estimate from an independent garage is a photograph of a handwritten sheet. A medical invoice from a large clinic is machine-generated; from a sole practitioner it is a Word document with the totals typed in by hand. Handlers reconcile all of it manually.
Generic document AI handles the easy end of this and fails in a specific way at the hard end. It reads the text accurately and then has no idea which of the four numbers near the bottom of a repair estimate is the figure you should pay, because that depends on whether VAT is included, whether a betterment deduction applies, and whether the labour rate matches the network agreement. Extraction without domain structure produces fields that still need checking, which means it has not saved the handler anything.
What makes the difference is validating the extraction against something. A repair estimate has internal arithmetic: line items sum to a subtotal, tax applies at a known rate, the total follows. A medical invoice has procedure codes with expected fee ranges. A document whose numbers do not reconcile is either an extraction error or a document problem, and in both cases the handler needs to know which fields to look at rather than being told the document was processed.
Who buys this
Insurers, Claims administrators, TPAs, Health insurers, Brokers
What the API returns
What comes back
- Structured fields per document type, with a confidence value on every individual field
- Line-item extraction with quantities, descriptions, unit prices and totals
- Arithmetic validation: line items against subtotals, tax calculations, stated totals
- Document classification and routing where a claim pack contains mixed document types
- Procedure, parts and diagnosis codes normalised to standard code sets where present
- Supplier identification matched against your approved network and agreed rates
- Handwriting and low-quality scan handling with explicit confidence degradation
- Field-level review queue listing only the fields that genuinely need a human
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/documents | Submit one document or a claim pack for extraction |
| GET | /v1/documents/{id} | Extracted fields with per-field confidence and validation results |
| POST | /v1/documents/{id}/corrections | Submit handler corrections to improve extraction |
| POST | /v1/documents/classify | Classify documents in a pack without full extraction |
| GET | /v1/documents/{id}/validation | Arithmetic and rate-agreement validation detail |
| GET | /v1/schemas | Available document types and the fields extracted from each |
Request and response
illustrativeRequest
{
"claim_reference": "CLM-2026-884210",
"documents": [
{ "id": "doc_1", "url": "https://\u2026/estimate.pdf", "hint": "repair_estimate" },
{ "id": "doc_2", "url": "https://\u2026/invoice_scan.jpg", "hint": null }
],
"region": "GB",
"validate_against": { "network_rates": true, "policy_terms": "POL-884120" }
}Response
{
"document_id": "doc_1",
"document_type": "repair_estimate",
"type_confidence": 0.98,
"supplier": {
"name_extracted": "Marchmont Autobody Ltd",
"matched_network_supplier": "sup_8841",
"match_confidence": 0.94,
"agreed_labour_rate": 54.00
},
"fields": {
"estimate_reference": { "value": "MA-2026-10441", "confidence": 0.99 },
"vehicle_registration": { "value": "LD21 KXR", "confidence": 0.97 },
"labour_hours": { "value": 11.5, "confidence": 0.92 },
"labour_rate": { "value": 61.00, "confidence": 0.95 },
"parts_total": { "value": 884.20, "confidence": 0.96 },
"vat": { "value": 288.14, "confidence": 0.93 },
"total_gross": { "value": 1728.84, "confidence": 0.97 }
},
"line_items": [
{ "description": "Front bumper cover", "qty": 1, "unit": 412.00, "total": 412.00,
"confidence": 0.95 },
{ "description": "Front wing, left", "qty": 1, "unit": 338.40, "total": 338.40,
"confidence": 0.94 },
{ "description": "Paint materials", "qty": 1, "unit": 133.80, "total": 133.80,
"confidence": 0.81 }
],
"validation": [
{ "check": "line_items_sum_to_parts_total", "result": "pass" },
{ "check": "vat_rate", "result": "pass", "implied_rate": 0.20 },
{ "check": "labour_rate_vs_agreement", "result": "fail",
"detail": "Estimate rate 61.00 exceeds agreed network rate 54.00" }
],
"review_required_fields": ["labour_rate"],
"pages_processed": 3
}Where the data comes from
| Your historical claim documents with keyed data | Documents paired with the values a handler actually entered — the training set, and one you already hold in volume |
| Supplier and network agreements | Agreed labour rates, discount terms and panel membership, which is what makes rate validation possible |
| Standard code sets | Parts catalogues, procedure and diagnosis code sets, licensed where required, used to normalise extracted codes |
| Policy and cover data | Excess, limits and cover terms, so an extracted total can be validated against what the policy actually permits |
| Tax and regulatory rate references | Tax rates by jurisdiction and period, needed for arithmetic validation on historical documents as well as current ones |
| Handler corrections | Every field a handler fixes is a labelled example, and this feedback loop matters more than the initial model choice |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Layout-aware extraction rather than plain text parsing, because the position and grouping of numbers on a claims document carries most of the meaning
- Per-field confidence from the model rather than a single document-level score, since a handler needs to know which three fields to check, not that the document scored 0.87
- Arithmetic reconciliation as a first-class validation layer: documents whose internal sums do not agree are flagged with the specific failing relationship
- Document type classification before extraction, with a fallback path for packs containing unexpected or mixed types
- Handwriting handled by a separate path with honestly degraded confidence, rather than forcing one model across print and manuscript
- Code normalisation to standard sets with unmapped codes surfaced explicitly instead of silently dropped
- Active learning on handler corrections, prioritising the field types where corrections cluster
- Per-supplier template learning, since a supplier who sends four hundred documents a year in the same layout should be extracted near-perfectly after the first dozen
What it changes for the business
Handler time recovered
The retyping disappears and the handler reviews the few fields the model is genuinely unsure about.
Rate leakage caught
Validating estimate rates against network agreements catches overcharging that manual review routinely misses.
Faster claim cycle
Documents processed on receipt rather than when a handler reaches them removes a queue from the middle of every claim.
Structured claims data
Line-item data captured as structure rather than as a scanned attachment makes downstream analytics possible at all.
How it fits into your product
How it embeds
- Called on document receipt in your claims system, with results written straight into the claim record
- Field-level review interface showing only low-confidence and validation-failed fields, not the whole document
- Asynchronous processing with webhooks, since multi-page packs take seconds and some scans take longer
- Corrections captured automatically from handler edits rather than requiring a separate labelling exercise
- Per-supplier template learning so your highest-volume suppliers extract most reliably
- Deployment inside your infrastructure, which medical and personal claim documents generally require
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 12 weeksDiscovery and data review
Weeks 1–2
We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.
Architecture and prototype
Weeks 3–4
You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.
Production build
Weeks 5–10
Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.
Integration and handover
Weeks 11–12
We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
What accuracy can we expect?
It varies so much by document type that a single figure would be misleading. Machine-generated PDFs from a regular supplier extract near-perfectly after template learning. Clean scans of printed invoices are reliable. Photographs of handwritten estimates are considerably weaker, and the API reports that as low confidence rather than producing a tidy number. We measure per document type on your own documents during the prototype.
Can we straight-through process on the extraction?
For some document types and above a confidence threshold you set, yes — and arithmetic validation makes that much safer than confidence alone, because an extraction error usually breaks the internal sums. For handwritten documents, unusual layouts or anything where validation fails, no. The honest design routes by confidence and validation rather than claiming full automation.
Does this read medical documents and make clinical judgements?
No. It extracts administrative and billing fields: provider, dates, procedure codes, amounts, policy references. It does not interpret clinical content, assess medical necessity or make any judgement about treatment. Those are clinical and coverage decisions for qualified people, and we scope deliberately short of them.
What about documents in other languages?
Workable, with per-language effort rather than a free switch. Extraction quality depends on having enough examples in that language and script, and arithmetic validation helps considerably because numbers are language-independent. We would scope the languages explicitly rather than claiming general multilingual coverage.
Who is responsible if an extracted figure is wrong?
You remain responsible for what you pay, which is why confidence and validation are surfaced per field rather than hidden. The design assumption is that low-confidence and validation-failed fields are reviewed by a handler. If you configure straight-through processing above a threshold, that threshold is a risk decision you own, and we would document what the measured error rate is at each threshold so the decision is informed.
Related blueprints
Medical Claims Anomaly Detection API
Billing outliers, duplicate submissions and unusual service patterns surfaced across health claims, scoped firmly to billing rather than clinical judgement.
Vehicle Damage Estimation API
Damage detection, parts identification and a repair cost range from claim photographs, for motor insurers and claims administrators.
Property Risk Scoring API
Flood, wildfire, storm and subsidence exposure scored at individual address level, for property underwriting and portfolio management.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.