Quick Answer: Payment fraud detection software is good at catching attacks that produce an abnormal record — duplicates, phantom vendors, amounts outside a pattern, payment files that do not match what was approved. It is structurally poor at catching attacks that produce a perfectly normal record, and the most expensive attack in accounts payable is exactly that kind: a genuine invoice, from a genuine vendor, paid to a bank account that changed last week. No amount of transaction monitoring detects a payment that looks correct. That one is closed by verification outside the channel the request arrived on, or it is not closed.

Vendors sell detection as though it were coverage. It is not. Detection is a function of signal, and each attack either leaves a signal in your data or it does not. This page is organised by attack rather than by product, because that is the only order in which the question "would this tool have stopped it?" has an answer.

For each of the six attacks that account for almost everything hitting AP, five things: whether software can detect it, what signal it uses, how it behaves when it is wrong, what has to happen outside the system, and what evidence the control leaves for an auditor. It is the companion to our AP fraud prevention checklist, which covers the same six attacks from the control side.

The number that frames the purchase

In ACFE's Occupational Fraud 2026: A Report to the Nations, covering 2,402 cases across 143 countries and $3.4 billion in losses, tips detected 43% of frauds — more than half of them from employees. The median case ran for 12 months before anyone found it, at a median loss of $104,000. Cases found within six months had a median loss of $40,000.

The finding most relevant to a software purchase is a different one. In over half of all cases, an anti-fraud control was absent or overridden. Not defeated by a sophisticated attack — absent, or present and overridden by someone with the authority to override it. That is a useful corrective to a demo. The question to ask of any fraud tool is not what it detects. It is what happens after it fires, whether the override is recorded, and who is allowed to perform it.

Separately, and for scale: the FBI's Internet Crime Complaint Center recorded $2,770,151,146 in business email compromise losses in 2024. BEC is the delivery mechanism for the first attack below, which is also the one software is worst at.

Attack 1: Vendor bank account change

How it runs. An email arrives from a real vendor domain, a close lookalike, or the vendor's genuinely compromised mailbox. Bank details have changed; please update before the next run. It is timed to land shortly before a large, real invoice is due.

Can software detect it? Not from the payment. This is the important sentence on this page, so it is worth being exact about why. Transaction monitoring works by comparing a payment to a pattern: this vendor, this amount, this frequency, this approver. In a bank-change attack, every one of those is correct. The invoice is real. The amount is contracted. The approver is the right person, approving something they should approve. The only field that changed is the destination account — a field with no history to compare against, because it changes legitimately too, and rarely enough that "it changed" is not by itself an anomaly. The payment is unremarkable, so nothing in the payment can raise a flag.

What signal is available. Not in the payment — in the vendor record. Software detects the change event, not the fraud: a bank detail was edited, by whom, from what IP or session, how close to a due invoice, and whether the new account has been seen before across a shared network. Account-validation services add one more signal by checking that the account name matches the account number at the bank. That is a real signal and worth buying, but note what it proves: that the account belongs to whoever it belongs to, not that the person who asked you to pay it is your vendor.

False-positive behaviour. Low volume, high friction. Vendors do change banks, and every legitimate change becomes a held payment and a phone call. Teams tolerate this for about two months and then start releasing holds on the strength of the email. That is the override in the ACFE finding, arriving on schedule.

What must happen outside the system. A callback to a number already on file — not a number in the request, not one in the email signature — made by someone other than the person who received the change request, with the payment held automatically until the callback is logged. Out-of-band means a different channel and a different person. It is not a supplement to the software control; it is the control. The software's job is to make the hold automatic and the callback record mandatory. See vendor bank account verification for the full protocol.

Evidence for an auditor. The change log with before and after values and the editing identity; the callback record naming who called, which number, and who answered; the hold release with the approving identity and timestamp.

Attack 2: Fake vendor billing

How it runs. A vendor that does not exist, or a real vendor's details attached to a controlled bank account, invoicing for services that leave no physical trace — consulting, maintenance, licences.

Can software detect it? Partly, and better after the fact than before it. The invoice looks fine; the vendor does not.

What signal is available. Vendor-master anomalies: a bank account or address shared with an employee record, a tax ID that fails a registry lookup, no purchase order history, a creation date shortly before the first invoice, invoices that sit just below an approval threshold. The last of those is the strongest single signal and the easiest to configure.

False-positive behaviour. Noisy on threshold rules, because most invoices below a threshold are simply small invoices. Duplicate-address matching against employee records is precise and worth running quarterly rather than continuously.

What must happen outside the system. Verified onboarding: registry lookup, banking evidence, and separation between whoever creates a vendor and whoever approves the first payment. A small team that cannot separate them documents that and puts a review outside the AP line in its place.

Evidence for an auditor. The onboarding pack, the creator and approver identities as separate people, and the dormancy or new-vendor-paid-fast report with its disposition.

Attack 3: Duplicate submission

