Where Document AI Breaks in Indian Commercial Claims: Handwriting, Stamps, Vernacular Scans and the Forged-Document Trap

Two regulatory clocks are now pushing document automation into commercial claims whether teams are ready or not. IRDAI's fraud monitoring framework, effective 1 April 2026, asks every insurer to run early-warning analytics, maintain a fraud incident database, refresh red-flag indicators and report frauds above one crore rupees inside tight windows. At the same time the 2024 Master Circular timelines (cashless pre-authorisation in an hour, settlement within set day-counts, interest at two percent above bank rate for delay) mean claims teams cannot afford to read every page by hand. Extraction has to move fast, and fraud signals have to surface early.

The trouble is that the 99-percent field accuracy quoted in vendor demos is measured on clean, printed, English documents. Indian commercial claim files are nothing like that. Open a typical marine or fire file and you find a handwritten surveyor's site note, a photocopied lorry receipt with a faded rubber stamp, a tax invoice mixing Hindi and English, a delivery challan signed across the page, and a bill of entry printed in a font the model has never seen. Off-the-shelf optical character recognition was trained on a different world.

This post is the candid version brokers and corporate risk managers rarely get from a sales pitch. We walk through exactly where document intelligence breaks on real Indian claim documents, how to design confidence thresholds and fallbacks so a wrong digit never silently reaches a payout, and why a forged-document detection layer now sits alongside extraction rather than after it. The goal is a system you can defend to a surveyor, a loss adjuster and an IRDAI inspection on the same day.

The single hardest document in a commercial claim file is the one the loss assessor writes by hand at the site. A surveyor visiting a flooded godown or a burnt-out plant records stock counts, damage observations, salvage estimates and reserve figures in a notebook, often in a hurry, often in a hybrid of English shorthand and local-language abbreviations. This is precisely the input that defeats general OCR, which was tuned for printed text and tends to skip handwriting or guess at it.

The failure mode is not random noise. It is confident, plausible, wrong numbers. A handwritten salvage value of 45,000 read as 15,000, or a quantity of 7 read as 1, produces a clean-looking field that no downstream check questions. On a marine cargo total-loss file that single misread can swing the recommended settlement by lakhs.

Three design rules help here.

• Treat every handwritten field as low-confidence by default, regardless of what the model returns. Handwriting should route to human verification as a policy, not as an exception triggered by a score.
• Capture the handwritten figure and the typed version of the same figure (most surveyors also file a typed report) and reconcile them. A mismatch is a flag, not a tie to break automatically.
• Never let a handwritten number set a reserve or a settlement figure without a human keystroke confirming it.

The better insurtech tools now separate printed-text extraction from handwriting recognition and score them on different scales, because a 0.9 confidence on print and a 0.9 on a scrawled site note do not mean the same thing. If your vendor reports a single blended confidence number across both, that number is hiding the risk you most need to see. For the deeper version of this problem on assessor documents, see our piece on extracting structured data from surveyor reports.

Rubber stamps and seals do disproportionate work in Indian claims. A port-trust stamp on a survey report, a transporter's seal on a goods receipt, a notary stamp on an affidavit, a bank endorsement on a bill of exchange: each one carries evidentiary and sometimes legal weight, and each one is exactly the kind of low-contrast, overlapping, often-smudged mark that text extraction handles worst.

The problems compound. A stamp printed over typed text corrupts both the stamp and the underlying field, so an invoice date sitting under a paid stamp may be unreadable in both layers. Circular seals defeat line-based OCR entirely. And because stamps are the visual cue humans use to judge whether a document is genuine, a model that ignores them loses the most important fraud signal on the page.

What to extract, and what to merely locate

A useful distinction in system design is between fields you extract and artefacts you locate. You extract an invoice number. You locate a stamp: you do not need to read every word inside a transporter's seal, but you do need to confirm a seal is present, capture its position, and compare it against the seal you expect for that party.

• Run stamp and seal detection as a separate computer-vision pass, not as part of text OCR. Detection answers a different question (is the mark present and roughly where expected) than recognition.
• Build a reference library of seals for your repeat counterparties (major transporters, ports, recognised surveyors). A goods receipt from a known logistics vendor whose seal does not match the library is worth a human look even if every text field extracted cleanly.
• Flag any field whose characters overlap a detected stamp region as low-confidence, because the model is reading through ink.

For brokers placing marine and transit cover, this matters at claims time on every consignment that moves through a port or a transporter, which is to say nearly all of them in the logistics and warehousing chain.

A commercial claim file rarely speaks one language. A fire claim from a Surat textile unit may carry a Gujarati municipal report, a Hindi police complaint, and English tax invoices, sometimes all three scripts on one page. Mixed-script documents are a known weak point: the model has to detect the script before it can read, and when a single line switches from Devanagari to Latin halfway through (a Hindi address with an English PIN code and a numeral), recognition degrades at exactly the switch point.

The practical failures show up in named entities and numbers. Party names transliterated inconsistently across documents break the matching logic that links an invoice to a policy to a subrogation target. Dates written in regional formats or in words get parsed wrongly. Amounts in Indian numbering (lakh and crore groupings with their own comma placement) are misread by models trained on Western thousands separators, turning twelve lakh into a number two orders of magnitude off.

A vernacular document that extracts with high confidence is not the same as a vernacular document that extracts correctly. Confidence on a script the model handles poorly is itself unreliable, so it cannot be the only gate.

