SOV data extraction: how to read and check every location on a statement of values

SOV data extraction reads the statement of values in a property submission into one clean row per building. Each row holds the address, the construction and occupancy details, and the values to insure. Carriers, MGAs and broker teams automate it so nobody has to retype the spreadsheet before rating.

What a statement of values is#

A statement of values (SOV) lists the property an insured wants covered, one row per location or building. Each row says where the building is, what it is, how it's built and what it's worth. ACORD publishes a standard form for it, the ACORD 139 Statement / Schedule of Values. The form ends with the insured's signature under a line saying the values and locations are correct to the best of their knowledge.

For the team that receives it, the SOV is the main source of property data in the submission. IRMI describes values as the exposure data an underwriting submission needs so the premium can be calculated. Catastrophe models read the same rows, one location at a time. The SOV travels with the ACORD 140, the property section of the application, and the two should agree.

The columns underwriters rely on#

Every SOV is laid out differently, but the same groups of columns come up again and again. IIABA, the independent agents' association, gives its members a list of what an SOV should hold. It starts with the address and construction type and includes sprinklers and alarms. Underwriters call the building details COPE. The letters stand for construction, occupancy, protection and exposure. The ACORD 140 records the exposure, meaning what stands on each side of the building and how far away.

Two details often cause mistakes. First, the word "masonry" on its own could mean ISO construction class 2 or class 4. ISO numbers its classes from frame (1) to fire resistive (6). Second, catastrophe models share a format for exposure data, the Open Exposure Data (OED) standard. It expects business income as a 12-month figure, kept apart from the building and contents values.

Why SOVs arrive messy#

ACORD's form has columns for values, not for construction or year built. Many SOVs arrive as the broker's or the insured's own spreadsheet instead, and each one follows its own layout. The same field turns up under different names, such as "Bldg Limit", "Building Value" or "RE Value".

A workbook may have several tabs. It may split its header over two merged rows, or put subtotal rows between the locations. The worked example below shows a few more. Construction comes as shorthand, the year built as a decade, and one amount is typed as "4.2M".

A person can still read a sheet like this. A rating tool or catastrophe model can't load the sheet as sent. Those systems need one set of columns, each with one meaning, so every SOV has to be mapped to that set first. That mapping, row by row, is the manual work SOV extraction takes over.

One SOV, four locations#

Quillmere Properties LLC is renewing its commercial property policy from January 1, 2027. Its broker sends an SOV for four buildings in North Carolina. The workbook has a two-row merged header and a subtotal row after location 2. Business income is on a second tab, listed by location number. Construction is written as "Frame", "JM", "Masonry NC" and "Non-comb.", and location 3's building value is typed as "4.2M".

Extraction reads the rows. Then steps your team sets up in the workflow join the two tabs on the location number and drop the subtotal row. They also map each construction entry to its ISO class and turn every amount into a number. These are the location and building columns that come out.

The value columns come next, with the sum of the three values beside the TIV the sheet states.

The sheet's own total, 21,345,000, equals the four stated TIVs added together, so a quick look at the sheet finds nothing wrong. The checks below find two problems.

Checks on the rows and totals#

Run these as soon as the rows are extracted, before anything goes to rating.

• Each row adds upThe values on the row sum to its stated TIV. If they don't, keep both figures and flag the row.
• The total adds upThe location rows sum to the file's total, with subtotal rows left out. A subtotal counted as a location inflates the TIV.
• Required columns are filledAddress, occupancy, construction, year built and the values. Gaps go back to the broker.
• Amounts are numbersText such as "incl." or "TBD" in a value column gets flagged instead of being read as zero.
• Years are yearsA decade such as "1970s" gets flagged, and so does a year that hasn't happened yet.
• Codes map to your listEach construction and occupancy entry maps to one of your codes. "Masonry" alone could be ISO class 2 or class 4, so it goes to a person.
• No location appears twiceThe same address under two location numbers is a duplicate until someone confirms it isn't.

On the Quillmere file, locations 1 and 3 pass every check. Location 2 gives "1970s" as its year built, which isn't a year. Location 4's three values add up to 6,690,000, but the sheet states a TIV of 6,960,000, with two digits swapped. That puts the stated total 270,000 above the sum of the parts. Both questions go back to the broker as one request, before an underwriter opens the file.

Checks against the ACORD 140 and the application#

A clean SOV can still disagree with the rest of the submission. The ACORD 140 sets the coverage for each premises, with an amount, valuation, coinsurance and deductible for each subject of insurance. The ACORD 125 names the insured and lists the premises. Compare the SOV with both.

In the Quillmere file, the named insured and the dates match the ACORD 125, which lists all four locations. Locations 1 to 3 match their ACORD 140 premises blocks, and every amount agrees. Location 4, the Garner warehouse, has no premises block on the ACORD 140. So the broker gets a third question, asking where the warehouse's ACORD 140 page is.

Our take. Judge an SOV tool by what it catches across the whole submission, not by how well it reads one spreadsheet. A tool could read all four Quillmere rows without an error. It could still mark the file ready, even though the warehouse has no ACORD 140 page. The checks between the SOV and the application decide whether an underwriter can quote, so test them with whole submissions rather than single SOVs.

How to automate SOV intake#

Docsumo is an intelligent document processing platform, and it extracts SOV spreadsheets for commercial property submissions. It also reads the rest of the submission, such as the ACORD forms and loss runs. On the Business plan, it classifies and splits those documents. Our guide to insurance submission intake shows those steps for a whole emailed submission.

Row checks, such as the TIV sum and the four-digit year, are steps you set up in the workflow. A step can call an LLM (a large language model) or run your own Python code. A step like this can also map "JM" or "Masonry NC" to your construction codes. On the Enterprise plan, cross-document validation can check the SOV against the ACORD 140 and ACORD 125. Confidence thresholds are set per field. Fields below them go to a person for review, and reviewer corrections improve the model.

The rows leave through the API and webhooks or as an Excel export. The Data Table can also collect the rows from many SOVs into one table to filter and export to CSV or Google Sheets. Docsumo doesn't rate the policy or model catastrophe risk. Your own systems do that, with clean rows to start from.

What to bring to an SOV test#

Pick a recent renewal with a long SOV, from the broker whose layout causes your team the most rework. Bring it to a demo with the ACORD 125 and ACORD 140 it came with, so the cross-checks have something to compare. A tidy spreadsheet on its own tells you little. A whole submission shows which mismatches would send your team back to the broker with questions.

Book a demo with a few of your own SOVs and the applications they came with, or start a free trial.

Frequently asked questions#