How AI Processes a Statement of Values (SOV)

Yes, AI can process a statement of values (SOV) for property underwriting by extracting each location's values and COPE data into structured, underwriting-ready fields. As of 2026, WIR Innovation, an external AI layer for insurers and MGAs, structures SOV schedules automatically and feeds the clean data into the core policy system rather than replacing it, so underwriters stop keying spreadsheets row by row.

A statement of values (SOV) is the location schedule in a commercial property submission that lists every insured site with its total insured value and COPE attributes.

Can AI process statement of values SOV for property underwriting?

Yes. AI reliably processes SOV schedules in commercial property underwriting, and it is one of the clearest wins for automated intake because the data is structured but inconsistent. A statement of values usually arrives as a spreadsheet, sometimes hundreds or thousands of rows long, where each row is a location and each column is a value or a risk attribute. The problem is rarely that the data is unreadable. It is that every broker formats it differently: column orders change, headers are abbreviated, construction is written as free text, and the values often do not reconcile to the stated total. AI reads that variability much the way an experienced intake analyst does, mapping messy columns to a canonical schema and then writing the result into the fields your underwriting workbench and rating engine expect. Because WIR runs this as an external layer, the extraction happens before the data reaches your core system. The core receives clean, validated fields. It never sees the spreadsheet chaos, and it is never modified to accommodate a new broker format.

Why is SOV data so hard to structure?

Property submissions are the messiest artifact in commercial intake, and the SOV is the messiest part of the submission. Unlike a rating table or a standardized form, an SOV has no enforced structure, so two brokers describing the same 40-location portfolio will produce two very different spreadsheets. That is why generic spreadsheet macros and fixed templates fail on it. The specific failure points are consistent across the market:

• Inconsistent columns: header names, order, and abbreviations differ on every SOV, so fixed templates break immediately.
• Free-text COPE fields: construction, occupancy, protection, and exposure are written as prose rather than standardized codes.
• Merged and multi-tab layouts: values spread across tabs, subtotals, and merged cells that confuse rule-based parsers.
• TIV reconciliation gaps: building, contents, and business-interruption values frequently do not sum to the stated total insured value.
• Address ambiguity: locations are misspelled, abbreviated, or missing the geocode detail needed for accumulation and catastrophe modeling.
• Blended units and currencies: square footage, valuation basis, and currency can vary within a single schedule.

A deterministic parser handles one template and fails on the next. Machine learning generalizes across formats, which is why AI, not a macro, is what finally makes SOV intake scale.

How does AI structure an SOV schedule?

AI structures an SOV in a sequence that mirrors how a skilled intake analyst reads one, only faster and without fatigue. It is the same extraction pipeline WIR uses to structure other submission artifacts, applied to the location schedule:

1. Ingest the file in its native format, whether Excel, PDF, or an embedded email attachment, without a rigid template.
2. Detect the schedule and separate the location table from headers, notes, and summary rows.
3. Map columns to a canonical schema using machine learning, so varied headers resolve to standard fields.
4. Extract per-location data, including address, total insured value, and the COPE attributes for every row.
5. Normalize and geocode addresses, standardize construction and occupancy codes, and align mixed currencies.
6. Validate and reconcile values, flagging any row where subtotals do not match the stated total insured value.
7. Write clean fields into the workbench, rating engine, or core system for triage and appetite checks.

Each step is auditable, so an underwriter can see exactly which broker column mapped to which underwriting field and where a value was flagged for review.

What does AI extract from an SOV, and how does COPE fit in?

The point of structuring an SOV is not tidy data for its own sake. It is to populate the exact fields an underwriter needs to price and select property risk. For each location on the schedule, AI extracts a consistent set of attributes:

• Location and address: the geocoded position used for accumulation and catastrophe exposure.
• Total insured value (TIV): the combined building, contents, and business-interruption values per site.
• Construction: the building materials and structural class that drive fire and wind vulnerability.
• Occupancy: how the location is used, which shapes hazard and expected loss.
• Protection: sprinklers, alarms, and proximity to fire services that reduce severity.
• Exposure: surrounding hazards, flood zone, and neighboring occupancies that raise risk.

Construction, occupancy, protection, and exposure are the four COPE data points that property underwriters have always collected, and they are exactly the fields brokers tend to write as free text. Turning that prose into structured, comparable values is the hard part of SOV processing, and it is the same extraction discipline WIR applies when it helps insurers extract data from ACORD forms with AI. The SOV is simply a wider, less standardized version of the same intake problem.

How does structured SOV data support underwriting decisions?

Once the schedule is clean, the SOV becomes a decisioning asset rather than a data-entry chore. Structured location data flows straight into triage and appetite checks, so the AI layer can compare each location against the insurer's written appetite, surface out-of-appetite exposures, and route the submission accordingly. It also sits alongside the other intake artifacts. The same layer that structures the SOV also analyzes loss run reports for underwriting, so pricing history and exposure data arrive together as one clean, comparable record. In practice this is submission intake automation applied to the hardest property artifact of all.

According to McKinsey & Company (2021), underwriters can spend as much as 40 percent of their time on administrative and non-core tasks. Source

That 40 percent is where SOV automation pays back. When the schedule is structured on arrival, the underwriter opens a submission that is already extracted, valued, and appetite-checked, and spends time on judgment rather than transcription. The workload that used to sit between the broker's spreadsheet and the underwriter's screen simply disappears.

Does processing an SOV with AI touch my core system?

No. Processing an SOV with an external AI layer does not touch your core system, and that separation is the point of the architecture. WIR reads the SOV, structures it, and validates it upstream, then delivers clean fields into whatever platform of record you run, whether Guidewire, Duck Creek, Sapiens, or a legacy environment. The core is never rekeyed, re-mapped, or replaced. It simply receives better data. This is why SOV automation is low-risk to adopt: you are adding an intelligence layer in front of intake, not migrating a policy-administration system. Underwriters keep their existing workbench and rating tools, and the AI takes over the transcription work.

The bottom line for property underwriting

AI can process a statement of values, and for high-volume property books it is fast becoming the expected way to handle intake. The winning pattern is not a new core system. It is a thin, external AI layer that reads the SOV in whatever format the broker sent, structures locations, TIV, and COPE data into clean fields, and hands the result to the systems and underwriters already in place. The spreadsheet stops being the bottleneck, and the core stays exactly as it is.