Accounts Payable Fraud Prevention Checklist: Controls That Catch Real Attacks

Most AP fraud checklists are organised the way your department is organised: invoice controls, vendor controls, payment controls, access controls. That is a filing system, not a defence. It works fine until an auditor sits down and asks the only question that matters — "show me what stops a vendor bank account from being changed by someone impersonating the vendor" — and you find yourself reading out five controls from four different sections, none of which is the answer.

This version is organised by attack. Six attacks account for almost everything that actually hits accounts payable. For each one: how the attack runs, the control that stops it, the control that catches it when prevention fails, and the evidence you can put in front of an auditor.

One number frames the whole thing. In ACFE's Occupational Fraud 2024: A Report to the Nations, which analysed 1,921 cases across 138 countries, 43% of frauds were detected by tips. Internal audit found 14%. Automated transaction and data monitoring found 3%. Your control environment is mostly a prevention story, and the detection story is mostly people telling you.

That is not an argument against preventive controls. It is an argument for pairing every preventive control with a detective one, which is exactly what organising by attack forces you to do.

Attack 1: Vendor bank account change

How it runs. An email arrives from a real vendor domain, or a close lookalike, or genuinely from the vendor's compromised mailbox. Remittance details have changed, new bank attached, please update before the next payment run. It is timed to arrive shortly before a large invoice is due, and it is polite, specific, and unremarkable.

What stops it. A bank change protocol with three mandatory parts, and all three have to be present or the control is decorative:

1. An automatic hold on all pending payments to that vendor the moment the record is touched. Not a reminder — a system state.
2. Callback to a number already on file, never a number in the request, and never a number in the email signature. The person calling must not be the person who received the request.
3. Second-person approval by someone who cannot also enter vendor data.

What detects it if prevention fails. An exception report of every payment to a vendor whose banking details changed in the previous 30 days, reviewed weekly by someone outside AP. A vendor statement reconciliation will also surface it, but later, and by then the money has moved.

Evidence for an auditor. The vendor master change log showing before and after values, timestamp, and user. The callback record — who called, which number, from where it was sourced, who answered. The payment hold and its release, with the approver. If the log cannot show which number was called and where that number came from, the control is not evidenced, whatever the policy says.

This attack deserves disproportionate attention because it is irreversible and invisible: nothing looks wrong until the real vendor chases payment weeks later. Our business email compromise prevention guide has the full callback script and the social-engineering patterns to brief staff on.

Attack 2: Fake vendor billing

How it runs. Someone with the ability to create a vendor record creates one — a plausible services company, no purchase order trail because services are hard to receive against, invoices sized just under the approval threshold that would attract a second pair of eyes. It runs monthly and quietly.

What stops it. Two controls in combination, and neither works alone:

• Verified onboarding before any payment: tax ID confirmed against the issuing authority, business registration active, bank documentation on vendor letterhead, and an address that is not residential and not a mail drop.
• Segregation between vendor creation and invoice approval. Whoever can create a vendor must not be able to approve invoices from it. This is the control the attack is built to exploit, and in small teams it is the one most often quietly abandoned.

What detects it if prevention fails. A monthly report of new vendors paid within 60 days of creation, cross-checked against the employee address and bank list. Plus a dormancy review: any vendor with no activity for 18 months is deactivated, because dormant records are the raw material for this attack.

Evidence for an auditor. The onboarding pack per vendor with verification artefacts attached and dated. The creation record showing who created it. The approval history showing a different person. And the match report showing the vendor address and bank account do not appear in payroll. The vendor risk assessment checklist covers what the onboarding pack should contain.

Attack 3: Duplicate submission

How it runs. The same invoice arrives twice: once by email and once through a portal, or with the invoice number reformatted, or resubmitted six weeks later after the vendor's own AR team lost track. Some of this is opportunistic fraud and much of it is ordinary error, but the money leaves the same way and the control is identical.

What stops it. Automated matching on the combination that catches restatements, not just the invoice number. Flag any invoice matching an existing one on vendor plus amount plus date within a 90-day window, even where invoice numbers differ, and hold rather than warn. Warnings get clicked through; holds do not.

