Tag: Document Fraud

Authentic, Suspicious, Likely Tampered: How a Document Earns a Verdict

Document fraud detection: Authentic, Suspicious, Likely Tampered verdicts

Key Takeaways

  • Every document on a fraud-enabled schema gets one of three verdicts: Authentic, Suspicious, or Likely Tampered.
  • One strong finding caps the score, so eight clean checks can’t average it back up to Authentic.
  • Each verdict comes with a plain-language summary, a breakdown of every check, and the page and region where the problem is.
  • Checks that can’t run on a document type are marked skipped and left out of the score. They are never counted as passed.
  • Likely Tampered sends the document to a person for review. It never rejects a claim automatically

Document fraud detection only helps if your claims team can act on it. “The system says this document is suspicious” is not actionable. A handler needs to know which check fired, what it found, and where on the page to look. Otherwise, the flag becomes one more queue nobody trusts. In our first post, we looked at why altered, duplicated and AI-generated documents slip past manual review, a pattern the Coalition Against Insurance Fraud has been tracking as generative tools spread. This post covers what happens next: how CoverGo IDP turns nine independent checks into one verdict, with the evidence attached.

See it run on a tampered invoice: Book a CoverGo IDP AI Agent demo.

Three document fraud detection verdicts, not a score to interpret

On a fraud-enabled schema, the CoverGo IDP AI Agent returns one of three verdicts for every document.

Authentic. No strong tampering signals were detected. The document proceeds through the normal workflow.

Suspicious. Signals fired, but not conclusively. The document is routed for manual review rather than held or refused.

Likely Tampered. There is strong evidence of tampering. What happens next is the insurer’s decision — escalate to the fraud team, request a resubmission, or hold pending investigation. It is a flag for human review, never an automatic rejection.

Handlers see a badge, not a number to calibrate against. Teams that want finer control can build routing rules on top of the verdict.

One strong signal is enough

You might expect a single check to be outvoted. That is the risk with any average. A weighted average across nine checks has an obvious weakness: a single decisive finding could be diluted by eight checks that found nothing. The pipeline handles this with override rules. When one check returns a strong, specific finding — the arithmetic does not reconcile, the visible text disagrees with the embedded text layer — that finding caps the document’s score, so it cannot be averaged back up into Authentic. A document with one unambiguous problem and eight clean checks still lands in review.

The reasoning travels with the verdict

Alongside the verdict, each document carries a detection summary in plain language, a per-check breakdown showing what every technique returned and why, and a list of flagged issues describing which check fired, what it detected, and where.

Where the evidence is visual — a retouched region, an altered digit — the flagged issue includes the page and a bounding box over the area. Where it is textual, such as a mismatch between what a PDF displays and what its text layer contains, the suspect text itself is surfaced instead. The execution log records which checks ran, which were skipped, and why.

Skipped is not the same as passed

Some checks only apply to some documents. Two of the most reliable checks read the internal structure of a PDF, so they cannot run on a photograph or scanned image of a receipt. Rather than scoring those as clean, the pipeline marks them skipped and excludes them from the calculation, so an absent check never inflates a verdict. A reviewer looking at the technique list sees exactly which checks were available for that document.

Why it matters

Document fraud detection fails in practice when handlers cannot see why something was flagged. A verdict with per-check reasoning, visible evidence, and an honest account of which checks could not run is something a claims team will act on, and something an auditor or regulator can follow after the fact.

See the per-check breakdown on your own claims documents. Book a CoverGo IDP AI Agent demo →

TL;DR

A fraud flag only helps if a claims handler can act on it. CoverGo IDP runs nine independent authenticity checks on each document and returns one of three verdicts: Authentic, Suspicious, or Likely Tampered. Each verdict shows which check fired, what it found, and where on the page to look. One strong finding is enough to cap a document’s score. Checks that can’t run are reported as skipped, not counted as passed. A Likely Tampered verdict sends the document for human review and never rejects the claim automatically.

Frequently Asked Questions

What verdicts does CoverGo IDP return on a claim document?

There are three: Authentic, Suspicious, and Likely Tampered. Authentic documents carry on through the normal workflow. Suspicious documents go to manual review. For Likely Tampered documents, the insurer decides the next step.

Does a Likely Tampered verdict reject the claim?

No. It flags the document for human review. Nothing in the pipeline refuses a claim, closes a case, or contacts the customer.

Can one failed check change the verdict if all the others pass?

Yes. A strong, specific finding, such as totals that don’t add up or a PDF whose visible text differs from its text layer, caps the score. The document can’t average back up to Authentic.

How does a handler see why a document was flagged?

Each verdict comes with a plain-language summary, a breakdown of what every check returned, and a list of flagged issues. Visual findings show the page and a box around the area. Text findings show the suspect text itself.

What happens when a check can’t run on a document?

It is marked skipped and left out of the score. For example, the PDF-structure checks can’t run on a photographed receipt. The reviewer can see exactly which checks were available.

Is document fraud detection on for every document?

No. It is off by default and turned on per document schema, which in practice means per document type.

For more information or an expert-led demo, reach out to a team member.

See the Per-Check Breakdown on
Your Own Documents

A fraud flag only helps if your team can act on it. Bring a claim document from your own book and see the CoverGo IDP AI Agent return its verdict: which check fired, what it found, and where on the page to look. If a check can’t run on that document type, you’ll see that too.

BOOK A DEMO

Altered, Duplicated, Generated: The Document Problem Behind Claims Fraud

Altered, Duplicated, Generated - The Document Problem Behind Claims Fraud

