ChatGPT can read a single carrier's loss run and summarize claim counts, incurred losses, and loss ratios accurately, but loss run analysis rarely arrives as one carrier's report. It arrives as a dozen or more carriers' worth of reports, in as many different layouts, and the underwriting or claims team on the other end needs one consistent schema out of all of them — not a stack of accurate summaries that don't line up with each other.
That normalization problem, not reading comprehension, is where loss run workflows built directly on a general assistant tend to run into trouble once they move past a handful of test files.
What ChatGPT Does Well for Loss Run Analysis
ChatGPT brings genuine, verifiable capability to reading loss run reports, and it's worth being specific about it.
- GPT-5.6's flagship models carry a 1.05-million-token context window as standard, per OpenAI's documentation — enough to hold a lengthy multi-year loss run in a single pass without fragmenting it, which matters when claim history spans many policy periods in one document.
- A Custom GPT can encode how a specific carrier's format maps to a target schema — which column is incurred loss, which is paid, how open claims are flagged — as a reusable configuration instead of re-explaining each carrier's quirks every time.
- Apps and connectors can pull loss runs directly from a shared mailbox, SharePoint, or Google Drive under the analyst's existing permissions.
- ChatGPT Work can run a multi-step task across a folder of loss runs from different carriers, producing a first-pass normalized summary for each file.
Where Many Formats Break What One Format Never Would
The failure pattern here isn't ChatGPT misreading any single carrier's report — it's what happens once the number of distinct formats climbs.
- By carrier format 5, two carriers report "incurred" differently — one includes reserves, one doesn't — and both loss runs map to the same schema field without anyone flagging that the underlying figures aren't apples-to-apples.
- By carrier format 9, a claim listed as closed in one carrier's format uses a status code that a different carrier uses for "closed without payment." Mapped naively to the same target field, the two get treated identically in a downstream loss ratio calculation that shouldn't treat them the same way.
- By carrier format 13, the analyst who built the Custom GPT's format-mapping instructions for the trickiest carriers moves to a different account. The mapping logic exists in the configuration, but the judgment calls behind it — why one carrier's "reserve" column gets excluded from a specific calculation — don't transfer cleanly.
- By carrier format 17, an underwriter pulling a consolidated loss history for a renewal asks which mapping version was used for a specific carrier's file six months ago, since the schema mapping has been adjusted twice since then. Nothing ties the historical output to the mapping version that produced it.
None of this is about model accuracy on any one document. It's that a dozen or more carriers' worth of format idiosyncrasies compound in ways a single configuration's instructions don't track over time.
Why Schema Normalization Is the Actual Job, Not Extraction
Reading a loss run and normalizing it into a schema that means the same thing across many carriers are different jobs, and normalization is the one that determines whether the output is usable.
Every mapping decision — what counts as incurred, how a status code translates, how multi-year history gets aggregated — has to be applied the same way every time a given carrier's format shows up, and verifiable against the source when someone questions a figure. Without a citation tying a normalized value back to its exact line in the original loss run, and without a record of which mapping version was active, checking one contested figure means re-reading the original report and reconstructing the mapping logic that was in force at the time.
Who Owns the Format Mappings, the Version History, and the Re-Validation
The carrier-by-carrier format mappings are the actual intellectual property of a self-built loss run workflow, and per OpenAI's own documentation, GPT builders "cannot view user conversations" — in a typical deployment, those mappings live in one Custom GPT with no version history tying a specific output to the mapping logic that produced it.
Two consequences follow. First, when a carrier changes its report layout — which happens without notice — someone has to catch it, update the mapping, and decide whether prior files processed under the old mapping need reprocessing. Second, when the underlying model version changes, re-confirming that all carrier mappings still produce correct output is work that scales with the number of formats, and in practice it's the kind of maintenance that gets deferred until a discrepancy forces the issue.
ChatGPT-Based Loss Run Analysis Compared With a Purpose-Built Platform
| Requirement | Self-Built on ChatGPT | Purpose-Built Platform |
|---|---|---|
| Reads an individual carrier's loss run accurately | Yes | Yes |
| One schema enforced across many carrier formats | You build and maintain each mapping | Built with you, enforced on output |
| Detects a carrier's silent format change | Not automatic | Flagged and routed for review |
| Field-level citation to source line | Instructed, not enforced | Enforced on every field |
| Mapping version tied to each processed file | Not built in, per OpenAI's documentation | Built in |
| Consistency across dozens of loss runs | Usually unmeasured | Validated independently |
| Re-validation when the model version changes | Your team, per format | Vendor benchmarks and validates |
| Structured output into underwriting systems | Manual export | Structured push into existing systems |
| Audit record for a specific historical figure | You build it | Built in |
| Who owns the accuracy of the outcome | Your team | Shared with the vendor |
When Using ChatGPT Directly for Loss Run Analysis Is the Right Choice
ChatGPT, used directly, works well for loss run reading that's occasional, single-carrier, or fully reviewed by the person requesting it.
- One-off review of a single submission. Reading one applicant's loss run in full ahead of a renewal decision is exactly what a large context window handles well.
- An individual underwriter's small book. One person reviewing a handful of accounts personally, checking every figure themselves, doesn't need a maintained multi-carrier mapping library.
- Prototyping a mapping for a new carrier. Working out how a newly encountered carrier's format should map to your schema, before committing it to a production pipeline, is a reasonable use of a Custom GPT.
- Low volume. Below a few dozen submissions a month across a small number of carriers, maintaining a full normalization pipeline may cost more than it saves.
The dividing line isn't whether ChatGPT can read a given carrier's format. It's whether the output has to line up, field for field, with a dozen other carriers' formats in a way an underwriter can trust without re-checking the source.
How Kolena Works
Kolena is an AI document automation platform built for insurance carriers, MGAs, and brokers running loss run and submission review across many source formats. Kolena's agents read loss runs regardless of carrier layout, apply your target schema consistently across every format, and return structured outputs — incurred and paid losses, claim status, loss ratios — with every field cited to its exact location in the source document.
Kolena maintains the carrier-format mapping logic centrally, flags a carrier's format change instead of silently mapping it wrong, and produces a full audit trail tying each output to the mapping version and model version that produced it. Kolena also benchmarks leading models against real document tasks and routes each step to the best performer, so a model version change is validated across every carrier format before it reaches your workflow. Kolena is SOC 2 Type II certified, processes onshore, and does not train on customer data.
Independent research on early enterprise AI adoption — MIT's Project NANDA study on the state of AI in business — found that firms deploying AI this way eliminated $2 to $10 million in annual outsourced processing expenditure, with one firm saving roughly $8 million a year after an initial tool spend of about $8,000. Loss run normalization across many carrier formats is exactly the kind of high-volume, format-heavy work that pattern describes.