Design implications:

• Detect script per region of the page, not per document, so a mixed page is handled in parts rather than forced into one language.
• Hold a normalisation layer for party names and addresses that treats transliteration variants as the same entity, otherwise your fraud-network and duplicate-claim checks will miss links that a human would see instantly.
• Validate every monetary field against Indian numbering conventions and against the policy sum insured; a claimed loss exceeding the sum insured by a clean factor of ten is usually a comma-grouping misread, not a fraud, but it must be caught.

Vernacular handling is where many deployments quietly fail, because the demo was run on English and the regional documents only appear once the system is live across a real book of business.

Even when the language and handwriting are manageable, image quality on Indian commercial claims is unforgiving. The lorry receipt is a third-generation photocopy. The invoice arrives as a mobile photo taken at an angle under a tube light, half in shadow. The discharge or delivery document was faxed, then scanned, then emailed as a compressed image. Generic tools struggle with exactly this real-world mess: blurry photos, skewed pages, variable layouts and poor scans.

The danger is that quality degradation does not announce itself. A blurred 8 becomes a 3 with no error thrown. So the first job of a serious pipeline is not extraction at all; it is triage on image quality.

1. Score every page for resolution, skew, contrast and blur before extraction runs. Pages below a defined floor go back to the submitter or to a human, not into the model.
2. Set field-level confidence thresholds that are deliberately conservative for the fields that move money: claim amount, policy number, dates of loss, quantities. A field below threshold is not extracted-and-flagged, it is held until a human confirms it.
3. Reconcile the same fact across documents. The invoice value, the goods-receipt value and the surveyor's assessed value should agree within reason. The pipeline's most valuable output is often the list of disagreements, not the extracted values.

Designing the human fallback as a feature, not an apology

The biggest mistake teams make is treating human review as the failure state of automation. It is the opposite. The system's purpose is to send the right ten percent of fields to a human and clear the other ninety percent confidently, so the assessor spends time only where judgement is needed. A well-built fallback queue, sorted by the cost of an error rather than by the model's discomfort, is what makes automation safe. This thinking sits at the centre of any honest straight-through claims processing design and of broader end-to-end agentic claims workflows.

IRDAI's framework moves the sector from reactive detection to proactive prevention, and document AI has to move with it. Extraction tells you what a document says. It does not tell you whether the document is genuine. In commercial claims, where the documents are invoices, goods receipts, valuation reports and bills, altered or fabricated paperwork is a live and growing risk, and the same automation pressure that speeds genuine claims also speeds fraudulent ones if no authenticity layer exists.

A forged-document layer runs alongside extraction and asks different questions of the same file:

• Is this document internally consistent? Do the totals add up, do the line items sum to the stated amount, does the invoice date precede the date of loss in a way that makes sense?
• Is it consistent across the file? The amount on the invoice, the goods receipt and the survey report should reconcile; manipulation usually shows up as a figure changed in one place but not the others.
• Does the artefact layer look genuine? Detected stamps, seals and signatures compared against reference samples; font and spacing anomalies that suggest a number was digitally edited; metadata on uploaded images that contradicts the claimed timeline.
• Does it fit the network? The same invoice number, vehicle number, bank account or transliterated party name recurring across unrelated claims is a classic ring signal. This is where extraction feeds graph-based fraud network detection and the wider commercial fraud analytics effort.

The practical payoff is a single enriched record per document that carries both the extracted fields and an authenticity assessment, so the fraud monitoring unit gets early-warning signals as a by-product of normal claims processing rather than as a separate, slower investigation.

Pulling the pieces together, here is the shape of a document-intelligence pipeline built for real Indian commercial claim files rather than for a demo.

1. Ingestion and quality triage. Accept the file, classify each page by document type, and score image quality. Reject or return pages below the floor before spending compute on extraction.
2. Split-track extraction. Run printed-text OCR, handwriting recognition and stamp or seal detection as separate passes with separate confidence scales. Detect script per region for mixed-language pages.
3. Field-level confidence and routing. Apply conservative thresholds on money-moving fields. Clear high-confidence fields automatically; route low-confidence and all handwritten figures to a human queue ordered by error cost.
4. Cross-document reconciliation. Reconcile amounts, dates, quantities and party names across the file. Surface every disagreement as a worklist item.
5. Authenticity and fraud scoring. Run the forged-document checks and feed extracted identifiers into network detection. Flag, do not decline.
6. Human-in-the-loop settlement. A surveyor or examiner confirms the held fields and signs off the figures that set reserves and payouts. The model assists; it does not authorise.

What this means for placement and audit

For brokers, the takeaway is to ask insurers and TPAs harder questions: not what accuracy you achieve, but how you handle handwriting, vernacular and stamps, and what your human-fallback rate is on commercial files. A vendor who cannot give you a field-level confidence breakdown is selling you the demo number.

For corporate risk managers, especially in manufacturing and logistics where claim files are document-heavy, well-designed extraction is a faster, cleaner settlement and a defensible audit trail. For the marine-specific version of these edge cases, our companion piece on document intelligence for marine cargo claims goes deeper into bills of lading, survey reports and the paperwork a surveyor files with every consignment.

Document AI in Indian commercial claims is genuinely useful. It is just useful in proportion to how honestly it is designed around the documents that break it.