How to Detect Document Fraud in 2026: Altered Invoices, Contracts and Credentials

The pattern shows up again and again in business email compromise reports. A mid-sized company has worked with a supplier for years. One day the supplier emails to update their banking details for the next payment. The email arrives on the existing thread, references a real purchase order, and carries an attached invoice identical in every visible respect to the dozens that came before it. The payment goes out. The account belongs to the fraudsters.

Losses in individual cases of this kind run well into six figures. And the attack is not a sophisticated nation-state operation — it is a playbook circulating on darknet forums for the price of a takeaway. What has changed recently is not the idea. It is how cheap and how convincing the paperwork has become.

What generative tools can produce now

The barrier to entry for document fraud has collapsed. Given a single reference image, modern models can reproduce almost any business document — letterhead, layout, typography, tone of voice.

Invoices and purchase orders

Current models can reproduce the exact output formatting of the major accounting platforms — QuickBooks, Xero, NetSuite — from one example. They will invent plausible vendor names, invoice numbers, line items and totals. Paired with a compromised email thread, a fraudster can inject a fabricated invoice into an existing payment approval workflow where it passes routine scrutiny precisely because it arrives through the expected channel.

Invoice fraud predates all of this. What is new is the quality and the speed. Work that used to require a skilled forger with Photoshop and a few hours now takes ninety seconds and no design skill at all.

Contracts and agreements

Language models generate contracts that match the structure, register and legal phrasing of real agreements. A forged employment contract, vendor services agreement or NDA can be produced with consistent formatting, correct clause ordering and plausible signatory details. These documents are not necessarily legally enforceable — but they do not need to be. They need to survive an accounts payable manager's first glance on a busy Monday morning.

ID documents and credentials

This is where the problem gets genuinely dangerous. Realistic-looking government IDs, employee badges, academic credentials and professional certifications are all within reach, and each has a workflow attached to it where money moves on the strength of the document:

• Loan applications — forged payslips, bank statements and employment verification letters.
• Insurance claims — altered medical documents, inflated receipts, forged repair estimates.
• HR onboarding — fake degree certificates, fabricated employment histories, fraudulent references.
• B2B due diligence — forged business registrations, fabricated insurance certificates, fake compliance documentation.

The common thread: in every case, the document's job is simply to look legitimate enough to clear an initial review. The stakes behind that first glance are real money.

Three ways this plays out

The scenarios below are composites rather than specific cases, drawn from patterns documented in BEC reports filed with the FBI and IC3.

Scenario 1: the vendor payment update

Your company has a long-standing relationship with a supplier. They email — from their real address, referencing a real PO number — asking you to update their bank details before the next payment run. They attach an updated W-9 and a voided check. Everything looks right.

What actually happened: an attacker compromised the vendor's email account, or spoofed it convincingly. They read the existing thread, matched its tone and formatting, then sent a routine-looking banking update with fabricated attachments. The W-9 carries a correctly formatted EIN. The voided check shows a legitimate-looking routing number. The account behind it is a mule account.

Red flags worth training your team on:

• The attached invoice differs subtly from the usual payment terms format.
• A banking change request arrives with no verbal or secondary confirmation.
• There is urgency in the email — unusual for a routine administrative update.
• Font rendering or document metadata does not match previous invoices from the same vendor.

Scenario 2: the forged employment credential

During onboarding, a new hire submits a degree certificate and prior employment verification. The documents look professional and properly formatted. Three months later you discover the institution does not exist and neither does the previous employer.

What was actually submitted: a plausible bachelor's degree in Business Administration from a university with a realistic name, seal and embossed letterhead — and no campus. Alongside it, an employment verification letter from a "Fortune 500 company" naming a fabricated HR contact and supervisor. Both passed a routine document review.

• The certificate seal looks slightly pixelated at print resolution.
• The HR contact's email domain is a personal address, not a corporate one.
• Employment dates do not line up with the candidate's stated timeline.
• The verification callback reaches a voicemail that is never returned.

Scenario 3: the inflated insurance claim

A claims processor receives itemised invoices, lab results and a prescription history from a claimant. The numbers add up. The formatting is consistent with the provider. The claim is approved.

What actually happened: the underlying documents were genuine. The claimant edited them — raising line item costs, adding fictional charges — and re-exported the result. Fonts, layout and letterhead all still match the provider's real documentation, because they are the provider's real documentation, with numbers changed.

• Line item totals show unusual rounding patterns.
• Dates and reference numbers do not follow the provider's actual sequence.
• File metadata shows a creation timestamp far from the date of service.
• Header placement drifts subtly between pages.

Scenario 3 is the most instructive of the three, because it defines what a document check should actually be measuring. Nothing here was generated from scratch. A real document was altered — and that is the thing a forensic check can see.

What our document check actually measures

This is the part most worth reading carefully, because it is the most commonly misunderstood feature we ship.

Our document mode answers one question: has this document been altered? It returns a manipulation probability — a score for how likely it is that the artefact you uploaded has been edited after the fact. It is not an AI-authorship score. It does not tell you that a document was "written by AI" or "generated by ChatGPT," and any tool that claims to do that for a scanned invoice is overselling itself.

Three layers run over the document, and each one sees something the others cannot.

Error Level Analysis

Every time a JPEG is saved, compression artefacts are baked into the pixels. A region that has been edited and re-saved carries a different compression history from the untouched parts of the same image. Error Level Analysis re-compresses the document at a known quality level and measures how far each region moves — the untouched areas barely shift, while edited regions light up. In practice this is what catches an amount that has been painted over on a bank statement or a date that has been retyped on a receipt.

Semantic and visual inspection

