Habitational excess turns on the portfolio: how many doors, in what construction, where — and a loss picture built from slip-and-falls, habitability and premises-security claims. The submission is an SOV, GL and WC schedules, and a premises-heavy loss run over a $25M lead umbrella. We ran a real 55-property portfolio, Beacon Harbor Residential, through InsightXtract on the Excess Casualty agent.

Insured: Beacon Harbor Residential LLCRevenue $142M GL payroll $38.1MWC payroll $58.5M Properties (SOV) 55Named insureds 34 5-yr claims 23 / $7.8M incurredLead umbrella $25M

Why habitational is an excess casualty risk

Apartment owner-operators buy primary GL over a large, distributed schedule of values and stack an umbrella on top — the excess sits over premises liability across dozens of properties, plus habitability and assault/battery exposure. Because a single claim (a fall, an assault, a fire) can pierce the primary, the tower and the per-location aggregate structure matter as much as the raw limits.

The submission packet

A real habitational placement is rarely one clean file. This one is five, in four different shapes — the everyday reality an underwriting team has to re-key by hand today:

  • broker_email.pdf — the renewal narrative: account description, requested limits, exposure snapshot, and the excess-layer options to quote.
  • rfq.pdf — the umbrella/excess application: general information, coverage requested, and the exposure bases.
  • exposure_workbook.xlsx — the heart of the file: a 55-property SOV (occupancy & construction), GL exposure by state and class, WC payroll by class, and a named-insured schedule of the property LLCs.
  • loss_run.pdf — five years of currently-valued losses, dominated by general liability (premises) with a workers-comp property-management book.
  • schedule_of_underlying.pdf — the primary casualty and lead umbrella the excess attaches over.

Step 1 — Classification

Every file is routed to a document type first — evidence-bearing, with a confidence, not a black-box label:

Document
Classified as
Conf.
broker_email.pdf
excess_casualty_submission_email
0.98
rfq.pdf
excess_casualty_application
0.97
exposure_workbook.xlsx
excess_casualty_exposure_workbook
0.99
loss_run.pdf
excess_casualty_loss_run
0.98
schedule_of_underlying.pdf
excess_casualty_schedule_of_underlying
0.96

Step 2 — Coverage structure, with citations

The requested tower is read from the email and application, every value grounded to its page:

CoverageRequestedSource
General Liability — each occurrence$1,000,000rfq p.2
General Aggregate$2,000,000rfq p.2
Products / Completed-Ops Aggregate$2,000,000rfq p.2
Commercial Auto — CSL$1,000,000rfq p.3
Employers Liability$1,000,000rfq p.3
Lead Umbrella$25Memail p.1

Step 3 — Exposure schedules, typed & normalized

The workbook is where template OCR falls over — many sheets, hundreds of rows, broker-specific wording. InsightXtract reads every sheet, maps each to a typed schedule, and normalizes the codes against governed glossaries. A slice of the GL exposure schedule:

StateWC CodeDescriptionRevenuePayroll
FL us_state_codes60010 ncciApartment building operation$14,200,000$2,130,000
GA us_state_codes61212 ncciCondominium operation$9,800,000$1,470,000
TX us_state_codes62003 ncciProperty management$7,300,000$1,095,000
… 40 GL rows · workers_compensation 46 · named_insured_mix 34 · location_list 55

Column bindings: state → us_state_codes, class → ncci_wc_class_codes / iso_gl_class_codes, occupancy → occupancy_types. Out-of-vocabulary values are flagged by validation, not silently kept — and fuzzy column resolution means a rule written for payroll still binds a broker’s “Total Payroll” column.

Step 4 — Derived exposures (deterministic, not guessed)

The account is rated on totals. Rather than ask a model to eyeball-sum hundreds of rows, the document type declares deterministic sum / count / group_by rules that reduce the extracted schedules exactly — the same numbers every run, each traceable to its source table:

$38.1M
GL payroll
∑ general_liability.payroll
$58.5M
WC payroll
∑ workers_compensation.payroll
55
Properties (SOV)
count(location_list)
34
Named insureds
count(named_insured_mix)

Step 5 — The loss run

For a habitational account the loss run is a premises story — common-area falls, habitability, assault, and the occasional pool or dog-bite claim. Every claim is extracted — coverage line, status and cause normalized — and rolled up, with a by-line split for the loss pick:

Claim #CoverageCauseStatusIncurred
BEA-4417GL coverage_linesSlip/Fall - common areaOpen claim_statuses$286,400
BEA-4388GL coverage_linesHabitabilityClosed claim_statuses$142,000
BEA-4361WC coverage_linesLifting strainClosed claim_statuses$38,600
… 23 claims across 5 policy years, currently valued
23
Claims (5 yr)
count(claims)
$7.8M
Total incurred
∑ claims.incurred
by line
Incurred split
group_by coverage_line

What the underwriter reads first

The coded record surfaces exactly the drivers that move this class of business:

  • Door count & construction mix from the SOV — frame vs. non-combustible drives the premises rate.
  • Occupancy & assault exposure — garden vs. high-rise, and the requested abuse & molestation / assault-battery sub-limits captured from the email.
  • Per-location aggregate and how a single large loss attaches to the umbrella.
  • Premises loss frequency by property, from the coded loss run.

Why it holds up in production

  • Every value is cited — page/region provenance on fields and schedules; a file review can click any number to its source.
  • Codes are normalized against governed glossaries; out-of-vocabulary values are validated, not hidden.
  • Totals are computed, not guessed — deterministic derived fields over the extracted rows, exact and reproducible.
  • Configuration is versioned — document types, glossaries and rules pinned to a published version, so an output made today reproduces tomorrow.
  • Nothing is dropped — the all-sheets extractor surfaces every schedule, even ones the base schema didn’t anticipate.