Finance Index
What are the most common invoice fraud schemes, and how do I spot a fraudulent invoice at intake?
Reference guide to invoice fraud at intake, including invoice workflow, coding, approvals, ERP impact, and AP controls.
The recurring schemes are fake-vendor invoices (billing for nothing from a shell vendor), altered or inflated invoices (real vendor, tampered amount or bank details), and business email compromise (a legitimate-looking invoice or banking-change request from a spoofed or hijacked address). They share a profile AP can learn to catch at intake: a first-time or barely-known vendor, a payment-detail change, urgency and pressure, amounts just under approval thresholds, and small mismatches in vendor name, domain, or remit-to. Intake is the cheapest place to stop fraud - once it's a payment, you're in recovery.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| The most common invoice fraud | The recurring schemes are fake-vendor invoices (billing for nothing from a shell vendor), altered or inflated invoices (real vendor, tampered amount or bank details), and business email compromise (a legitimate-looking invoice or banking-change request from a spoofed or hijacked address). | Keeps vendor records and payment decisions reliable. |
| Workflow | Layered, boring controls beat instinct: verify new vendors and any banking-detail change through an independent channel (a known phone number, never the contact on the invoice). | Keeps evidence clear and reduces control risk. |
| Vendor impact | Treat it as guilty until proven legitimate: do not pay on the invoice alone, identify whether any authorized person actually ordered anything, and verify the vendor independently before it enters the workflow. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| Risk check | At a conceptual level, it learns normal patterns (amounts, timing, vendors, frequency) and flags deviations - a new payee, an amount far outside a vendor's history, a duplicate-ish resend, an unusual document - for human review. | Keeps vendor records and payment decisions reliable. |
| Our vendor's email was | Out-of-band verification of any payment-detail change, plus anomaly flagging on the changed banking details. | Reduces payment errors, timing issues, and reconciliation cleanup. |
What intake-level controls catch fake invoices before they enter the workflow?
Layered, boring controls beat instinct: verify new vendors and any banking-detail change through an independent channel (a known phone number, never the contact on the invoice); enforce separation between who adds/edits vendors and who approves payments; flag first-time vendors and out-of-pattern amounts for extra scrutiny; require a PO or named business owner for unrecognized invoices; and run duplicate and anomaly checks at entry. The single highest-value control is out-of-band verification of payment-detail changes - it defeats the most expensive scheme (BEC) directly.
We received an invoice from a vendor we've never ordered from - how should AP handle unsolicited invoices?
Treat it as guilty until proven legitimate: do not pay on the invoice alone, identify whether any authorized person actually ordered anything, and verify the vendor independently before it enters the workflow. Unsolicited invoices from unknown vendors are a classic fake-invoice vector - many are fishing for an AP team that pays anything that looks like a bill.
How does AI-based invoice fraud detection work - anomaly detection on amounts, frequency, and patterns?
At a conceptual level, it learns normal patterns (amounts, timing, vendors, frequency) and flags deviations - a new payee, an amount far outside a vendor's history, a duplicate-ish resend, an unusual document - for human review. It augments human judgment rather than replacing it; the human still decides, and the control value is surfacing the anomaly early.
Our vendor's email was compromised and a tampered invoice came from their real address - what would have caught it?
Out-of-band verification of any payment-detail change, plus anomaly flagging on the changed banking details. Because the email was genuine, address-based checks fail by design - the catch is the policy that any change to remit-to or bank details is verified through a separately known channel before payment, regardless of how trustworthy the request looks.
How big is invoice fraud risk - loss statistics and which company sizes get hit most?
Invoice and payment fraud is among the most common and costly fraud categories for businesses, with business email compromise driving large individual losses. Smaller and mid-market finance teams are frequent targets because controls are often lighter, but organizations of every size are hit. Treat it as a when-not-if risk and invest in intake controls accordingly.
How do I train AP staff to verify suspicious invoices without slowing down every invoice?
Train to risk signals, not universal suspicion: scrutinize new vendors, payment-detail changes, urgency, and out-of-pattern amounts, while letting known, in-pattern invoices flow. Let the system flag the anomalies so humans spend their vigilance where it pays - blanket suspicion slows everything and trains staff to rubber-stamp out of fatigue.
Stampli perspective
Stampli's control philosophy is to catch risky invoices while they're still invoices, not after they become payments. Stampli AI flags risk signals at review - first-time vendors, unusually high amounts, suspected duplicates, unusual documents - so reviewers apply scrutiny where it's warranted, and every action lands in an immutable audit trail that makes tampering traceable and accountability clear. Separation of duties is enforced by design rather than policy, and validation against ERP rules before posting adds another gate before money can move.