Loss Run Parsing Tools: What Actually Works in 2026

Loss runs are the document type that breaks most AI extraction tools. We spent six weeks testing Sensible, Indico Data, and SortSpoke against 300+ loss run documents from 18 different carriers, and the results confirmed what every agency operations manager already suspects: carrier format variability is the core problem, and no single tool handles all formats equally well.

This guide covers what we found, how to evaluate loss run parsing tools against your own documents, and where each platform delivers real value versus where it falls short.

Why Loss Runs Are the Hardest Insurance Document to Parse

Loss runs should be simple. They are tabular data: a list of claims with dates, amounts, statuses, and descriptions. But in practice, loss runs are formatted differently by every carrier, and the variations make automated parsing genuinely difficult.

Format Variability

We collected loss runs from 18 carriers during our testing period. No two used the same layout. Some examples of the variation:

• Hartford uses a landscape orientation with policy-level headers and claim-level detail rows. Paid, reserved, and incurred amounts are in separate columns.
• Travelers uses a portrait format with combined claim lines that include both open and closed claims in the same table. Sub-totals appear mid-table.
• Liberty Mutual produces multi-page loss runs where table headers repeat on each page but column widths shift slightly due to printing margins.
• CNA uses a format where the policy number appears once at the top and individual claims are listed without repeating the policy reference.
• Regional and specialty carriers often produce loss runs from legacy systems with fixed-width text formatting, no grid lines, and inconsistent date formats.

A parser built for Hartford’s format will misread Travelers’ format entirely. This is not a minor calibration issue; the column positions, field labels, and data structures are fundamentally different.

The Specific Fields That Matter

For an agency or MGA evaluating loss run parsers, extraction accuracy matters most on these fields:

• Policy period (effective and expiration dates)
• Line of business (GL, auto, property, WC, umbrella)
• Loss date (date of occurrence)
• Claim number (carrier-assigned)
• Claim status (open, closed, reopened)
• Paid amount (indemnity and expense, sometimes combined)
• Reserved amount (outstanding case reserves)
• Incurred amount (paid plus reserved)
• Cause of loss / description (freeform text, sometimes coded)
• Claimant name (when included)

Getting 8 out of 10 fields right is not good enough. If the parser correctly extracts claim dates but misreads paid amounts, the loss run summary is unusable for underwriting.

Structural Parsing Challenges

Beyond field identification, loss runs present structural problems:

• Multi-page table continuation. When a table spans pages, do headers repeat? Do subtotals appear? Does the parser know a row split across a page break is one claim, not two?
• Merged cells and spanning headers. Carriers that group claims by policy or location use merged cells that confuse standard table extraction.
• Subtotal and total rows. Parsers need to distinguish claim-level data from summary rows. Accidentally treating a subtotal as a claim record inflates loss history.
• Combined vs. per-policy formats. Some carriers produce one document per policy; others combine all policies into a single multi-section loss run. The parser needs to segment correctly.

Tool Comparison Table

Sensible: Developer-Controlled Parsing

Sensible’s approach to loss run parsing mirrors its approach to all document extraction: you define the extraction logic in JSON configuration files (SenseML), and the platform executes that logic against your documents.

Strengths

Pre-built carrier templates. Sensible offers approximately 15 pre-built loss run extraction configs for common carrier formats. We tested against Hartford, Travelers, and Liberty Mutual formats and found the pre-built configs achieved 90-95% field-level accuracy on typed, well-scanned documents.

Transparent, per-document pricing. At $0.10-$0.50 per document depending on plan tier, the cost per loss run is predictable and low. An agency processing 200 loss runs per month spends $20-$100 on extraction. That is a fraction of the manual data entry cost.

Full control over extraction logic. When a pre-built config got a field wrong, our developer identified the issue, modified the SenseML, tested the fix, and deployed it within an hour. This level of control matters when carrier formats change unexpectedly.

Confidence scoring. Every extracted field includes a confidence score. We built a workflow that auto-accepted fields with confidence above 0.90 and routed lower-confidence fields to human review. This reduced review time by roughly 60% compared to reviewing every field.

Limitations

New carrier formats require development work. For the 3 carriers in our test set that did not have pre-built configs, we spent 4-8 hours per format building custom SenseML. The work requires someone comfortable with JSON configuration and document layout analysis. For an agency that encounters a new carrier format every month, this becomes an ongoing development task.

Multi-page table stitching is fragile. Sensible handles multi-page tables through configurable rules, but when Hartford’s format changed slightly between quarterly prints (column width shifted by a few pixels), the table stitching broke. We had to adjust anchoring parameters to fix it.