What detects it if prevention fails. Vendor statement reconciliation with your top vendors by spend, quarterly at minimum. A vendor whose records show a smaller balance than yours has usually been paid twice. Credit balances on the vendor ledger are the same signal from the other side.

Evidence for an auditor. The duplicate rule configuration with its matching window, the queue of held invoices, the disposition of each hold and who cleared it, and the recovery record for any duplicate that did pay. Our duplicate payment prevention guide covers rule tuning and the false-positive rate to expect.

Attack 4: Invoice inflation by a genuine vendor

How it runs. A real vendor delivering real work bills for slightly more than was delivered: quantities rounded up, an unagreed rate uplift, a line item for work that was scoped but not done. Every invoice is defensible in isolation. The pattern only exists across time, and nobody looks across time.

What stops it. Three-way matching on everything backed by a purchase order — invoice, order, and receipt must agree before payment — with a tolerance small enough to be meaningful. On services, where receiving is weak, the equivalent control is a contracted rate card held in the system and matched against automatically, so an uplift fails on arrival rather than on a reviewer's memory.

What detects it if prevention fails. Spend trend analysis per vendor: invoiced value per period against contracted rate, and average invoice value over time. A vendor whose average invoice creeps up 4% a quarter with no contract change is the finding.

Evidence for an auditor. Match results with tolerance settings and the exception disposition for every invoice that failed to match. The rate card version in force at the invoice date. And the trend report with its review sign-off. Matching that runs but produces no evidenced exception disposition is the most common weak spot we see — the system matched, something failed, someone released it, and no reason was recorded.

Attack 5: Internal collusion

How it runs. Two people who each hold half of the control. An AP clerk and a requester agree on inflated quantities. An approver and a vendor contact agree on payment terms nobody negotiated. Collusion defeats segregation of duties by design, because segregation assumes the two parties do not cooperate.

What stops it. Nothing entirely, which is worth stating plainly rather than pretending otherwise. What reduces it: mandatory leave with duties genuinely reassigned during absence, periodic rotation of vendor ownership, and thresholds that force a third party in — dual authorisation above a value that reflects real exposure rather than a round number chosen in 2019.

What detects it. This is where the 43% figure earns its place. Collusion is disproportionately caught by tips, because someone always notices. That means an anonymous channel available to employees and vendors, run by someone outside the AP reporting line, actively advertised rather than buried in a handbook. Alongside it: surprise reviews with a random sample, unannounced, so there is no window to tidy.

Evidence for an auditor. The leave and rotation records showing duties actually moved. The threshold configuration and the approval chain for a sample of high-value payments. The reporting channel's existence, independence, promotion, and case log — including cases that were closed as unfounded, because a channel with no traffic at all usually means nobody knows it exists.

Attack 6: Payment file and check tampering

How it runs. The exposure is between approval and settlement. A payment file is edited after approval, a check is altered or forged, or a payment batch acquires an extra line. The invoice-level controls all passed; the attack happens downstream of them.

What stops it. Positive pay with your bank for any cheque issuance, so anything not on your issued file is rejected on presentation. For electronic payments: a payment file hash or control total agreed at approval and verified at submission, and bank-side dual release by someone who cannot create payment records.

What detects it if prevention fails. Daily bank reconciliation at transaction level rather than at balance level, plus a review of the batch summary before release: total value, payment count, any payee added in the past 30 days, and any change between the approved batch and the submitted one.

Evidence for an auditor. The approved batch and the submitted batch, with the control total tying the two. The bank's positive pay exception log. The release record showing two identities. The AP audit trail guide covers how to structure logs so this reconstruction is possible months later.

What an auditor actually asks for

The reason to organise by attack is that it survives contact with an audit. Here is the same content as a table you can walk through, one row at a time.

