Accounts payable fraud: stopping invoice schemes with AI

The scale of AP fraud

Accounts payable is one of the highest-value targets in corporate finance. AP departments process thousands of invoices per month, each triggering a payment if it clears the approval workflow. The combination of high volume, time pressure, and limited verification capacity creates an environment that is structurally vulnerable to fraud.

The numbers reflect this: an estimated $46 billion in annual losses across invoice manipulation, vendor fraud, and payment diversion schemes. The AFP Payments Fraud and Control Survey reports that 46% of organisations experienced payment fraud in the past year, with invoices as the most common attack vector. The median loss per incident is $100,000 - large enough to materially impact a mid-size company.

This problem is compounded by the rise of AI-generated documents. As we detailed in The rise of AI-generated invoice fraud, the tools required to produce a convincing fake invoice are now freely available, and the time required has dropped from hours to minutes. AP departments that relied on the difficulty of forgery as a deterrent no longer have that protection.

“AP fraud is not a technology failure - it is an architectural gap. AP automation systems were built to process invoices efficiently, not to verify document authenticity. They optimise for throughput, and fraudsters exploit the resulting blind spots.”

- Hesper AI Threat Research, Q1 2026

Common AP fraud schemes

AP fraud schemes fall into several categories, each exploiting a different weakness in the accounts payable workflow. The ACFE fraud tree classification provides a comprehensive taxonomy of these schemes. Understanding these categories is critical for building effective detection - because each scheme leaves different artifacts in the document, and detection systems need to catch all of them.

Altered bank details is the highest-value scheme. The fraudster intercepts or fabricates an invoice from a legitimate vendor and changes the bank account number to one they control. The invoice passes all validation: the vendor is real, the amount matches expectations, the PO number is valid. The only change is the payment destination - and most AP systems do not cross-reference bank details against historical payments at the document level.

Duplicate invoices exploit the volume and complexity of AP workflows. The fraudster submits the same invoice with minor modifications - a different invoice number, a slightly adjusted date, or a reformatted layout. AP automation systems check for exact duplicates but often miss near-duplicates where the document has been subtly altered.

Shell vendor invoices involve entirely fabricated vendors and documents. The fraudster creates a vendor entity, generates professional-looking invoices, and submits them for goods or services that were never delivered. These invoices pass formatting checks because they are professionally produced - often using AI generation tools that create realistic layouts, logos, and tax details.

Inflated amounts target existing vendor relationships. The fraudster - often an insider with AP access - modifies a legitimate invoice to increase the amount, pocketing the difference. The manipulation is typically small enough to avoid triggering amount-based alerts and is only detectable at the pixel level where the digit has been edited.

Why AP automation doesn't catch document-level fraud

Modern AP automation platforms - Coupa, SAP Concur, Tipalti, Bill.com, and similar systems - have significantly improved invoice processing efficiency. They automate data extraction, three-way matching, approval routing, and payment execution. But they were designed to optimise throughput and accuracy of processing, not to verify document authenticity.

The core limitation is the same one that affects all OCR-based systems: AP automation reads what the invoice says, not whether the invoice has been altered. Three-way matching verifies that the invoice amount matches the purchase order and receiving report - but if the invoice itself has been modified (altered bank details, inflated amount), the three-way match passes because the fraud is in the document, not in the data.

This is a specific instance of the broader OCR limitation we analysed in Why OCR alone is not enough for document fraud detection. OCR extracts text; it does not examine the pixel data for manipulation artifacts. A fraudster who understands your AP rules can comply with all of them while submitting an altered document.

How document forensics catches AP fraud

Document-level forensics applies several analysis layers to each invoice before it enters the AP processing pipeline. Unlike AP automation, which operates on extracted text, forensics operates on the raw document image - examining pixel data, document structure, and metadata for signs of manipulation or fabrication.

Cross-document fingerprinting compares each incoming invoice against a library of previously processed documents from the same vendor. It detects near-duplicate submissions that differ in only a few fields - the kind of manipulation that exact-match duplicate detection misses. It also detects when an invoice from Vendor A uses a template or layout that matches a known template generator rather than that vendor's historical invoice format.

Pixel-level analysis examines the raw image for compression artifacts, font rendering anomalies, and editing boundaries. When a bank account number or amount has been changed using image editing tools, the compression pattern around the edited region differs from the surrounding document. When a digit has been replaced using a PDF editor, the font rendering and baseline alignment contain subtle anomalies. These artifacts are checked across 200+ fraud signals per document.

Field-level verification cross-references specific high-value fields - bank details, amounts, vendor identifiers - against historical patterns. If an invoice from a vendor you have paid 50 times suddenly contains different bank details, that is a signal. If the bank detail field shows pixel-level editing artifacts, the combination of signals produces a high fraud score.

{
  "fraud_score": 88,
  "verdict": "LIKELY_FRAUD",
  "findings": [
    {
      "type": "pixel_manipulation",
      "description": "Compression discontinuity in bank account field - editing boundary detected",
      "region": { "x": 380, "y": 312, "w": 220, "h": 26 },
      "severity": "high"
    },
    {
      "type": "field_anomaly",
      "description": "Bank details do not match historical pattern for this vendor - first occurrence of this account number",
      "severity": "high"
    }
  ],
  "signals_checked": 221
}

Implementation pattern

Adding document forensics to an AP workflow follows the standard pre-OCR integration pattern. The detection layer sits upstream of your AP automation system and does not replace any existing processes - it adds a document authenticity check before invoices enter your processing pipeline.

1. When an invoice arrives (email, upload, EDI), intercept the document image before passing it to your AP automation platform
2. Send the raw document image to the forensics API - analysis completes in seconds
3. Receive a fraud score (0–100), verdict, and structured findings with pixel coordinates for any flagged regions
4. Invoices below your threshold (typically 65–75 for AP workflows) continue to your existing AP automation pipeline unchanged
5. Invoices above threshold are routed to a focused review queue where the reviewer sees the exact flagged regions with descriptions - reducing review time from minutes to seconds
6. High-confidence cases (score >90, high-severity findings) can be auto-held pending vendor verification if your risk policy permits

The implementation typically takes less than a day of engineering work for teams with API integration experience. The same pattern is used by expense platforms integrating receipt fraud detection - the architecture is identical, only the document type and threshold calibration differ.

For organisations processing high invoice volumes, the ROI is driven by two factors: direct fraud savings (catching altered bank details and inflated amounts before payment) and operational efficiency (reducing the manual review burden by giving reviewers specific pixel coordinates to inspect rather than entire documents to review).

Frequently asked questions