Insurance
Reading a loss run you didn't format
For brokers and MGAs who receive five years of claims history as five different documents, none of which agree on what a column is called.
A loss run is a simple document with a hard job. It says what a risk has cost before, and everything that happens next — the rate you quote, the layer you place, the questions you go back and ask — rests on reading it correctly.
The difficulty is never the individual document. It is that you receive them in sets. Five years of history from three carriers is eight PDFs, and no two of them lay the same fact out the same way. One gives you incurred, one gives you paid and outstanding and expects you to add them. One puts the policy period in the header, one puts it in a footer on every page, one leaves it implied by the file name. One is a clean export. One is a scan of a printout of an export.
None of that is hard to read. It is hard to read forty times a week while keeping the numbers straight.
What actually gets extracted
Nearly every loss run question reduces to the same short list, whatever the layout:
- Policy period — which year is this, and does it abut the others or leave a gap
- Claim count — how many, and open versus closed
- Total incurred and total paid — and whether the document means the same thing by both
- Open reserves — the number that moves after you quote
- Largest claim — because the shape of the loss matters more than the total
- Loss causes — the thing that tells you whether the history is one bad year or a pattern
That list is the whole job. Once you have it for every document in the set, side by side, the underwriting question becomes answerable in a way it simply is not when the same facts are spread across eight PDFs in eight layouts.
Ragextract ships this as a starting table — those are the columns in the built-in Loss runs table, not an example invented for this article. There are matching ones for policy schedules, broker submissions and certificates of insurance, because those arrive in sets too and have the same problem.
Why a table rather than a summary
The obvious thing to want from a machine here is a paragraph: "this risk has had eleven claims totalling £340,000, mostly water damage." It reads well and it is nearly useless, because you cannot check it.
A row per document with a cell per question is checkable. Every cell in Ragextract carries the quote it came from and the page it sat on, so total incurred for 2023 is not a number you are asked to trust — it is a number with the line of the document that says it, one click away. Citations are the whole reason the output is worth having: the answer and the evidence arrive together, and when a cell is wrong you can see immediately why it is wrong, which is usually that the document said something ambiguous rather than that the reading was careless.
That matters more in insurance than in most places. You are not the last reader of this number. An underwriter, a file reviewer or, eventually, somebody in a dispute will want to know where it came from, and "the system said so" is not an answer any of them accept.
Where the seams are
Three honest limits, because they are the ones that decide whether this is useful for your book.
It reads; it does not rate. Ragextract will tell you what the loss run says. It will not tell you what to charge, will not apply your rating factors, and has no view on whether the history is acceptable. That judgement stays exactly where it is.
It does not reconcile against your system. There is no bordereau matching, no policy-admin integration and no check that the claim count agrees with what you already hold. If the carrier's document disagrees with your record, the table shows you the carrier's number and it is still your job to notice.
It does not look anything up. The engine reads the documents you give it and nothing else — it will not check a company registry, will not search the web for a court record, and will not enrich a claimant name. That is a deliberate design choice rather than a missing feature: it is what makes every cell traceable to a page you can open. If a fact is not in the file, no cell will claim it.
Where to start
The smallest useful test is the one set of documents you already dread. Take the last submission where you had five years from more than one carrier, run the loss-run table over all of it at once, and see whether the comparison you needed falls out.
If it does, the thing that changed is not that reading got faster. It is that the eight documents became one table you can hand to somebody else.