The 5 Types of Invoice Fraud — and the One Layer Your AP Review Misses

A vendor you have paid for three years emails an invoice. The amount is right, the PO number matches, the logo is correct, and the PDF opens cleanly. Your AP clerk runs the three-way match, everything reconciles, and the payment goes out. Two weeks later the real vendor calls asking where their money is.

Nothing in that invoice looked wrong because, on screen, nothing was wrong. The only thing that changed was a string of digits in the remittance block — and that change was made by editing the PDF file after the vendor issued it. Three-way matching never saw it, because three-way matching reads the content, not the file.

This guide covers the five invoice fraud schemes that AP teams actually face, and then the layer that none of the standard controls inspect: the structure of the document itself.

What counts as a fraudulent invoice

A fraudulent invoice is any invoice submitted with intent to extract a payment that is not owed — to the wrong party, for the wrong amount, or for goods and services that never existed. Intent is the dividing line. A vendor who fat-fingers a total has made an error you correct on the next cycle. A fraudster who swaps a bank account is committing a crime designed to look exactly like that error.

It is useful to split fraudulent invoices into two families:

• Fabricated — the document was built from nothing to represent a transaction that never happened (a ghost vendor billing for phantom services).
• Altered — a real, legitimate invoice was intercepted and edited, with one or two fields changed before it reached you (a BEC bank-detail swap).

Most published guides cover the business logic of these schemes and stop at “confirm details out of band.” That advice is correct and incomplete. For the altered family, the evidence of the crime sits inside the PDF, and almost no AP workflow looks at it.

The 5 invoice fraud schemes

1. Business email compromise (BEC invoice redirect)

In a BEC invoice redirect, a fraudster gains access to a payment conversation — by compromising the vendor’s mailbox, spoofing their domain, or hijacking a reply thread — intercepts a genuine invoice, and changes the bank account number to one they control. Everything else stays intact, which is precisely why it works.

The FBI’s Internet Crime Complaint Center puts combined domestic and international BEC losses at $55.5 billion across more than 305,000 incidents between October 2013 and December 2023 — one of the highest-loss categories it tracks. AP teams are the front line, because the redirect lands as an ordinary-looking invoice in an ordinary-looking thread.

This is the scheme most worth catching at the document layer, because the altered invoice is a real file that was opened, edited, and re-saved — and that re-save leaves traces. We come back to those traces below, and in more depth in our guide to BEC invoice fraud detection.

2. Vendor impersonation and mandate fraud

Vendor impersonation — also called mandate fraud or a supplier-swap scam — is the slow-burn cousin of BEC. Instead of altering one invoice, the fraudster poses as a trusted existing vendor and requests a permanent change to the bank details on file. Once the change is accepted, every future payment to that vendor flows to the attacker’s account until someone notices.

The request usually arrives as a polite email with a PDF letterhead attached — a “change of banking details” notice on what looks like the vendor’s stationery. That attachment is often a real document from the vendor with the account number edited, or a lookalike rebuilt from a genuine template. Either way, the file carries structural evidence of how it was actually produced.

3. Ghost vendor fraud

A ghost vendor is a fictitious supplier created inside the payment system, frequently with internal collusion. An employee sets up a vendor record with fabricated bank, tax, and registration numbers, then submits invoices for goods or services that were never delivered and approves the payments to themselves or an accomplice.

Ghost-vendor invoices are usually fabricated, not altered — they were built from scratch to look like a real invoice. Here the document layer plays a different but still useful role: a genuine institutional vendor running accounting software produces files with a recognizable structure, while a one-off invoice typed up in a word processor and exported to PDF does not. That mismatch will not by itself prove fraud, but it is a signal that the document’s origin does not match what an established vendor would send.

4. Duplicate invoice fraud (double payment)

Duplicate-invoice fraud is the quietest scheme: a vendor submits the same invoice twice, betting that two near-identical documents slip through on separate cycles and get paid twice. Sometimes it is opportunistic and sometimes it is systematic, with the invoice number nudged by a character or the date shifted by a day to defeat exact-match controls.

Detecting duplicates is mostly a database problem — deduplication on invoice number, amount, and vendor catches the obvious cases. But when a fraudster re-saves and lightly edits a copy to make it look like a distinct document, the file’s edit history can show that the “new” invoice is a modified copy of an earlier one rather than a freshly issued original.

5. Inflated invoices and unauthorized charges

In an inflated-invoice scheme, a real or impersonated vendor pads the bill — higher unit prices, quantities that exceed delivery, or extra line items for work never done. The overcharge is usually small enough to stay under the threshold that triggers a manual review, so it sails through approval and repeats every month.

When the inflation is done by editing a legitimate invoice — taking the real PDF and bumping a number before forwarding it — the edit leaves the same structural fingerprint as a BEC swap. The total on screen changed; the file’s internal history records that something was changed after issuance.

Why manual review and three-way matching still miss the altered PDF

Three-way matching is the workhorse of AP fraud control, and it is genuinely good at what it does: it confirms that an invoice corresponds to a real purchase order and a real goods receipt. It answers the question “did we order this, and did we receive it?”

It does not answer a different question: “is this file the one the vendor actually issued, or a copy that was edited in between?”

Consider a BEC redirect. The fraudster changed one field — the bank account — and left the line items, totals, dates, and PO number exactly as the vendor wrote them. The match reconciles perfectly, because everything that matching checks is still correct. The one thing that is wrong, the remittance account, is not a field that three-way matching compares.

Manual review has the same blind spot. A reviewer looking at the rendered PDF sees a clean, professional invoice. An edited PDF renders identically to the original — the editing tool repaints the page from the modified content, so there is no visual seam, no smudge, no telltale. The change that matters is invisible on screen and absent from the match. It lives in the bytes.

The document layer: detecting a structurally tampered invoice

Every PDF carries an internal record of how it was made and whether it was changed after the fact. You never see this layer when you open the file, but it is always there, and it is where an altered invoice gives itself away.

A few of the signals a structural check reads:

• The software that produced the file. A PDF records the application that generated it and, separately, the one that last saved it. An invoice issued by an accounting platform that was later opened and re-saved in a general-purpose editor carries a producer string that does not belong in a clean vendor invoice.
• The edit history. PDF saves changes incrementally — each time a file is modified and saved, a new revision is appended and a fresh cross-reference table is written. A freshly issued invoice has one such generation. An invoice that was opened, edited, and saved again carries the evidence of additional sessions in that chain.
• Timestamps that do not line up. When a file’s internal modification time falls after the date the vendor says it issued the invoice, that gap is a question worth asking.

HTPBE? reads more than 60 forensic checks across these structural layers and returns one of three verdicts:

• intact — the file structure is consistent with a clean, once-generated document; proceed to matching.
• modified — a post-issuance edit was detected; hold the invoice for review before any payment runs.
• inconclusive — the file was produced in consumer software with no comparable structure to check; not a failure, but a prompt to confirm the document’s origin against what you know about the vendor.

That inconclusive verdict is its own signal, not a dead end. If a vendor you know runs on established accounting software submits an invoice that comes back inconclusive because it was clearly typed up in a word processor, the origin does not match the vendor’s profile — route it to review. For more on the specific fields involved, see what PDF metadata reveals about a fraudulent invoice.

The verdict ships with named markers, so the answer is never a black box — your AP system records exactly which structural signal triggered a hold, which becomes a permanent audit trail if a payment is ever disputed.

What HTPBE? is NOT

The invoice-fraud space is crowded and the categories blur, so this is worth stating plainly.

HTPBE? is not AP automation. It does not ingest, route, approve, or pay invoices. Platforms like Coupa, Tipalti, and Bill.com own that workflow — they manage the purchase order, the approval chain, and the payment run. HTPBE? does one thing those platforms do not: it reads the structure of the invoice file and tells you whether it was edited after the vendor issued it. The two are complementary. Your AP platform decides whether to pay; a tamper-detection check tells you whether the document is the one the vendor actually sent.

HTPBE? is also not a KYC or identity platform. It does not verify who a vendor is, check them against a registry, or confirm their banking relationship. It reads files, not identities. Out-of-band verification of a new or changed bank account remains the correct control for vendor impersonation — and it sits right next to a document check, not in place of it.

What HTPBE? adds is the one layer the other controls skip: a direct read of whether the invoice PDF in front of you is unedited. It will not catch a perfectly fabricated invoice built from scratch in the same software a real vendor uses, and it does not claim to. It catches the altered file — the BEC swap, the edited inflation, the lightly modified duplicate — which is exactly the family that renders identically and passes the match.

A practical intake workflow

The fix is to add one check at the front of the process, before matching, before approval, at the moment the PDF arrives.

1. Verify the invoice PDF is unedited at intake. When an invoice lands — in your AP platform, your ingestion pipeline, or your inbox automation — send the file’s URL to the API and read the verdict before anything else happens.
2. Route on the verdict. intact proceeds to your normal three-way match. modified is held for a human to review before any payment runs. inconclusive from a vendor you expect to use accounting software is escalated to confirm the document’s origin.
3. Store the check ID against the invoice record. The forensic report stays retrievable, so a disputed payment can be traced back to the exact structural signal that did — or did not — flag at intake.

Integration is a single POST with the PDF URL. Here is the intake check in Python:

import httpx
import os

HTPBE_API_KEY = os.environ["HTPBE_API_KEY"]
BASE_URL = "https://api.htpbe.tech/v1"
HEADERS = {"Authorization": f"Bearer {HTPBE_API_KEY}"}

# Vendors you expect to run on institutional accounting software.
INSTITUTIONAL_VENDORS = {"quickbooks", "xero", "sap", "netsuite", "sage"}


def screen_invoice(pdf_url: str, vendor_platform: str | None = None) -> dict:
    """Return an AP routing decision: 'proceed', 'hold', or 'escalate'."""
    submit = httpx.post(
        f"{BASE_URL}/analyze",
        headers=HEADERS,
        json={"url": pdf_url},
        timeout=30,
    )
    submit.raise_for_status()
    check_id = submit.json()["id"]

    result = httpx.get(
        f"{BASE_URL}/result/{check_id}",
        headers=HEADERS,
        timeout=30,
    )
    result.raise_for_status()
    data = result.json()

    status = data["status"]
    markers = data.get("modification_markers", [])

    if status == "modified":
        return {"action": "hold", "check_id": check_id, "markers": markers}

    if status == "inconclusive" and vendor_platform in INSTITUTIONAL_VENDORS:
        return {"action": "escalate", "check_id": check_id}

    return {"action": "proceed", "check_id": check_id}

The same call works from any stack — the REST API takes a PDF URL and returns the verdict, with self-serve plans (see current pricing) and pay-per-check credit packs for lower volumes. For the full intake pattern, vendor-profile routing, and the verdict catalog, see the fake invoice detection use case.

Who should run this

If you own accounts payable, fraud operations, or finance controls — and your current defense against a tampered invoice is a clerk eyeballing the PDF plus a three-way match — there is a gap in the middle of your process that the altered-file schemes are built to exploit. A document-integrity check closes it without changing how you route or approve a single invoice.

You can try it on real invoices before integrating anything: sign up for a free test key and get 5 checks to run against your own recent files, then decide whether to wire detecting a tampered invoice into your intake.

Frequently asked questions

What is the most common type of invoice fraud?

Business email compromise (BEC) with invoice redirect is the most common and most costly. A fraudster intercepts a real vendor invoice, swaps the bank account number, and sends it through a spoofed or hijacked email thread. The invoice looks legitimate because most of it is — only the remittance details changed.

How do you detect a fraudulent invoice that looks real?

Visual inspection and three-way matching compare the invoice content against your purchase order and goods receipt. They cannot see whether the PDF file itself was edited after the vendor issued it. Structural PDF analysis reads the file’s internal layer — the cross-reference tables, the incremental-update history, and the software that last saved it — to detect a document that was altered after issuance.

Can three-way matching catch a tampered invoice?

Not on its own. If a fraudster edits a real invoice and changes only the bank account, the line items, totals, and PO number still match. Three-way matching confirms the order is real; it does not confirm the file is unedited. The two controls are complementary — run a document-integrity check at intake, then match.

Is HTPBE? an AP automation or KYC platform?

No. HTPBE? is a PDF tamper-detection tool. It reads the structure of an invoice file and returns a verdict — intact, modified, or inconclusive — with named markers. It does not route or approve payments (that is AP automation, like Coupa or Bill.com) and it does not verify a person’s identity (that is KYC). It runs alongside those systems at the intake step.