What a proof of loss is

A proof of loss is the formal, signed statement a policyholder submits to substantiate an insurance claim. Versions are typically titled something like "Sworn Statement in Proof of Loss," and the name is literal: the insured swears to the contents, usually before a notary. A typical form captures the time, origin, and cause of the loss; the policy number; the insured's interest in the property and any other parties' interests; other insurance covering the same property; the value of the property at the time of loss; the amount claimed; and references to the supporting estimates and inventories attached behind it.

Deadlines are where teams get tripped up, because two different regimes exist. Under the New York Standard Fire Policy (NY Ins. Law § 3404), the insured must render proof of loss within 60 days after the loss, unless that period is extended in writing. Many modern homeowners and commercial forms work differently: the 60-day clock starts from the insurer's request for a proof of loss, not from the loss itself. Both variants are common, and neither generalizes to the other — the operative deadline is whatever the governing policy says, and state statutes and regulations can modify policy deadlines (in New York, for example, Insurance Law §3407 bars forfeiture unless the insurer has demanded proof in writing and furnished blank forms) — so check the policy and the governing law for each claim.

Why proof-of-loss packets are hard to parse

For a document that carries so much legal weight, the packet is remarkably hostile to automation:

• Notary stamps and signature blocks. Seals, embossments, and overlapping signatures sit directly on top of printed text, confusing naive OCR and making "is this actually sworn and notarized?" a real extraction question rather than a checkbox.

• Handwritten dollar figures. Claimed amounts, actual cash value, and deduction lines are frequently filled in by hand. A misread digit in a claimed amount is not a rounding error — it changes the claim.

• Carrier-specific templates around a common legal core. Carriers lay out the same statutory substance differently, so a template-locked parser that works for one carrier's form breaks on the next.

• The real data often lives in the attachments, not the form. The form itself may state a single claimed total, while the substance of the claim — room-by-room contents inventories, contractor estimates, repair line items — sits in schedules stapled behind it. A pipeline that only reads the sworn form captures the summary and misses the claim.

Where traditional approaches fall short

Print-tuned, single-pass OCR commonly misreads the handwritten dollar amounts and dates that carry the claim's substance, and treats notary stamps and overlapping signature blocks as either noise to drop or text to garble. Template and zonal extraction keyed to one carrier's field positions misfields the next carrier's layout, because the shared legal core moves around the page from form to form — and the attached inventory and estimate schedules, where the real data lives, need table-structure preservation that a flat OCR text dump doesn't provide. The job calls for handwriting-capable, template-free extraction that preserves structure across the sworn form and its attachments alike.

What to extract

A useful schema treats the packet as a form plus a set of schedules, not one flat document.

From the sworn form itself:

Field group	Examples
Identifiers	Policy number, claim number, insured name, property address
Loss details	Date and time of loss, cause/origin, location
Amounts	Total value at time of loss, amount claimed, other insurance
Interests	Insured's interest, mortgagees or other parties with an interest
Execution	Signature present, notarization present, date sworn

From the attached schedules, extract line items as repeated structured rows: for a contents inventory, each row's item description, quantity, age or condition, and claimed value; for a contractor estimate, each line's scope description and amount. Keeping schedule rows as structured line items — rather than a blob of text — is what makes downstream reconciliation possible.

Building it with Reducto

Reducto's pipeline maps naturally onto the packet's structure — and the hardest part, the handwriting, is exactly what Reducto's handwritten property loss form cookbook demonstrates end to end: reading a handwritten property loss notice and turning it into citation-backed structured JSON with confidence scoring on each field.

Split the form from its attachments. Proof-of-loss packets typically arrive as one scanned PDF: sworn form up front, inventories and estimates behind. The Split API partitions the packet by described categories — the sworn statement, contents inventories, contractor estimates — so each section can be processed with a schema that fits it.

Extract the form fields. Run the sworn form through Extract with a schema covering the identifier, loss-detail, amount, and execution fields above. Because extraction is schema-driven rather than template-locked, the same schema works across carrier layouts that share the common legal core.

Deep Extract over the schedules. Inventory and estimate schedules are repeating-row documents, which is exactly what Deep Extract is for: each inventory row or estimate line becomes one structured item, however many pages the schedule runs.

Citations for adjuster review. Enable citations so every extracted value carries a pointer back to its location in the source document. On a sworn statement, adjusters need to verify values against the page — especially handwritten ones — and citations make that a click rather than a hunt.

Edit, where carriers fill forms instead of reading them. Some workflows run the other direction: a carrier or TPA needs to populate a proof-of-loss form programmatically from data it already holds. The Edit API fills a PDF's fields — text, amounts, checkboxes — from natural-language instructions, following the same extract-then-fill pattern shown in the form-filling cookbook, where structured data extracted from one document populates a blank form.

For the claims-side sibling pattern — carrier loss history rather than policyholder submissions — see the loss run cookbook, which parses loss run reports into clean claims tables. For the broader claims-intake context, see Reducto for insurance.

Validating accuracy

Two checks are the workhorses of validation in proof-of-loss processing:

Reconcile the form total against the schedule sum. The amount claimed on the sworn form should tie out to the sum of the attached inventory and estimate line items. Because the form fields and the schedule arrays are extracted separately, this reconciliation is a simple comparison — and a mismatch is a signal worth surfacing either way: it may be an extraction error, or a genuine discrepancy in the packet that an adjuster should see before anything downstream happens.

Spot-check handwriting through citations. Route low-confidence or high-stakes values — handwritten dollar amounts above a threshold, the sworn date, the claimed total — to human review, with each value's citation opening the exact region of the scan it came from. Reviewers confirm digits against the page instead of re-reading the packet.

FAQ

Is the proof of loss the same as the claim? No. Filing a claim notifies the insurer that a loss occurred; the proof of loss is the sworn, formal statement substantiating what is being claimed and for how much.

What deadline applies to submitting a proof of loss? It depends on the governing policy. The New York Standard Fire Policy (NY Ins. Law § 3404) requires it within 60 days after the loss unless extended in writing, while many modern forms require it within 60 days of the insurer's request. Check the policy for the applicable version.

Can extraction handle handwritten amounts on the form? Yes — and because handwritten figures carry more risk than printed text, pair extraction with citations so reviewers can confirm each amount against the original scan.

Does one schema work across different carriers' forms? Generally, yes. Carrier templates vary in layout but share the same legal core — identifiers, loss details, amounts, execution — so a schema targeting that core transfers across layouts without per-template configuration.