Accounts Payable Fraud Prevention Controls That Survive Payment Release
An approved invoice can still become a fraudulent payment. Build controls that preserve authorization from vendor setup through bank release—and test whether your AP software actually enforces them.
Effective accounts payable fraud prevention controls combine independently verified vendor details, segregation of duties, invoice validation, enforced approvals, protected payment release, and independent reconciliation. The critical requirement is continuity: approval must remain tied to the supplier, destination account, amount, and currency that were authorized. Material changes should stop payment and trigger the appropriate verification and reapproval.
For finance teams moving from email approvals and bank portals to automation, this is the buying question: does the platform enforce that continuity, or simply move invoices faster?
The 2025 AFP Payments Fraud and Control Survey found that 79% of respondent organizations experienced attempted or actual payments fraud in 2024. That covers payments broadly, not AP alone, but reinforces why invoice approval cannot be the final fraud checkpoint.
Start with the handoffs, not the feature list
Fraud controls often fail between systems. AP approves an invoice in one application, treasury exports a payment file, and an operator uploads it to a bank portal. Meanwhile, someone updates the vendor master. Each system may show an authorized action without proving that the final payment matches the original authorization.
Map every place a person, integration, or service account can change the payee, destination, amount, currency, or payment status. Then identify which changes invalidate approval and which system blocks release.
Use the following matrix as a control-design baseline. These are recommended requirements to validate, not claims about any particular product.
| Risk point | Preventive control | Accountable owner | Evidence to retain |
|---|---|---|---|
| Fictitious vendor | Independent supplier verification | Vendor master owner | Identity checks and business sponsor |
| Bank-detail substitution | Trusted-channel verification and separate approval | Vendor master approver | Change history and verification record |
| Unsupported invoice | Matching or documented service acceptance | Business budget owner | Order, receipt, or acceptance evidence |
| Self-authorized payment | Conflicting-role restrictions | Controller | Permissions and approval history |
| Post-approval alteration | Hold and reapproval for material changes | Payment approver | Approved and released payment versions |
| Bank-portal bypass | Restricted access and independent release | Treasury lead | Bank authorization record |
| Concealed disbursement | Independent reconciliation and investigation | Accounting reviewer | Resolved exceptions and bank records |
Verify vendors and protect payment-detail changes
A legitimate invoice does not prove that the bank account printed on it belongs to the supplier. Neither does a reply from a familiar email address: the supplier's mailbox may be compromised.
Commerce Bank's AP fraud guidance emphasizes separating responsibilities and independently confirming changes to payment information. Turn those principles into a mandatory workflow:
- Establish a trusted baseline. Verify the supplier's identity, business purpose, and authorized contacts before enabling payment. A tax document alone does not establish account ownership.
- Quarantine requested changes. Store proposed bank details separately from the currently approved record. Do not overwrite the active destination on receipt of an email.
- Verify through an established channel. Contact a previously validated supplier representative using contact details not supplied in the change request. Record who verified the request and how.
- Require independent approval. The person entering the change should not approve their own modification.
- Reassess pending payments. Hold affected instructions until the new destination is verified and the appropriate payment authorization is renewed.
Where available, account-name or ownership checks can provide additional evidence. Coverage and match quality vary by market and provider; treat inconclusive results as exceptions, not successful verification.
A portal also needs controls. Strong authentication, protected contact changes, and recovery procedures matter because a compromised supplier account can submit a fraudulent request through a legitimate interface.
Separate authority across the full payment chain
Segregation of duties means more than having different people capture and approve invoices. Review who can create suppliers, edit bank details, approve invoices, release payments, administer permissions, and reconcile bank activity.
The AP internal controls framework described by Ramp includes segregation of duties and invoice matching. The operational challenge is enforcing those controls across applications, not just within AP.
For example, a clerk restricted from releasing payments in the AP platform may still have unrestricted bank-portal access. An administrator may be able to grant themselves approval rights. A shared integration credential may bypass restrictions applied to human users.
- Use named identities and strong authentication for finance and bank access.
- Review conflicting permissions across the ERP, AP platform, bank, and integration layer.
- Log privileged access changes and have someone independent review them.
- Apply equivalent restrictions to service accounts and AI agents.
- Make temporary delegation expire and prohibit self-approval through delegation.
Small teams may need compensating controls, such as independent owner approval of new beneficiaries and direct review of bank activity. Document the remaining concentration of authority: a detective review after settlement is not equivalent to a preventive release block.
Validate the obligation without trusting appearances
For purchase-order-backed goods, match the invoice to the approved order and receiving evidence. Configure tolerances deliberately, and route discrepancies to an accountable owner rather than automatically accepting them to improve processing rates.
Services and non-PO spending need a different evidence path: an executed agreement, milestone acceptance, or documented confirmation from the business owner that the service was delivered. Coding an invoice to an expense account is not proof of performance.
Duplicate checks and anomaly detection help identify suspicious submissions, but alerts require ownership and resolution. Conversely, a clean match is not a guarantee against collusion: coordinated purchase orders, receipts, and invoices can agree while describing a fictitious transaction.
Keep invoice extraction separate from vendor-master authority. OCR or an AI agent may capture bank details from a document; that should not authorize those details to replace the approved beneficiary.
Bind approval to what actually leaves the bank
Configurable approval policies should address more than spending thresholds. Define which changes invalidate existing authorization, including supplier substitution, beneficiary changes, increased amounts, and currency changes.
Hypothetical example: A genuine supplier invoice is approved for payment. Before the payment run, an attacker sends new bank details from the supplier's compromised mailbox. The invoice remains valid, but the destination is now untrusted. A robust workflow holds the affected payment, verifies the change independently, and obtains authorization for the revised instruction.
Ask vendors to demonstrate this sequence. Can they show exactly which beneficiary record the approver authorized? What happens if an API updates that record after approval? Does a queued payment retain the old destination, adopt the new one, or stop?
For file-based bank uploads, restrict file editing and reconcile released instructions to approved instructions. Batch totals alone are insufficient: a substituted beneficiary can leave the total unchanged.
Emergency payments need an exception path with a named approver, documented reason, and preserved verification requirements. Executive urgency should not become an informal bypass.
Use reconciliation to detect failure—and prepare to respond
Reconciliation is detective, not preventive. Independently compare bank activity with authorized payments, investigate unexpected beneficiaries and manual disbursements, and track unresolved exceptions to closure.
Retain a connected audit trail: source invoice, matching evidence, vendor-record history, approver identity, policy applied, overrides, payment instruction, and bank reference. Confirm who can alter or delete those records.
If suspected fraud is discovered, contact the financial institution immediately to request available recall or recovery measures, stop pending related payments, preserve evidence, and involve security and legal teams as appropriate. Recovery depends on the payment rail, timing, and circumstances; do not assume it is possible.
A buyer's checklist for the product demonstration
Ask each shortlisted provider to demonstrate failure cases, not only a clean invoice-to-pay flow:
- Change a beneficiary after approval: Does release stop, and what evidence unlocks it?
- Attempt self-approval: Do delegation, administrator access, and API credentials preserve role separation?
- Submit an unsupported invoice: Is missing receipt or service evidence routed to a named owner?
- Alter a payment export: Can the team detect a changed destination despite unchanged batch totals?
- Request an urgent override: Are authorization, rationale, and verification retained?
- Reconstruct a payment: Can an auditor trace the released instruction back to its approval and vendor-record version?
Track unresolved exceptions, unverified bank changes, overrides, and payments released outside the approved workflow. Evaluate cost per invoice alongside those measures. Lower processing cost achieved by removing necessary checks is not a control improvement.
Automate the controls before removing the touchpoints
The goal is not manual review everywhere. It is a trusted path for routine transactions and a hard stop when evidence, authority, or payment details change. That distinction is central to touchless invoice processing.
Before selecting an AP automation platform, bring your role map, bank-change procedure, and demonstration checklist. Require clarity on which controls the platform enforces, which depend on integrations or bank settings, and which remain your team's responsibility. Approval is only effective when it governs the payment that actually leaves the account.
Created with AI assistance. Sources are linked in the article; this content is general information, not legal, tax, or financial advice.
Discussion
33 commentsRelated resources
Touchless Invoice Processing: What It Really Means and How to Get From 0% to 80%+
Touchless invoice processing isn't a switch you flip — it's a rate you climb. Here's what it really means, how to measure it, and a step-by-step path from 0% to 80%+.
AI Invoice Processing Software: Test Accuracy Before Buying
A polished invoice demo does not prove production readiness. Learn how to test extraction, coding, and exception handling—and compare software on the cost of usable output.
Invoice Automation Platform: Buy for Your Invoice Mix
The right invoice automation platform depends on the invoices your team actually receives. Build a buying case around document complexity, exception workload, and the cost of reaching a correctly posted payable.
Run your entire money cycle on one ledger
Global payouts, AP/AR automation, and AI agents with their own wallets and spend limits.
Get started
The bank-portal bypass risk doesn't get enough attention. We had full segregation in our ERP and AP platform, but four people had unrestricted access to upload payment files directly through the bank's web portal—completely outside our approval workflow. Found it during an audit and it was a wake-up call.
We did a similar review last quarter and found the same issue—bank portal access was treated as an operational convenience rather than part of the approval chain. Ended up implementing a separate approval matrix for bank-portal users and restricting file uploads to treasury only.
We did a similar review last quarter and found the same issue—bank portal access was treated as an IT security question rather than a segregation-of-duties control. Had to rebuild our entire access matrix to include both internal platforms and external bank portals as part of the same approval chain.
The section on material changes invalidating approval is good in theory, but how are you defining 'material'? We have a $500 threshold for amount changes, but currency changes always require re-approval regardless of amount. The challenge is that different risk profiles need different triggers and most platforms force you into one global rule.
We ended up building materiality rules as a combination of fixed thresholds and category-based logic. Currency changes always trigger re-approval for us too, but we also flag any change to payment method (wire vs ACH) or country code regardless of amount. The real problem is maintaining those rules when you have multiple subsidiaries with different risk appetites—we had to create a config layer that lets each entity define their own triggers within guardrails set by group treasury.
We define material change as anything that alters the payment destination (account number, routing, SWIFT/IBAN), currency, or amount beyond 5%. The percentage threshold doesn't work for small invoices though, so we also flag any absolute change over $100. Agree that currency changes should always force re-approval since they introduce FX exposure and can mask amount manipulation.
The 'trusted baseline' step is where most companies cut corners. We had a vendor onboarding process that accepted W-9s and bank letters as sufficient proof, but when we actually called three suppliers to verify their details using our own contact research, two of them had no record of the bank accounts on file. Turns out a former AP clerk had been updating details for months. Now we require a live verification call and separate approver for every new vendor, no exceptions.
This is a surprisingly common finding. We now require dual-channel verification for all new banking details—one verification using contact info from the original onboarding, and a second from our procurement team's independent research. It adds a day to setup but has caught four attempted substitutions in the past year alone.
We had a similar issue during onboarding audit. Turned out four vendors in our master file had bank details that didn't match any legitimate contact at the supposed supplier. The scary part is how long those records sat there before anyone thought to verify them outside the paper trail.
The part about shared integration credentials bypassing restrictions applied to human users hit home. We discovered during an audit that our middleware service account had write access to vendor master, approve invoices, and initiate payments—effectively unlimited authority across the entire chain. No one person could do all three, but the bot could. Fixed it by splitting the integration into three separate service accounts with distinct permissions and added a rule that no service identity can hold conflicting roles.
We found the same thing during a SOX audit. The fix was painful but straightforward: created separate service accounts for each function (vendor read-only, invoice approval, payment initiation) and enforced the same role conflicts we apply to users. The ERP connector now authenticates with three different credentials depending on the operation.
We found the same thing during a SOX audit. The fix was painful but straightforward: created separate service accounts for each function—one read-only for AP data sync, one write-only for payment file creation with no vendor master access, and a third for reconciliation pulls. Then enforced that no single account could both modify a payment destination and release funds.
The section on service accounts and AI agents having the same segregation restrictions is something we're wrestling with right now. Our RPA bot technically has permission to both approve invoices under a threshold and initiate payment files, which violates the whole point of separation, but disabling that breaks the automation. Has anyone solved this without just adding more manual checkpoints that defeat the efficiency gain?
We hit the same wall. What worked for us was splitting the bot's function: one service account can mark invoices as validated and queue them, but a separate treasury-controlled account actually generates the payment file. The handoff creates an audit point and forces us to treat the bot like two different roles even though it's technically one process.
We ended up doing something similar—split the automation into two separate service accounts with different permissions, then added a manual treasury release step for anything the bot queued up. Not as automated as we wanted, but it closed the segregation gap without killing the efficiency gains.
The emphasis on post-approval alteration controls resonates. We discovered a fraud attempt where an approved invoice sat in the queue for three days, and during that window someone modified the account number in the vendor master. The payment file picked up the altered details even though the approval predated the change. Now we snapshot vendor payment details at approval time and compare them at release—any mismatch holds the payment and sends an alert.
This exact scenario is why we built a lock-on-approval step. Once the invoice hits approved status, the payment instruction captures a snapshot of the vendor bank details at that moment and ignores any subsequent master file edits. Changes to the vendor record trigger a hold and force reapproval of anything in queue.
We had almost the identical issue. What fixed it for us was treating the approved invoice record as immutable—any vendor master change after approval date triggers an automatic hold and routes back to the original approver with a red-flag notification showing what changed.
The matrix is helpful but I'd add one more row: reconciliation timing. We found fraud because our controller runs a same-day comparison of released payments against approved amounts, not waiting for month-end. By the time you're reconciling bank statements 15 days later, the money is long gone and you're just documenting the loss.
Agree completely. We shifted to a daily payment reconciliation workflow after a near-miss with a vendor master swap that happened between approval and release. Waiting for the bank statement to close means you're doing forensics, not prevention.
Absolutely. We added a daily reconciliation step specifically for wire and international payments that triggers before end-of-business. If the released payment file doesn't match what was approved in the AP system that morning, treasury won't initiate the next day's batch until it's resolved.
The point about AP approval not being the final fraud checkpoint is critical but most teams still treat it that way. We've seen cases where an invoice was approved weeks before payment and the vendor's bank details were changed three times in between—no reapproval triggered because the systems weren't connected. The real test isn't whether your AP tool has approval workflows, it's whether a change to routing details after approval actually stops the payment file from going out.
We solved this by having the payment file generation step include a cryptographic check against the original approved invoice record. If vendor bank details, amount, or currency changed after approval, the hash breaks and the payment gets kicked to a manual review queue. Took some work to implement but it caught two attempted substitutions in the first month.
We had exactly this scenario. The fix was configuring the payment platform to hash the approved invoice record including payee account details, then validate against that hash at release. Any mismatch triggers a hold and sends it back through approval with a visible change log. It's not native in most systems though—we had to build it as middleware.
The handoff mapping exercise is spot on. We had a situation last year where an invoice approved in our ERP got modified during the payment file export—amount was correct but routing number had been changed in the vendor master two days after approval. No one caught it until reconciliation because each system showed green checkmarks. Now we hash critical fields at approval and validate before release.
We've started treating any vendor master change as requiring a fresh approval for pending payments to that vendor. It's slowed things down a bit but the alternative is what you described—finding out at reconciliation that you paid the wrong account.
This is exactly why we built a daily control report that flags any vendor master changes made within 72 hours of a pending payment to that vendor. Catches the timing issue you describe and forces a secondary review before release.
"Does the platform enforce that continuity, or simply move invoices faster?" This should be printed on every RFP. Half the demos we sat through last quarter showed slick approval workflows but went silent when we asked what happens if someone edits the beneficiary between approval and file generation.
Same experience here. The vendors who actually answered that question well could show us the exact database state before and after approval, plus what conditions triggered a payment hold. Everyone else just talked about audit trails, which tells you nothing about whether the system actually stops a modified payment from going out.
Same experience here. The vendors who actually answered that question well could show us the exact database field lock or the reapproval trigger in the workflow. The ones who didn't have an answer tried to redirect to their 'audit trail' feature, which just proved someone changed it, not that the system prevented release.
Question on the trusted-channel verification: how are you all handling this for international suppliers where phone contact is expensive or impractical? We've been using video calls for large changes but it doesn't scale, and some of our smaller vendors in APAC don't have consistent availability.
We use a combination of the supplier portal for submitting changes plus email confirmation to the last-known contact, then follow up with a callback only if the value exceeds a threshold or the email response looks off. For smaller APAC vendors we also accept notarized bank letters as an alternative evidence path, though turnaround can be slow.
We require portal-based submission for international changes, then send confirmation through WhatsApp Business API to the contact number we verified during onboarding. Not perfect, but it scales better than scheduled calls and gives us an audit trail. The article's point about not using contact details from the change request itself is critical—we pull the number from our original vendor file.