Claim Indexing
Automatically classify inbound claim documents, match them to the right existing claim in your carrier system, and file them with the correct document-type tags — so a person's job becomes verify and approve rather than read, sort, and file.
The business problem
Claim files grow through the mail. Medical bills, attorney correspondence, demand letters, police reports, photos, EOBs, court filings — they arrive every day, in every format, and most of them have to be filed against the right claim before anyone can act on them. Two things make that hard. First, most inbound documents don't carry a claim number — the bill from a provider or the cover email from an attorney rarely references the carrier's claim. 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 sorting-and-filing pass. It classifies each document, extracts the fields that identify it, works out which existing claim the package belongs to, and attaches each document to that claim with the right doc-type tag. When it can't find a match — or when a package looks like it mixes documents from different claims — it routes the package to a person instead of guessing.
Trigger and source data
The template ships with the Manual File Upload trigger for testing. For production, use the Outlook Trigger to start the flow when correspondence lands in a connected claims mailbox. Both are available today. 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.
The source data is an inbound claim package — a cover email with attachments, a combined PDF, or a set of files — whose documents relate to a single existing claim. 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
You also need the matching claim to already exist in your carrier system; if no match is found, the package routes to review.
Template starting point
Create an AI agent from the Claim Indexing template and you get a working flow that classifies, extracts, matches, attaches, and routes for review out of the box. You then tune the classification, the matching logic, and the carrier endpoints to your environment. See Create an AI Agent.
What the template preconfigures
The template is wired end to end from these released nodes:
| Step in the flow | Node it uses | Category |
|---|---|---|
| Prepare the uploaded files | Read Files | Utility |
| Segment a combined file into separate documents | Split Documents | InsurGPT |
| 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 | Multiple Condition Branches | Control |
| Fetch candidate claims from the carrier system | API Request | Utility |
| Match the package to a claim | Custom Code Blocks | Utility |
| Branch on whether a claim was matched | Conditional Branching | Control |
| Attach each document to the matched claim | HTTP File Upload | Utility |
| Check extracted values against rules | Field Validation | Utility |
| Generate the package briefing | Insights | InsurGPT |
| Route unmatched or completed packages to a person | Flag for Human Review | Utility |
| Close out the work item | Mark Item as Complete | Action |
It also ships with the package-level assessment that drives the reviewer's briefing: a same-claim check, urgent-item flags, a recommended next action, and a package summary.
What builders must configure before deployment
- Carrier connection variables. Store your carrier system's base URL and API credential as variables in Settings → Variables, then reference them from the lookup and upload nodes. Variable values are encrypted and masked; there is no separate secret type. See Configure environments and variables.
- Lookup and upload endpoints. Point the candidate-claims lookup and the document-upload node at your carrier's endpoints, and map the doc-type tags to your carrier's taxonomy. If you run Guidewire ClaimCenter, the Guidewire app nodes (such as Search for a Guidewire Claim) can do the lookup.
- Matching logic. The default matcher runs two passes (described below). Adjust it for your data — name-token matching, additional tiebreakers, or fallback by policy number.
- 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.
The AI classification and extraction steps are an AI intelligence capability available to the Admin role; the Partner role can build the rest of the flow but is restricted from AI intelligence features. See Users and access.
Matching target
The matching target is an existing claim in your carrier system. The template never creates a claim or modifies reserves and assignments — its only write action is attaching documents to a claim that already exists, which keeps it safe to run with light supervision.
Matching runs in two passes in the Custom Code Blocks step:
- Exact claim number. If the package contains an authoritative carrier claim number (for example, on an acknowledgement letter or notice of representation), it matches on that.
- Claimant name and date of loss. When there is no claim number — the common case for third-party mail — it falls back to matching the extracted claimant name and loss date against the carrier's existing claims. If several candidates tie, the most recently reported claim wins.
If neither pass finds a match, the package routes to review for manual routing.
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 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 anything is filed incorrectly.
- 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 work item in the Bevaya Platform, across two tabs:
- The Insights tab opens with a severity banner (an urgent deadline, an unmatched claim that needs manual routing), an AI recommendation with a suggested action, a quick-stats strip (document count, matched claim number or "No Match", 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.
The template has two review gates: a no-match review when no claim could be matched, and a review on the happy path after documents are attached. Either way the item is finalized when the reviewer submits. The Reviewer role can work items and reviews but cannot build or run flows. See Human review.
Run status and reporting
Each package becomes a work item that moves through the standard lifecycle statuses — Queued, In Progress, Deferred, Review, Complete, Closed, 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. None of the attachments carries the carrier's claim number.
- 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 from the records and notice.
- The matcher's first pass finds no claim number, so the second pass matches the claimant name and loss date against the carrier's open claims and lands on a single claim.
- The flow attaches all three documents to that claim, each tagged with its document type.
- 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 work item, sees the demand deadline at the top of the Insights tab, confirms the match and the attached documents, and submits. The item is marked complete.
Common failure modes
- No matching claim. If neither pass matches, the package routes to no-match review for manual routing. The flow will not attach documents to a wrong claim or invent a new one.
- 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 filing.
- Sparse carrier claim descriptions. The fuzzy pass looks for the claimant name within each claim's description, so claims with thin descriptions can fail to match even when the loss date is right. Richer descriptions match more cleanly.
- 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.
- Validate the matcher against your claim data. Confirm both passes behave as expected and that your carrier claim descriptions are rich enough for the fuzzy pass.
- Pilot with review on every package while you confirm classification and matching accuracy.
- Promote to production. Publish the flow, point the Outlook Trigger at the production mailbox, and confirm the carrier variables resolve in the production environment. See Drafts and publishing.
- Let routine mail flow through. As confidence grows, lean on the matcher and the same-claim check for routine packages, keeping a person in the loop for no-match cases and urgent items.
Where to go next
- App integration nodes — connect the lookup and upload steps, including Guidewire.
- Utility nodes — API Request, HTTP File Upload, Custom Code Blocks, Field Validation, and Flag for Human Review.
- InsurGPT nodes — Split Documents, 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 — for opening a new claim from an FNOL package, rather than filing mail against an existing one.
- Use cases overview — the full catalog of supported patterns.