Delegating Accounts Payable: Vendor Fraud and Payment Authorization Controls

Published September 24, 2026.

The fraud surface behind a delegated payable process

Accounts payable is one of the most attractive functions to delegate and one of the most sensitive, because it is the function that moves money out of the business. A founder who hands invoice intake, vendor follow-up, and payment preparation to a virtual assistant removes real recurring work, but also creates a new question: who can actually release a payment. The answer to that question decides how much fraud risk the business carries, and it is worth designing deliberately rather than discovering by accident.

This review describes the fraud patterns that appear when payable work is delegated, maps them to the control layers that reduce them, and gives a practical division of labor for a small business. It is a general framework drawn from public fraud reporting and control guidance, not a substitute for the business's own accounting advice.

The fraud patterns that matter most

The first and largest pattern is the vendor bank change. In business email compromise, an attacker impersonates a known vendor, references a real invoice or project, and asks that future payments go to a new bank account. The request looks routine, arrives in a plausible thread, and often includes a forged attachment. Fraud reporting has consistently ranked this pattern among the costliest forms of cyber-enabled crime, and it succeeds because the change request is processed quickly by a person under normal time pressure. When payable work is delegated, the assistant becomes the natural target for this request, and the founder may never see it.

The second pattern is the fabricated or inflated invoice. An attacker, or even an opportunistic vendor, submits an invoice for work that was not performed, duplicates a legitimate invoice with a new number, or quietly raises a unit price. An assistant who only checks that an invoice received a signature or an approval, without matching it to a purchase order or a delivery, can process it without noticing.

The third pattern is the compromised assistant account. If the assistant's email or accounting credentials are stolen, the attacker can act as the assistant, approve work, or redirect payments. A shared login makes this worse, because the activity cannot be attributed and the attacker can hide behind a legitimate identity.

The fourth pattern is the insider or gray-area case, where a person with payment authority creates a shell vendor or approves a payment to a related party. This is the pattern that pure technology controls miss, which is why separation of duties remains the core defense.

The control layers that reduce the risk

Segregation of duties is the first layer. The person who prepares a payment should not be the person who releases it. In a small business the founder usually plays the release role, and the assistant prepares. The principle and its broader application across delegated financial tasks are set out in our review of segregation of duties in delegated financial work. Keeping the release decision with the owner is the single most important design choice in a delegated payable process.

Callback verification is the second layer. Any change to vendor bank details should be confirmed by the business through a known, independent channel before it takes effect. That means calling the vendor at a number already held in the business records, not a number supplied in the request. The callback should be performed by a person other than the one who received the request, which is where the assistant and the founder divide the work.

Dual release is the third layer. Where the banking or accounting platform supports it, a payment should require two approvals above a set threshold. Amount thresholds, new vendors, and international payments are the natural places to require the second approval. The threshold should be low enough to matter and high enough that the owner is not approving every small expense.

A single payment calendar is the fourth layer. Batching vendor payments into one or two scheduled runs replaces ad hoc transfers with a predictable cycle. The assistant prepares the run, the owner reviews it, and the bank or platform releases it. A predictable cycle gives the owner a natural review point and removes the urgency that fraudsters rely on. The wider set of controls that apply to delegated financial and operational work is summarized in our review of delegation risk and control statistics.

Dividing the work between owner and assistant

A workable division gives the assistant the preparation and follow-up tasks and reserves the money movement for the owner. The assistant can receive invoices, match them to purchase orders and delivery records, flag mismatches, chase missing approvals, maintain the vendor file, and prepare the payment run. The owner can review the run, make the release decision, own the banking relationship, and be the only person who can add a new vendor or change banking details.

This split keeps the assistant productive without making the assistant the last line of defense. It also creates a clean audit trail, because every release decision has a named owner.

Monitoring and recovery

Controls are only as good as the monitoring behind them. A short monthly review that lists new vendors, bank detail changes, duplicate payments, and payments just under the dual approval threshold will surface most problems early. The owner should also watch for requests that arrive outside normal channels, use a free email domain, or pressure the team to move quickly. Those signals are cheap to check and expensive to ignore.

If a fraudulent payment does go out, the response matters as much as the prevention. The business should contact its bank immediately to attempt a recall, preserve the request and any attachments as evidence, and report the incident. In the United States, business email compromise can be reported to the Internet Crime Complaint Center, and the report is often a prerequisite for any recovery effort through the financial system. A written incident path that names who calls the bank, who preserves evidence, and who notifies the accountant keeps the response fast.

Methodology and limits

This review examined public fraud reporting from the Federal Bureau of Investigation Internet Crime Complaint Center, the NIST Cybersecurity Framework, United States Small Business Administration guidance on managing business finances, Internal Revenue Service small-business guidance, and Federal Trade Commission business guidance on privacy and security. Each source was checked on September 24, 2026. The review provides a general control framework. It does not provide accounting, legal, or insurance advice, and it does not guarantee that any single control will prevent fraud. The appropriate control set depends on transaction volume, platform capabilities, and the business's risk tolerance.

Frequently asked questions

Can a virtual assistant approve payments? The assistant can prepare and match payments, but the release decision is safer with the owner. If the owner must delegate approval for small amounts, set a low threshold and require a second approval above it.

How should a vendor bank change be verified? Through a known, independent channel. Call the vendor at a number already in the business records, and have someone other than the person who received the request make the call.

Is a shared accounting login ever acceptable? No. A shared login destroys attribution and makes least privilege impossible. Give the assistant a named account with the narrowest role.

What is the fastest signal of trouble? A new bank detail request, a duplicate invoice, or a payment that sits just under the approval threshold. Review these monthly rather than at year end.

References

1. Internet Crime Complaint Center, Federal Bureau of Investigation
2. Cybersecurity Framework, National Institute of Standards and Technology
3. Manage your business finances, U.S. Small Business Administration
4. Small business and self-employed tax center, Internal Revenue Service
5. Data security and privacy business guidance, Federal Trade Commission
6. Privacy Framework, National Institute of Standards and Technology