A statement of values does not need to be perfect before it can be enriched. It does need enough structure to keep the right property, value, and source attached to the right row. Cleaning the file first reduces false matches and makes the remaining exceptions easier to review.
Define what one row represents
Decide whether each row represents a building, a location with several buildings, or a coverage item. Do not mix those levels without an identifier that shows the relationship.
For example, a campus may have one street address, three buildings, and separate values for each structure. If the file repeats the same address three times, add a stable location ID and building ID before enrichment. Otherwise, a later reviewer may mistake three building records for duplicates.
Preserve the source row number from the original file. It provides a simple route back to the submitted SOV when questions arise.
Normalize the location fields
Break a complete location into separate fields when possible:
- street address;
- unit, suite, or building designation;
- city;
- state;
- postal code; and
- country.
Remove instructions and commentary from the address field. Notes such as “rear warehouse,” “mailing only,” or “same as above” belong in a separate column. Expand inherited values such as “same” or blank cells that visually depend on the row above.
Keep the original address in its own field. A standardized address helps matching, but it should not erase what the insured or retailer supplied.
Keep values and units explicit
Give building, business personal property, stock, time-element, and other values distinct columns. Avoid a single total unless the file also preserves its components.
Check that every value column answers three questions:
- What does the number represent?
- Which currency applies?
- Is the value tied to the building, the location, or the account?
Remove currency symbols and thousands separators only in a working copy, and confirm that the resulting cells are numeric. Do not silently convert blanks, dashes, or “TBD” entries to zero. Zero is a value; blank is an unresolved field.
Square footage and distance fields also need units. A column labeled only “Area” can become ambiguous when files move between teams or systems.
Standardize high-value review fields
Normalize common variations without claiming more certainty than the source supports. Useful review fields often include:
- construction type or class;
- occupancy or building use;
- year built and renovation year;
- number of stories;
- building area;
- roof covering and roof update year;
- sprinkler status; and
- stated building value or TIV.
Map spelling and abbreviations to a controlled set, but retain the submitted term. “JM,” “joisted masonry,” and a numeric construction code may refer to the same broad category in one workflow and different classifications in another.
If a conversion requires judgment, flag it for review instead of forcing it into a category.
Separate submitted data from enriched data
Do not overwrite supplied fields with assessor, permit, imagery, or modeled results. Use paired columns such as submitted_year_built and sourced_year_built, then add a comparison or review status.
This makes three important situations visible:
- the sources agree;
- one source fills a blank; or
- the sources conflict.
The conflict is often the most useful outcome because it tells the reviewer what to verify. The same principle applies to construction, area, roof information, occupancy, and valuation context.
For a broader review of these fields, see the COPE data guide.
Find duplicates without deleting evidence
Exact duplicate rows are only one case. Also look for:
- the same address written in different formats;
- separate buildings sharing one parcel address;
- mailing addresses entered as risk locations;
- unit numbers that disappeared during export; and
- one location repeated under different named insureds.
Assign suspected duplicates a review status. Do not delete them until the business relationship between the rows is understood.
Build an exception queue
A cleaned SOV should make unresolved work easy to filter. Add exception flags for issues such as incomplete address, failed location match, missing building value, ambiguous construction, invalid year, possible duplicate, or major source conflict.
Prioritize exceptions using the needs of the placement. A missing roof update may deserve attention in a wind-exposed book, while uncertain occupancy may be the first concern in a mixed-use schedule.
Preserve a reviewable handoff
Before the SOV moves forward, keep three layers distinct:
- the original submitted values;
- normalized working fields; and
- enriched fields with source and date context.
Document material transformations, keep the original file unchanged, and record who resolved manual exceptions. The goal is not a spreadsheet with no blanks. It is a schedule where each populated field can be understood and each important gap can be found.
Use the property submission checklist to review the resulting file before it reaches the market.
Download an SOV template
Start with the blank SOV CSV template . The companion fictional example CSV demonstrates field placement only; its sample address, values, and dates are not real and must not be used for underwriting.
| Field | What to enter |
|---|---|
account_id | Stable account or submission identifier. |
location_id | Stable identifier for a site or location. Reuse it for buildings at that location. |
building_id | Stable identifier for an individual building. |
street_address, city, state, postal_code, country | Separate address components. Preserve postal codes as text so leading zeros are retained. |
occupancy_description | Specific use of the building, including mixed use where material. |
construction_type, year_built, stories, building_area_sq_ft | Submitted building characteristics. Leave unknown fields blank and document conflicts. |
building_value_usd, business_personal_property_value_usd, time_element_value_usd | Submitted values in USD. These are separate coverage categories; do not duplicate a total across them. |
total_insured_value_usd | Submitted total insured value in USD, when supplied. Reconcile it to component values using the submission’s conventions. |
protection_notes, roof_year | Submitted protection or roof context. Record evidence in notes where available. |
source, source_date | Source and date for the row or input where known. Keep field-level sources in notes when they differ. |
notes | Open questions, exceptions, units, or source limitations. Do not use notes to silently overwrite submitted values. |
The template is a starting structure, not a required PerilScore import schema. Keep a copy of the original submission and map these fields to your team’s agreed format before upload.
When you need to map a working file into an established data exchange, consult ACORD’s Property and Casualty data standards and the carrier’s accepted submission format. The CSV above is a practical worksheet, not an ACORD form or universal schema.