Invoice Fraud in Accounts Payable: Detect Altered PDFs Before Payment

Originally published at solution guide covers vendor risk profiling, producer allowlists by vendor, and integration patterns for common AP platforms.

False Positives in a Real AP Pipeline

A modified verdict in an enterprise AP environment is not a fraud verdict — it is a structural anomaly that requires interpretation against the vendor's known toolchain. Five sources of benign modified and producer drift come up often enough that any production deployment needs to plan for them:

• 
  E-signature platforms (DocuSign, Adobe Sign): adding a signature block is, structurally, an incremental update with a new producer line.


• 
  DMS and ERP middleware (SAP Ariba, Coupa, Tipalti, OpenText, M-Files): re-emit PDFs on ingest with overwritten metadata.


• 
  Mailbox sanitisers and security gateways (Mimecast, Proofpoint, Microsoft Defender): re-encode incoming PDFs to strip active content, leaving new producer fingerprints.


• 
  Print-to-PDF roundtrips on the vendor side: a vendor who prints the invoice, scans it, and re-attaches submits a structurally different file with no content change.


• 
  Cross-platform re-exports: a vendor on macOS opens a Windows-generated invoice in Preview and re-saves to add a comment — different producer, same content.

The right operational posture for the first few weeks is hold and verify out-of-band, never auto-reject. Log every modified and every institutional-vendor inconclusive against the reviewer's ground-truth outcome (real fraud / false positive / out-of-policy-but-legitimate). After several weeks of labelled data, the auto-routing rules tighten themselves; before that, the system runs as a structured signal into human review, not as enforcement.

How This Compares to Existing PDF-Validation Channels

A few existing controls cover adjacent ground; none replace structural forensics for the BEC-style edit:

• 
  PDF digital signatures and S/MIME-signed email: prove the file came from a specific signer and has not been altered since. Few vendors actually sign invoice PDFs, and signed-email coverage in AP inboxes is sparse. Where signatures exist, they are stronger than structural inference — verify them first. Where they do not, structural analysis is the next line.


• 
  ERP-native invoice channels (Ariba Network, Coupa Supplier Network, EDI 810, PEPPOL): bypass the PDF entirely and exchange invoice data over an authenticated channel. These are the right long-term answer; structural forensics is the control for the share of vendors who continue to send PDF attachments over email.


• 
  Standalone PDF validation tools (Acrobat's "compare files", forensic suites): are designed for legal discovery on a per-document basis, not for automatic gating on every inbound invoice at AP scale. They share part of the underlying signal model.

Structural PDF forensics is one layer in an AP fraud prevention stack — the layer that catches the specific attack of editing a legitimate invoice between issuance and AP, which the others above do not cover at machine speed.

What This Cannot Detect

Structural forensics detects modifications to existing documents and inconsistencies in document origin. Two scenarios fall outside its scope.

Fabricated invoices that mimic institutional origin. If a fraudster clones a vendor's QuickBooks account and generates a fraudulent invoice directly through QuickBooks, the file structure will be consistent with a legitimate document. The forensic check returns intact. This attack pattern requires vendor fraud detection through an out-of-band channel — a phone call to a known number, not a reply to the invoice email.

Legitimate vendors using consumer software. Some small vendors genuinely create invoices in Word or Google Docs. For these vendors, inconclusive is the expected result and carries no fraud signal. Vendor onboarding should capture the expected document origin so routing logic applies the signal correctly. Vendors known to use consumer software should not trigger escalation on inconclusive.

Forensic PDF analysis closes the structural gap that OCR and three-way match leave open. It does not replace vendor fraud detection or payment controls — and the controls above (signatures, ERP-native channels, payment-side verification) are complementary, not redundant.

The Cost Case

The average BEC incident reported to the FBI's IC3 ran into the six figures per loss event in 2023. The per-document cost of a structural check is several orders of magnitude lower than that, which makes the math obvious if the layer actually catches a meaningful share of attempts in your specific inbound flow. That is what a sampling exercise — running a back-cohort of disputed and known-good invoices through the API before integration — establishes.

The forensic layer does not close the AP fraud surface; it adds an automated check on a layer that has historically not been examined at AP scale. That is a useful addition, not a complete defence. The other layers — vendor verification, payment-side controls, signed-document channels — still do the work they always did.

For the technical layer behind what the analysis detects, see the breakdown. The API reference lists the full request/response contract.

Frequently Asked Questions

How can I tell if a vendor invoice was altered before it reached AP?

Three structural signals carry most of the signal: the producer field (which records the software that last saved the file), the cross-reference (xref) count (every save session appends a new entry), and the gap between CreationDate and ModDate. An invoice generated by QuickBooks Online that arrives with producer: "Microsoft Word" and xref_count of 2 was opened and re-saved between issuance and AP. Whether that re-save is a fraudster swapping bank details, a mailbox sanitiser, or a legitimate intermediary needs human follow-up — the structural layer surfaces the anomaly, the reviewer decides.

What is a BEC bank-detail swap?

Business email compromise (BEC) invoice fraud intercepts a legitimate vendor invoice — through a compromised mailbox, spoofed domain, or hijacked thread — then edits the remittance bank account number before forwarding it to AP. The vendor name, invoice number, line items, and total all match the PO. Only the payment destination is wrong. Three-way match cannot see this because the bank account is not on the PO; OCR cannot see it because the displayed content is internally consistent. The edit shows up structurally as producer mismatch plus an incremental update.

Does Coupa, Ariba, Tipalti or Bill.com catch altered invoices?

Not at the structural layer. AP automation platforms route and approve based on extracted content (OCR, three-way match, approval workflows). None of them examine the PDF’s producer chain, xref geometry, or modification timestamps. A forensic check at intake is complementary to those platforms, not a replacement for them.

Can structural forensics catch a fabricated supplier invoice?

Indirectly. A document built from scratch in Word or Excel returns inconclusive, not modified, because there is no prior structure to compare against. For an invoice claimed to be from a vendor whose onboarding record says they use QuickBooks Online or Xero, inconclusive is structurally inconsistent with the claim and warrants vendor verification through an out-of-band channel.

Vollständiger Original-Bericht

Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.

↗ Original-Artikel auf dev.to lesen