ERP Fraud Detection: Why Rules Are Not Enough Anymore

Seventy-nine percent of organizations reported attempted or actual payments fraud in 2024, and the number has held stubbornly high for three consecutive years, according to the AFP Payments Fraud and Control Survey. That figure has not improved meaningfully year over year. What has changed is the attack surface: AP workflows that once required insider access are now targeted by external actors using AI-generated communications, synthetic vendor identities, and bank account substitution schemes that arrive through normal email channels. Rule-based ERP fraud detection was designed for a different threat environment. It is showing its age.

Rule-based ERP fraud controls: built for yesterday

Every ERP has some version of fraud controls. Duplicate invoice detection flags exact matches on invoice number and amount. Approval thresholds route anything above a defined value to a second reviewer. Vendor master change requests trigger a notification. These controls are real and they work for the fraud scenarios they were designed around.

The problem is that fraud has adapted, and adapted faster than most ERP vendors have updated their detection logic.

Several structural factors have made this worse since 2024. Generative AI has lowered the cost of creating convincing fake communications: a Business Email Compromise attack that once required a skilled social engineer can now be drafted and personalized at scale with minimal effort. The average requested wire transfer in BEC attacks reached 4,586 in early 2025, according to research from Trustpair. That is not a large enterprise problem. That is a mid-market problem. A duplicate invoice submitted with INV-891 changed to INV-0891 bypasses exact-match duplicate detection. A $24,900 payment request from a known vendor bypasses a $25,000 approval threshold. A bank account change request arrives via a spoofed email that looks identical to the vendor's real domain. None of these trigger the existing rules, and all of them represent scenarios that occur regularly in mid-market AP functions.

The gap between what rule-based controls catch and what actually happens is where AI-based ERP fraud detection creates operational value. Not by replacing rules, but by running a second, parallel analysis that looks at behavior rather than thresholds.

Four ERP fraud detection patterns AI catches that rules miss

Near-duplicate invoice detection. Fuzzy matching compares invoices across multiple fields simultaneously: invoice number, vendor ID, amount, date, line item descriptions, and payment terms. A fraudster who changes a single digit in the invoice number still gets flagged because the combination of vendor, amount, and date matches a record already in the system. This is what catches the INV-0891 scheme. Exact-match logic does not.

Behavioral anomaly detection. Every vendor has a payment pattern: typical invoice amounts, frequency, usual line item categories, and payment terms they have historically accepted. An AI model trained on 18 months of your transaction history knows what normal looks like for each vendor. An invoice from a supplier who typically bills $8,000 to $12,000 per month that suddenly arrives for $47,000 for "consulting services" gets flagged, not because it exceeds a threshold, but because it does not match anything in that vendor's history.

Vendor master cleansing. Phantom vendor fraud, where an employee creates a fictitious supplier in the vendor database and approves invoices for services that never existed, is one of the most common forms of internal fraud. Research from ACFE's 2024 report indicates that internal fraud accounts for a significant share of total AP losses. AI-based vendor master analysis looks for structural signals: vendors that share address data with employees, vendors with no purchase history but active payment records, bank account details that appear across multiple vendor records, and tax ID numbers that fail validation. Routine rule-based validation does not cross-reference these fields against each other.

Bank account change monitoring. Vendor Email Compromise targets the bank account change workflow specifically because it is often lightly controlled. An attacker compromises a supplier's email, sends a bank account update request, and waits for the next payment cycle. AI monitoring flags bank account changes that arrive outside the vendor's normal communication pattern, from email domains that differ by one character from the legitimate domain, or within 30 days of a new vendor setup. Seventy percent of organizations still rely on manual callbacks to validate vendor bank account changes, according to Trustpair's 2026 fraud analysis. A manual callback is not a system control. It is a human behavior that can be bypassed.

There is a detail about the bank account monitoring use case that is worth being specific about. The 70% figure for organizations using manual callbacks refers to the industry as a whole. Among companies with a packaged ERP and no custom fraud controls, the number is almost certainly higher. The callback process works until it does not: an attacker who has compromised a supplier's email can intercept the callback request, respond convincingly, and the account change proceeds. This is not a theoretical vulnerability. It is a documented attack vector in multiple fraud cases from 2024 and 2025.

ERP fraud detection built in, not bolted on

Standalone fraud detection tools exist and several of them are effective. The architecture challenge is the same as with any external AI layer: the tool's data and the ERP's data are always partially out of sync. A vendor master change in the ERP does not propagate to the fraud tool instantaneously. A transaction approved in the ERP may not be visible to the fraud tool's analysis until the next sync cycle. These gaps are not theoretical. They are the windows through which fraud passes undetected.

Building AI fraud detection into a custom ERP means the behavioral models run on the same transaction data, the same vendor master, and the same approval logs that drive every other workflow. There is no sync window. A vendor master change flagged by the anomaly detection model can trigger a hold on pending payment runs immediately, without waiting for a data transfer.

At Baseball Town, the ERP Witify built processes over two million member token transactions and monitors usage patterns in real time across 50,000 member accounts. The fraud detection logic identifies behavioral anomalies at the session level, not just at the transaction level, because the detection system has access to the full activity context inside the same database. That kind of cross-context detection is architecturally impossible when the fraud tool and the operational system are separate.

The honest limits of AI fraud detection

Fraud detection AI reduces risk. It does not eliminate it. Models trained on historical patterns can be surprised by genuinely novel fraud schemes. False positives are a real cost: a legitimate payment flagged by the anomaly model still requires human review, and over-alerting trains AP teams to dismiss warnings. Threshold tuning, model monitoring, and periodic review of what the system is catching and what it is missing are ongoing operational tasks, not a one-time setup.

Contrary to what many security vendors imply, AI fraud detection in an ERP is not a system you configure once and walk away from. Models trained on historical patterns can be surprised by genuinely novel fraud schemes. False positives are a real cost: a legitimate payment flagged by the anomaly model still requires human review, and over-alerting trains AP teams to dismiss warnings. Threshold tuning, model monitoring, and periodic review of what the system is catching and what it is missing are ongoing operational tasks.

My view, after seeing this across multiple ERP builds, is that AI fraud detection is not a substitute for process controls, segregation of duties, and periodic audits. It is a complement to them. The combination of strong process design and AI anomaly detection catches more than either does alone, at a lower review burden than manual auditing. The combination of neither is what puts an organization inside that 79% figure year after year.

The threat environment changed. Detection needs to match it, and matching it requires a system that can learn from your data rather than enforce rules that fraudsters learned to work around years ago. That is the operational case for building AI-based anomaly detection into a custom ERP rather than relying on the static controls that came with a packaged system.