Originally published at htpbe.tech. The version on htpbe.tech stays in sync with the latest detection algorithm — refer to it for the canonical text.
Every week, finance teams around the world approve wire transfers that never reach the intended vendor. The money is gone within hours, usually unrecoverable, and in many cases the fraud is not discovered until the real vendor follows up asking why payment is late. By then, the funds have passed through several accounts and are effectively unrecoverable.
This is not a theoretical risk. According to the FBI Internet Crime Complaint Center (IC3) 2022 Internet Crime Report, business email compromise (BEC) — the category that covers invoice payment fraud — resulted in losses exceeding $2.7 billion in a single year. When you divide total losses by the number of reported complaints, the average loss per BEC incident comes to approximately $127,000.
That number is not a worst case. It is the average.
Who Gets Targeted: The SMB Misconception
The instinct when reading numbers like $2.7 billion is to assume this is a large-enterprise problem — something that happens to companies with complex supply chains, hundreds of vendors, and sophisticated attackers willing to invest weeks in reconnaissance.
That instinct is wrong. The majority of BEC victims are small and medium-sized businesses, according to industry fraud research. The reasons are straightforward: SMBs have fewer fraud detection controls, less fraud awareness training, and smaller AP teams where one person often handles everything from receiving invoices to approving payments. There is no second set of eyes.
Large enterprises are attractive targets for the size of individual transfers. SMBs are attractive targets for the ease of execution. For a criminal who has learned to intercept a vendor invoice and modify it in two minutes, the ROI on targeting a 50-person company is excellent.
If your business pays vendor invoices by wire transfer, ACH, or international bank transfer, you are in scope. Industry and company size are not meaningful protective factors.
How the Attack Works: A Two-Minute Job
The sophistication gap between how this attack is perceived and how it actually works is one reason it succeeds so consistently.
Here is a realistic reconstruction of the steps:
Step 1: The criminal intercepts a legitimate vendor email.
This is the hardest part of the attack — and it is not that hard. Vendor email accounts are compromised through phishing, credential stuffing using leaked passwords from prior data breaches, or malware installed on the vendor’s systems. Once inside, the attacker monitors the inbox until a payment-relevant invoice is sent to one of the vendor’s customers.
Step 2: The PDF is downloaded.
The legitimate invoice PDF — complete with your vendor’s letterhead, logo, correct invoice number, correct amount, and correct purchase order reference — is saved locally.
Step 3: The bank details are changed. This takes approximately two minutes.
Online PDF editors like iLovePDF, Smallpdf, or PDF24 are free, require no account for basic use, and are accessible from any browser. The attacker opens the PDF, navigates to the payment section, and overwrites the IBAN, account number, or routing number with one they control. Nothing else changes. The invoice number is correct. The amount is correct. The vendor’s name and logo are intact.
Step 4: The modified PDF is sent from a spoofed or similar-looking domain.
The email may come from billing@acme-corp.com (legitimate) or from billing@acme-c0rp.com (a lookalike domain registered by the attacker that morning for $12). The email body matches the vendor’s typical communication style, which the attacker has been reading for days. If the vendor’s email account was compromised rather than spoofed, the email arrives from the real address.
The entire operation, excluding reconnaissance, takes under fifteen minutes.
The Systemic Blind Spot in Accounts Payable
Accounts payable teams are not careless. They apply real discipline to what they review. The problem is that their checklist — built over years to catch mistakes and duplicate payments — was not designed to detect file modification.
A standard AP fraud detection covers:
- Invoice amount matches purchase order ✓
- Vendor name matches vendor master file ✓
- Invoice number has not been processed before ✓
- Approving manager has signed off ✓
- Services or goods were actually received ✓
None of these checks answers the question: was this specific PDF file altered after it was generated by the vendor?
That question never appears on the checklist, because until recently it required technical expertise to answer. The result is a structural gap that every fraudulent invoice walks straight through. The visual checks pass because nothing visible changed. The business logic checks pass because the invoice is for a real vendor, for a real amount, for real work.
The only thing that changed is the bank account number — and nobody looks at bank account numbers in the vendor master until after payment fails to reach the vendor.
What the PDF File Actually Records
When a PDF is created by accounting software, an ERP system, or even a word processor, the file embeds metadata that describes its own history. This includes:
- CreationDate: When the file was originally generated
- ModDate: When the file was last modified
- Producer: The software that created the PDF (e.g., QuickBooks PDF Converter, Microsoft Word, SAP)
- Creator: The application that originally authored the document
- Xref table count: The number of revision sections in the file structure — more than one means the file was updated after initial creation
When an attacker opens a PDF in iLovePDF, changes the bank account number, and saves it, the file records this. The ModDate changes. The Producer field changes to reflect the online editor. A new xref table is appended, marking the revision.
This is what an HTPBE? analysis result looks like for a modified invoice:
{
"id": "c7e9a123-45b6-78cd-ef01-234567890abc",
"status": "modified",
"creator": "Microsoft Word",
"producer": "iLovePDF",
"creation_date": 1772874862,
"modification_date": 1773153428,
"origin": { "type": "consumer_software", "software": "Microsoft Word" },
"page_count": 2,
"xref_count": 2,
"has_incremental_updates": true,
"modification_markers": [
"Known PDF editing tool detected",
"Different creation and modification dates"
]
}
A legitimate invoice from a vendor’s accounting system would show status: "intact", a single xref table, consistent creation and modification timestamps, and a producer field matching the accounting software the vendor actually uses.
The presence of iLovePDF, Smallpdf, PDF24, or any generic online editor in the Producer field of a financial document is not definitive proof of fraud on its own — some vendors do use these tools for legitimate document adjustments. But it is a high-risk signal that warrants fraud detection before payment proceeds. Combined with a modification timestamp that post-dates the invoice date by several days, the case for manual review becomes extremely clear.
The ROI Argument: $0.43 vs. $127,000
Finance teams evaluate tools using cost-benefit frameworks. The numbers here are unusually straightforward.
Running an invoice PDF through HTPBE?’s Growth plan costs $0.43 per check. That figure covers API access for teams that want to integrate fraud detection into their existing AP workflow programmatically.
The average loss from a single BEC invoice fraud incident: $127,000.
If automated fraud detection catches one fraudulent invoice per year — a conservative expectation for any business that processes more than a handful of vendor invoices monthly — the ROI on that single prevented incident is approximately 295,000:1.
Even at the Pro tier ($499 per month, 1,500 checks, $0.33 per check), a team running 50 invoice checks per day could prevent losses that dwarf the annual cost of the service by several orders of magnitude.
The alternative — doing nothing — has a cost too. It is just deferred and uncertain, right up until it arrives as a $127,000 wire transfer that cannot be recalled.
Why Recovery Is So Difficult
The reason the $127,000 average is so consequential is not just the magnitude — it is the near-impossibility of recovery after the fact.
Wire transfers and international bank transfers are not reversible in the way a credit card charge is. Once funds leave your account, your bank can request a recall from the receiving bank, but the receiving account is typically emptied within hours of the transfer clearing. The funds move through one or more intermediary accounts before reaching the criminal’s actual destination, each transfer further complicating the trail.
FBI guidance on BEC recovery consistently emphasizes that immediate action — contacting your bank and filing with IC3 within hours — is required for any chance of partial recovery. Even then, full recovery is rare. The IC3’s Recovery Asset Team works to freeze transferred funds when notified promptly, but complete recovery remains the exception rather than the rule, and the chance of any recovery drops sharply when reporting is delayed.
Filing a report with IC3 is still valuable and strongly recommended even when immediate recovery is unlikely. Aggregated IC3 data helps law enforcement identify patterns, link cases, and pursue criminal networks. Your report may contribute to an investigation that recovers funds from a broader operation.
Cyber insurance policies increasingly cover BEC losses, but coverage is subject to policy terms, often requires demonstration that reasonable controls were in place, and claims processes take time your business may not have. Insurance is a backstop, not a substitute for prevention.
How to Add Fraud Detection to Your AP Workflow
The process change required is minimal. It does not require restructuring your AP team or replacing your accounting software. It adds one step — approximately two seconds — before wire transfer approval.
The updated workflow:
- Vendor sends invoice PDF
- AP receives the invoice
- Upload the PDF to HTPBE? or send it via the API — takes 2 seconds
- Review the result: if
statusis"intact", proceed; ifstatusis"modified"or"inconclusive", route for manual review before payment - For any modification flag, contact the vendor through your existing checked phone number or official email — not the contact information on the invoice
For teams that process invoices at volume, the HTPBE API allows fraud detection to be embedded directly in AP automation software, triggering a check automatically when a new invoice PDF is received. The check result can gate payment approval in the same system that routes invoices for sign-off.
For teams processing invoices manually, the web interface at htpbe.tech is free to try — new accounts get 5 free checks. Upload the PDF, sign in to see the result. After that it is pay-per-check (credit packs from $5) or a subscription from $15/mo — suitable for evaluation and for low-volume use cases where paid API access is not warranted.
What a modification flag does and does not mean:
A status: "modified" result does not automatically mean the invoice is fraudulent. Some legitimate vendors do adjust invoices after initial creation — correcting amounts, adding line items, applying discounts. A modification flag is the trigger for a phone call to the vendor, not automatic rejection of the invoice.
What it means in practice: the invoice requires one additional fraud detection step before payment. That step — a 60-second phone call to confirm bank details using the number in your vendor master file — is the intervention that stops the fraud.
What a clean result means:
A status: "intact" result confirms the PDF file has not been modified since it was created. It does not confirm the invoice amount is correct or that the vendor is legitimate — those checks remain part of standard AP process. But it does close the specific vector that BEC attackers rely on: the undetected post-creation modification of payment details.
The Process Minimum: Before Any Wire Transfer
If you implement nothing else from this article, implement this one rule:
No wire transfer, ACH payment, or international bank transfer is approved until the invoice PDF has been checked as unmodified.
This single control, applied consistently, eliminates the PDF modification attack vector. It does not require new software for most teams. It requires discipline and a 2-second upload before the payment approval step.
For payments above a material threshold — say, $5,000 or whatever your business defines as high-value — combine the PDF tamper detection with a callback to the vendor through your checked contact number. Two-factor invoice fraud detection: file integrity plus voice confirmation.
This is not a novel concept in fraud prevention. Dual controls, callbacks, and separation of duties are standard AP best practices. What has been missing is the file-level integrity check — the one that catches the modification that the human eye cannot see.
