Litigation Spend: The Claims Cost Insurers Still Manage With a Spreadsheet

For a lot of insurers, legal spend is one of the largest controllable costs in claims — defense counsel fees, expert witnesses, litigation expenses — and one of the least managed with any rigor. The premium-sized irony is that an industry built on measuring and pricing risk manages its own litigation spend the way a small business manages petty cash: invoices reviewed one at a time, panel counsel chosen by habit, and almost no aggregate view of what's actually driving cost or which firms deliver value. It's a data blind spot hiding in plain sight on the loss run.

Why it stays unmanaged

Legal invoices are messy, unstructured, and voluminous. They arrive as PDFs, in inconsistent formats, with line items described in each firm's own shorthand. Reviewing them for reasonableness is tedious, so it's done superficially or not at all. And because the data is never aggregated into a structured, analyzable form, the questions that would actually control cost simply can't be asked: which firms settle efficiently versus running up hours? Which case types predict runaway spend? Are we paying partner rates for associate work? The information to answer all of that is in the invoices — it's just trapped in a format nobody has operationalized.

The questions the data could answer

  • Panel performance. Which defense firms consistently resolve claims for less — accounting for case mix — and which don't? Right now most insurers reward relationships, not outcomes, because they can't see the outcomes.
  • Early cost prediction. Which claims, at the point litigation begins, are likely to become expensive? Knowing that changes how you staff and strategize the defense.
  • Billing hygiene. Block billing, over-staffing, work billed above the appropriate level — the patterns a structured review catches that a per-invoice glance misses.
  • Settle-versus-defend. A data-informed view of when fighting a claim costs more than settling it, instead of a case-by-case gut call.

From invoices to intelligence

The path from "pile of PDFs" to "managed spend" is a document-and-data problem, and a very tractable one. Modern document intelligence can extract and structure legal invoice data at scale — line items, rates, timekeepers, task codes — turning an unreadable stack into an analyzable dataset. Joined to claim outcomes, that dataset supports exactly the panel-performance, cost-prediction, and billing-hygiene analysis that's been impossible. This isn't exotic AI; it's extraction plus joins plus the will to actually look. But it doesn't happen until someone treats legal spend as a data asset rather than an administrative chore.

What it takes

  1. Extract and structure invoice data — get the line items, rates, and tasks out of the PDFs and into a consistent schema.
  2. Join to claim context and outcomes so spend can be evaluated against results, not in isolation.
  3. Score panel performance and predict cost — informed by case mix, not raw totals.
  4. Feed it back into decisions — counsel selection, staffing, and settle-versus-defend strategy.

Legal spend is a large, controllable cost that most insurers don't control because the data lives in a format they've never operationalized. Turning that stack of invoices into structured, analyzable intelligence joined to outcomes is precisely the kind of document-and-data foundation work we do with insurers at IntelliBooks.

You measure and price risk for a living. It's worth pointing some of that discipline at the millions you spend on your own lawyers.

Comments

Post a Comment

Popular posts from this blog

Why Your Insurance Data Warehouse Didn't Fix Anything

You built the data warehouse. It took eighteen months and cost more than planned. Policy data, claims data, billing — it's all in there. The project was declared a success and everyone moved on. And yet: underwriting still can't see the whole customer. The AI initiative is still stalled. Someone still asks for a report and waits three weeks. Nobody says it out loud, but the question hangs there — what exactly did we buy? You're not alone, and it isn't because you built it badly. It's because a warehouse solves a problem you didn't have. The problem a warehouse solves Warehouses solve location . Before: your data was in eight systems. After: it's in one place. That's genuinely valuable — you can run a query across policy and claims without begging two teams for extracts. But notice what that fixes: it fixes where the data is . It doesn't touch what the data means , whether it's trustworthy, or whether the records refer to who you think t...
Read more

Embedded Insurance: Why the API Is the Easy Part

Embedded insurance is the idea that coverage should be offered at the moment of need, inside someone else's product — travel insurance at checkout, device protection when you buy the phone, cover for the rental car in the booking flow. It's one of the fastest-growing distribution models in the industry, and every insurer has a strategy slide about it. Most of those strategies underestimate the same thing, and it isn't the partnerships or the product. It's the data plumbing. Everyone assumes the API is the hard part. The API is the easy part. What embedded insurance really demands The promise of embedded is speed and invisibility: a customer buys a flight and, in the same breath, is offered exactly the right travel cover at exactly the right price, and accepts with one tap. No forms, no friction. Deliver that and you've won. But "exactly the right cover at exactly the right price in one tap" makes brutal demands on your back end: You must price i...
Read more

RAG Over Policy Documents: What Works and What Doesn't

"Just point an AI at our policy documents and let people ask questions." It's the most requested AI use case in insurance and one of the easiest to build badly. Retrieval-augmented generation — RAG — genuinely works for this. But policy documents have properties that break the naive implementation, and the failure mode is dangerous: a confident, fluent, wrong answer about what someone's coverage includes. Why the standard tutorial fails on policy wordings The default RAG recipe is: chop documents into fixed-size chunks, embed them, retrieve the top few by similarity, stuff them into a prompt. On blog posts and FAQs, fine. On insurance contracts, it produces confidently wrong answers for four specific reasons. 1. Meaning depends on structure. A policy is a legal instrument where an exclusion three pages after a coverage grant completely changes what that grant means. Naive chunking retrieves the coverage paragraph, misses the exclusion, and the model cheerfull...
Read more