Trusted by teams turning documents into production data
Insurance
An auto insurance ID card is the document a driver hands over at a traffic stop, a claims desk, or a lender's compliance check. It packs insurer, policy number, named insured, coverage dates, and vehicle details onto a pocket-sized card, and the layout changes with every carrier and every state. Most arrive as a phone photo or a back-office scan. Sensible converts proof of insurance into structured JSON for policy verification, claims intake, and lienholder tracking.
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
Every carrier prints its ID card differently, and every state mandates a different set of fields. The card is small, the inputs are often phone photos, and the values that matter most (VIN, policy number) are the ones OCR misreads first. Layout-based rules pin the fields that hold position on a given carrier's card; LLM parsing absorbs the layout you have never seen before.
01
Progressive, GEICO, State Farm, and a regional mutual each arrange the card their own way, and each state mandates its own field set. There is no single grid to anchor to. LLM parsing reads whatever card it is handed; SenseML rules map the result to one consistent schema across every carrier.
02
Proof of insurance rarely arrives as a clean PDF. It comes in as a glare-streaked phone photo, a screenshot of a wallet app, a crooked desktop scan, or a fax. Hybrid extraction reads the degraded inputs and flags low-confidence fields for review rather than returning a plausible-looking guess.
03
A 17-character VIN and an alphanumeric policy number are the fields OCR gets wrong most, because a misread 0/O or 5/S looks fine until verification fails downstream. Sensible applies format checks to these fields and returns null on the ones it can't read confidently, so a wrong VIN never passes silently into your records.
Managed services
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
Every verification workflow maps the card to its own schema, so we build the config around your fields rather than a fixed list. These are the fields verification and claims teams pull most often; we map whatever else your intake workflow needs.
01
Policy & insurer
Insurer name, NAIC company code, policy number, policy effective date, policy expiration date, agent or issuing office, state of issue
02
Named insured
Named insured name, mailing address, additional insured or co-insured, lienholder or loss payee where listed on the card
03
Vehicle & term
Vehicle year, make, model, VIN, coverage effective and expiration dates, and one row per vehicle when the card covers more than one
config.json
SenseML
{ /* SenseML: proof of insurance extraction */
"fields": [
{
"method": {
"id": "queryGroup",
"queries": [
{ "id": "insurer", "description": "insurer name, insurance company, carrier" },
{ "id": "policy_number", "description": "policy number, policy no, policy #" },
{ "id": "named_insured", "description": "named insured, insured name, policyholder" },
{ "id": "vin", "description": "VIN, vehicle identification number, 17-character" }
// + vehicle and term fields, mapped to your schema
]
}
}
]
}Sensible processes proof of insurance across carriers, states, and capture methods. The extraction logic is explicit in SenseML, not buried in prompt tuning, so a new carrier layout can be configured in hours rather than waiting on a model to learn it.
National carriers, regional mutuals, and state-mandated ID card layouts, including multi-vehicle cards and electronic proof-of-insurance formats
PDF cards, phone photos, wallet-app screenshots, desktop scans, and faxed copies, front and back of the card
Answers about carrier and state layout support, reading phone photos and scans, and VIN and policy-number accuracy.
A 17-character VIN and an alphanumeric policy number are the fields OCR gets wrong most, because a misread 0/O or 5/S looks fine until verification fails downstream. Sensible applies format checks to these fields and returns null on the ones it cannot read confidently, so a wrong VIN never passes silently into your records.
Yes. Proof of insurance rarely arrives as a clean PDF. It comes in as a glare-streaked phone photo, a wallet-app screenshot, a crooked scan, or a fax. Hybrid extraction reads the degraded inputs and flags low-confidence fields for review rather than returning a plausible-looking guess.
Insurer, NAIC code, policy number, effective and expiration dates, named insured, lienholder or loss payee, and vehicle year, make, model, and VIN are all extracted, with one row per vehicle when the card covers more than one. Custom fields can be added in SenseML to match your verification schema.
Sensible processes auto insurance ID cards from national carriers, regional mutuals, and state-mandated layouts, including multi-vehicle cards and electronic proof-of-insurance formats. The extraction logic is explicit in SenseML, so a new carrier layout can be configured in hours rather than waiting on a model to learn it.
Start free
Free 14-day trial. No credit card required. Start extracting in minutes.