Key Takeaways

  • Much of claims fraud arrives as a document, not a scheme. An invoice total edited from 260 to 2,600, the same receipt submitted against two policies, a PDF where the visible number and the embedded text underneath disagree.
  • AI-generated documents are the newest category and the fastest-growing. Consumer tools now produce a correctly formatted, internally consistent invoice in seconds. Three years ago this barely existed.
  • Manual review fails structurally, not through carelessness. Compression artifacts and noise inconsistency sit below human reading resolution, line items are rarely reconciled against the stated total, and review depth falls as the queue grows.
  • Checking authenticity at intake changes the economics. CoverGo IDP analyzes every document on a fraud-enabled schema on upload, in the same pass that extracts the data, and returns a verdict with the evidence attached.

See it run on a tampered invoice: Book a CoverGo IDP AI Agent demo.

Claims document fraud starts with the document itself

Claims document fraud is rarely elaborate. Instead, it is small, repeatable and hard to spot at reading speed. Four patterns cover most of it.

Someone edits the amount. For example, an invoice total moves from 260 to 2,600. Or a pen stroke turns a 1 into a 4 on a printed hospital bill. Otherwise, the document is entirely genuine.

The same receipt comes back twice. It appears in a second claim, or across two policies. This works because nobody compares submissions.

New text covers the old number. A claimant edits a PDF so the visible figure differs from the text underneath. As a result, the page looks clean and prints clean.

An AI tool creates the whole document. Consumer tools now produce a plausible receipt or invoice in seconds, with correct formatting and consistent figures. Three years ago, this category barely existed.

Why manual review does not catch claims document fraud

The failure is structural. In other words, it is not a matter of diligence.

The signals sit below human resolution. Compression artifacts, uneven noise where someone retouched an image, a font that changes inside one field — nobody reads for these.

Nothing reconciles the arithmetic. Handlers rarely add line items up against the stated total, because doing that on every claim would cost more than the leakage.

Nobody compares across the submission. A claim arrives with four supporting documents. Consequently, service dates that disagree slip through unless someone lays the pages side by side.

Volume beats scrutiny. The longer the queue, the shallower the review. And the queue is always long.

In short, the checks that would catch tampering are exactly the checks that are too slow to run by hand on every claim.

What changes when you check authenticity at intake

The useful moment to check a document is the moment it arrives. That means before adjudication, and before a payment decision depends on it. So the analysis runs on upload, in the same pass that extracts the data, rather than as a separate investigation someone triggers on suspicion.

CoverGo IDP adds this as a layer on top of document extraction. For every document on a fraud-enabled schema, the pipeline looks for signs of tampering, inconsistency and synthetic generation. It then returns a verdict and attaches the evidence to it. Legitimate claims carry on as normal. Documents that look wrong, however, go to review with a specific reason, a page reference, and where the evidence is visual, a box around the region in question.

In upcoming posts, we will cover how a document earns its verdict, what the nine checks look for, why the system flags rather than rejects, and where in the claims book this matters most.

See the evidence open on a tampered invoice. Book a CoverGo IDP AI Agent demo →

TL;DR

Claims document fraud is rarely elaborate: an edited amount, a resubmitted receipt, a PDF with new text laid over the original figure, or an invoice generated by a consumer AI tool and never issued by anyone. Manual review misses these because the signals sit below reading speed and the queue is always long. CoverGo IDP runs document authenticity analysis at intake, in the same pass that extracts the data, and returns one of three verdicts — Authentic, Suspicious, or Likely Tampered — with per-check reasoning and the flagged region marked on the page. In addition, checks that cannot run on a given file type are marked skipped rather than scored as clean, so an absent check never inflates a verdict. As a result, claims document fraud surfaces where it is easiest to act on: before adjudication, not after payment.

Frequently Asked Questions

What counts as claims document fraud?

Four patterns cover most of it. Bad actors edit amounts on an otherwise genuine invoice. Claimants resubmit the same document in a second claim or across two policies. Fraudsters overlay text on a PDF so the visible figure differs from the text layer underneath. And increasingly, the document is generated by a consumer AI tool rather than issued by a provider. None of it requires sophistication, which is why volume is the problem rather than complexity.

Why doesn’t manual review catch altered documents?

Because the checks that would catch tampering are the ones that are too slow to perform by hand on every claim. Nobody adds up line items against the stated total on each submission. Nobody lays four supporting documents side by side to compare service dates. Furthermore, nobody reads a page for compression artifacts or a font that changes inside a single field. A handler has minutes and is assessing coverage, not authenticity.

Can you detect AI-generated invoices and receipts?

Yes — one of the nine authenticity checks looks specifically for documents produced by generative tools rather than issued by a provider. It is deliberately tuned strict, so some synthetic documents will pass rather than over-flagging honest scans. There is no published detection rate, and any vendor quoting one for this category should be asked how it was measured.

Does the system automatically reject a suspicious claim?

No. A Likely Tampered verdict is a flag for human review, with the reasoning and evidence attached. Nothing in the pipeline refuses a claim, closes a case, or contacts a customer. What happens after the flag is a routing rule the insurer sets and owns.

Does this work on a photograph of a receipt, or only on PDFs?

Both, but not identically. Arithmetic reconciliation, date logic, and image forensics all run on photographs and scans. Two of the most reliable checks read the internal structure of a PDF and cannot fire on an image — in that case they are marked skipped and excluded from the score rather than counted as clean, so a reviewer can see exactly which checks were available for that document.

For more information or an expert-led demo, reach out to a team member.

See the Evidence Open on a
Tampered Invoice

Bring a claim document from your own book and see the CoverGo IDP AI Agent run authenticity checks: the verdict, per-check reasoning, and the flagged region marked on the page.

BOOK A DEMO