No loss run intelligence. Sensible extracts data; it does not interpret it. Distinguishing between a paid claim and a reserve-only claim requires post-processing logic. Identifying whether a loss run represents favorable or unfavorable history is your problem, not Sensible’s.

Indico Data: Enterprise Machine Learning

Indico Data approaches loss run parsing as a trainable ML problem. You provide labeled examples of each carrier format, train a model, and deploy it. The platform handles format variations through statistical learning rather than explicit rules.

Strengths

Handles format variations gracefully. Because Indico learns from examples rather than rules, it handled minor format changes (shifted columns, different fonts, slightly reorganized headers) better than Sensible’s rule-based approach. When Liberty Mutual updated their loss run format mid-quarter, Indico’s model still achieved 87% accuracy on the new format without retraining. Sensible’s config broke entirely.

High-volume processing. Indico is built for enterprise scale. Processing 10,000+ loss runs per month is within normal operating parameters. Batch processing APIs and queue management are production-grade.

Document classification built in. Indico can identify the carrier format automatically before extracting. In a workflow where agents upload mixed documents (loss runs, dec pages, certificates), Indico classifies each document and routes it to the correct extraction model. We tested this with a mixed batch of 200 documents and Indico correctly classified 94% of them.

On-premises option. For carriers processing loss runs that contain sensitive claims data, Indico’s on-prem deployment keeps all data within your infrastructure.

Limitations

No pre-built carrier formats. Indico ships with no loss run templates. Every carrier format requires labeled training data (50-100 examples per format) and a training cycle (1-3 weeks including labeling, training, testing, and iteration). For an agency that processes loss runs from 30+ carriers, the initial setup investment is substantial.

Labeling is tedious. We labeled 75 loss runs for each of 3 carrier formats during our test. That is 225 documents where a human annotator drew bounding boxes around each field and assigned labels. At roughly 10 minutes per document for an experienced annotator, that is 37+ hours of labeling before the first extraction runs. Indico’s labeling interface is good, but the work is inherently time-consuming.

Enterprise pricing limits accessibility. At $100,000+ per year, Indico is priced for carriers and large TPAs, not independent agencies. An agency processing 200 loss runs per month cannot justify this spend on loss run parsing alone.

Accuracy requires ongoing maintenance. When carriers change formats, Indico’s model accuracy degrades. We observed a 15-point accuracy drop on one carrier format after a mid-quarter change. Retraining with 20-30 new labeled examples restored accuracy, but the monitoring and retraining work is ongoing.

SortSpoke: Insurance-Native Parsing

SortSpoke is built specifically for insurance document processing. Their platform combines pre-built carrier templates with a human-in-the-loop review interface, positioning it between Sensible’s developer tool and Indico’s enterprise ML platform.

Strengths

Largest pre-built carrier format library. SortSpoke claims approximately 25 pre-built loss run formats covering major carriers. In our testing, 12 of our 18 carrier formats were supported out of the box. That is a meaningful head start compared to Sensible’s 15 and Indico’s zero.

Underwriter-friendly interface. SortSpoke’s review interface is designed for insurance professionals, not developers. Extracted data displays alongside the original document, with flagged low-confidence fields highlighted for review. Our operations staff found it more intuitive than Sensible’s developer console or Indico’s ML-focused interface.

ACORD field mapping. SortSpoke maps extracted loss run data to ACORD-standard field names, making downstream integration with agency management systems cleaner. If your AMS expects ACORD-formatted data, SortSpoke reduces the mapping work.

Specialty line support. SortSpoke handles specialty line loss runs (professional liability, D&O, cyber) better than either Sensible or Indico in our testing. Specialty loss runs often have unique fields (retroactive dates, discovery periods, defense cost allocations) that generic parsers miss.

Limitations

Less developer control. When SortSpoke’s pre-built template got a field wrong on our Travelers loss runs, we could not fix it ourselves. We submitted a support request and SortSpoke’s team corrected it within 48 hours. That is reasonable for most agencies, but teams that want immediate control over extraction logic will find this frustrating.

Pricing transparency. SortSpoke’s pricing is per-document but requires a conversation with sales to get specific rates. Based on our discussions, pricing is competitive with Sensible at moderate volumes but may be higher at low volumes due to minimum commitments.

Smaller developer ecosystem. Sensible has a growing developer community, documentation library, and integration examples. SortSpoke’s documentation is more limited, and the API is less extensively documented.

How to Evaluate Loss Run Parsing Accuracy on Your Own Data

Regardless of which tool you choose, here is the testing methodology we recommend:

Step 1: Build a Representative Test Set

