Every property insurance submission starts with a Statement of Values — the property inventory that sets coverage and premium. And nearly every attempt to automate underwriting hits its first wall right here. Read this before you write a line of code, whether you’re evaluating extraction tools or building a data pipeline for a digital underwriting operation.
What a Statement of Values actually is
An SOV is a detailed schedule the insured submits. It lists every insured location and its values. For each building it should carry the address, construction type, occupancy, year built, square footage, number of stories, roof type, sprinkler/protection status, and stated building and contents values. Insurers use it to set limits, model catastrophe exposure, and price the account.
Here’s the catch. There’s no standard format. One broker sends a tidy 12-column spreadsheet. The next sends 4,000 locations across six tabs with merged headers. Another sends a PDF export from an old system, or a scanned printout. The data you need is all in there. It just isn’t structured, consistent, or clean.
The SOV is the property inventory that sets coverage and premium — and it almost never arrives in a form a model can trust.
How extraction works, step by step
Modern extraction combines OCR, machine learning, and natural-language processing to turn any incoming format into a standardized, submission-ready schema. When it’s done properly, it runs roughly like this:
- Classify and split. Figure out what each document and tab is — SOV, loss run, ACORD form, supplemental — and separate them.
- Parse across formats. Read Excel, CSV, PDF, and scans with flexible column mapping, so “YR BLT,” “Year Built,” and “construction year” all resolve to one field.
- Extract the fields. Pull building location, construction, occupancy, values, stories, and protection details into a normalized structure.
- Score confidence. Attach a confidence value to each field, so low-certainty extractions get flagged instead of silently trusted.
- Validate. Check completeness and sanity: required fields present, values in plausible ranges, no obvious construction/occupancy mismatches.
- Human-in-the-loop review. Route only the exceptions to a person to confirm or correct in-line, instead of re-keying the whole file.
Where it goes wrong
Extraction that looks impressive in a demo fails in production for boring, expensive reasons:
- Silent field errors. A construction type mis-mapped from “FR” (Frame or Fire Resistive?) to the wrong class throws no error. It just mis-prices the risk.
- Format brittleness. A pipeline tuned to one broker’s template breaks the moment a different template arrives.
- No confidence signal. Without per-field confidence you can’t tell a solid extraction from a guess, so you either trust everything or review everything.
- Under/over-valuation. Stated values taken at face value, with no cross-check against construction-cost data, feed straight into underinsurance.
Inaccurate SOV data leads to underinsurance, overpayment, and stalled renewals. Manual review can’t keep up with the volume.
Extraction is step one. Enrichment is step two.
Clean extraction gets you a trustworthy version of what the broker sent. It doesn’t get you everything you need. Next comes enrichment: geocode each location, then append CAT zone, flood zone, fire protection class, replacement-cost estimates, and building characteristics — the context that turns a bare address into a priceable risk. Extraction and enrichment together are what finally make straight-through, agentic underwriting possible.
What to look for in a solution
Whether you build or buy, hold any SOV extraction approach to a simple bar. It should handle every format and normalize to a consistent schema. It should score confidence per field. It should validate against insurance-specific rules and hand off enrichment cleanly. It should geocode. That combination is exactly what we built Ping to deliver as infrastructure — so your team spends its time on risk selection and pricing, not on cleaning spreadsheets.