How to build a statement of values (SOV), column by column

A commercial property submission can contain hundreds of pages, but the statement of values is often where the underwriter starts. It puts the buildings, construction details and insured values in one place. Errors in that spreadsheet can affect a quote, a catastrophe model run or recovery after a loss. Below are the fields to check and the records that support them, followed by a free 51-column Excel template.

What a statement of values is, and who reads it#

A statement of values (SOV), also called a schedule of values or property schedule, lists every insured location and building with its physical characteristics and the dollar values the insured wants covered. One row per building. For a single-building risk it can be a few cells on an application. For a REIT or a manufacturer with 300 sites it is the core of the submission.

Four groups use the schedule for different purposes:

• Brokers build and maintain it, and use it to market the account. A complete, consistent SOV gets more carriers to quote.
• Carriers price from it. The underwriter rates each building on its COPE profile (construction, occupancy, protection, exposure; see what COPE data is), and the limit, deductibles and sublimits all key off the values.
• Risk managers at the insured own the values. The schedule is their statement of what they believe the property is worth, and it follows them into every claim.
• Reinsurers and cat modelers take the SOV, geocode it, and run it through catastrophe models to estimate probable maximum loss. The model can only be as good as the rows it is fed.

The SOV is usually an attachment to the application, and many carriers take it on their own template, so the column order changes from market to market. The content does not.

The columns, group by group#

COPEData's SOV export uses 51 columns, the layout of a working broker schedule. They fall into six groups. Hover or tap any column below for a one-line definition; a filled swatch means COPEData fills it automatically from public records, permits and web research (when a source is found), and a hollow one means it is left for the broker or insured.

Location and identification#

Verify the address for each building before submitting the schedule. Catastrophe models geocode each row, and Verisk includes “missing or inaccurately geocoded exposure data” in its quality checks (Verisk, Data Quality Analytics in Touchstone). A location resolved only to a ZIP centroid may sit a mile from the actual building, potentially placing it on the wrong side of a flood or wildfire boundary.

Construction#

Construction type and year built are the two primary characteristics every model and every rating plan asks for. Year built stands in for the building code in force when it was designed, which matters a great deal for wind and earthquake.

Secondary modifiers: roof and systems#

Roof and system details help distinguish buildings with the same construction class and year built: a 1985 office with a 2021 reroof is a different wind risk from one still on its original roof. Verisk's Touchstone, for example, carries Roof Year Built as its own field, separate from the building's year built, and documents roof covering as a secondary characteristic for its U.S. hurricane, severe thunderstorm and wildfire models (Touchstone 11.0, location roof detail fields). Missing details trigger model defaults, which can change the loss estimate. Confirm them where records are available.

The fastest source for update years is building permit history. A reroof, a service upgrade or a repipe almost always pulled a permit.

Occupancy and protection#

Pick one occupancy vocabulary and use it on every row. "Office," "Professional office," "OFF" and "Commercial" on the same schedule look like four occupancies to a model that maps text to codes.

Exposure and CAT#

Carriers and modelers usually derive these fields from the geocode. Including them in the schedule gives you a chance to check the result beforehand, especially for locations near a flood-zone boundary.

Valuation#

COPEData leaves all of these blank. It does not estimate replacement cost; valuation is the insured's representation and belongs with whoever can stand behind it.

Which columns matter for which peril#

Prioritize missing fields according to the relevant peril. Sprinkler details are important for fire; roof covering and age matter for hail. For flood, concentrate on location, elevation and foundation. The matrix below shows where to focus a review before a submission deadline.

Address quality matters across the hazards because it places the building within the model. Fire review also depends on construction, occupancy and protection. Wind, hail and wildfire assessments draw heavily on the building envelope, especially the roof. Flood assessment requires zone, distance, elevation and foundation details.

Insurance to value and the coinsurance penalty#

Insurance to value (ITV) is the ratio of the limit you carry to what the property would actually cost to replace. When it slips below 100%, two things happen. The obvious one is that a total loss is not fully paid. The less obvious one is the coinsurance clause, which can cut a partial loss too.

IRMI defines a coinsurance provision as one that "penalizes the insured's loss recovery if the limit of insurance purchased by the insured is not equal to or greater than a specified percentage (commonly 80 percent) of the value of the insured property" (IRMI). The recovery is capped at:

Recovery = Loss × (Limit carried ÷ (Value at time of loss × Coinsurance %)) − Deductible

and never more than the loss itself or the limit. Two details trip people up. The value is measured at the time of loss, not at binding. And the test applies per building or per item as the policy defines it, so one undervalued building in a schedule can be penalized even when the total looks fine.

