The loss run: what it is, and why its valuation date changes the answer
In short
A loss run report is a carrier's claim-level extract of everything reported against a policy, produced as at a single valuation date. That date is the load-bearing field: open claims keep developing, so two runs covering the same policy term but valued six months apart will show different incurred totals and both will be correct.
Key takeaways
- A loss run is a point-in-time extract, not a ledger: open files develop after it is produced.
- Incurred is paid plus outstanding reserve, so it moves down as well as up between 2 valuations.
- The valuation date sits in a header or footer — exactly where table-only extraction loses it.
- Some carriers report incurred net of recoveries and others gross; 1 numeric field cannot hold both.
- Store a run as a header plus claim rows, with the valuation date non-nullable on the header.
A loss run is the report a carrier or third-party administrator produces listing every claim recorded against a policy, claim by claim, with dates, status and what has been paid and reserved on it. The same artefact travels under other names — claims experience report, loss history, claims listing — and they generally mean this document.
The difficulty is not the layout. The report describes files that are still moving, frozen at one moment, and if that moment is not captured none of its numbers can be compared to anything.
Who produces it, and what period it claims to cover
The producer is whoever holds the claim records: the carrier on a conventional programme, a TPA on a self-insured or large-deductible one, sometimes both across different years of one account. A run must therefore be attributed to its producer, which is why the carrier record needs the company code that joins it rather than the name on the letterhead.
Coverage is organised by policy term, commonly 3 to 5 terms deep. A claim appears under the term whose policy period contains its date of loss, not the term it was reported in — which is how a late-reported claim lands on a term that closed years ago. Note what is absent: case reserves only, never IBNR.
The column families every version has, under different names
There is no standard layout, only a standard set of things the report is trying to say, in each carrier's own headers and column order. Normalising to these families is most of the work.
| Column family | What it holds | The trap when normalising it |
|---|---|---|
| Claim identity | Carrier claim number, sometimes a separate occurrence reference | Numbers are unique only within a carrier, so the key is carrier plus number |
| Policy and term | Policy identifier and the term the claim attaches to | Term suffixes make 1 policy look like several; anchor on term dates too |
| Dates | Date of loss, date reported, date closed, sometimes reopened | Loss and reported dates sit in different column orders and are easily transposed |
| Status | Open, closed, reopened, plus litigation or subrogation flags | Closed with an outstanding reserve means closed in the source system, not final |
| Financials | Paid indemnity, paid expense, outstanding reserve, incurred, recoveries | Some carriers report incurred net of recoveries, some gross; 1 field cannot hold both |
| Cause and coverage | Cause of loss and coverage part, often with free text | Codes are carrier-defined, so mapping to a shared taxonomy is a lookup, not a rename |
Incurred is paid plus outstanding reserve, so it moves both ways: a reserve released on a file that settled cheaply pulls the term total down. Store paid and outstanding separately and derive incurred, so the arithmetic stays checkable.
Valuation date: the field that decides whether two reports disagree
The valuation date is the moment the extract was taken. Open claims develop after it — reserves revised, payments made, files closed and occasionally reopened. A run valued in March and one valued in September are 2 photographs of the same moving thing. Separating real revaluation from extraction fault is worked through in two loss runs covering the same period with different totals.
A target schema that refuses to store a run without its date
Model the report as 2 records rather than one flat table: a header for what is true of the whole run, rows for the claims. A mandatory header is what stops an unusable extract entering AMS360, Applied Epic or your own warehouse quietly.
- Header, required. Producing carrier and code, named insured as printed, policy identifier, term start and end, valuation date, currency, and a hash of the source file.
- Header, also worth keeping. Producer type, and whether the output is claim-level or a summary exhibit — a summary cannot be reconciled row by row and should not share a table.
- Row, required. Claim number, date of loss, status, paid indemnity, paid expense, outstanding reserve, and a per-field confidence so review is targeted rather than wholesale.
- Row, derived and flagged. Incurred, with an explicit marker for gross or net of recoveries. Recomputing later from an unflagged number is guesswork.
A loss run without its valuation date is not a weaker loss run. It is a page of numbers with nothing to attach them to.
Two neighbouring documents differ enough that they should not share an extractor: the short dense field set of the declarations page as a structured record, and the column-unstable statement of values as a schedule you can parse.
Ask for the valuation date explicitly rather than inferring it later — the structured-request discipline that a change request must carry on the servicing side. Extraction, thresholds and the review queue behind it are AI agents and automation work, under the constraints in running AI agents in production. This page sits in the forms: extraction and classification, part of our insurance and claims software practice.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is a loss run report?
It is a claim-level listing of everything reported against a policy, produced by the carrier or TPA holding the claim records. Each row carries a claim number, dates, status, what has been paid and what is still reserved. Brokers request it at renewal and underwriters price from it, usually across the last 3 to 5 policy terms.
What does the valuation date on a loss run mean?
It is the moment the extract was taken, and everything on the report is true only as at that moment. Open claims keep developing afterwards, so a run valued in March and one valued in September show different figures for the same term. Without the date, nothing on the report can be compared with any other source.
Is a loss run the same thing as a claims experience report?
In most usage, yes: loss run, claims experience report and loss history describe the same claim-level document. The distinction worth enforcing is claim-level versus summary. Some carriers issue an exhibit showing totals per term with no individual claims, which cannot be reconciled row by row and should not share a table.
- loss runs
- document extraction
- insurance data
- underwriting
The work behind this page
Builds from our portfolio that this page draws on.
AP Copilot
An AI accounts-payable copilot that reads invoices, matches them to POs, and routes clean approvals
FintechAskVault
An AI internal knowledge-search platform that answers employee questions from your own docs — grounded in citations, with knowledge gaps surfaced and deflection tracked.
Productivity AIScanQueue
An AI radiology worklist that flags suspected critical findings on incoming CT, MR and X-ray studies and orders every read by acuity and SLA — so the sickest patient is read first, not FIFO.
Healthcare AIRead next
- The declarations page: the shortest document saying what was boughtThe dec page is an index, not a contract. It names the parties, the term, the limits and the forms attached, and a third of those fields have no standard shape at all.definition
- Statement of values: a spreadsheet pretending to be a policy documentAn SOV is a table whose columns were agreed between a broker and a carrier, not standardised by anyone. Settle the grain and the valuation basis first.definition
- Cause of loss: the coded field, and why the caller's story is not itThe loss narrative and the coded cause of loss are two fields with two jobs. Conflating them gives reporting nobody trusts and routing nobody can explain.definition
- Claim severity score: a routing input, not a reserve and not a decisionA severity score exists to decide which queue a new claim joins and how fast. Everything a licensed person is accountable for stays outside its remit.definition
- Claimants start the online loss report and phone in anywayChannel fallback is measurable. A step-level drop table segmented by device and reporter, joined to inbound calls within the following hour, names the step that sends people to the phone.diagnostic
- Claims leakage: what the term actually counts, and what it quietly cannotLeakage is a subtraction where 1 of the 2 numbers came from a reviewer imagining a file that never happened. The standard is part of the answer.definition
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation