An email arrives from a long-standing supplier's accounts team. They have moved banks, the letter on headed paper is attached, and could you update the details before Friday's run. The invoice reference in the email is real. Someone in AP updates the vendor master data, the run goes out, and two weeks later the supplier calls to ask why they have not been paid.
Nothing in the invoice process failed. The invoice was genuine, matched and approved. The control that failed was on the vendor record, and in many companies that record gets less attention than any invoice.
Why vendor master data is the weak point
Three-way match, approval workflows and duplicate checks all look at the invoice. None of them asks whether the bank account on the vendor record is the right one. The payment run trusts the master.
The master is also maintained by many hands. New vendors come from procurement, address changes from AP, tax details from the tax team, and bank details from whoever opens the email. The work is high volume and treated as administration, which makes it a convenient place for both external fraud and internal misuse.
How bank-detail change fraud works
The external pattern is the one above. A supplier's mailbox is compromised, or a lookalike domain is registered, and a request to change bank details arrives in the middle of a real email thread. It often comes with urgency: a new account, an old one closing, a payment due.
Internal patterns are quieter. Someone with vendor maintenance access changes the bank account on a dormant vendor, pays it, and changes it back. Or creates a vendor that does not exist, with an address or account that matches their own. A change made and reversed around a single payment run is a classic signature.
The controls that close the gap
Call back on a number you already hold. Never the number in the request. Speak to a known contact, confirm the new details, and record who called, who answered and what was confirmed. The change is not effective until the call-back record exists.
Dual control on sensitive fields. Bank details, payment method, address and tax ID should need a second person to confirm any change. SAP, for example, offers dual control for sensitive vendor fields, blocking the vendor for payment until a second user confirms. Check that it is switched on and that bank details are on the sensitive list.
Segregation of duties. The person who maintains vendors should not post invoices or release payments. In small teams where that is not possible, an independent review of every change is the compensating control.
Change log review. A weekly report of every change to sensitive fields, reviewed by someone outside AP and matched to a call-back record.
Dormant vendors. Block vendors with no activity over a period your policy sets. Reactivation goes through the same checks as a new vendor.
Vendor creation checks. Validate the tax ID, check for an existing record with the same bank account or address, and compare vendor bank accounts and addresses with the employee master.
| Control | Risk addressed | Performed by | Frequency |
|---|---|---|---|
| Call-back on bank-detail change | Impersonation of a supplier | AP or vendor team, not the requester | Every change |
| Dual control on sensitive fields | One person changing where money goes | A second authorised user | Every change |
| Separation of vendor maintenance, invoice posting and payment release | Internal fraud | Access design, reviewed by the controller | Quarterly access review |
| Change log review | Unverified or reversed changes | Controller or internal audit | Weekly, and before each run |
| Dormant vendor block | Reuse of an inactive record | Master data team | Quarterly |
| Employee to vendor match | Fictitious vendors | Internal audit | Quarterly |
| Extra approval on first payment after a change | Late detection | Payment approver | Each run |
What AI can monitor in vendor master data
Most of these controls are periodic. Fraud is not. The gap between a change and the next review is where the money goes, and continuous monitoring is a reasonable use of AI. Gartner asked 183 CFOs and senior finance leaders about their AI use in May and June 2025, and 34% named error and anomaly detection, one of the most cited uses.
A read-only monitor over the change log and the payment proposal can flag:
A model can also read the request email and compare it with past correspondence from that supplier, then explain in plain words why it raised the flag.
AI cannot verify a bank account. Verification is a conversation with a known person on a known number, and it stays with people, as does releasing a held payment. Expect false alarms, and tune them, because a monitor that flags everything trains people to ignore it. Monitoring tools should never have write access to the vendor master. A tool that can change bank details is itself a risk.
What vendor master data controls will not do
They will not stop collusion. If the person who changes the record and the person who confirms it act together, dual control fails. Access reviews and rotation reduce the risk; they do not remove it.
They will not get money back. Once a payment reaches a fraudulent account, recovery depends on how quickly you tell your bank and theirs. Have that procedure written down before you need it.
Frequently asked questions
What is vendor master data?
Vendor master data is the record the ERP holds for each supplier: name, address, tax ID, payment terms, payment method and bank details. The payment run uses it to decide where money goes.
How should a company verify a vendor bank detail change?
Call the supplier on a phone number already on file, not one supplied in the request, confirm the new details with a known contact, and record the call before the change takes effect.
What segregation of duties is needed for vendor master data?
The person who creates or changes vendor records should not also post invoices or release payments. Where a small team cannot separate those roles, an independent review of every change compensates.
Why block dormant vendors?
Dormant vendor records can be reactivated and paid with little scrutiny. Blocking them, and treating reactivation like a new vendor set-up, closes that route.
Can AI detect vendor bank detail fraud?
AI can flag patterns that often accompany it, such as a bank change followed quickly by a payment or one account shared by two vendors. It cannot verify the account; a person still makes the call-back.
Where CFOLogic fits
We build monitoring and exception tools for finance teams over the systems they already run, reading data without changing it and leaving each release decision with a person. Work usually starts as a proof of concept on one control. A public demo with fictional data shows payables exceptions grouped by owner and status in a purchase-to-pay setting.