# 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](/api/flow-executions#run-a-flow). See [Configure triggers](../build-ai-agents/triggers.md).

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](../build-ai-agents/create-agent.md).

## 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](../build-ai-agents/utility-nodes.md) | Utility |
| Segment a combined file into separate documents | [Split Documents](../build-ai-agents/insurgpt-nodes.md) | InsurGPT |
| Pull package-level context (claim number, claimant, date of loss) | [InsurGPT: Custom](../build-ai-agents/insurgpt-nodes.md) | InsurGPT |
| Process each document in turn | [For Loop](../build-ai-agents/control-nodes.md) | Control |
| Classify each document and extract its fields | [InsurGPT: Custom](../build-ai-agents/insurgpt-nodes.md) | InsurGPT |
| Route each document to the right extractor | [Multiple Condition Branches](../build-ai-agents/control-nodes.md) | Control |
| Fetch candidate claims from the carrier system | [API Request](../build-ai-agents/utility-nodes.md) | Utility |
| Match the package to a claim | [Custom Code Blocks](../build-ai-agents/utility-nodes.md) | Utility |
| Branch on whether a claim was matched | [Conditional Branching](../build-ai-agents/control-nodes.md) | Control |
| Attach each document to the matched claim | [HTTP File Upload](../build-ai-agents/utility-nodes.md) | Utility |
| Check extracted values against rules | [Field Validation](../build-ai-agents/utility-nodes.md) | Utility |
| Generate the package briefing | [Insights](../build-ai-agents/insurgpt-nodes.md) | InsurGPT |
| Route unmatched or completed packages to a person | [Flag for Human Review](../build-ai-agents/utility-nodes.md) | Utility |
| Close out the work item | [Mark Item as Complete](../build-ai-agents/action-nodes.md) | 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](../build-ai-agents/environments-variables.md).
- **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](../build-ai-agents/app-integration-nodes.md) (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](../build-ai-agents/utility-nodes.md).

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](../onboarding/users-access.md).

## 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:

1. **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.
2. **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](../monitor-review/human-review.md).

## 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](../monitor-review/run-history.md), and see live counts of items by status on the [Item status reporting](../monitor-review/item-status-reporting.md) 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.

1. The flow ingests the package and prepares the files.
2. 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.
3. 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.
4. The flow attaches all three documents to that claim, each tagged with its document type.
5. The package assessment confirms the documents belong to the same claim and raises an urgent flag on the 30-day demand deadline.
6. 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

1. **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](../build-ai-agents/test-debug-draft.md).
2. **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.
3. **Pilot with review on every package** while you confirm classification and matching accuracy.
4. **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](../build-ai-agents/drafts-publishing.md).
5. **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](../build-ai-agents/app-integration-nodes.md) — connect the lookup and upload steps, including Guidewire.
- [Utility nodes](../build-ai-agents/utility-nodes.md) — API Request, HTTP File Upload, Custom Code Blocks, Field Validation, and Flag for Human Review.
- [InsurGPT nodes](../build-ai-agents/insurgpt-nodes.md) — Split Documents, classification, and extraction.
- [Human review](../monitor-review/human-review.md) — the Insights and Review tabs the reviewer works from.
- [Item status reporting](../monitor-review/item-status-reporting.md) — track packages by status.
- [Claim-to-Policy Comparison](./claims-to-policy-comparison.md) — for opening a new claim from an FNOL package, rather than filing mail against an existing one.
- [Use cases overview](./overview.md) — the full catalog of supported patterns.