A vision pass examines the document the way an experienced forensic examiner would, looking for signs of tampering and internal inconsistency: font weight, size or kerning that changes inside a single field; numbers that sit slightly off the document's grid; tone and saturation mismatches between one region and its surroundings; selective blurring; cloned or repeated pixel textures; shadows and lighting that do not agree with the rest of the page; damaged or missing security features. It also weighs the evidence the other way, treating consistent typography, uniform compression, and the natural skew, folds and wear of a genuinely handled document as signs of authenticity.

Structural forensics

The third layer reads the file rather than the picture — metadata and internal document structure. Signals here are often the bluntest evidence available:

How the layers are combined

The signals are combined rather than averaged. The semantic pass carries the greater weight, because it is the layer that can distinguish a suspicious inconsistency from ordinary scanning noise. Error Level Analysis contributes the remainder. Structural forensics then acts as a floor rather than an ingredient: the strongest forensic signal is never diluted below its own level. If the file structure shows clear evidence of editing, a clean-looking scan cannot average that evidence away.

What you get back is a manipulation probability with a verdict band — from appears authentic, through minor inconsistencies detected and possible signs of tampering, to appears manipulated — plus the individual score from each signal, so you can see which layer fired and how hard.

The question is not "did a machine write this?" It is "is this document still the document it claims to be?" Those are different questions, and only the second one can be answered from the pixels.

The misreading to avoid

Here is the single most common misinterpretation, and it is worth stating plainly: a genuine, human-produced document that was later edited will score as manipulated. That is correct behaviour, not a false positive.

If a real supplier invoice is opened in an image editor and one figure is changed, the document is now manipulated — regardless of who created the original or how legitimate the supplier is. Conversely, entirely fabricated paperwork that was rendered once, cleanly, in a single pass may show few manipulation artefacts, because nothing was edited after the fact. The score measures tampering, not honesty. Read it as "this artefact has been worked on," and it will serve you well; read it as a fraud verdict, and it will mislead you in both directions.

What the check does not do

The tool analyses the document artefact itself. That is the whole of its scope, and being clear about the edges matters more here than in most product copy, because money moves on these decisions.

It does not verify vendor identity. It does not check sender domains or read email headers. It does not validate bank details against your supplier master record. In the vendor payment scenario above, a forensic check might well flag the attached voided check — but nothing in the analysis of that image can tell you the routing number belongs to a mule account, or that the email account was compromised last Tuesday.

And a clean result means one specific thing: no detectable signs of manipulation. It is not a certificate of authenticity. Treat the document check as one control inside a payment approval process — a fast, consistent screen that catches altered artefacts before a human is asked to make a judgement call — rather than as a replacement for that process.

On input: upload an image or scan of the document — JPEG, PNG or WebP — or the PDF itself, up to 10MB. A clear photo of a printed invoice works, and so does a flatbed scan.

PDFs take a deliberately different route, and it is worth knowing which signals you get. Error Level Analysis is a raster technique: it reads compression history in pixels, which a digitally generated PDF simply does not have. So on a PDF we skip ELA rather than run it and report a meaningless number, and lean on the other two layers instead — the semantic pass reads the PDF directly, and structural forensics parses the file's own bytes for incremental-update history, editing-tool metadata and signature state. That last layer is often stronger on a PDF than on a photograph, because a PDF carries a record of its own revisions in a way a flattened image does not.

The practical consequence: on a PDF you will see the error-level analysis line reported as not applicable, and that is expected rather than a failed check. What we do not offer is bulk ingestion straight from an email inbox — each document is checked individually.

We also do not publish an accuracy figure or a false positive rate for document detection, for the same reason we do not publish one for text. We have not run the kind of controlled, reproducible evaluation that would justify a number on this page, and quoting one anyway is the industry habit we would rather not join. What we will tell you is exactly which signals ran and what each one scored, on every check.

How to protect your organization

Document fraud detection is not a single product decision — it is a process. Here is what a robust approach looks like.

1. Add a verification step before any payment or credential approval

Any request to change payment details, banking information or wire instructions should require secondary verification — not a reply to the email, but a phone call or video confirmation to a number you already hold on file. This one control stops most invoice fraud, including every variant of Scenario 1. It costs a two-minute call against a six-figure loss.

2. Run a document check on all new vendor credentials

Before onboarding a new vendor or contractor, put their submitted documents through the document scanner. This matters most for contracts above $10K, vendor agreements with suppliers you have no history with, and any credential submitted for a regulated compliance purpose — the cases where nobody in the chain has a prior version of the document to compare against.

3. Scan submitted documents before insurance or loan processing

Insurance claims and loan applications are the two highest-stakes document workflows most organisations run. Checking every submitted document — not only the ones that already look suspicious — is what catches the submissions that would never have triggered a manual review. The alteration in Scenario 3 was invisible precisely because the claim looked ordinary.

4. Check metadata before approving any scanned submission

A surprisingly large share of document fraud involves files that were produced digitally and presented as scanned originals. Metadata frequently gives this away on its own — creation timestamps, editing history, the software fingerprint, camera EXIF where there should be scanner output. Build a metadata check into your intake workflow rather than leaving it to whoever happens to open the attachment.

"The invoice looked exactly like every other invoice we'd received from them for three years. Same formatting. Same font. Same sign-off style. We'd have caught it if we'd been looking for altered documents — but nobody is." — Accounts payable manager, manufacturing firm (BEC report, 2025)

That last sentence is the real problem. The documents are not perfect; they are simply never examined. A check that runs by default, on every document, changes the economics of the attack more than any amount of additional vigilance from people who already have a full inbox.