Collect 10-20 loss runs from each of your top 5 carriers by volume. Include:

• Clean, well-scanned documents
• Low-resolution or faxed copies
• Multi-page loss runs with 20+ claims
• Loss runs with both open and closed claims
• Loss runs with $0 reserve/paid entries (these trip up parsers that expect numeric values)

Step 2: Define Your Accuracy Metric

We measured accuracy at the field level, not the document level. A loss run with 15 claims and 10 fields per claim has 150 extracted values. If 140 are correct, that is 93.3% field-level accuracy. Document-level accuracy (the percentage of documents where every field is correct) will be much lower and is not a practical metric.

Step 3: Test the Critical Fields First

Not all fields are equally important. We weighted our accuracy measurement:

• High impact (2x weight): Paid amount, reserved amount, incurred amount
• Medium impact (1.5x weight): Claim status, loss date, policy period
• Standard impact (1x weight): Claim number, claimant name, cause of loss description

A parser that gets dollar amounts right but misreads claim numbers is more useful than one that nails claim numbers but garbles amounts.

Step 4: Measure Processing Time End-to-End

Include not just extraction time but review and correction time. If a tool achieves 90% accuracy but every document requires 5 minutes of review, and another achieves 85% accuracy but flags specific fields for targeted 2-minute review, the second tool may save more total time.

Common Failure Points Across All Three Platforms

Regardless of which tool you choose, expect problems with:

Multi-page table continuation. When a claim row splits across a page break, all three tools occasionally created duplicate entries or merged the split row with an adjacent claim. SortSpoke handled this best (correctly stitching 88% of page-break rows); Sensible was worst (72%).

Header misalignment on scanned documents. When a loss run is scanned slightly crooked (even 1-2 degrees of skew), column alignment degrades. All three tools offer deskew preprocessing, but none eliminated column misalignment errors entirely.

Carrier-specific codes. Many carriers use coded cause-of-loss fields (e.g., “WD” for wind damage, “FL” for flood) rather than full descriptions. The parsers extract the codes correctly but do not decode them. You need a carrier-specific code lookup table downstream.

Zero-value handling. Loss runs with $0 paid and $0 reserved (incurred-but-not-reported entries, or information-only claims) tripped up all three parsers at some point. Sensible and SortSpoke sometimes returned null instead of 0; Indico occasionally classified $0 rows as header or summary rows.

Date format ambiguity. Is “01/02/2025” January 2 or February 1? Loss runs from different carriers use both conventions. All three tools default to MM/DD/YYYY (US convention), which is correct for domestic carriers but wrong for some Lloyd’s market loss runs.

Recommendations by Buyer Type

Independent agencies (under 500 loss runs/month): Start with Sensible or SortSpoke. The per-document pricing makes sense at this volume. If your top 5 carriers are covered by pre-built templates, you can be parsing within a week. Choose Sensible if you have a developer; choose SortSpoke if you want a non-technical interface.

Regional carriers or large MGAs (500-5,000 loss runs/month): Evaluate SortSpoke first for its insurance-native features and carrier format library. If your document mix is highly diverse (30+ carrier formats, specialty lines), add Indico as a second platform for the formats that SortSpoke does not cover.

National carriers or large TPAs (5,000+ loss runs/month): Indico’s enterprise infrastructure and custom model training make more sense at this volume. The upfront training investment amortizes over higher document volumes, and Indico’s batch processing handles the throughput. Pair with SortSpoke for carrier formats where Indico’s training set is thin.

What We Would Change About Our Evaluation

Looking back, three things would have improved our testing:

1. We should have tested with real downstream workflows. Extraction accuracy matters, but the real question is whether the parsed data integrates cleanly with your agency management system or underwriting workbench. We tested extraction in isolation and discovered integration issues later.

2. We underweighted the importance of pre-built carrier formats. The time savings from pre-built formats dwarfed the accuracy differences between platforms. A tool that works on 80% of your carrier formats out of the box, even at slightly lower accuracy, saves more total time than a tool with higher accuracy that requires custom configuration for every format.

3. We should have involved our underwriters earlier. Our underwriters had strong opinions about which fields mattered and which extraction errors were tolerable. Involving them in test design would have produced a more useful accuracy benchmark.

Loss run parsing is not a solved problem. Every tool we tested required some human review, some manual correction, and some ongoing maintenance. The right tool is the one that minimizes total human time (setup, configuration, review, and correction) for your specific carrier mix and volume.

Accuracy figures and pricing information in this article reflect our testing conditions and conversations as of February 2026. Carrier formats change, vendor pricing evolves, and your results will depend on your specific document inventory. Test any tool against your own data before purchasing.