Loss Run Processing
Turn a loss run report into structured policy and claim data that's been checked against known accounting relationships and carrier-specific reporting quirks.
The business problem
Loss runs arrive from many carriers and TPAs, each with its own layout and reporting conventions. Getting the numbers off the page is only half the job — the harder part is knowing whether they actually add up, and whether an apparent inconsistency is an extraction error or just how a particular carrier reports that field.
The Loss Run Processing template extracts a policy-level table and a claim-level table, resolves any figures recorded as a calculation, and checks the results against a set of financial and business rules. Where a check fails, an AI step re-reads the source document and decides whether the flagged row is a genuine error or an accepted carrier convention, correcting only what it's confident about. Every file then goes to a person, with the violations, the AI's reasoning, and a few portfolio counts already attached.
Trigger and source data
The template ships with the Manual File Upload trigger. You can configure other triggers if you'd like, including a connection to an Outlook email inbox and starting runs programmatically through the Bevaya API. See Configure triggers.
To run the template, upload a loss run report. The template extracts data across the lines of business it recognizes — Accident & Health, Auto, Aviation, Boiler & Machinery, BOP, Cargo, Crime/Fidelity, Cyber, D&O, E&O, EPLI, GL, Inland Marine, Marine, Package, Property, Umbrella, and WC & EL.
By default, the template works entirely from the uploaded content — no system match is built in.
Template starting point
Create an AI agent from the Loss Run Processing template for a working flow that extracts, resolves, validates, corrects, and routes for review out of the box. Open it in the canvas, select an environment, click Start Editing, and adjust it to your carrier mix and validation rules. See Create an AI Agent.
What the template preconfigures
The template will execute the following nodes:
| Step in the flow | Node it uses | Category |
|---|---|---|
| Prepare the uploaded files | Read Files | Utility |
| Extract policy-level fields, one row per policy term | InsurGPT: Custom | InsurGPT |
| Extract claim-level fields, one row per claim | InsurGPT: Custom | InsurGPT |
| Resolve any figures recorded as a calculation, and write the resolved policy and claim tables | Custom Code Blocks | Utility |
| Check the resolved rows against financial and business invariants | Custom Code Blocks | Utility |
| Branch on whether any invariant failed | Switch | Control |
| Record the violations found (violation path only) | Custom Code Blocks | Utility |
| Re-read the source document and decide which violations are genuine errors, proposing corrections (violation path only) | InsurGPT: Custom | InsurGPT |
| Apply the confident corrections and write the corrected claims table (violation path only) | Custom Code Blocks | Utility |
| Compute portfolio-level counts (large claims, open claims, litigated claims, largest claim) | Custom Code Blocks | Utility |
| Route the file to a person for review | Review | Utility |
| Close out the item | Complete | Action |
What builders must configure before deployment
- Carrier- and TPA-specific correction rules. The correction step's prompt already recognizes a few conventions — a TPA that splits one claim into duplicate rows, a code column that reclassifies amounts, carriers that report reserves or expenses as one combined figure. Extend it to the carriers and TPAs you actually work with, or it won't catch their conventions.
- Review is unconditional in this version. Every file routes to review whether or not a violation was found — there's no straight-through completion path yet. Add a branch after the insights step if you want clean files to complete on their own.
- Validation thresholds. The $50,000 large-claim threshold and the rounding tolerance used in the financial checks are starting points — tune them to your standards.
- A connection to your policy or claim system, if you want the extracted policy or claims matched to an existing record or written back. We recommend an HTTP node followed by a Custom Code Block to apply your own matching rules.
How the AI agent behaves
The agent extracts two related tables from the loss run — one row per policy term, and one row per claim. Where a figure comes from combining several amounts on the page, extraction records it as a calculation rather than guessing a total, and a following step evaluates that calculation to get the final value in both tables.
The resolved rows are then checked against a set of financial and business invariants — for example, that a policy or claim's totals reconcile against their components, that key dates fall in a sensible order, and that a claim's status is consistent with its reserve and its financials.
If any invariant fails, the flagged rows go to an AI step that re-reads the source document and decides, row by row, whether the violation is a genuine error or an accepted convention, stating its reasoning either way and proposing a correction only where it's confident. Confident corrections land in a corrected copy of the claims table alongside the original and the violation detail; anything it can't resolve is left for the reviewer. If nothing fails, this pass is skipped.
The flow finishes by computing a few portfolio-level counts — claims over $50,000 incurred, open claims, litigated claims, and the single largest claim — before the file routes to a person.
Human review model
Review happens on the item in the Bevaya Platform, organized into these groups on the Review tab:
- Policies — the resolved policy-level table
- Claims — the resolved claim-level table
- Corrected Claims — the claim-level table with any confident AI corrections applied
- Violations — the invariant violations found (read-only), the AI's row-by-row reasoning (read-only), and the corrections it proposed
The Insights tab opens with the AI's correction reasoning (when it ran), the portfolio-level counts, and the invariant violations as the exception detail. Since every file routes to review, check the Violations group to see whether anything was actually flagged. See Human review.
Run status and reporting
Each report becomes an item that moves through the standard lifecycle statuses — In Progress, Review, Complete, Failed, Canceled. Watch individual runs and inspect each step's input, output, and status in Run history, and see live counts of items by status on the Item status reporting page.
Example run
An underwriter uploads a Workers Compensation loss run from a regional carrier covering three policy years and 14 claims.
- The flow extracts one row per policy year and one row per claim, resolving a couple of claims whose total paid was recorded as a calculation combining indemnity, medical, and expense amounts.
- The invariant checks flag two rows: a claim marked open with a zero reserve, and a claim whose reported date is recorded one day before its loss date.
- The correction step re-reads the source: the "open, zero reserve" claim turns out to be coded report-only, an accepted convention it leaves alone; the reported-date issue is confirmed as a genuine transcription error, and it proposes the corrected date.
- The confident date correction is applied to the corrected claims table; the report-only claim isn't touched.
- Insights compute 2 claims over $50,000 incurred, 6 open claims, 1 litigated claim, and name the largest claim. The item routes to review, where the underwriter checks the Violations group against the corrected table and completes it.
Common failure modes
- An unrecognized carrier or TPA convention. If a source reports figures in a way the correction step doesn't already know — a combined expense total, a split-row claim, a reclassifying code column — the invariant check still flags it, but it routes to review as an unresolved violation instead of a confident fix.
- A genuine extraction error that doesn't reconcile. Flagged by the invariant checks and, when the correction step isn't confident enough to fix it from the document, left as-is for the reviewer to resolve.
Recommended rollout path
- Add your own carrier- and TPA-specific rules to the correction step, based on the sources you actually receive loss runs from.
- Tune the large-claim threshold and rounding tolerance to your standards.
- Decide whether to add a straight-through branch for files with no violations, and build it before pilot if so.
- Connect it to your policy or claim system, if you want the extracted data matched or written back.
- Build and test on real loss runs. Use Run Draft across your actual carrier and line-of-business mix, inspecting each step. See Test and debug a draft.
- Pilot with a reviewer to confirm the invariants and carrier-specific rules actually match your loss run mix.
- Promote to production. Publish the flow and configure your production trigger. See Drafts and publishing.
Where to go next
- Utility nodes — Custom Code Blocks and Review.
- InsurGPT nodes — extraction.
- Control nodes — Switch.
- App integration nodes — connect a write-back to your own systems.
- Human review — the Insights and Review tabs the reviewer works from.
- Item status reporting — track files by status.
- Triage and Routing — a related template that consumes loss run data as part of a broader submission triage decision.
- Use cases overview — the full catalog of supported patterns.