Loss run extraction automation turns a carrier's loss run report — the periodic claim history an insurer sends an insured or its agent — into structured data an agency or underwriting file can use. The hard part isn't reading the PDF; it's that extraction built for one carrier's layout won't necessarily work for the next. This article gives a minimum field schema built for that variation, plus a five-check tie-out test for catching a bad extraction before it reaches a renewal file.
At a glance
- Carrier loss run formats differ; this article's minimum field schema is built to map onto any of them.
- A five-check tie-out — totals, valuation date, policy periods, open reserves, and duplicate claims — catches a bad extraction before it reaches underwriting.
- Reserves and incurred totals are only accurate as of a report's valuation date; capture that date with every extraction, not just the dollar figures.
- A missing policy year or a 'no known losses' letter needs its own handling, not a blank row.
- Extracted loss run data should route to a reviewer when a tie-out check fails, not post automatically to a quote or renewal file.
What is in a loss run report?
A loss run report is a carrier's record of an insured's claims for one or more policy periods, issued as of a valuation date. IRMI, the commercial insurance reference, defines a valuation date as [1] "the cutoff date for adjustments made to paid claims and reserve estimates in a loss report." Whatever a carrier's own layout, sort what's on the report into three layers: header information, claim-level detail, and summary totals.
- Header information: named insured, policy numbers, line of coverage, and the policy period(s) covered.
- Claim-level detail: one row per claim, with claim number, date of loss, a short description, status, and the paid, reserve, and incurred amounts as of the valuation date.
- Summary totals: paid, reserve, and incurred by policy period and line — figures the claim-level rows should tie back to.
Layout, column order, and terminology are carrier-specific. The schema below names the fields worth extracting so any of those layouts can map to the same set.
The loss-run field schema and accuracy test
Treat extraction from a loss run like extraction from any variable-format document: define the minimum fields every output must have, then test every extraction against the source. The table below is that field set; the five-check list after it is the test.
What fields should be extracted from every loss run?
Several of the fields below carry published definitions from IRMI's insurance glossary worth matching exactly. IRMI's own example for valuation date shows the scope: [1] "a workers compensation loss report for the 20x3 policy year that has a 20x5 valuation date includes all claim payments and changes in loss reserves made prior to the 20x5 valuation date." A loss run's paid column works the same way: it's cumulative to the valuation date, not limited to a single accounting period.
| Field | What it captures | Why the tie-out check needs it |
|---|---|---|
| Named insured | The policyholder named on the loss run; should match the renewal exactly. | Confirms the report belongs to the account being quoted or renewed. |
| Carrier | The insurer that issued this loss run report; record which carrier issued each period when a report spans more than one. | Tells one carrier's claim numbers and totals apart from another's, including in the duplicate-claim check below. |
| Document type | A claim-level loss run, or a "no known losses" letter. | Lets a true zero-claim period be told apart from an extraction that found nothing. |
| Policy number(s) | Every policy number the loss run covers, including prior carriers' numbers. | Links each claim row to the specific policy it falls under. |
| Line of coverage | The coverage line each section reports under: general liability, auto, workers' compensation, property, etc. | A loss run covering multiple lines needs totals kept separate by line. |
| Policy period(s) | The effective and expiration date of each policy period the report covers. | A gap between periods means the loss history is incomplete. |
| Claim number | The carrier's unique identifier for each claim. | The key for matching a claim across years, re-pulls, or duplicate rows. |
| Date of loss | The date the incident occurred, not the date it was reported. | Determines which policy period a claim belongs to. |
| Claim status | Open, closed, or reopened as of the valuation date. | An open claim's reserve can still change; a closed claim's figures are final. |
| Paid loss | Paid losses, plus ALAE if the carrier's paid column includes it, cumulative to the report's valuation date, not a single accounting period. | Should sum to the report's own paid total by policy period and line; confirm whether ALAE sits inside this figure or in its own column. |
| Outstanding reserve | The carrier's current estimate of what's left to pay on an open claim, as of the valuation date. | Drives the incurred total; flag it if a re-pulled report shows a different reserve under the same valuation date. |
| Incurred | Paid plus outstanding reserve for a claim or group of claims. | The input a loss ratio calculation uses; compare it against the report's own incurred total in the first check below. |
| Valuation date | The cutoff date for the paid and reserve figures on the report. | Without it, there's no way to know how current the open reserves are. |
| Report-level totals | The carrier's own sum of paid, reserve, and incurred by policy period and line. | The number every claim-level row should tie back to in the first check below. |
IRMI's separate glossary entry defines a paid loss as [2] "losses and allocated loss adjustment expenses (ALAE) paid to claimants during a financial reporting period." Record whether a carrier's paid column keeps ALAE with indemnity or reports it separately; if that differs from how your schema defines paid, the totals check fails. A loss reserve is [3] "an estimate of the value of a claim or group of claims not yet paid."
Incurred losses are [4] "the total amount of paid claims and loss reserves associated with a particular time period." IRMI defines policy period this way: [5] "the policy period signifies the duration of the policy."
How do you verify extracted loss runs against report totals?
A field schema only says what to pull. The five checks below say whether it can be trusted, for any format once the fields above are mapped.
- Totals tie out
Sum paid, reserve, and incurred from the claim-level rows and compare the result to the report's own totals, by policy period and line. A mismatch means a row was dropped, mis-mapped, or a subtotal was misread. If the report prints no totals row, mark the check not verifiable and route the extraction to a reviewer.
- Valuation date is captured
Record the date the report is run as of, not just the dollar figures. Without it, there's no way to tell whether an open reserve is current or stale.
- Policy periods are complete
Confirm every policy period the submission or renewal needs is present, with no gap between one expiration date and the next effective date.
- Open reserves are flagged, not dropped
Every open claim should carry a reserve amount; a blank or zero reserve on an open claim is a flag to check against the source, not a zero to accept.
- No duplicate claims
Check claim numbers for exact and near-duplicates — the same claim re-listed across periods. A claim carried over under a new number from a prior carrier won't show up this way; cross-check date of loss, claimant or description, and amounts.
A failed check is a routing decision, not an automatic rejection: send the mismatch to a reviewer, following the same human-in-the-loop principle covered in human-in-the-loop AI governance.
How do you handle missing years or no-loss letters?
A loss run request can come back with a gap: a missing policy year, or a "no known losses" letter instead of a claim-level report. Treat both as data to record, not a blank to skip past.
Extract a no-loss letter as a zero-claim row, keeping the letter as the source document, not as a gap in the loss history. A year the carrier never produced, with no letter explaining it, should block the policy-periods-complete check until it's requested or explained, not filled in with an assumed zero.
When this doesn't apply
- The account has one or two policy years of loss history on one consistent carrier format; a person can tie that out as fast as a system can be built for it.
- Loss runs arrive as scanned, low-quality images with no machine-readable text; fix the intake channel with the carrier or managing general agent (MGA) first.
- The underwriting decision needs the adjuster notes behind a specific claim, not just the summary fields; a person still has to read the file.
- Nobody has agreed what the field schema should contain for your book of business; agree the fields first, as the table above does.
Where to start: a first scoped workflow
Start with one line of coverage and one carrier format, and prove the schema and tie-out checks before you scale either.
- Pick one line and one format
Choose the coverage line and carrier format with the largest share of your loss run volume, and build the schema and checks against it first.
- Extract against the schema
Map every field in the table above, leaving a field blank, not guessed, when the source doesn't state it.
- Run the five-check tie-out
Apply every check above to each extraction before anyone downstream sees the output.
- Route failures to a reviewer
Send anything that fails a check to a person who can open the source, rather than a rule that guesses which number is right.
- Add formats once the first is solid
Only after the first format's failure rate is acceptable to reviewers should you add the next carrier format or line.
Frequently asked questions
What is in a loss run report?
Sort a loss run report into three layers: header information (named insured, policy numbers, line of coverage, policy periods), claim-level detail (claim number, date of loss, status, paid, reserve, incurred amounts), and the carrier's summary totals by period and line where printed, all as of a valuation date.
What fields should be extracted from every loss run?
At minimum: named insured, the issuing carrier, document type, policy number, line of coverage, policy period, claim number, date of loss, claim status, paid loss, outstanding reserve, incurred total, the valuation date, and the report's own totals by period and line — the fields a tie-out check uses to confirm the extraction is complete.
How do you verify extracted loss runs against report totals?
Run five checks before trusting the output: the claim-level sum ties to the report's own totals, the valuation date is captured, every policy period is present, every open claim carries a reserve, and claim numbers show no duplicates. Route anything that fails a check to a reviewer who can open the source document.
How do you handle missing years or no-loss letters?
Extract a "no known losses" letter as a zero-claim row for that policy period, keeping the letter itself as the source document. Treat a year the carrier never produced, with no letter explaining it, as a block on the policy-periods-complete check until it's requested or explained, never fill it in with an assumed zero.
How accurate does loss run extraction need to be for underwriting?
This article doesn't publish an accuracy figure, because the right threshold depends on what the extraction feeds: a quick submission triage tolerates more error than a bound renewal. Set the bar with the five-check tie-out list; passing every check on a hand-verified sample is the test, not a published percentage.
Related reading
- The document review with human approval solution page covers the extract-flag-approve pattern a failed tie-out check routes into.
- The insurance invoice analysis solution page covers a similar rulebook-driven extraction workflow on the invoice side.
- For a method to measure extraction accuracy on your own documents rather than a vendor's, see how to build a ground truth dataset for document extraction.
- For the difference between extraction accuracy and financial accuracy, see extraction accuracy vs. financial accuracy.
- The AI agent implementation service describes how a workflow like this one is scoped, tested, and handed over.
Sources
- IRMI, "Valuation Date" (insurance glossary) (accessed 2026-09-30)
- IRMI, "Paid Losses" (insurance glossary) (accessed 2026-09-30)
- IRMI, "Loss Reserve" (insurance glossary) (accessed 2026-09-30)
- IRMI, "Incurred Losses" (insurance glossary) (accessed 2026-09-30)
- IRMI, "Policy Period" (insurance glossary) (accessed 2026-09-30)
More in Insurance operations
What AI Claims Automation Costs: A Cost and ROI Model for Carriers, TPAs and MGAs
AI claims automation cost depends on scope, not a price list. Get the cost drivers, an LAE baseline worksheet, and a payback method for carriers, TPAs and MGAs.
Insurance CompaniesBordereaux Automation for MGAs and Carriers: Ingestion, Validation and Reconciliation Checks
Bordereaux automation for MGAs and carriers: a validation-and-reconciliation check matrix with data source, rule, tolerance, owner and action for every check.
Insurance CompaniesInsurance Commission Reconciliation Automation: AMS Module, Point Tool or Custom AI Agent?
Choosing insurance commission reconciliation automation: a decision matrix for AMS module vs. point tool vs. custom agent, and a discrepancy routing table.
Insurance Companies