Invoice Fraud in 2026: The 7 Attack Patterns Every AP Team Should Know

Invoice fraud has evolved faster than most AP defenses over the past three years. The forged paper invoice that an alert analyst could spot by feel is now a statistically minor category. In its place: business email compromise, AI-generated lookalike invoices, vendor account takeover, and bank-change fraud that can drain a construction GC's account of six or seven figures in a single wire.

The FBI's Internet Crime Complaint Center (IC3) has published annual reports tracking business email compromise losses, and the US construction sector consistently ranks in the top three industries for BEC losses by dollar volume. Why: construction AP processes high-dollar subcontractor and material payments, has time-sensitive pay-app deadlines that pressure fast approval, and frequently involves new vendor onboarding on every project — all conditions that favor the attacker.

This post walks through the seven attack patterns that drive almost all invoice fraud losses, how each one actually executes, and the defenses that reliably catch them before payment clears.

Pattern 1: Business Email Compromise (BEC) — Vendor Impersonation

The attacker registers a domain that visually resembles a legitimate vendor's domain — substituting an 'rn' for an 'm', a '1' for an 'l', or a .co for a .com. They send an invoice from that domain to the AP team, often timed to land just after a real invoice from the same vendor is expected. The PDF looks correct, the amount is plausible, and the only thing that's different is the remit-to bank account.

This is the single most common BEC pattern seen in construction AP. It works because the attacker does not need to breach anything — they just need the AP team to glance at the domain and trust it.

Pattern 2: Vendor Account Takeover

More sophisticated than Pattern 1: the attacker compromises a real vendor's email account (via phishing, credential reuse, or malware) and sends invoices from the legitimate address. Now SPF/DKIM/DMARC all pass. The domain is real. The email signature is real. Only the bank account in the remit-to section has been changed.

This pattern typically succeeds because the 'change of banking' notice is embedded in the invoice or in a separate email that precedes the invoice, and the AP team accepts the change based on the email chain rather than verifying through a side channel.

Pattern 3: Bank Change Fraud (The Remit-To Attack)

Pattern 3 is the operational execution of Patterns 1 and 2. Whether the attacker spoofs a domain or compromises a real one, the endpoint is always the same: get the AP system to update the vendor's remit-to bank account. Once the new account is on file, every subsequent invoice — legitimate ones included — routes to the attacker until the fraud is detected.

The standard defense is a bank-change verification protocol: any request to change vendor banking information requires a callback to a previously-verified phone number on file (not a number provided in the change request), a fresh W-9 or W-8 confirming the vendor identity, and a signoff from a designated approver separate from the AP analyst handling the change.

Pattern 4: Ghost Vendor Fraud

A ghost vendor is a fictitious supplier set up in the vendor master by an insider, with the insider controlling the corresponding bank account. Invoices are submitted from the ghost vendor, approved through the usual AP workflow, and paid — the money flows directly to the insider's account.

The classic ghost vendor tells: the vendor address matches an employee's home address or a PO box; the vendor was added by someone who also approves its invoices; the vendor does not have a TIN on file or has a TIN that never verifies; the vendor's first invoice arrives within days of setup and rises in frequency and amount; and the vendor is never visited, never called, and only communicates by email.

Defenses: segregation of duties (the person who sets up a vendor cannot also approve its invoices), address verification against a commercial database, mandatory W-9/TIN matching on first payment, and periodic vendor-audit sampling that flags low-transaction-count vendors for manual review.

Pattern 5: Duplicate Injection

Duplicate injection is the attack version of accidental duplicates. An attacker obtains a real vendor invoice (by intercepting email, colluding with a vendor's accounting clerk, or harvesting from a compromised portal) and resubmits it to AP weeks later with small modifications: a different invoice number, a slightly altered date, or a re-keyed total. If the AP system's duplicate detection is only matching on exact invoice number or total, the duplicate clears.

Defense is fuzzy duplicate detection — matching on vendor, amount, line items, and date within tolerances, not just exact invoice numbers. This is the technical area where AI-powered matching systems dramatically outperform rule-based ones, because they can detect near-identical invoice fingerprints even when individual fields have been altered.

The gap between exact-match and fuzzy-match detection is large in practice — rule-based exact-match systems typically catch 55-65% of duplicate attempts, while fuzzy systems trained on vendor-specific signatures routinely exceed 95% recall. For an attacker, the exact-match ceiling is essentially free money; the fuzzy-match floor is an expensive problem.

Pattern 6: AI-Generated Lookalike Invoices

The newest and fastest-growing pattern. Generative AI tools can now produce convincing invoice PDFs that visually match a target vendor's real invoice template — same logo, same layout, same font, same line-item structure — at essentially zero cost per attempt. The attacker does not need to breach the vendor; they just need a single real invoice as a template.

Static document analysis defeats early-generation AI-generated invoices because the generated PDFs often lack proper metadata, use slightly off fonts, or produce rasterized text where the real vendor uses vectorized. More recent generations are getting harder to distinguish visually. The reliable defense is verification against the vendor's actual billing system — automated reconciliation against a PO and receipt, or programmatic confirmation against the vendor's portal where one exists.

This is also an area where AI-powered AP systems have a structural advantage over AI-powered fraud: the defender has full access to the vendor history, payment patterns, and document signatures, while the attacker is working from a single template. Models trained on the defender's own vendor history can catch inconsistencies that static analysis cannot.

Pattern 7: Internal Overbilling

The last pattern is not external attack but internal collusion. A project manager and a subcontractor coordinate to submit inflated pay apps — billing for work that wasn't performed, materials that weren't delivered, or change orders that were never approved. The sub cuts the PM a share of the overpayment after the invoice clears.

This pattern is harder to detect than any external attack because every document looks legitimate — the vendor is real, the invoice is real, the PM's approval is real. The defense is structural: three-way matching against independent receipts, line-item tracking against the schedule of values, variance analysis on vendor billing patterns, and rotation of project manager / AP analyst pairings to break up stable collusion channels.

Layered Defense: How the Pieces Fit Together

No single control catches all seven patterns. A layered defense stacks controls so that even if one layer fails, the next catches the attack. For a mid-sized construction AP operation, the minimum viable stack is five layers deep.

What Automation Contributes That Policy Alone Cannot

Every one of these controls can exist as written policy. In most AP teams, they do exist as policy. The problem is execution: under volume pressure, a policy that requires a callback gets shortcut 'just this once,' a policy that requires TIN matching gets skipped because IT hasn't provisioned the service, a policy that requires segregation of duties gets violated because the team is short-staffed.

Automation rebuilds the controls as system-enforced gates rather than voluntary checks. A bank-change request that can't be processed without a matching callback log. An invoice that can't be paid without a matching receipt. A vendor that can't be activated without TIN matching. The policy becomes the default, and deviating from it requires an explicit override with its own audit log — which, in practice, eliminates the 'just this once' failure mode.

Bottom Line

Invoice fraud in 2026 is a sophisticated, well-funded attack space that has fully caught up to — and in some patterns surpassed — traditional manual defenses. The seven patterns above drive essentially all mid-market AP fraud losses. None of them is new. None of them is defensible with awareness alone. The teams that consistently avoid losses are the ones that turn fraud prevention from a set of policies into a set of automated gates that run on every payment.