Insurance Claims Software: Queues, Evidence and Moving Reserves

A team building claims software often starts from a ticketing model: a claim comes in, gets assigned, moves through statuses, and closes. It looks right on a whiteboard. Then the first adjuster asks where to record that the estimated cost of the claim just went from eight thousand dollars to twenty-two thousand, and why, and who approved it, and the status column has no answer.

The difficulty is that a claim is a financial object as much as a workflow object. It holds an estimate of money not yet paid, a set of people with different interests in it, evidence that may later be disputed, and legal deadlines that run whether or not anyone has looked at it. Generic task tools model none of that.

This post walks through the parts of the domain that break a ticket-shaped design, so that you can recognize them in a requirements document, or in a vendor demo, before they become schema changes.

One claim, many exposures

A single loss event usually produces several things to resolve. A car accident might involve damage to the insured vehicle, damage to another party's vehicle, and injuries to two people, each under a different coverage with its own limit and its own payee. These are often called exposures or features, and each needs its own status, reserve and payments.

If your data model has one amount and one status per claim, you will end up cramming this into notes. The sound structure is a claim at the top, the policy and coverages beneath it, and exposures under those, with claimants and payees attached to the right level. Closing the claim should be a computed outcome: every exposure closed, every payment reconciled.

Reserves are estimates with a history

A reserve is the insurer's current estimate of what a claim will ultimately cost. It is revised as facts come in, and the revisions matter: finance relies on them for reporting, and reviewers use the pattern to evaluate how well claims were handled.

So reserve changes are append-only entries, never an edited number. Each entry carries the amount, the reason, the person, and the time. Three figures then fall out of the history: the current reserve, the paid to date, and the total incurred, which is the paid plus the outstanding reserve. Keep them distinct in the interface, because adjusters and accountants use the same words for slightly different things, and confusing them produces the wrong report.

CREATE TABLE reserve_entries (
  id           BIGINT PRIMARY KEY,
  exposure_id  BIGINT NOT NULL REFERENCES exposures(id),
  amount_cents BIGINT NOT NULL,       -- new outstanding reserve
  reason       TEXT   NOT NULL,
  set_by       BIGINT NOT NULL REFERENCES users(id),
  approved_by  BIGINT REFERENCES users(id),
  created_at   TIMESTAMPTZ NOT NULL DEFAULT now()
);
-- current reserve = latest entry per exposure; never UPDATE a row.

Money in integer cents, as in any ledger. If the reasoning for that is new to you, our note on reconciliation, ledgers and why a float is not money explains it.

The adjuster's queue is driven by clocks

The queue is where adjusters spend their day, and an ordinary FIFO list is the wrong design. Claims should rise in the queue for reasons: a regulatory deadline approaching, a follow-up date the adjuster set for themselves, an incoming document that unblocks the next step, or a large reserve that needs review.

Regulators set deadlines for acknowledging a claim, requesting information, and communicating a decision, and the rules differ by state and by line of business. Your software should therefore treat deadlines as data attached to claims, computed from jurisdiction and event dates, with a visible countdown. Hard-coding them is tempting and goes wrong the first time a rule changes. Whether a particular deadline applies is a question for your compliance team, and the software should make that configuration editable by them.

Authority limits are the second queue driver. An adjuster can usually approve payments or reserves only up to a certain amount, above which the item routes to a supervisor. That is a rule, not a convention, and the system should enforce it at the moment of the action, the same way a good admin console enforces permissions.

Evidence is a record, not a folder

Photos, recorded statements, repair estimates, police reports and medical records arrive from many sources and in many formats. A shared drive with a naming convention fails the first time a claim is disputed and someone needs to show what was received, when, from whom, and whether it was changed.

• Store each item immutably with source, received time and who attached it. A correction is a new version, not an overwrite.
• Link evidence to the exposure it supports, not only the claim, so reviewers see the basis for each number.
• Record who viewed sensitive items, especially medical documents, because access to them is itself regulated.
• Keep the original file alongside any extracted or summarized text.

This is also where automation starts to help. Reading a repair estimate or classifying a photo as a first pass saves adjuster time. The same caution applies as anywhere else with documents: extraction errors are common on real-world scans, so output should carry a confidence score and route low-confidence items to a person. We wrote about both sides of this in what breaks when vision models read real documents and confidence scoring. A model should propose and a human should decide on anything that moves money.

Reopenings, subrogation and the long tail

Claims do not end cleanly. They reopen when new damage appears or a late bill arrives. A recovery effort against a responsible third party (subrogation) can run for years after the insured has been paid. A closed state that blocks all edits will frustrate the people who have to do this work, so closure should be a state with defined ways back, each recorded with a reason.

When you should not build this

If you handle a few hundred claims a year, a well-designed intake form, a spreadsheet for reserves and a shared evidence folder with strict naming may carry you for a long time, and it will cost far less than a custom system. If your line of business is standard, a configurable off-the-shelf claims platform may match well enough; weigh that with the five build-versus-buy questions before commissioning anything.

Custom software starts to pay off when your process is the differentiator: an unusual line of business, a program with unusual authority rules, or a workflow where adjusters currently juggle three systems and a spreadsheet. We have not shipped a claims product of our own, so we will not pretend to; what we bring is the structural work behind it, such as multi-tenant data models, append-only financial records, document pipelines and review queues, described under our services and the sectors on our industries page.