How it runs. The same invoice arrives twice — resubmitted after a delay, sent to two entities, or reissued with a modified reference.

Can software detect it? Yes. This is the attack software genuinely closes, because the fraud is definitionally a data collision.

What signal is available. Vendor plus amount plus date, then fuzzy matching on the reference to catch INV-1042 arriving again as INV1042 or INV-1042A. Cross-entity matching catches the version that exploits two subsidiaries not seeing each other's ledgers.

False-positive behaviour. The highest-volume false positives of any control here, because genuine repeat billing — identical monthly retainers, standing orders — looks exactly like a duplicate. This is where override discipline decides whether the control means anything.

What must happen outside the system. Very little, which is what makes it worth automating first. What does have to happen is human: a recorded reason on every hold release. A duplicate hold released with no note is indistinguishable in the log from a hold that never fired.

Evidence for an auditor. Rule configuration with tolerances, the hold queue, and a disposition with a named reason per hold.

Attack 4: Invoice inflation by a genuine vendor

How it runs. A real vendor delivering real goods bills for slightly more than was delivered or agreed — quantities over, rates above contract, unapproved surcharges.

Can software detect it? Yes, if it can see the purchase order, the receipt, and the contracted rate. Without all three it is guessing.

What signal is available. Three-way matching against PO and receipt, rate-card comparison against contracted prices, and per-vendor spend trends over time. Trend analysis is what catches inflation that stays inside every per-invoice tolerance.

False-positive behaviour. Governed entirely by tolerance settings. Tolerances that are too tight generate exceptions on ordinary partial deliveries and freight rounding; too loose and they authorise the fraud. Set them as a percentage and an absolute figure, whichever is lower, and review the auto-accept rate quarterly.

What must happen outside the system. Someone at the dock confirming what physically arrived. No amount of matching software fixes a receipt that was ticked without counting.

Evidence for an auditor. Match results with tolerances, exception reasons, and the per-vendor spend trend with its review record.

Attack 5: Internal collusion

How it runs. Two people inside the process, or one inside and one at the vendor, agreeing that the control will pass.

Can software detect it? Weakly, and this is where the ACFE tip statistic earns its place. Collusion produces valid records by design — that is the entire point of colluding.

What signal is available. Behavioural rather than transactional: the same approver and requester pairing repeatedly, exceptions clustered around one identity, activity during a person's leave, or a vendor whose invoices are only ever handled by one clerk. These are patterns, not proof, and they are useful for directing a look rather than for raising an alert.

False-positive behaviour. High, and expensive in a different currency — a false positive here is an accusation against a colleague. Route these to a review, never to an automated block.

What must happen outside the system. Mandatory leave during which duties genuinely transfer, rotation of vendor ownership, dual authorisation above a threshold, and a reporting channel outside the AP reporting line that reaches vendors as well as employees. Given that tips found 43% of cases, the channel is a detection control, not an HR formality.

Evidence for an auditor. Leave and rotation records showing duties actually moved, the channel's case log, and surprise-sampling results.

Attack 6: Payment file and check tampering

How it runs. The approved batch and the submitted batch differ — an account edited between approval and release, a line added, a cheque altered.

Can software detect it? Yes, and it is one of the few places where the detection is close to complete, because the control compares two artefacts you already have.

What signal is available. Control totals and a hash or line-level comparison between the approved batch and the file the bank received. Positive pay does the equivalent at the bank for cheques.

False-positive behaviour. Near zero. A mismatch is a mismatch. Where teams get noise is from legitimate late edits, which is an argument for freezing the batch at approval rather than for loosening the check.

What must happen outside the system. Dual release at the bank, held by people who are not the people who prepared the file. Bank-side controls are outside your software by definition and have to be configured with the bank, not with the vendor.

Evidence for an auditor. Approved-versus-submitted batch comparison, the release identities, and daily transaction-level reconciliation.

The coverage table

Read a row to answer "would this tool have stopped it?" Read the last column to assemble an audit pack.

Attack	Software detection	Signal it uses	False positives	Must happen outside	Evidence produced
Vendor bank change	Poor — payment is unremarkable	Change event on the vendor record; account-name match	Low volume, high friction, overridden early	Callback to a number on file, by a second person	Change log, callback record, hold release
Fake vendor billing	Partial — vendor is anomalous, invoice is not	Shared address or bank, no PO history, just-under thresholds	Noisy on threshold rules	Verified onboarding, creation separated from approval	Onboarding pack, creator and approver identities
Duplicate submission	Strong	Vendor + amount + date, fuzzy reference, cross-entity	Highest volume; genuine repeat billing	Recorded reason on every release	Rule config, hold queue, disposition per hold
Invoice inflation	Strong with PO and receipt	Three-way match, rate card, spend trend	Governed by tolerance settings	Counting what arrives at the dock	Match results, tolerances, exception reasons
Internal collusion	Weak — records are valid by design	Approver/requester pairing, exceptions per identity	High, and costly to be wrong	Mandatory leave, rotation, tips channel	Leave and rotation records, channel case log
Payment file tampering	Strong	Approved-versus-submitted comparison, positive pay	Near zero	Bank-side dual release	Batch comparison, release identities

