What is a Loss Run Report
By SortSpoke
SOV Standardization: How Underwriting Teams Automate Statement of Values (SOV) Processing
TL;DR
- SOV standardization converts every statement of values (SOV) a broker sends — each in a different spreadsheet layout — into the one consistent schema your underwriting, rating, and CAT modeling systems need.
- Done manually, it's slow and error-prone: analysts rekey every incoming SOV, quotes wait on data entry, and transposition errors flow straight into pricing and catastrophe model inputs.
- Automated SOV standardization should handle Excel and PDF layouts without per-template setup, map columns to your schema, validate values, route low-confidence fields to human review, and output data your downstream systems can load directly.
- SortSpoke does this with insurance-trained, template-free extraction — pretrained SOV models, native Excel handling, normalization to your standards, and a human-in-the-loop review step your team controls.
A statement of values (SOV) is the document commercial property underwriting runs on — and almost every one arrives in a different shape. One broker sends a 40-column Excel workbook with three tabs. Another sends a PDF export of someone else's template. A third sends a location schedule with merged cells, a multi-row header, and total insured value (TIV) subtotals scattered between location rows. Before an underwriter can quote or a CAT model can run, someone has to turn all of that into one consistent format. That work is SOV standardization — and at most carriers and MGAs, it is still done by hand.
This guide covers what SOV standardization involves, why the manual version taxes underwriting operations, what to require from tools that automate it, and how SortSpoke approaches it with template-free extraction under your team's own review.
What Is SOV Standardization?
SOV standardization is the process of converting incoming statements of values — whatever layout, format, or file type a broker sends — into a single consistent schema that rating, policy, and catastrophe modeling systems can consume. It has two halves: extracting the property data (locations, addresses, construction, occupancy, year built, values, coverages) from the source file, and normalizing it so every SOV, from every broker, comes out as the same structured fields.
Statement of Values (SOV)
A statement of values (SOV) — also called a property schedule or location schedule — is a document listing every location an insured wants covered, with the values and characteristics of each: address, building value, contents value, business interruption value, total insured value (TIV), construction type, and occupancy. Brokers typically send it as an Excel workbook or PDF alongside the application and loss history in a commercial property submission.
SOV standardization — converting SOVs from many broker-specific layouts into one consistent schema, so every location record has the same fields in the same format regardless of the source layout.
Standardization exists as a discipline because there is no enforced industry-standard SOV layout. Unlike ACORD forms, which follow a published structure, an SOV is whatever the broker's or insured's spreadsheet happens to be. Column names, units, and subtotal conventions all differ — and underwriting needs one schema on the other side.
Why Manual SOV Standardization Hurts Underwriting Operations
Rekeying Time Comes Out of Quoting Time
When SOVs are standardized by hand, an underwriting assistant or operations analyst opens each incoming file, deciphers its layout, and rekeys or copy-pastes the data into the house template. A large schedule can take hours, and the cost lands hardest during renewal season, when property submissions stack up and the first quote back often wins. Manual standardization is one of the biggest hidden costs inside insurance submission intake and triage, because nothing downstream — clearance, triage, quoting — can start until the SOV data exists in usable form.
Errors Flow Into Pricing and CAT Modeling
Rekeying is not just slow — it is a data-quality risk. A transposed digit in a building value, a construction code pasted into the wrong row, a TIV subtotal treated as a location: these errors don't stay in the spreadsheet. They flow into rating and into catastrophe model inputs, where location-level accuracy drives the modeled result. A CAT model is only as good as the schedule it is fed, so every manual touch on SOV data is a chance to distort the numbers the account will be priced on.
The Layout Problem Never Converges
Teams sometimes try to solve this with templates — build a mapping for each broker's format and reuse it. In practice the layouts never stop changing: brokers revise their spreadsheets, insureds maintain their own versions, and every new producer relationship introduces a new format. A template library becomes its own maintenance burden, and the first submission from any new source still lands back in manual processing. The same dynamic runs through the rest of the submission packet — loss runs have the identical problem, with every carrier issuing its own report format.
What to Look For in Automated SOV Standardization
Automated SOV standardization tools replace rekeying with AI-driven extraction and normalization. Evaluating them comes down to a short list of capabilities:
- Handles any incoming layout without per-template setup — a new broker's spreadsheet should work on day one, not after someone configures a mapping for it.
- Reads native Excel and PDF — including multi-sheet workbooks, merged cells, multi-row headers, and tables that span pages.
- Maps columns to your schema — "Bldg Limit," "Building Value," and "RE Value" should all land in the same field, with values normalized to your standards for dates, currencies, and state codes.
- Validates the data — rules that catch non-numeric TIVs, missing required fields, and values that don't add up.
- Routes low-confidence values to human review — every field should carry a confidence score, with anything below your threshold going to your reviewers, traceable to the source cell.
- Outputs to your downstream systems — structured location records (JSON, CSV, XML, or direct integration) that your rating engine, policy admin system, or CAT modeling workflow can load without another conversion step.
The table below contrasts the manual status quo with an automated approach that meets this bar:
| Dimension | Manual SOV Standardization | Automated SOV Standardization |
|---|---|---|
| New broker layout | Analyst deciphers and rekeys it by hand | Extracted on day one — no template to build |
| Time per SOV | Hours for large schedules | Minutes, with review focused on flagged fields |
| Error control | Spot checks, if time allows | Validation rules plus confidence-scored human review |
| Output | Another spreadsheet to re-enter downstream | Structured records delivered to your schema and systems |
| Scaling at renewal season | More headcount or a growing backlog | Volume scales without adding rekeying work |
How SortSpoke Standardizes Statements of Values
SortSpoke is an AI document extraction platform built for insurance, and SOVs are one of its pretrained document types. Here is how the pieces map to the checklist above:
- Pretrained SOV models. SortSpoke ships with models pretrained on statements of values and location schedules — extracting structured property records with TIV, coverages, and occupancy already broken out.
- Template-free by design. No per-broker templates to build, maintain, or update. A new layout works without configuration, because the models learn structure from the document itself rather than from a predefined map.
- Native Excel and complex-table handling. SortSpoke reads Excel workbooks directly — sheets, tabs, and formulas' computed values — and detects tables inside PDFs, including the merged cells, multi-row headers, and multi-page tables that break generic OCR. A PDF SOV and an Excel SOV come out the same way: one schema, regardless of source format.
- Every location as its own record. Repeating structures — a location with its own address, values, and characteristics — are extracted as separate structured records, whether the schedule lists five locations or five hundred.
- Normalization to your standards. Dates, currencies, and state codes are normalized on the way out, and raw values map to your controlled vocabulary — "Calif," "California," and "CA" all become "CA."
- Human review where it counts. Every extracted field carries a 0–100 confidence score. Fields above your thresholds flow through automatically; anything below routes to your own reviewers, who see each value next to its source — click a field and the document jumps to the cell it came from. Validation rules flag values that look wrong, like a non-numeric TIV, before data leaves review.
- Output your systems can use. Standardized SOV data leaves as structured records — JSON, CSV, XML, or database-ready — shaped to your downstream schema. Classification keeps the SOV distinguished from the loss runs and ACORD forms arriving in the same submission package.
The result: manual SOV standardization eliminated as a rekeying task, without giving up control of the data — your own team reviews everything the AI is not confident about.
FAQ
What is SOV standardization?
SOV standardization is the process of converting statements of values — the property schedules brokers send in many different spreadsheet layouts — into one consistent schema for underwriting, rating, and CAT modeling. It involves extracting location-level data from each incoming Excel or PDF file and normalizing it so every SOV produces the same structured fields.
Can AI extract data from any SOV format?
Insurance-trained, template-free extraction is built to handle SOVs across layouts — Excel workbooks, PDFs, merged cells, multi-row headers — without a template configured per format. The honest qualifier is confidence: strong systems score every extracted value and route anything uncertain to a human reviewer, so an unusual layout degrades to a quick review rather than a silent error.
Is generic OCR or an AI agent better for extracting data from loss runs and schedules of values?
Generic OCR converts pixels into text but doesn't understand table structure, so merged cells, multi-row headers, and repeating location or claim records come out scrambled. Insurance-trained AI extraction understands what an SOV or loss run is — which columns map to which fields, and how records repeat — and pairing it with human review of low-confidence values gives you the accuracy control that a fully hands-off AI agent doesn't.
How does human review fit into automated SOV standardization?
Every extracted field carries a confidence score, and you set the thresholds: high-confidence values flow through automatically while lower-confidence ones route to your own reviewers. The reviewer sees each value next to its source cell in the original document, corrects it in seconds if needed, and validation rules flag entries that fail checks — so the standardized output is verified before it reaches rating or CAT modeling.
Key Takeaways
1
SOV standardization turns every broker's differently-shaped statement of values into the one schema underwriting and CAT modeling need — and manual rekeying makes it a bottleneck and a data-quality risk.
2
Template-based approaches don't converge: broker layouts keep changing, so require tools that handle new formats without per-template setup.
3
The evaluation bar is layout-agnostic extraction, column mapping to your schema, validation, confidence-scored human review, and output your downstream systems can load directly.
4
SortSpoke meets that bar with pretrained SOV models, native Excel and complex-table handling, normalization to your standards, and a review step your own team controls.
Want to see an SOV from your own inbox standardized under your team's review? See a demo →
