Claim Indexing
Automatically classify inbound claim documents and extract the fields that identify them, so a person's job becomes verify and approve rather than read, sort, and transcribe.
The business problem
Medical bills, attorney correspondence, demand letters, police reports, photos, EOBs, court filings — they arrive every day, in every format, and each one has to be identified and its key fields captured before anyone can act on it. Two things make that hard. First, the volume and variety of formats — every provider, attorney, and vendor sends paper in their own layout, so a person is doing pattern-matching on hundreds of variants. Second, some of that mail is urgent — a demand letter with a response deadline or a court filing with an appearance date is easy to miss in a stack of routine paper.
The Claim Indexing template automates the classification and extraction pass. It sorts each document by type, pulls the fields that identify it, validates the results, and surfaces a package briefing with any urgent flags, so the reviewer can confirm and act on a structured view instead of a stack of PDFs.
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 so the flow starts when correspondence arrives. Inbound webhooks, scheduled/timer triggers, and SFTP are not currently available; to start runs from a scanning vendor or document system, drive the flow through the Bevaya API. See Configure triggers.
To run the template, manually upload a file to trigger the flow — either a PDF, a spreadsheet, or a cover email with its attachments. The template recognizes a broad set of claim document types, including:
- Claims documents — FNOL, FROI/SROI, acknowledgement letters, claims analysis, photos
- Legal documents — demand letters, settlement disbursements, court filings, depositions, subpoenas, notices of representation, releases
- Medical documents — bills, records, narrative reports, EOBs, authorizations, work-status forms, CMS-1500s, UB-04s
- Financial documents — vendor invoices, checks, wage statements, W-9s, mileage reports
- Reports — police reports, expert reports, ISO reports, regulatory filings
- Correspondence — general correspondence, postage, returned mail
The template runs entirely on the uploaded content — it does not read from or write to a carrier system.
Template starting point
Create an AI agent from the Claim Indexing template and you get a working flow that classifies, extracts, validates, briefs, and routes for review out of the box. Once the template is open in the canvas, select an environment, click Start Editing, and make any changes you'd like to tune the template to your use cases and documents — for example, adjust field prompts, extraction rules, or validation thresholds. 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 |
| Pull package-level context (claim number, claimant, date of loss) | InsurGPT: Custom | InsurGPT |
| Process each document in turn | For Loop | Control |
| Classify each document and extract its fields | InsurGPT: Custom | InsurGPT |
| Route each document to the right extractor | Switch | Control |
| Generate the package briefing | Insights | InsurGPT |
| Check extracted values against rules | Field Validation | Utility |
| Route the package to a person | Review | Utility |
| Close out the item | Complete | Action |
The template also comes with a package-level assessment that shapes what the reviewer sees: a check of whether all documents belong to the same claim, flags for any time-sensitive items, a recommended next action, and a plain-language summary of the package.
What builders must configure before deployment
- Classification and field sets. Tune the classification prompt and the per-type field sets to the documents you actually receive.
- Validation thresholds and review routing. Set confidence thresholds and the reviewer assignment to your standards. See Utility nodes.
How the AI agent behaves
The agent extracts package-level context, then classifies and extracts each document, working only from the supplied content. After the loop, it produces three signals that shape the reviewer's briefing:
- A same-claim assessment — an evidence-based check of whether all documents in the package belong to the same claim, returned as Yes — Same Claim, No — Different Claims, or Inconclusive with a short explanation, so a reviewer can split a mixed package before acting on it.
- Urgent flags — time-sensitive items such as demand deadlines, court appearance dates, and regulatory windows, each with the deadline and the consequence of missing it.
- A recommended next action with a confidence score.
The agent does not invent values; low-confidence fields are flagged by validation rather than fabricated, and Grounding can tie each extracted value back to its place on the page for easy verification.
Human review model
Review happens on the item in the Bevaya Platform, across two tabs:
- The Insights tab opens with a severity banner for any urgent deadline, an AI recommendation with a suggested action, a quick-stats strip (document count, claimant, date of loss), the same-claim assessment, the urgent flags, a package summary, the source documents, and an audit trail.
- The Review tab is field-by-field verification organized by document, where the reviewer confirms values, corrects a misclassification and resubmits to re-run extraction for the corrected type, and approves.
Every package lands in review; the item is finalized when the reviewer submits. Reviewers can work items and reviews but cannot build or run flows. See Human review.
Run status and reporting
Each package 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. Status reporting is a live count of where work stands, not a trend or throughput analytic.
Example run
A law firm emails three PDFs about a bodily-injury claim: a notice of representation, a medical records bundle, and a demand letter with a 30-day response window.
- The flow ingests the package and prepares the files.
- It classifies each document — Legal: Notice of Representation, Medical: Records, Legal: Demand — and extracts the identifying fields, including the claimant's name and date of loss.
- Validation checks the extracted fields against the confidence threshold; anything below is flagged.
- The package assessment confirms the documents belong to the same claim and raises an urgent flag on the 30-day demand deadline.
- The reviewer opens the item, sees the demand deadline at the top of the Insights tab, verifies the classifications and extracted fields on the Review tab, and submits. The item is marked complete.
Common failure modes
- A package mixing different claims. Misfiled mail can combine documents from separate claims. The same-claim assessment surfaces this so the reviewer can split the package before acting on it.
- A misclassified document. The reviewer corrects the classification during review and resubmits so the agent re-runs extraction for the corrected type; persistent patterns are best fixed in the classification prompt.
- Low-confidence fields. Poor scans or unusual layouts are flagged by validation and surfaced for review rather than guessed.
Recommended rollout path
- Build and test on real mail. Start from the template and use Run Draft on representative inbound packages, inspecting each step. See Test and debug a draft.
- Pilot with a reviewer on every package while you confirm classification and extraction accuracy on your document mix.
- Promote to production. Publish the flow and configure your production trigger — for example, a connection to an Outlook email inbox. See Drafts and publishing.
- Tune the classification prompt and field sets as patterns emerge from real reviewer corrections.
Where to go next
- Utility nodes — Field Validation and Review.
- InsurGPT nodes — classification and extraction.
- Human review — the Insights and Review tabs the reviewer works from.
- Item status reporting — track packages by status.
- Claim-to-Policy Comparison — a related template for evaluating a new claim against an insurance policy.
- Use cases overview — the full catalog of supported patterns.