Two of the six are strong, one is strong conditional on data you may not have, one is partial, and two are poor or weak. That is the real coverage of the category, and it is a perfectly good reason to buy — as long as you buy knowing which two rows you are still carrying yourself.

Why "out-of-band" is not optional language

The bank-change row deserves restating because it is the row vendors gloss. Every other attack here leaves a trace in a record at the moment it happens: a duplicate collides, an inflated line breaks a match, a tampered file diverges from what was approved. The bank-change attack leaves a trace only in the payment destination — a field with no expected value, because there is nothing to compare a new account number against except the one it replaced.

So the detection has to move upstream of the payment, to the request to change the details. And the request arrives by email, which is the channel the attacker controls. Verifying an emailed change by replying to the email, or by calling the number in it, verifies nothing at all: it asks the attacker whether the attacker is genuine. Out-of-band means a channel the attacker did not choose and a person who did not receive the original request. Software can enforce that the hold exists and that the callback is logged before release. It cannot make the call.

What to require from a vendor

Ask for evidence and behaviour, not prevention rates. A prevention percentage that cannot be traced to a named study of a defined population is marketing.

Show me the override path. Who can release a hold, is a reason mandatory, and does the log distinguish a released hold from one that never fired? Given that over half of ACFE's cases involved absent or overridden controls, this is the single most predictive question.
Which of the six rows above do you claim, and on what signal? A tool that answers "all of them" is describing a roadmap.
What does the audit export contain? Ask for a sample file, not a screenshot. The evidence column of the table is the specification.
What is your false-positive rate on duplicates in the first 90 days, and what tuning is included? Duplicate noise is the most common reason a control gets switched off.
For bank changes: does the tool hold the payment automatically, or does it notify? A notification is not a hold.

Where Ken fits

Ken is AP automation, not a fraud specialist, and the honest version of that is: it closes the rows where the fraud collides with data, and it makes the rows it cannot close harder to skip. Duplicate detection across entities, three-way matching with tolerances you set, and an approval trail where every hold release carries an identity and a recorded reason. On bank changes, Ken's contribution is the boring, decisive one — the payment holds automatically when the record is touched, and the hold does not release until someone records the callback. That is the part software should own. The call itself is still a person, on a number that was already on file, and any product that tells you otherwise is selling you the row it cannot cover.

FAQ

Can payment fraud detection software stop vendor bank account fraud?

Not on its own, and not from the payment. A bank-change fraud produces a payment that is unremarkable in every dimension monitoring examines — real vendor, real invoice, contracted amount, correct approver. The only changed field is the destination account, which has no baseline to be anomalous against. Software's genuine contribution is upstream: detecting that the vendor record was edited, holding all pending payments to that vendor automatically, and refusing to release the hold until a callback is logged. The callback itself — to a number already on file, made by someone other than whoever received the change request — is the control that actually stops the attack.

What does payment fraud detection software actually catch well?

Attacks that create a data collision or a comparison failure. Duplicate submissions, because the same invoice colliding with itself is definitionally detectable. Invoice inflation, provided the tool can see the purchase order, the goods receipt, and the contracted rate card. Payment file tampering, because the approved batch and the submitted batch are two artefacts that can be compared directly. Fake vendor billing is partially detectable through vendor-master anomalies rather than invoice anomalies. Internal collusion is the weakest, because colluding parties produce valid records by design.

How is accounts payable fraud usually detected in practice?

By people. ACFE's Occupational Fraud 2026: A Report to the Nations, covering 2,402 cases across 143 countries, found tips detected 43% of frauds, with over half of those tips coming from employees. The median case ran 12 months before discovery at a median loss of $104,000; cases caught within six months had a median loss of $40,000. The implication for a software purchase is not that tools are pointless, but that a reporting channel available to employees and vendors alike, run outside the AP reporting line, belongs in the same budget conversation as the detection tool.

What evidence should a fraud control leave behind?

Enough to reconstruct the decision without asking anyone. For every control that fires: what triggered it, what the system did, who intervened, on what basis, and when. ACFE's 2026 report found that over half of cases involved an anti-fraud control that was absent or overridden — which means the override record is the evidence, not the control's configuration. A duplicate hold released with no recorded reason is indistinguishable, in the log, from a hold that never fired at all.

Do we still need manual verification if we buy a fraud detection tool?

Yes, for two specific things, and the list is short enough to be worth writing down. First, out-of-band callback on any change to vendor banking details — a different channel and a different person from the one that received the request. Second, physical confirmation of what was actually received before an invoice matches. Everything else in the six-attack table can be automated to a useful standard. Those two cannot, because one depends on a channel the attacker does not control and the other depends on someone counting.

Payment Fraud Detection Software: What It Catches, What It Cannot, and What to Verify Outside It