BEC Invoice Fraud Detection API: Stop Redirected Payments

A vendor email arrives. It looks correct — the sender domain matches, the invoice number is real, the branding is correct. The PDF attachment opens without error. The only change is a bank account number in the remittance section, replaced with an attacker-controlled account.

This is business email compromise applied to invoice fraud. The FBI’s Internet Crime Complaint Center reports $43 billion in adjusted losses globally since 2016, making BEC the single highest-loss fraud category it tracks. AP teams are the target. The structural evidence of the swap is inside the PDF — undetected because no one examines the file structure.

Why AP Review Misses BEC Invoice Fraud

The invoice number matches the PO. The vendor name is correct. The email thread shows a plausible conversation. A manual AP reviewer comparing the PDF to the prior email chain has no reason to suspect anything.

AP review compares document content against business records. It does not examine the file structure that reveals how the document was produced.

When a fraudster intercepts a legitimate vendor invoice — by compromising the vendor’s email, spoofing their domain, or hijacking a payment thread — they take the original PDF and edit it. They change the bank account number, sometimes a payment reference, occasionally the invoice amount. They save it using any available tool: Microsoft Word, Adobe Acrobat, or an online editor.

That save operation writes evidence into the file. This evidence survives transmission, does not require the original document, and most AP workflows never check for it.

What the Fraudster Changes and What They Leave Behind

The bank account swap is invisible to visual inspection. The act of editing, however, leaves two structural traces.

The producer field. Every PDF carries metadata identifying the software that generated it. The creator field records the application that originally created the document. The producer field records the software that last saved it. A legitimate invoice from a vendor running QuickBooks Online, Xero, or SAP will carry a producer string matching that platform. When a fraudster opens the PDF in Word and saves it, the producer field is overwritten with “Microsoft Word” or “Microsoft: Print To PDF” — while the creator field still shows the original accounting software.

The mismatch is immediate. Real invoices from institutional accounting platforms are not re-saved in Word. If you see creator: QuickBooks Online alongside producer: Microsoft Word, someone intervened between issuance and delivery.

The xref chain. PDF uses an incremental update architecture: when a file is modified and saved, the changes are appended to the end of the file and a new cross-reference table is added pointing to the updated objects. The original content remains in the file. Every edit session leaves a traceable revision in the xref chain.

A clean invoice from an accounting system has one xref entry — the original generation. An invoice that was opened, edited, and saved again has at least two. The xref count is a direct count of post-creation edit sessions. Combined with a producer mismatch, multiple xref entries confirm the document was modified after it left the issuing system.

Business Email Compromise Invoice API: What the Response Looks Like

Here is the HTPBE? response on a BEC-modified invoice. The vendor is a real company running QuickBooks Online. The attacker intercepted the invoice, swapped the bank details in Microsoft Word, and sent it through a spoofed email thread:

{
  "id": "ck_7b3a1f2e-4c8d-4e9f-a2b1-8d0c5e7a9b3f",
  "status": "modified",
  "modification_confidence": "high",
  "modification_markers": ["PRODUCER_MISMATCH", "INCREMENTAL_UPDATES"],
  "creator": "QuickBooks Online",
  "producer": "Microsoft Word",
  "xref_count": 2,
  "has_digital_signature": false,
  "creation_date": 1745884800,
  "modification_date": 1746057600
}

creator: "QuickBooks Online" and producer: "Microsoft Word" do not appear together in any legitimate document workflow. QuickBooks generates the PDF; nothing in a normal AP process saves it again in Word. The modification_date trailing the creation_date by 48 hours — the gap between when the vendor generated the invoice and when the attacker edited it — adds corroboration.

The verdict is modified with modification_confidence: "high" and two named markers. Your AP system has everything it needs to flag this for manual review before the payment runs.

The inconclusive Signal Matters Too

Not all BEC-adjacent fraud results in a modified verdict. Some fraudsters create invoices from scratch rather than editing an existing file. A document built entirely in Excel and saved as PDF will return inconclusive — not modified — because there is no prior xref structure to compare against.

inconclusive is not a failure. For invoice processing, it is a meaningful signal: real invoices from established vendors running accounting software do not arrive as documents created from scratch in consumer software.

If your vendor profile shows they use QuickBooks and a submitted invoice returns inconclusive with producer: "Microsoft Excel", the document origin is inconsistent with the vendor’s known toolchain. Route it to manual review. The routing logic is straightforward:

• intact — file structure consistent with claimed origin, proceed to PO matching
• modified — post-creation edit detected, hold for manual review before payment approval
• inconclusive + institutional vendor — origin inconsistent with vendor profile, escalate

Integration at Invoice Intake

Run the check before PO matching, before three-way match, before payment approval. Place it at the moment the PDF arrives — in your AP automation platform, your invoice ingestion pipeline, or your email attachment processor.

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}"}

# Known institutional vendors — flag inconclusive from these
INSTITUTIONAL_VENDORS = {"quickbooks", "xero", "sap", "netsuite", "sage", "freshbooks"}


def check_invoice_integrity(pdf_url: str, vendor_platform: str | None = None) -> dict:
    """
    Run forensic check on an incoming invoice PDF.
    Returns a 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", [])
    producer = data.get("producer", "")

    if status == "modified":
        return {
            "action": "hold",
            "check_id": check_id,
            "reason": f"Modification detected: {', '.join(markers)}",
            "producer": producer,
        }

    if status == "inconclusive" and vendor_platform in INSTITUTIONAL_VENDORS:
        return {
            "action": "escalate",
            "check_id": check_id,
            "reason": f"Invoice origin ({producer}) inconsistent with vendor platform ({vendor_platform})",
        }

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

The check_id is stored against the invoice record. If a payment is later disputed, the forensic report is retrievable via GET /api/v1/result/{check_id} — a permanent audit trail showing exactly which signals triggered the hold.

The full integration guide and additional code patterns are in the accounts payable fraud detection solution guide.

What This Does Not Catch

Structural forensics detects modifications to existing documents. Two scenarios fall outside its scope:

Fabricated invoices built from scratch in the same software a real vendor uses. If a fraudster creates an invoice in QuickBooks using a cloned account, the file structure will be consistent with a legitimate QuickBooks document. Forensic PDF analysis will return intact. Vendor fraud detection by phone or an out-of-band channel remains the correct control for this attack pattern.

Invoices where the original was generated in consumer software. Some small vendors genuinely create invoices in Word or Google Docs. For these vendors, inconclusive is expected and does not indicate fraud. Vendor onboarding should capture the expected document origin so your routing logic can apply the signal correctly.

The Cost Case

The FBI’s 2023 IC3 report puts the average BEC loss per incident at $137,132. A single intercepted payment at that average covers years of API usage at any pricing tier.

The real value is not in catching one payment. It is in closing the gap permanently. When forensic fraud detection runs automatically on every incoming invoice, the structural check that BEC currently exploits — the absence of any file-level inspection between email receipt and payment approval — no longer exists.

AP teams evaluating this can start with the free web tool at htpbe.tech to check a sample of recent invoices before committing to an integration. Teams ready to build can register for API access and use a test key against the mock invoice endpoints before touching live documents.

For the full use case including vendor risk scoring patterns, see the invoice fraud detection solution page.

Teams ready to integrate can view API pricing and get a test key — no sales call required.