Attack	Control that stops it	Control that catches it	Evidence to produce
Vendor bank change	Hold, callback to a number on file, second approver	30-day changed-bank payment report	Change log, callback record, hold release
Fake vendor billing	Verified onboarding, creation separated from approval	New-vendor-paid-fast report, dormancy review	Onboarding pack, creator and approver identities
Duplicate submission	Automated hold on vendor plus amount plus date	Vendor statement reconciliation, credit balances	Rule config, hold queue, disposition per hold
Invoice inflation	Three-way match, contracted rate card	Per-vendor spend trend	Match results, tolerances, exception reasons
Internal collusion	Mandatory leave, rotation, dual authorisation	Tips channel, surprise sampling	Leave and rotation records, channel case log
Payment file tampering	Positive pay, control total, bank dual release	Transaction-level daily reconciliation	Approved versus submitted batch, release identities

Read down the evidence column and you have the audit pack. Read across a row and you have an answer to the question an auditor is actually asking. Neither is possible from a list of 25 controls sorted by department.

The gap that survives every checklist

Run through the six attacks and most finance teams find the same shape of gap. Prevention is decent, evidence is patchy, and detection is thin.

Evidence is patchy in a specific way: the control runs, but the disposition is not recorded. The duplicate hold was released — by whom, on what basis? The match exception was cleared — why? A control that fires and is then silently overridden looks identical, in the log, to a control that never fired. That is the single most common finding, and it is cheap to fix because the control already exists.

Detection is thin because prevention feels productive and detection feels like admitting prevention will fail. The ACFE data is unsentimental about this: the median fraud in the 2024 study ran for 12 months before detection, with a median loss of $145,000. A control environment with no detection layer does not reduce that duration, it just moves the discovery to whoever eventually notices — which, 43% of the time, is a person who decided to say something.

Two things close it. Make every attack row above name its detective control explicitly, so the absence is visible. And make sure the reporting channel reaches vendors, not only employees, because in bank-change and inflation attacks the vendor is the party with the information you do not have.

FAQ

What is the most damaging accounts payable fraud attack?

Vendor bank account change, by a distance. It is irreversible once the payment settles, it produces no anomaly at the invoice level because the invoice is genuine, and it stays invisible until the real vendor chases payment weeks later. Every other AP attack leaves a trace in the invoice or the vendor record at the moment it happens. This one leaves a trace only in the payment destination, which is the field nobody re-reads. The control that stops it is a callback to a number already on file, made by someone other than whoever received the change request, with the payment held automatically until the callback is logged.

How do you organise an AP fraud checklist for an audit?

By attack rather than by control category. An auditor asks what stops a specific scheme; a checklist sorted into invoice, vendor, payment, and access controls forces you to assemble that answer live from four sections. Organised by attack, each row names the preventive control, the detective control, and the evidence, so a single row answers a single question. Practically: list the six attacks that hit AP, then for each write what stops it, what catches it if prevention fails, and which artefact proves the control operated — not that the policy exists.

How is most accounts payable fraud actually detected?

By tips. ACFE's 2024 Report to the Nations, covering 1,921 cases, found 43% of occupational frauds were detected through tips, ahead of internal audit at 14% and management review at 13%. Automated transaction and data monitoring accounted for 3%. The implication for AP is that a reporting channel available to both employees and vendors, run outside the AP reporting line and actively promoted, outperforms any single system control you can buy. It does not replace preventive controls; it is what finds the fraud those controls missed.

What evidence should each AP control leave behind?

Enough to reconstruct the decision without asking a person. For each control that fires: what triggered it, what the system did, who intervened, on what basis, and when. The most common audit finding is not a missing control but a missing disposition — a duplicate hold released with no recorded reason, or a match exception cleared with no note. In the log, a control that was silently overridden is indistinguishable from a control that never ran, so the override record is the evidence, not the control configuration.

Can small AP teams achieve segregation of duties?

Not fully, and it is better to document that than to claim otherwise. Where one person necessarily handles entry and approval, the compensating controls are review by someone outside the process — an owner, a controller, an external accountant — on a defined sample, plus system-enforced thresholds that require a second identity above a value, plus mandatory leave during which duties genuinely transfer. Write down which segregations are not achievable and which compensating control covers each. An auditor accepts a documented compensating control far more readily than a segregation policy that the roster shows was never possible.