Business income has its own version of the test. BI coinsurance is measured against a projection of net income plus operating expenses over the coming 12 months, which is why the BI worksheet exists and why a back-of-envelope BI figure on the SOV is dangerous.

Why valuations go stale#

Building values do not hold still. A replacement cost that was right three years ago can be badly short today, because the cost of the materials and services that go into a building has moved much faster than general inflation.

Review schedules that used a flat 3% annual increase through 2021–2022 against the cost changes shown above. A valuation carried forward from that period may need an appraisal or cost-estimator update, particularly if it has gone three to five years without one.

Common SOV mistakes#

Check for these errors before sending a schedule to market.

1. Stale values. The single most expensive mistake, for the reasons above. Trend annually with a construction cost index, and re-appraise on a cycle.
2. Market or assessed value in the building column. Market value includes land and reflects rents; assessed value reflects tax policy. Neither is the cost to rebuild.
3. Missing secondary modifiers. Blank roof year, blank sprinkler column. The model defaults, the underwriter assumes the worst, and the rate shows it.
4. Inconsistent occupancy and construction codes. Free text in a coded field, three spellings of the same thing, or an ISO class that contradicts the narrative (a "fire resistive" wood-frame apartment).
5. Geocoding problems. PO boxes, ranges ("100–140 Main St"), intersections, campus addresses for 12 buildings, or rural routes that only match to a ZIP centroid. Give each building a real address, or coordinates if the address will not resolve.
6. Campuses collapsed into one row. A business park entered as one building with combined square footage. The model sees one big building instead of six separate ones, which changes both the fire and the cat picture.
7. Totals that do not tie. The TIV on the SOV, the TIV on the application and the limit on the dec page should all reconcile. Underwriters check.
8. Implausible combinations. Verisk's validation rules exist because portfolios contain things like "seven-story wood frame buildings" or "a mobile home with a replacement value of $200,000" (Verisk). Sort by each column once before sending and look at the extremes.

How carriers and cat models use the data#

The underwriter reads the SOV row by row for the big locations, and in aggregate for the rest. Construction and occupancy set the base fire rate, protection modifies it, and values set the exposure. Deductibles, wind and flood sublimits, and the decision to quote at all come out of that read.

The cat modeling team does something more mechanical. The schedule is imported, geocoded, mapped into the model's construction and occupancy codes, and run against a stochastic catalog of events to produce average annual loss and probable maximum loss at various return periods. In Verisk's description, its exposure dashboard breaks a portfolio down "by occupancy and construction, building age and height, geocode quality," and validation checks "identify exposures for which building characteristics are unknown" (Verisk). That output goes into pricing, into the carrier's accumulation management, and into what the carrier's reinsurers see.

Two practical consequences:

• Unknowns cost money. When a characteristic is missing, the model falls back on an assumption about what is typical for the area, and the underwriter loads for the extra uncertainty. Typical is rarely the well-maintained, recently reroofed building your insured actually owns.
• Better data is a negotiating tool. A complete schedule with documented roof years and sprinkler coverage lets the underwriter credit what is really there. Verisk's own pitch for its data quality score is that it "quantifies the improvement... that is possible with better exposure data quality."

How to build an SOV, step by step#

1. 1
   List every building
   Start from leases, deeds and the fixed asset register. One row per building, with a real street address.
2. 2
   Fill COPE from records
   Assessor, permits, FEMA and USGS data for construction, roof, systems, protection and exposure fields.
3. 3
   Get values from the insured
   Replacement cost from an appraisal or cost estimator, contents from the asset ledger, BI from the worksheet.
4. 4
   Normalize and check
   One code list per column. Sort each column, check extremes, make the totals tie.
5. 5
   Date it and keep it
   Record the valuation date and source per row. Trend values every renewal.

The second step is where most of the hours go, and it is the step COPEData automates: type an address and in about a minute you get a cited report covering construction, occupancy, protection, exposure and permit history, with every value linked to its source. The SOV export drops those values straight into the 51 columns above and leaves the valuation columns blank for the insured to complete. If you are building the schedule by hand, start from the template below.

SOV checklist before you send it#

• Every row has a street address that geocodes to the rooftop, not the ZIP.
• Construction type uses one code system (ISO 1–6 or the carrier's) on every row.
• Roof type and roof year are filled for every building; update years for electrical, plumbing and HVAC where known.
• Sprinkler status is filled, with percentage of area where partial.
• Building values are replacement cost, dated, and trended to the policy inception.
• Contents and BI are separate from building, and BI matches the worksheet.
• The row totals sum to the schedule TIV, and the schedule TIV matches the application.
• Flood zone is checked for every building, especially anything near water.