# Accounts Payable Fraud: Schemes and Detection Tests

- Author: PreciseBankFlow (https://precisebankflow.com)
- Published: 2026-10-17
- Category: Embezzlement and fraud schemes
- Canonical: https://precisebankflow.com/blog/accounts-payable-fraud

> Accounts payable fraud schemes from fake vendors to altered bank details, and the detection tests on vendor files and bank payments that find them.
Accounts payable fraud uses the bill-paying process to send company money to the wrong place: a fake vendor, a real vendor's changed bank account, or a duplicate payment that an insider later collects. It is found by testing two records together. Compare the vendor master file with employee data, then compare bank payments with approved invoices.

## Which accounts payable fraud schemes are most common?

The most common accounts payable fraud schemes are fake vendors, altered vendor bank details, duplicate or inflated invoices, and payments for goods never received. Each one uses a normal step in the payables process. The invoice is entered, approved and paid like any other, and the money goes somewhere it should not.

A quick map of the schemes:

| Scheme | Who usually runs it | Where the money goes |
| --- | --- | --- |
| Fake vendor | Employee who can add vendors and enter invoices | An account the employee controls |
| Altered bank details | Insider, or outside fraudster posing as the vendor | A new account under the fraudster's control |
| Duplicate payment | Employee who enters invoices | The real vendor, then a refund to the insider |
| Inflated or unneeded invoice | Buyer working with a supplier | The supplier, who passes part back |
| Personal purchase as a business bill | Employee or manager | A personal creditor or retailer |

Other frauds move money through the bank without passing through payables. Check kiting, for example, uses the float between two bank accounts, and [the post on check kiting](/blog/check-kiting) covers that scheme. On the receivables side, the mirror image of payables theft is [lapping fraud, where customer receipts are stolen and covered with later ones](/blog/lapping-fraud).

## Fake vendors and shell companies in the vendor master file

A fake vendor is a supplier record created to receive payments for work that never happened. The vendor master file is the list of approved suppliers, with names, addresses, tax IDs and bank details. An employee who can add a record to that list and also enter or approve invoices can create a vendor, bill the company and pay it.

The vendor file usually gives such a record away: a name close to a real supplier, a home or PO box address, a missing or mismatched tax ID, or bank details shared with an employee. Each of those fields, and how to read them, is covered in [the ghost vendor signs in the vendor master file](/blog/ghost-vendor-fraud#ghost-vendor-signs-in-the-vendor-master-file).

Shell companies are a variant: a real registered business, owned by the employee or a relative, that bills for services the company did not need or did not receive. A business registration search on the vendor's name can reveal who stands behind it.

## Altered vendor bank details and payment diversion requests

Altered bank details redirect a real supplier's payments to someone else. An insider can change the account in the vendor file directly. An outsider can send an email, apparently from the supplier, asking the company to pay a new account. Either way, the next real invoice is paid to the wrong place, and the supplier chases payment weeks later.

Outside versions are a form of business email compromise. The FBI's Internet Crime Complaint Center describes it in its [public service announcement on business email compromise](https://www.ic3.gov/PSA/2023/PSA230609) as a scam carried out after someone "compromises legitimate business or personal email accounts through social engineering or computer intrusion." Its advice is to "use secondary channels or two-factor authentication to verify requests for changes in account information," and, if money has gone, to contact the bank quickly to ask for a recall and to file a complaint at ic3.gov.

Controls that work against both versions:

- **Call back on a known number.** Verify every bank change by phone using the number already on file, not the one in the request.
- **Separate who requests and who approves a change.**
- **Notify the vendor.** Send a confirmation of the change to the vendor's previous contact details.
- **Hold the first payment.** Review the first payment to new bank details before release.
- **Log every change** to the vendor file with the user, date and old and new values.

## Duplicate invoices and overpayments recovered by an insider

Duplicate payments become fraud when an insider pays the same invoice twice on purpose and then collects the extra. The vendor receives two payments, notices the overpayment and sends a refund. The insider intercepts the refund check, or asks the vendor to send it to a different address or account. The books show the second payment as an ordinary expense.

Duplicates get past the system's own check through altered invoice numbers, a statement paid as well as the invoice, two vendor records for one supplier, or a manual payment followed by the normal run. The disguises and the tests that separate them from honest repeats are set out in [altered invoice numbers that hide a duplicate payment](/blog/duplicate-payment-fraud#altered-invoice-numbers-that-hide-a-duplicate-payment).

Accidental duplicates are more common than deliberate ones, and the test is the same for both. Look for the same vendor, same amount and close dates. PreciseBankFlow flags possible duplicates on that basis in the bank data, which gives you a list to compare with refunds and vendor credits.

The insider step is the refund. Review vendor credits and refund checks received, and confirm each refund reached the company's own bank account.

## Vendor master file tests for accounts payable fraud

Vendor master file tests compare the supplier list with other data the company holds, looking for links that should not exist and records that look invented. The strongest single test is to compare vendor bank accounts, addresses and phone numbers with employee records. A match is not proof, but it needs an explanation.

### Step list for the vendor file review

1. **Export the vendor master file** with name, address, phone, email, tax ID, bank account and date created.
2. **Export employee records** with home address, phone and direct deposit account.
3. **Match on bank account, address and phone.** List every vendor that shares a detail with an employee.
4. **Look for vendors with missing data.** No tax ID, no phone or a PO box only.
5. **Find near-duplicates.** Vendors with similar names or the same bank account under two names.
6. **Review recent additions and changes.** Vendors created or changed in the period, and who made each change.
7. **Check dormant vendors that wake up.** A vendor with no activity for a year that is suddenly paid.
8. **Confirm a sample of vendors exist.** Look up their registration, website and phone, and call them.

The vendor file test finds suspicious records. The bank payment tests in the next section show whether money actually went to them.

## Which bank payment tests find accounts payable fraud?

Bank payment tests compare what actually left the bank with the approved invoice and the vendor details on file. The bank statement and payment files record the amount, the date and, for electronic payments, the receiving account. If any of those differ from the approved invoice or the vendor master file, the payment is an exception.

The table lists the main tests, the data each uses, what it flags and an example result. Example results are illustrative.

| Test | Data used | What it flags | Example result |
| --- | --- | --- | --- |
| Payee account check | Payment file, vendor master | Payment to an account not on the vendor record | ACH of $18,400 to an account changed two days earlier |
| Duplicate check | Bank debits | Same payee, same amount, close dates | Two payments of $3,215.60 to one supplier six days apart |
| Payment without invoice | Bank debits, AP ledger | Debit with no approved invoice | Wire of $9,000 coded to "consulting" with no invoice |
| Round amounts | Bank debits | Even-dollar vendor payments | Monthly $2,500 payments to a "maintenance" vendor |
| Unusual timing | Bank debits | Payments on weekends or outside the normal run | Manual check dated on a Sunday |
| Employee match | Payment file, payroll | Vendor payment to an employee's account | Supplier payment to the account used for a clerk's pay |

### Where the data comes from

Start with the bank's record, not the payables system's. A bank statement shows what cleared. A bank payment file or online banking report shows the receiving account for each ACH or wire. Compare those to the approved invoices and the vendor master file, line by line.

A spreadsheet can carry most of this matching. The guide to [running a bank reconciliation in Excel with macros](/blog/bank-reconciliation-in-excel-with-automation-macros) shows how to set up repeatable matching that can be extended to these payment tests.

## When does an accounts payable exception have an innocent cause?

Most accounts payable exceptions have an innocent cause. Suppliers change banks, recurring bills really are round amounts, and duplicates usually come from rushed data entry. An employee who is also a vendor may have disclosed it and been approved. The exception becomes a concern when the explanation cannot be checked or relies on the person under review.

Common innocent causes:

- **Genuine bank changes** after a supplier's merger, new bank or new payment processor, confirmed by a call back.
- **Fixed-fee contracts** such as rent, retainers and subscriptions, with round monthly amounts.
- **Accidental duplicates** that the vendor refunded to the company's own account.
- **Approved related-party vendors**, where an employee's business supplies the company with management's knowledge.
- **Weekend payments** made by the bank's processing schedule rather than a person.

For each exception, write down the explanation, who gave it and how it was confirmed. An explanation confirmed by an independent source closes the item. One that rests only on the AP clerk's word stays open.

If you test payables for many clients, [PreciseBankFlow](/get-started) produces an exception report from the bank statements, with the source lines behind each item, ready for this follow-up.