Four Numbers on a Loss Run Report
That Have to Agree
Two loss runs for the same account can put the same claim at different costs and both be right. One was valued in March, the other in September, and the reserve moved in between. That difference is easy to explain. The hard one shows up when the dates match and the numbers still will not reconcile, because each carrier decided for itself what belongs inside paid and whether a reserve has to be printed at all.
Key Takeaways
- A claim with $9,000 paid and an $86,000 reserve can land in your sheet as a $9,000 claim, and every total still ties.
- The reserve column can legally be missing, so a computed Incurred quietly returns paid for every open claim.
- Leave a missing reserve blank instead of zero, because blank reads as unknown and zero reads as a fact.
A Loss Run Is Three Documents Stacked Together, and Only the Middle One Is a Claim Table
Every loss run report carries a header, a claim grid and a set of totals, and the claim grid is the only part that becomes rows in your spreadsheet. The header identifies the insured, the carrier, the policy numbers, the line of coverage and the policy periods. The claim grid lists one claim per block or row. The totals restate paid, reserve and incurred by policy period and often by coverage, plus a claim count.
The header also carries the valuation date, sometimes labeled "as of" or "evaluated." It is the cutoff for every paid and reserve figure on the page. Without it, an incurred number is a value with no clock attached, and two reports cannot be compared even when they cover the same claim. A loss run printed on 14 October tells you what the carrier believed on 14 October, and nothing about what it believes now.
Reading the file as one continuous table is where the first errors come from. The claim grid often starts on page two or page five, scans repeat the policy header at the top of every page, and totals rows share the column shape of claim rows. A year with no claims may arrive as a "no known losses" letter rather than a blank page, which is a real document and not an empty result. Everything below assumes those layers are separated before anyone talks about accuracy.
Four Numbers Decide Whether Two Reports Can Be Compared at All
Paid, reserve, incurred and the report's own printed total are the only figures that have to agree before the rest of the table means anything. The other fields explain how those numbers got there. They do not test them.
| Number | What it is | Why it decides comparability |
|---|---|---|
| Paid | Money the carrier has already disbursed on the claim, cumulative to the valuation date | It only moves in one direction, so it is the floor of the claim's final cost. Whether it includes defence and adjusting expense is the first thing to settle. |
| Reserve | The adjuster's estimate of what is still to be paid on an open claim | It is an opinion, revised as facts arrive. It is also the column most often missing from a legally compliant report. |
| Incurred | Paid plus outstanding reserve, as of the valuation date | It is the figure that gets compared to premium. If two carriers define it differently, the comparison measures the definitions. |
| Printed total | The carrier's own sum of the claim rows, by policy period and line | It is the only independent check on whether you captured every row. No total means the check cannot be run. |
Incurred is the one an underwriter actually prices. A claim with $47,000 paid and a $28,000 reserve is a $75,000 claim, not a $47,000 one, and the open reserve is where loss development still hides. What surprises people new to this work is how often incurred is not printed at all. It is a derived figure, and on many reports the carrier gives you the two inputs and expects you to add them.
Incurred Breaks First, and the Cause Is Usually a Definition Rather Than a Typo
Three carrier conventions can move incurred by tens of thousands on the same claim, and only one of them announces itself on the page. None of them is an extraction error. All of them become extraction errors if your column set ignores them.
Expense sits inside or outside the money columns. Many carriers fold allocated loss adjustment expense, the defence counsel and independent adjuster cost, into paid and reserve. Others print "loss only, ALAE not included" and put expense in separate columns. If you extract paid and reserve from both without reading the note, you are comparing a claim that includes $30,000 of defence cost with one that excludes it. If you also add the separate expense columns into incurred for a carrier that already folded them in, you count the same dollars twice. The note decides which of your two rules applies, and it is usually a stamp or a footnote, not a column header.
Recoveries are netted or shown gross. Subrogation and salvage money recovered from a third party can reduce incurred, or sit in their own column while incurred stays gross. A claim that paid $80,000 and recovered $60,000 from a subcontractor is a $20,000 net loss and an $80,000 gross one. Both numbers are correct. Adding one carrier's net figure to another's gross figure is not.
The reserve may not exist, and that can be fully legal. Florida requires an insurer to send an insured a five-year loss run within 15 calendar days of a written request, and the same statute states that an insurer is not required to provide loss reserve information (Fla. Stat. § 627.444). Kentucky sets a 20-day window on the same five years (KRS 304.20-100). The request side is regulated. The content is not standardized. Even the form is standardized on one side only: ACORD 611 is a claims history and loss run request, not the report itself, and the report that comes back follows no shared layout (ACORD forms index). Brokers describe the same variation: some carriers print a date of loss, others only a report date, some leave reserves and claim expenses off entirely, and some show almost nothing on a claim until it closes (r/InsuranceProfessional).
On a paid-only report, a computed incurred column returns paid. A claim with $9,000 paid and an $86,000 reserve becomes a $9,000 claim, the sheet fills cleanly, and nothing in the process reports an error.
That failure is worth sitting with, because it is the one that survives every downstream check. The row count is right, the totals tie, the file opens. The account simply looks better than it is. The only defence is a rule applied before the arithmetic: a missing reserve stays blank, never zero, and a status column records that the field was not reported. Blank propagates as unknown. Zero propagates as a fact.
Row Count and Grouping Fail Next, Even When Every Dollar Is Right
A claim table can pass every arithmetic check and still overstate frequency, because frequency is counted in rows rather than dollars. Four problems account for most of the damage.
Totals rows counted as claims. A subtotal line has a claim-shaped amount and often a blank claim number. If it lands in the data, the policy period gains a phantom claim and the dollars are counted twice. Since the count is what an underwriter reads first, that error changes the story about the account's operations even when incurred is correct.
One accident, two claim numbers. A yard tractor striking a visitor can be reserved under both auto and general liability, with a separate claim number under each coverage. Deduplicating on claim number finds nothing, because the two numbers are genuinely different. The workable rule is to match on date of loss, description and amount, count the accident once, and keep both coverage reserves. Applied blindly, the same accident doubles the claim count and the incurred.
A closed claim with no payment still counts. It contributes $0 to severity and one claim to frequency, which is exactly the signal a risk manager needs when a safety programme is failing quietly. Filtering rows to "amount greater than zero" deletes the most useful pattern in the report.
Valuation dates that differ inside one submission. A five-carrier packet can contain five valuation dates, and one of them is often years old because the same report has been forwarded with the account since it was issued. Summing incurred across those reports produces a total that no single date supports. Keep the valuation date on every row and refuse to pool reports without saying which date each figure belongs to.
The Fields an Underwriter Reads First, and the Report-Level Fields That Keep Them Attached
A claim row without its policy context is unusable, because the same claim number means nothing until you know which carrier issued it and which period it falls under. That is why the column set has to carry both levels on every row, not just in a cover sheet. For a broker assembling a packet, the deliverable is underwriting submission data: a claim-level table a rating system or an underwriter's workbook can absorb without another transcription pass.
| Field | Level | What it does in the table |
|---|---|---|
| Named insured | Report | Confirms the report belongs to the account being quoted |
| Carrier | Report | Separates one carrier's claim numbers and totals from another's |
| Policy number | Report | Attaches each claim to a policy when one report spans several |
| Line of coverage | Report | Keeps general liability, auto, property and workers comp totals apart |
| Policy period | Report | Places the claim in a policy year and exposes a missing year as a gap |
| Valuation date | Report | Dates every paid and reserve figure on the row |
| Claim number | Claim | The key for exact duplicates and for matching a re-pull |
| Date of loss | Claim | Decides the policy year, and catches losses dated outside the period |
| Date reported | Claim | A long gap after the loss flags late reporting and claims that tend to develop |
| Description or cause | Claim | The only severity clue on a paid-only run, and the tie-breaker for one accident under two coverages |
| Status | Claim | Open, closed, reopened, closed without payment. Decides whether the money can still move |
| Paid | Money | Loss paid to date, plus expense if the carrier folds it in |
| Reserve or outstanding | Money | Remaining estimate on an open claim; leave blank when not reported |
| Expense or ALAE | Money | The column that decides whether incurred is gross or net of defence cost |
| Recoveries | Money | Subrogation and salvage, which may or may not already be netted out |
| Incurred | Money | Printed on some reports, derived on others. Keep the printed version when it exists |
Workers compensation runs need two more columns. The first is claim type, medical only or lost time, because a book of medical-only claims reads very differently from one carrying indemnity at the same total dollars. The second is the medical and indemnity split, since both can be paid or reserved separately. Everything else follows the same pattern.
One Row per Claim Is a Column Definition, Not a Document Template
Loss run extraction works by fixing the output columns and letting the reading adapt to each document. That is the difference between Custom Column Extraction and template-based parsing. You type the column names you want, such as Claim Number, Date of Loss, Paid, Reserve, Status and Valuation Date, and the AI locates each value by understanding what the label means, not by knowing where it sits on the page. Each carrier gets no template, no sample set and no configuration.
The template route fails on this document type for a structural reason. A template maps positions, so it needs one per carrier layout, and a reissued report or a new scan resolution breaks it. Twenty carriers means twenty templates and a maintenance queue. A semantic column definition is written once and applies to the next carrier that shows up, which matters in a submission where the prior carriers are not known until the packet arrives.
Batch processing is what turns the column definition into a submission-ready sheet. Upload every carrier PDF in one batch and the results merge into a single table, so a five-year history across four carriers becomes one set of rows with the carrier and policy period attached to each. Order does not matter as long as those report-level columns are carried down.
Two columns do the arithmetic that the report leaves to you. A computed column defined as Incurred (Paid + Reserve) derives the figure on every claim row, including rows where the carrier printed no incurred. A second computed column can return the difference when the row's paid plus reserve does not match the printed incurred, or when a section's claim rows do not sum to the printed period total. Both are worth having: the first fills a gap, the second tells you where the carrier's own arithmetic or your row capture went wrong.
The last setting that matters is verification. Review Mode with bbox highlighting lets you click any extracted cell and see where the value came from on the original page, and clicking a region on the page jumps back to the cell. For a loss run, that is how you check a reserve that looks low without re-reading forty pages. Turn on auto-annotate for a batch you intend to review and the highlights are waiting when you open it.
Files are processed securely and not stored.
Five Checks Decide Whether the Table Is Worth Pricing From
The table is a draft until the claim rows tie back to the carrier's own totals, and that check is the only one that can catch a missing page. Run these in order before the sheet reaches an underwriter.
Tie the claim rows to the printed total
Sum paid, reserve and incurred by policy period and line, then compare with the totals block. A mismatch means a dropped row, a misread column or a subtotal counted as a claim. If the report prints no total, mark the check not verifiable and route the file to a person.
Read the valuation date on every report
One date per report, stored on every row. Reports older than your acceptance window, commonly 90 days, get flagged rather than silently discounted. Do not add incurred across reports valued months apart without keeping the dates visible.
Confirm the policy periods are all there
Five years requested should produce five periods, or a "no known losses" letter for the empty ones. A missing year is a gap. It is not a clean year, and it must not appear as zero losses in the summary.
Flag every open claim with a blank or zero reserve
An open claim should carry an outstanding amount. A zero means either the carrier closed it without payment or the field was never reported. Check the source before either value reaches a total.
Run the duplicate check twice
Exact and near-duplicate claim numbers first. Then the same accident under two coverages, matched on date of loss, description and amount. The second pass is the one that catches the claim count inflation.
Sampling is the part teams skip when the batch looks clean. Pulling a handful of rows and reading them against the page catches the failure that totals cannot: a value that is internally consistent but attached to the wrong claim. A working routine for that is set out in batch verification and spot-check sampling.
What a Claim Table Will Not Tell You
A clean table answers what the carrier reported. It does not answer what the risk is worth. The boundary is worth stating because the failure mode on this document type is over-trust, not under-trust.
It does not make the underwriting decision. Appetite, terms, deductible structure and price stay with the underwriter. It does not produce an actuarial view: you can divide incurred by earned premium in the spreadsheet, but trend selection, development factors and credibility are not something the extraction layer does or should imply. It does not ship a connector to a carrier or agency management system. The output is a spreadsheet, CSV or JSON that you or your rating tool load, and the mapping into Applied Epic, Vertafore or an internal workbench is your integration.
It also cannot invent what the carrier left out. If the reserve column is not on the page, the correct output is a blank and a flag, not a modelled estimate. It does not resolve a definition conflict between two carriers; it can only show you that the conflict exists, which is the point of keeping expense and recoveries in their own columns. And it does not replace the loss history section on the application, where ACORD 125 and the line sections record what the applicant says about prior claims. The carrier loss run is the evidence, and the two are read together. The same caution applies to a workers compensation experience mod: it is calculated from unit statistical data the carrier files with the rating bureau, so a mismatch with the loss run in front of you is expected rather than proof of an error.
If your submission also carries certificates of insurance, those are a separate extraction job with their own fields, and the workflow for pulling certificate of insurance data into a spreadsheet is worth keeping separate. Loss runs are the claims history. Claims intake documents such as FNOL forms and repair estimates are a third category, covered in the guide to insurance claim extraction.
FAQ
Can AI read a scanned or faxed loss run?
Yes. The extraction reads the page visually rather than relying on a text layer, so a scan, a fax and a native PDF all go through the same column definitions. Legibility still sets the ceiling. A skewed third-generation fax with a stamp over the reserve column will need review, and the honest answer is that some pages should be re-requested rather than extracted.
How do I calculate incurred when the report has no reserve column?
You cannot, and you should not try. Record paid, leave reserve blank, and mark the row as reserve-not-reported. The alternative, treating the missing value as zero, produces an incurred equal to paid and understates every open claim on the report. If the number matters for the quote, the reserve has to come from the carrier or the adjuster.
Does this work across carriers without building a template for each one?
It does, because the columns are defined once by name and the extraction locates values by meaning. A paragraph-style loss run with no table at all is the harder case, since the fields may not be individually labeled. Those documents still extract, but they deserve a review pass before the rows are trusted.
Can the tool calculate a loss ratio for me?
It can give you the columns a loss ratio needs, incurred by policy year, and you can add the premium and the division yourself in the spreadsheet. It does not decide which years to include, how to annualise a partial period, or whether the result is credible for the account's size. Those are actuarial judgements.
Is a loss run the same as the loss history on an ACORD application?
No. The ACORD application section is the applicant's own summary of prior losses, completed as part of the submission. The loss run is the carrier's record, issued as of a valuation date and tied to policy numbers. Underwriters ask for both because they answer different questions, and a discrepancy between them is itself worth knowing about.
The value of the table is not that it removes the reading. It is that it puts paid, reserve and incurred in the same place for every carrier, so a definition that does not match becomes a visible gap in a column instead of a number that quietly made the account look better. That is the point at which a loss run stops being a document you page through and becomes something you can check.