Most of the writing about claims automation stops at the first notice of loss. A form arrives, a model reads the policy number, the loss date and the description, and the claim lands in the right queue. That moment is real and worth automating, but it is the shortest part of the life of a claim. Everything that decides what the claim will actually cost arrives later, and it arrives as a stream of documents that keep revising one another.
A typical auto physical damage claim does not have one estimate. It has the first estimate, written before anyone took the bumper off, then a supplement when the shop finds a bent bracket behind it, sometimes a second supplement, then an adjusted copy of the shop estimate from the carrier, then the final repair invoice. A property claim does the same with a contractor scope, a revised scope, depreciation adjustments and a final bill. The police report, the photos and the recorded statement sit alongside all of that and change different things.
A claims document pipeline that treats each of those arrivals as a fresh extraction, and writes its totals over whatever the claim record held before, will be right about each document and wrong about the claim. This piece is about the other half of claims document processing: reading each document for the role it plays in the sequence, and keeping the claim’s numbers derived from the documents rather than overwritten by the latest one.
The first notice is the start of the file, not the claim
The regulation that makes this concrete is California’s Fair Claims Settlement Practices Regulations, Title 10 of the California Code of Regulations, sections 2695.1 onward. They apply to insurers in one state, and other states have their own versions, so the specific deadlines below are California’s and only California’s. What makes them useful here is that they define the documents of a claim with unusual precision.
Section 2695.2 separates two things that intake pipelines tend to merge. A notice of claim is any written or oral notification that reasonably apprises the insurer that the claimant wishes to make a claim and that a condition giving rise to the insurer’s obligations may have arisen. A proof of claim is any evidence or documentation in the insurer’s possession, submitted by the claimant or obtained in the investigation, that provides evidence of the claim and “reasonably supports the magnitude or the amount of the claimed loss.”
The two definitions start different clocks. Under section 2695.5(e), once notice of claim arrives the insurer has fifteen calendar days to acknowledge it, provide forms and instructions that specify what the claimant must supply as proof of claim, and begin any necessary investigation. Under section 2695.7(b), once proof of claim arrives the insurer has forty calendar days to accept or deny the claim, in whole or in part, and the amounts accepted or denied must be documented in the claim file.
So the first notice opens the file and sets one deadline. The documents that establish the amount set another, and they keep arriving after the first one is met. An extraction that knows only “this is a claim document” cannot tell which clock a document belongs to. One that classifies it as notice, proof, investigation or settlement can.
Every document has a role in the sequence
The practical move is to classify each incoming document twice: once for what it is, and once for what it does to the claim. The second classification is the one most pipelines skip. It has a small vocabulary.
- Opens — the document starts the file and fixes the facts that everything else refers back to: the policy, the loss date, the reported circumstances.
- Complements — it adds facts the claim did not have, without changing any number already established.
- Adds to — it changes an amount by reference to an earlier document, as a delta rather than a restatement.
- Replaces — it becomes the new basis for an amount, and the earlier document stays in the file as history.
- Closes — it records what was actually paid or actually done, against which every earlier figure can be reconciled.
None of these roles is visible from the layout alone. A supplement and an original estimate can come out of the same estimating system with the same header. A shop’s estimate and the carrier’s adjusted copy of it can share every line. What separates them is a reference: an estimate number, a supplement sequence such as S01 or S02, the name of the party who prepared it, and the date it was received. Those references are the fields that make the sequence reconstructable, and they deserve the same extraction attention as the totals.
A worked sequence for an auto claim
The table below follows one partial-loss auto claim from first notice to final invoice. The third column names the claim fields a document moves. It does not say how any carrier sets or changes a reserve; that is a matter for each carrier’s own claims guidelines, and nothing here describes one. What it shows is which inputs a reserve reviewer would want to see change, and from which document.
| Document | Role against what came before | Claim fields it moves |
|---|---|---|
| First notice of loss | Opens the file | Policy, loss date, reported cause, vehicle, parties, notice date that starts the acknowledgement clock |
| Police report | Complements the notice | Parties, citations, narrative of fault; no amount |
| Photos or desk appraisal | Complements the notice | Damage areas observed; sometimes the first estimate basis |
| Insurer’s initial estimate | Sets the first amount basis | Estimated repair amount, parts, labour hours, estimate number |
| Claimant’s shop estimate | Competes with the insurer’s estimate | A second amount, with the difference flagged for the adjuster |
| Supplement S01 | Adds to a named estimate | New lines found at teardown; current estimated amount becomes base plus S01 |
| Adjusted estimate | Replaces the shop estimate as settlement basis | Each adjusted line with its cost, the settlement amount |
| Final repair invoice | Closes the repair | Amount actually billed, reconciled against base plus every approved supplement |
| Total-loss valuation | Replaces the repair path entirely | Comparable-vehicle value, taxes and fees; every repair estimate becomes history |
Two rows deserve a closer look, because the regulations describe them directly. Section 2695.8(f) says that when a partial loss is settled on a written estimate prepared by or for the insurer, the claimant gets a copy of that estimate. If the claimant then contends, on a written estimate they obtain, that the necessary repairs will cost more, the insurer either pays the difference or, if the claimant asks, names at least one shop that will do the work for the insurer’s figure. The same subdivision says that an adjusted estimate is either an edited copy of the claimant’s shop estimate or a supplemental estimate built on its itemised copy, and that it must identify the specific adjustment to each item and the cost of each adjustment.
That last sentence is an extraction specification. An adjusted estimate is useless as a single total. Its value is line by line: which item changed, by how much, and why. A pipeline that reads only the bottom line has thrown away exactly the information the regulation requires the document to carry.
The total-loss row is the other one. Section 2695.8(b) sets the standards for a cash settlement based on the actual cost of a comparable automobile, less any deductible, including applicable taxes and one-time transfer fees. Once a claim moves onto that path, the repair estimates and supplements stop governing the amount. They still belong in the file, and the pipeline has to know they are now history rather than the latest word.
A supplement is a delta, and it can go down
The habit that causes most of the damage is treating every supplement as an increase. It usually is: hidden damage is the common reason a shop asks for one, and California’s regulation gives supplements their own timing rule. Under section 2695.8(e)(4)(B)2, for first-party claims, an insurer that chooses to inspect or re-inspect in response to a request for a supplemental estimate must, within six business days of receiving that request, ask for the vehicle to be made available and, if it reasonably is, inspect it. A request for a supplement is therefore an event with its own date, separate from the original estimate.
But a supplement is a revision of an earlier document, and revisions can subtract. Consider a reverse example. The original estimate replaces a headlamp assembly. At teardown, the shop finds the assembly intact and only a mounting tab broken, and repairs the tab. Separately, the estimate listed blend labour on an adjacent panel that turned out to be included in another operation. The supplement that follows removes the headlamp part, adds a smaller repair line for the tab, and deletes the duplicated labour. Its net is negative.
A pipeline that sums supplement totals as positive amounts will overstate the claim. One that takes the supplement’s printed total and writes it into the claim’s estimate field will understate it, because the supplement total is a delta and the field expects a full amount. Both errors come from the same mistake: reading the supplement as a standalone estimate instead of as an operation on a named parent.
The safe shape is to keep the lines. Each supplement line carries an operation (added, removed, changed), the item it refers to on the parent estimate where there is one, and the amount of the change. The current estimated amount is computed from the parent and every supplement in sequence. When a supplement arrives that refers to an estimate number the file does not have, or skips from S01 to S03, the computation stops and a person is asked, because the sequence is incomplete and any total would be a guess.
Property claims follow the same shape
Property claims use different documents and the same roles. A contractor’s scope sets an amount basis. A revised scope adds to or replaces it. A public adjuster’s estimate competes with the insurer’s. A final invoice closes the repair. Section 2695.9(d) mirrors the auto rule: when losses are settled on a written scope or estimate prepared by or for the insurer, the claimant gets a copy of each document the settlement is based on, and the estimate must be of an amount that restores the property to no less than its condition before the loss.
Property adds one adjustment that auto handles differently. Under section 2695.9(f), when the amount claimed is adjusted for betterment, depreciation or salvage, all justification for the adjustment has to be in the claim file, and the adjustment must be “discernable, measurable, itemized, and specified as to dollar amount.” Depreciation, in other words, is not a single percentage applied to a total. It is a set of lines tied to specific items, each with its own amount and its own basis, and the extraction has to preserve it in that form.
The consequence for a pipeline is the same as for an auto supplement. Depreciation lines adjust named items on a named scope. Read as a free-standing total, they lose the link that makes them checkable, and the file no longer shows why the paid amount differs from the estimate.
The claim file has to be reconstructable
All of this would be a matter of good practice if the regulation did not also say what the file must contain. Section 2695.3(a) requires claim files to hold all documents, notes and work papers that reasonably pertain to each claim “in such detail that pertinent events and the dates of the events can be reconstructed.” Section 2695.3(b)(2) adds that the insurer records the date it received, the dates it processed, and the date it transmitted or mailed every material and relevant document in the file.
Those three dates are not metadata to attach if convenient. They are part of what the file has to show, and a document pipeline is usually the first system to see a document arrive. If it discards the received date in favour of the date printed on the estimate, or overwrites the previous estimate when a supplement lands, it has made the file harder to reconstruct at exactly the point where a regulator or an auditor would look.
There is a simple test. Pick any claim and ask the system what the estimated repair amount was on a given past date, and which document it rested on. If the answer requires someone to open every attachment and rebuild the sequence by hand, the pipeline is storing documents and losing the claim.
What the extraction should deliver
For each document that arrives on an open claim, the output of a sequence-aware pipeline is a small record alongside the usual extracted fields:
- The document class — notice, police report, estimate, supplement, adjusted estimate, invoice, valuation, scope, with the confidence of the classification.
- The role in the sequence — opens, complements, adds to, replaces or closes, and the document it acts on, identified by estimate number and supplement sequence.
- The line operations — for supplements, adjusted estimates and depreciation, each line as added, removed or changed, with the amount of the change and the source region on the page.
- The derived amounts — the current estimated amount computed from the parent and every supplement, never copied from a single document’s total.
- The dates — received, processed and transmitted, kept separate from the dates printed on the document.
- The break in the chain — a missing parent, a skipped supplement number, an invoice above the last approved total, or a supplement received after the closing invoice, each routed to review with its evidence.
The reserve field stays with the adjuster. A pipeline can show that the current estimated amount rose by a given figure on a given day because of a named supplement, and it can put that change in front of the person who owns the reserve. Deciding whether and how the reserve moves is a judgement under the carrier’s own guidelines, and an extraction system that writes reserves on its own has taken a decision nobody delegated to it. The claims document processing API is built for the first part: classification, field confidence, evidence links and reviewer routing, with insurance claim extraction merging the documents of a packet into one claim record.
Not first notice triage, not submission intake
Two neighbouring problems share some of the same documents and are worth keeping apart.
Triage at first notice, where a model reads the loss report, checks coverage and decides whether a claim can go straight through or needs a handler, is covered in the extraction-to-execution article. That is a decision about routing one document at one moment. This piece starts after it, when the claim is already open and the documents that arrive are revising each other.
Submission intake for underwriting, where an ACORD application arrives with loss runs, schedules and supplemental questionnaires and the question is whether the packet is complete enough to quote, is the subject of the ACORD submission packet article. A loss run there is history used to price a policy that does not exist yet. A supplement here is a revision to a loss that has already happened.
Neither of them is fraud detection. A sequence that is internally consistent can still rest on a fabricated invoice, which the generative fraud article discusses. The checks above test whether the documents agree with each other and with their own references. They do not test whether any of them is genuine.
The claim is the sequence
A first notice tells you that a claim exists. The estimates, supplements, adjusted copies, valuations and invoices that follow tell you what it is worth, and each of them only makes sense against the one it revises. Claims document processing that reads every document well and the sequence badly produces a file of accurate pages and an inaccurate claim. Reading each arrival for its role, keeping the lines rather than the totals, deriving the amounts instead of overwriting them, and keeping the dates the regulation asks for gives the adjuster a file that explains itself, and leaves the reserve with the person accountable for it.