Insurance

Extract certificates of insurance to structured JSON

A certificate of insurance is the document a company hands over to prove it carries coverage. The standard certificate of liability insurance packs producer, insured, and a coverages grid of separate policies into one page, and real-world certs arrive as carrier-branded forms, broker-system exports, and plain-letter proofs that say the same thing in a different shape. Sensible converts certificates of insurance into structured JSON for vendor compliance and COI tracking.

vendor compliance | COI tracking | subcontractor onboarding

Validated JSON

Schema-enforced output; every field matches your contract

Source coordinates

Every value links back to page + bounding box for audit

Per-document pricing

Predictable cost. No token-volatility surprises

Trusted by teams turning documents into production data

What makes certificates of insurance hard to extract

The standard certificate has a defined layout, but the certs you actually receive drift from it. Carrier systems, broker software, and plain-letter proofs each render the same coverage differently, the coverages grid stacks multiple policies with their own numbers and limits, and the parts that matter for compliance hide in free-text endorsement language. Positional rules pin the standard boxes; LLM parsing handles the certs that don't follow the form.

01

Standard and Non-Standard Variation

Most certs use the standard layout, but revisions differ and plenty arrive as carrier-branded forms or plain coverage letters that never touch it. Fingerprints identify the form so the right configuration runs, and LLM parsing reads the off-form certs into the same schema as the standard ones.

02

The Coverages Grid

One certificate lists several policies stacked in a grid: general liability, auto, umbrella or excess, workers comp. Each row carries its own insurer letter, policy number, effective and expiration dates, and a column of limits. Sensible reads the grid as structured rows so each policy's number, dates, and limits stay tied together instead of collapsing into one blob.

03

Additional Insured and Endorsements

Whether a holder is an additional insured, and whether waiver-of-subrogation or primary-and-non-contributory language applies, lives in the Description of Operations free-text box and referenced endorsement form numbers. Hybrid extraction pulls those clauses and flags low-confidence reads for review rather than guessing compliance.

Managed services

Don't want to build it? We'll write your configs from your samples.

Solutions engineers handle plan, build, deploy, and adjust on your behalf. You see clean JSON in your API response. Same engine as self-serve, just with the configuration work outsourced.

What's included

01Plan.Engineers review your samples and pick the right method

02Build.SenseML configs written from your samples

03Deploy.Same engine as self-serve, ready for production

04Adjust.We update configs when formats shift or new edge cases appear

05Integrate.Help with custom integration into your downstream systems

Fields we extract

Every compliance workflow maps the certificate to its own schema, so we build the config around your fields rather than a fixed list. These are the fields COI teams pull most often; we map whatever else your vendor-onboarding or tracking workflow needs.

01

Parties

Producer name and contact, named insured and address, insurers A through F with NAIC numbers, certificate holder name and address, authorized representative, certificate number and issue date

02

Coverages & limits

Per policy: coverage type (general liability, automobile, umbrella/excess, workers comp), insurer letter, each-occurrence and aggregate limits, combined single limit, employers liability limits

03

Policy terms & holders

Policy numbers, effective and expiration dates per coverage, additional-insured status, waiver of subrogation, primary-and-non-contributory language, and the Description of Operations text

config.json

SenseML

{ /* SenseML: certificate of insurance extraction */
"fields": [
{
"method": {
"id": "queryGroup",
"queries": [
{ "id": "insured", "description": "named insured, insured block, insured name" },
{ "id": "producer", "description": "producer, broker, agency name" },
{ "id": "certificate_holder", "description": "certificate holder, name and address" },
{ "id": "certificate_number", "description": "certificate number, cert no" }
// + coverages array (per-policy type, number, dates, limits), mapped to your schema
]
}
}
]
}

Supported certificate formats

Sensible processes certificates of insurance across carriers, brokers, and submission channels. Fingerprints identify the certificate revision so the right configuration runs, and non-standard certs can be configured in hours. The extraction logic is explicit in SenseML, not buried in prompt tuning.

By form type

The standard liability certificate (2016/03 and earlier revisions), property coverage certificates, carrier-branded certificate forms, and plain-letter proof-of-coverage documents

By submission format

Broker-system PDF exports, carrier-portal downloads, emailed and scanned copies, faxed certificates, and image-only certs that need OCR

Common Questions

Answers about certificate revisions, the multi-policy coverages grid, and pulling additional-insured and endorsement language.

Can Sensible pull additional-insured and endorsement language?

Yes. Whether a holder is an additional insured, and whether waiver-of-subrogation or primary-and-non-contributory language applies, lives in the free-text Description of Operations box and referenced endorsement form numbers. Hybrid extraction pulls those clauses and flags low-confidence reads for review rather than guessing compliance.

How does Sensible handle the multi-policy coverages grid?

Each policy is read as a structured row, so general liability, auto, umbrella or excess, and workers comp keep their own insurer letter, policy number, dates, and limits tied together instead of collapsing into one blob.

What fields does Sensible extract from a certificate of insurance?

By default Sensible pulls producer, named insured, insurers A through F with NAIC numbers, certificate holder, and the full coverages grid (type, policy number, effective and expiration dates, and limits per policy). Additional-insured status, waiver of subrogation, and primary-and-non-contributory language come from the Description of Operations text. Those fields live in configuration, so you add, drop, or reshape what gets extracted to fit your workflow.

Which certificate of insurance formats does Sensible support?

Sensible reads any certificate layout. The library covers the standard liability certificate (2016/03 and earlier revisions), property coverage certificates, carrier-branded forms, and plain-letter proof-of-coverage documents, with fingerprints that pick the right config per revision. A non-standard cert or a layout you haven't sent before gets configured in SenseML.

Start free

Turn your next certificate of insurance into JSON.

Free 14-day trial. No credit card required. Start extracting in minutes.