Statement of values: a spreadsheet pretending to be a policy document
In short
A statement of values is the schedule of insured property behind a commercial property policy: 1 row per location or building, carrying address, occupancy, construction, area and values at risk. Its columns are agreed between broker and carrier rather than standardised, so parsing one is a normalisation problem before it is an extraction problem.
Key takeaways
- Settle the grain first: 1 row can mean a location or a building, and flattening loses the difference.
- A values column with no valuation basis beside it cannot be compared with anything.
- A blended total insured value cannot be split back into building, contents and business income.
- Most schedules carry a grand total, giving you a real reconciliation the dec page never offers.
- Occupancy and construction arrive as English and must be mapped to the carrier's own scheme.
A statement of values, universally shortened to SOV, is the schedule of property behind a commercial property policy. Each row describes a location or a building and states what it is worth: address, what goes on there, how it is built, how big it is, and the values at risk on the building, its contents and the income it produces.
It is not a carrier form. It is a spreadsheet the broker or insured maintains, shaped by whichever template that carrier prefers, and it arrives as XLSX, as CSV, as a PDF export, or as a scan with the right-hand columns clipped off the page.
A schedule with no column contract, and what that costs
There is no agreed column set, order or vocabulary. One schedule labels a column TIV, the next splits the same money across 3 columns, a third uses Bldg and Cont. Header rows repeat mid-file, subtotal rows sit between location groups, and merged cells span buildings sharing an address.
The first decision is the grain, and most pipelines skip it. If a schedule distinguishes location 1 building 1 from location 1 building 2, the key is composite, and flattening to 1 row per address destroys the distinction the rating depends on. Decide whether your record is per building with a location parent, or per location with a building count, before writing a mapping rule.
The normalised row a downstream system can actually use
| Target field | What it must hold | Typical source labels |
|---|---|---|
| Location and building key | The composite identifier, kept even when only 1 building exists | Loc, Site, Prem, Bldg, Unit |
| Address | Parsed to street, city, region, postcode, country — not one string | Address, Situation, Premises, Risk Location |
| Occupancy | What is done at the site, mapped to the carrier's scheme | Occupancy, Use, Description, Class |
| Construction | Construction class, plus year built and storey count | Const, Construction Type, Wall Type, YOC |
| Area | Floor area, with its unit recorded explicitly | Sq Ft, Area, GIA, Size |
| Protection | Sprinklered flag, alarm, distance to hydrant and station | Spr, Prot Class, PPC, Fire Protection |
| Values | Building, contents and business income as separate numbers | Bldg, BPP, Contents, Stock, BI, TIV |
| Valuation basis | Replacement cost or actual cash value, per value column | Val Basis, RC, ACV, Basis |
The named insured on an SOV deserves the suspicion it gets on an application. Schedules are often maintained by a property team and carry a trading name or a subsidiary rather than the entity on the policy — the failure traced in extraction picking the wrong entity on a multi-name application.
Three ambiguities that recur on every schedule
- Blended values. A single TIV column already combining building, contents and business income cannot be split back apart. Store it as blended with a flag, and treat later per-peril analysis of that row as unavailable rather than estimated.
- Per-location against blanket. The schedule states values; the policy states how limits attach to them. A blanket limit over 40 locations behaves nothing like 40 scheduled limits, and nothing on the SOV settles which is in force.
- Valuation basis. A value at replacement cost and one at actual cash value are different quantities, so a column with no basis recorded is uninterpretable. If the schedule does not say, the field is unknown; never inherit the basis from the row above.
Occupancy and construction are codes wearing English
Two columns look like free text and are not. Occupancy — office, warehouse, light manufacturing, restaurant — drives rating and appetite, and every carrier maps it into its own scheme. Construction resolves to a small set of classes running from combustible frame to fire-resistive, and the exact list and its definitions come from the rating manual in force, which is where to confirm them rather than from any general article including this one.
Both columns are therefore lookups against a per-carrier table, not string normalisation, which is another reason the carrier record needs the company code that joins it. An unmapped occupancy is an unknown that goes to a person; a guessed one is a rating error nobody catches until renewal.
An SOV is the one underwriting document the insured edits between submissions. Version it, or you will underwrite last year's building count.
That point is operational rather than technical. Locations are added, sold and revalued mid-term, and each change is a service request that has to reach the carrier and return as an endorsement — the workflow in a service queue for mid-term changes. Keep every SOV version with its received date and the submission it supported. Building the parser, the mapping tables and the review queue behind it is internal tools and ops work. This page sits in the forms: extraction and classification, part of our insurance and claims software practice.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is a statement of values in commercial insurance?
It is the schedule of insured property behind a commercial property policy, with a row for each location or building giving address, occupancy, construction, area and the values at risk. It is maintained by the broker or the insured rather than issued by the carrier, and underwriters use it to rate the account and to decide how limits attach.
Why is a statement of values hard to extract into a database?
Because its columns are agreed between a broker and a carrier rather than standardised, so labels, order and vocabulary change with every account. The grain is ambiguous too — a row may be a location or a building — and value columns often arrive blended with no valuation basis stated. Those are normalisation decisions, and no extraction model resolves them for you.
What should happen when an SOV value column has no valuation basis?
Record the basis as unknown and route the row for confirmation. Replacement cost and actual cash value are different quantities, so a number without its basis cannot be compared, aggregated safely or used for adequacy analysis. Inheriting the basis from the row above, or from last year's schedule, is the most common way a schedule quietly becomes wrong.
- statement of values
- commercial property
- document extraction
- schedules
The work behind this page
Builds from our portfolio that this page draws on.
AP Copilot
An AI accounts-payable copilot that reads invoices, matches them to POs, and routes clean approvals
FintechScanQueue
An AI radiology worklist that flags suspected critical findings on incoming CT, MR and X-ray studies and orders every read by acuity and SLA — so the sickest patient is read first, not FIFO.
Healthcare AIAskVault
An AI internal knowledge-search platform that answers employee questions from your own docs — grounded in citations, with knowledge gaps surfaced and deflection tracked.
Productivity AIRead next
- The declarations page: the shortest document saying what was boughtThe dec page is an index, not a contract. It names the parties, the term, the limits and the forms attached, and a third of those fields have no standard shape at all.definition
- The loss run: what it is, and why its valuation date changes the answerA loss run is a snapshot of files that are still moving. Without the valuation date beside them, the numbers on it cannot be compared to anything, including a later copy of themselves.definition
- Cause of loss: the coded field, and why the caller's story is not itThe loss narrative and the coded cause of loss are two fields with two jobs. Conflating them gives reporting nobody trusts and routing nobody can explain.definition
- Claim severity score: a routing input, not a reserve and not a decisionA severity score exists to decide which queue a new claim joins and how fast. Everything a licensed person is accountable for stays outside its remit.definition
- Claimants start the online loss report and phone in anywayChannel fallback is measurable. A step-level drop table segmented by device and reporter, joined to inbound calls within the following hour, names the step that sends people to the phone.diagnostic
- Claims leakage: what the term actually counts, and what it quietly cannotLeakage is a subtraction where 1 of the 2 numbers came from a reviewer imagining a file that never happened. The standard is part of the answer.definition
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation