Expense Report Fraud Detection: The Altered Receipt PDF Your Controls Never Inspect

The Association of Certified Fraud Examiners puts expense reimbursement fraud at a median loss of $40,000 per scheme, with a median duration of two years before detection. That two-year gap is not an accident. It is the predictable result of a control environment that validates everything about an expense claim except the one artifact the claim rests on: the receipt PDF itself.

First, a quick boundary, because this site covers two different fraud classes that people often confuse. Vendor invoice fraud — a supplier’s invoice intercepted and edited in transit, or a fake supplier billing for nothing — is a different document, a different submitter, and a different control. We cover it in the accounts payable invoice fraud breakdown. This post is about the other case: employee-submitted expense receipts and hotel folios in a travel-and-entertainment (T&E) reimbursement workflow. Same finance team, completely different blind spot. The vendor-invoice control is the three-way match. The expense-receipt control is the expense policy. Neither one looks at the file.

The T&E Control Environment, and Where It Stops

Walk through how a typical mid-market expense claim is checked, and you can see exactly where the inspection ends.

An employee returns from a trip, opens the expense tool — Concur, Expensify, Ramp, Brex, a homegrown form — and uploads receipt images and PDFs against each line. A manager approves. Finance spot-checks. If the company is large enough to care about SOX, the controllership layer adds detective controls: sampling, duplicate-detection, policy-threshold flags, and the famous three-way match — purchase order against invoice against goods receipt.

Every one of those controls operates on data extracted from the receipt, never on the receipt as a file. The three-way match confirms that an invoice amount agrees with a purchase order and a goods-received note. It is an excellent control for procurement. But it says nothing about whether the hotel folio an employee attached to a $312 line was the folio the hotel actually issued, or a copy of it with the room rate quietly raised from $189 to $312.

This is the structural blind spot in detective controls for accounts payable: the three-way match was designed for vendor-billed spend that flows through purchasing. Employee reimbursements flow through a different door. They are usually self-submitted, individually small, and — most important — almost always below the approval and sampling thresholds that trigger review. A $312 dinner does not get a second look. A thousand $312 dinners across a sales team over two years is the $40,000 ACFE median walking out the door.

Why Receipt Fraud Survives the Standard Checks

Four properties of T&E make the receipt PDF the softest target in the finance stack.

It sits below the threshold. Sampling and dual approval start at amounts that most travel line items never reach. The fraud is sized to stay unnoticed — small edits, repeated.

It is self-submitted. Unlike a vendor invoice that arrives over a (theoretically) controlled channel, the receipt is whatever the employee chooses to upload. There is no handshake with an issuing system. The finance team receives a file and a claim, and is asked to trust that the two match.

It is reviewed visually, if at all. A manager glancing at a folio is checking that it looks like a hotel bill for roughly the right city on roughly the right dates. An edited room rate, an added minibar line, a date moved to bring a personal weekend inside the business-trip window — none of that is visible to a human approver who has no original to compare against. OCR-based duplicate detection reads the displayed number; it cannot tell whether that number was the one the hotel printed.

The genuine receipts are messy too. Real receipts come as phone-camera photos, scanner output, airline emails saved to PDF, and folios generated by whatever property-management system the hotel runs. The finance team has no clean baseline to compare against, which is exactly the cover an edited receipt needs.

The result: the receipt PDF is the only document in the entire reimbursement chain that nobody inspects structurally, and it is the one document the claim depends on entirely.

What an Altered Receipt Actually Looks Like

The common T&E manipulations are simple and effective:

• The inflated restaurant receipt. A real $84 dinner becomes a $184 dinner by editing the total. The restaurant name, the date, and the card’s last four digits all stay correct — only the number changes.
• The edited hotel folio. A genuine folio for a discounted rate is opened, and the nightly rate or the number of nights is raised. Fake hotel folio fraud is a long-standing favorite, because folios are dense, full of line items, and rarely checked against the booking.
• The doctored rideshare or airfare receipt. An Uber or airline receipt saved to PDF, then edited to raise the fare or change the route so a personal trip looks like business.
• The date shift. The amount does not change; a single date is moved so a non-reimbursable expense falls inside an approved travel window.

In each case the fraudster starts from a real document and changes a value. That detail matters a great deal, because it is exactly the pattern structural tamper detection is built to catch. The original file was generated by a hotel system, an airline, or a card terminal’s e-receipt service. The edit was made afterward, in a consumer PDF editor, and opening and re-saving that file leaves a structural record — the editor cannot make the change without disturbing the document’s internal construction.

How Structural Tamper Detection Catches the Edit

HTPBE? is a file-integrity layer. It does not read the dollar amount on the receipt, decide whether $312 is reasonable, or know what the hotel charged. It is not a KYC or identity tool, and it does not validate content. What it does is analyze how the PDF was built — its cross-reference (xref) tables, its incremental update layers, its signature state, and the producer and date metadata that records which software touched the file and when — and return one of three verdicts: intact, modified, or inconclusive, plus a list of named markers that describe what was found.

When a genuine institutional receipt is opened in a desktop editor and a value is changed, the editor appends an incremental update layer rather than rebuilding the file from scratch, and it rewrites the metadata to record itself as the last tool that saved the document. A folio that claims to come from a hotel property-management system but carries the modification fingerprints of a consumer PDF editor is internally inconsistent in a way the displayed page never reveals.

Here is the response on a hotel folio that was issued cleanly, then opened in a desktop PDF editor to raise the nightly rate. First submit the file:

curl -X POST https://api.htpbe.tech/v1/analyze \
  -H "Authorization: Bearer $HTPBE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://your-storage.example.com/expenses/folio-8841.pdf"}'

That returns an id. Retrieve the verdict:

{
  "id": "7c4a1f90-2b6e-4d3a-9f81-5e2c8a4b7d10",
  "status": "modified",
  "modification_confidence": "high",
  "modification_markers": [
    "HTPBE_MULTIPLE_REVISION_LAYERS",
    "HTPBE_EDITING_TOOL_FINGERPRINT",
    "HTPBE_DATES_DISAGREE"
  ],
  "origin": { "type": "consumer_software", "software": "desktop PDF editor" },
  "creator": null,
  "producer": "a desktop PDF editor",
  "xref_count": 2,
  "has_digital_signature": false,
  "creation_date": 1755302400,
  "modification_date": 1755561600
}

Three things line up. HTPBE_MULTIPLE_REVISION_LAYERS reports that the file carries more than one revision layer — it was modified after it was first created. HTPBE_EDITING_TOOL_FINGERPRINT reports the fingerprints of a known PDF editing tool, which is not how a hotel system produces a folio. HTPBE_DATES_DISAGREE reports that the modification timestamp is three days later than the declared creation date. On its own, any one of these can have an innocent explanation. Together, on a document that is supposed to be a freshly issued folio, they are a high-confidence signal that the file was opened and re-saved between issuance and submission.

The verdict is modified with named markers. That is enough to hold the line item for review — not enough to fire the employee. A modified verdict is a structural anomaly, not a confession. It justifies a reviewer asking the employee for the original folio, or calling the hotel. Other markers in the same family carry the same weight where they apply: HTPBE_CHARACTER_OVERLAY_EDIT (targeted character-level overlays added by a desktop editor) and HTPBE_TEXT_OVERLAY_ON_SCAN (values painted on top of a scanned receipt) describe the two most common ways a number gets changed on a receipt. The full id-to-outcome dictionary is published on htpbe.tech/how, so you can branch your routing logic on the marker id and render the human-readable label from one place.

Want to See It on Your Own Receipts?

Before you integrate anything, pull a handful of receipts from a closed expense cycle — some you trust, ideally one or two you have already flagged — and run them through the free PDF check on the homepage. No API key, no signup. You will get the verdict and the markers in a few seconds. This is the fastest way to see whether this layer catches anything in your actual receipt flow before you spend a line of engineering time.

The inconclusive Verdict Is What Matters Most in T&E

Here is where expense receipts differ sharply from vendor invoices, and where most teams misread the tool if they are not warned.

A large share of legitimate receipts are generated by consumer software. A genuine Uber receipt is an HTML email rendered to PDF. A genuine restaurant e-receipt comes from a card-terminal service. A photo of a paper receipt is a phone-camera scan. None of these are institutional documents in the way a bank statement or a notarized deed is. When HTPBE? sees a file with no prior structure to compare against — a clean, single-revision document built in consumer software — it returns inconclusive:

{
  "id": "b91e7d23-4c8a-4f15-8e6d-3a9f1c7b2e04",
  "status": "inconclusive",
  "status_reason": "consumer_software_origin",
  "modification_markers": [],
  "origin": { "type": "consumer_software", "software": "an HTML-to-PDF renderer" },
  "producer": "an HTML-to-PDF renderer",
  "xref_count": 1,
  "has_digital_signature": false,
  "creation_date": 1755302400,
  "modification_date": null
}

inconclusive is not a failure and it is not a fraud signal. It means this file was built by consumer software, so there is no institutional baseline against which integrity can be proven or disproven. On a vendor invoice that claims to come from QuickBooks, inconclusive is suspicious. On an Uber receipt, inconclusive is exactly what a genuine receipt looks like. If you auto-reject every inconclusive in a T&E pipeline, you will reject most of your honest receipts and learn nothing.

The correct way to use inconclusive in expense workflows is to route on the claimed issuer, not on the verdict alone:

• A receipt that claims to be a hotel folio or an airline e-ticket and returns inconclusive deserves a second look. Those issuers normally produce structurally distinctive output, so a consumer-software origin is slightly off-profile.
• A receipt that claims to be a restaurant tab, a rideshare, or a phone photo of paper and returns inconclusive is unremarkable. That is the expected result. Move on.

This is the single most important operating instruction for T&E: modified is your hold signal; inconclusive is a routing hint that means something only when compared with what the receipt claims to be. Treat them differently, or the tool is useless to you.

Integrating Into the Reimbursement Workflow

The check fits in at submission, before the claim enters the approval queue. Three steps:

1. At upload, when the employee attaches a receipt, push the stored file URL to POST /api/v1/analyze. You get back an id.
2. Read the verdict from GET /api/v1/result/{id}. Branch on status and the modification_markers[] array.
3. Route the claim. intact → continue to normal approval. modified → flag the line item and hold it for a reviewer with the marker list attached. inconclusive → apply your claimed-issuer rule above.

import requests, os

def check_receipt(file_url):
    api = "https://api.htpbe.tech/v1/analyze"
    headers = {"Authorization": f"Bearer {os.environ['HTPBE_API_KEY']}"}

    submitted = requests.post(api, headers=headers, json={"url": file_url})
    check_id = submitted.json()["id"]

    result = requests.get(
        f"https://api.htpbe.tech/v1/result/{check_id}", headers=headers
    ).json()

    status = result["status"]                 # intact | modified | inconclusive
    markers = result["modification_markers"]  # e.g. ["HTPBE_MULTIPLE_REVISION_LAYERS"]

    if status == "modified":
        return "HOLD", markers                # structural edit — reviewer follows up
    if status == "inconclusive":
        return "ROUTE_BY_ISSUER", markers     # apply claimed-issuer rule
    return "PASS", markers

Store the id against the expense line. There is no numeric risk score — the API returns a verdict plus named markers, never a 0–100 number — so your audit trail is a stable verdict and the specific markers that produced it. If a reimbursement is ever disputed or pulled into an internal-audit sample, GET /api/v1/result/{id} retrieves the immutable forensic record that shows which markers triggered the hold and when. That is a detective control with an evidence trail, which is exactly what a SOX environment wants.

What This Cannot Catch — Stated Plainly

Structural tamper detection has a hard boundary, and pretending otherwise would set you up to fail.

Receipts fabricated from scratch are out of scope. If a fraudster does not edit a real folio but instead builds a fake receipt from nothing — a convincing hotel bill generated in a design tool or on a receipt-generator site — the file has no prior structure to be inconsistent with. It is internally clean. HTPBE? returns inconclusive (consumer-software origin) on such a file, exactly as it would for a genuine consumer-software receipt. The structural layer cannot tell a well-made fake-from-scratch apart from an honest one, because neither has anything to contradict.

AI-generated receipts are out of scope for the same reason. A receipt produced end-to-end by a generative model is born synthetic. There is no edit to detect, because there was no original to edit. Catching fabricated and AI-generated receipts is a content-layer problem — cross-referencing the claimed transaction against issuer data, card-network records, or booking systems — which is a different category of product from file-integrity forensics.

What HTPBE? catches reliably is the alteration of a genuine document: the real folio with the rate raised, the real airfare receipt with the route changed, the real restaurant tab with the total raised. That is the most common T&E manipulation, precisely because starting from a real receipt is easier than fabricating a convincing one — and it is the manipulation that structural forensics is built to surface. Use it for what it is: one layer in a defense that also includes policy controls, issuer cross-checks for high-value claims, and human review of what gets flagged.

Who This Is For

If you own a T&E control environment — Head of Internal Audit, Controller, AP or expense operations lead, a finance team with a SOX detective-controls mandate — this closes a gap your existing stack genuinely does not cover. The three-way match protects procurement. Sampling and duplicate detection catch the obvious cases. Neither inspects the receipt PDF as a file, and the receipt is where reimbursement fraud lives.

A practical starting point is the expense reimbursement fraud use-case guide for routing patterns and policy integration, and the fake receipt detection deep-dive for the document-class detail. When you are ready to connect the check to your submission flow, the API reference lists the full request and response contract, and you can create an account to generate a key. Run a sample of closed expense reports through it first. The math on a check that costs a fraction of a cent against a $40,000 median scheme only matters if the layer catches a meaningful share of your actual receipt flow, and a sampling pass is how you find out.

Frequently Asked Questions

How do you detect a fake or altered expense receipt?

By analyzing the receipt PDF’s structure rather than its displayed content. When a genuine receipt is opened in a desktop editor and a value is changed, the editor appends a new revision layer and rewrites the metadata to record itself as the last tool that saved the file. HTPBE? returns modified with named markers such as HTPBE_MULTIPLE_REVISION_LAYERS and HTPBE_EDITING_TOOL_FINGERPRINT when those structural fingerprints are present on a document that is supposed to be a freshly issued receipt. It does not read the dollar amount and does not decide whether the amount is reasonable — that is a content question.

Does the three-way match catch expense receipt fraud?

No. The three-way match validates a vendor invoice against a purchase order and a goods receipt — it is a procurement control. Employee expense reimbursements are self-submitted, usually below sampling thresholds, and do not pass through purchasing, so the three-way match never sees them. It also never inspects the receipt PDF as a file under any circumstance. That is the structural blind spot in detective controls for accounts payable that file-integrity analysis fills.

What does an inconclusive verdict mean on an expense receipt?

It means the receipt was generated by consumer software — an HTML-to-PDF renderer, a phone-camera scan, a card-terminal e-receipt — so there is no institutional baseline to prove or disprove integrity against. A large share of genuine receipts return inconclusive, so it is not a fraud signal on its own. Route it by what the receipt claims to be: inconclusive on a hotel folio is slightly off-profile and worth a look; inconclusive on a rideshare or restaurant tab is the expected, normal result.

Can you catch a receipt that was fabricated from scratch or generated by AI?

No — that is the honest limit. A receipt built from nothing in a design tool or produced by a generative model has no original to be inconsistent with, so structural forensics returns inconclusive, the same as a genuine consumer-software receipt. Catching fakes built from scratch and AI-generated fakes requires content-layer verification against issuer or card-network data, which is a different category of tool. HTPBE? reliably catches the alteration of a genuine document, which is the most common T&E manipulation.

Where does this fit in a SOX control environment?

As an automated detective control at the point of receipt submission, with an evidence trail. Each check produces a stable verdict plus the specific markers that justified it, retrievable later via GET /api/v1/result/{id} if a reimbursement is disputed or sampled in an internal-audit review. It complements policy controls and sampling rather than replacing them — it adds inspection of the one artifact those controls historically never examine.