Key Takeaways
Vendor master data now sits on the front line of payment fraud. Most attacks on B2B payments end with one edited field in a real supplier record, usually the bank account. In the eurozone, banks now check the payee name against the IBAN before credit transfers, so a loosely typed legal name shows up as a payment warning. E-invoicing rules push the same records toward structured, machine-checkable tax and address data. The vendor master data management best practices below focus on controlling changes to payment-relevant fields and on recording who verified each attribute and when.
Why Vendor Data Became A Payment Security Problem
The Association for Financial Professionals surveyed 465 US treasury practitioners in January 2026. In their organizations, 76% saw attempted or actual payments fraud in 2025, and 74% were hit by business email compromise. Only 17% use AI against payment fraud.
Business email compromise usually ends in the vendor master. The attacker poses as a known supplier and sends a letter about a "new bank account." Someone in accounts payable updates the IBAN. The ERP then pays a correct invoice to the wrong account. No duplicate record and no fake vendor are involved. Every downstream control sees a legitimate supplier with a legitimate invoice.
Checks remain the most targeted payment method, cited by 58% of respondents in the same survey. And 68% of organizations that plan to keep using checks name vendor requirements as the reason. So the payment method field in the vendor record carries fraud risk too, and it needs the same change control as the bank account.
Most vendor payment fraud in 2026 needs no fake vendor. It needs one edited bank field on a real one.
Verification Of Payee Turns The Legal Name Into A Control
Under the EU Instant Payments Regulation, eurozone payment service providers must offer Verification of Payee (VoP) from 9 October 2025. The EPC rulebook for the VoP scheme entered into force on 5 October 2025. The check covers regular SEPA credit transfers as well as instant ones.
The payer's bank sends the payee name and IBAN to the payee's bank. The answer comes back as a match, a close match, no match, or check not possible. On a close match, the payer sees the name the receiving bank actually holds.
Business customers sending bulk payment files can opt out of VoP. Many treasury teams did, to avoid warnings slowing down payment runs. That choice moves the check back to your own data. Opting out means you trust your vendor master more than the bank's account registry, which is only reasonable if the master deserves it.
What this means for the record:
Store the legal name exactly as registered with the vendor's bank, in its own field. Trading names, abbreviations, and the name your buyers use go into separate fields. "Müller Stahl GmbH & Co. KG" and "Mueller Steel" may be the same supplier. Only one of them matches the account.
Route every "no match" on an existing vendor to the record owner before payment. It means either the vendor changed something or someone changed your record. Both deserve a look.
Close matches pile up when legal names were entered loosely over years. Cleaning names once costs less than reviewing the same warnings every payment run.
Your vendor master should hold the name the bank holds. Everything else is a nickname.
Lock Down Bank Detail Changes
The change request usually looks routine. A PDF on real letterhead, a familiar contact name, a polite note about switching banks. Attackers often take over a real mailbox at the supplier, so the email passes every sender check. Voice cloning now covers the follow-up phone call as well. The AFP survey looked at AI-enabled fraud and deepfakes for the first time this year, and organizations using AI against fraud reported better deepfake detection.
So the control has to sit in the process, because the request itself will look genuine. These controls hold up in practice:
- Accept bank changes through one channel only, such as an authenticated vendor portal or a signed form. Email can trigger the process but never completes it.
- Call back on a number already stored in the master record. Never use the number or contact named in the change request.
- Separate duties. The person who enters a bank change cannot approve it, and cannot release the first payment to the new account either.
- Hold the first payment to a changed account for review, or add a cooling-off period of a few days before the new account becomes payable.
- Notify the previously known vendor contact that a change was made. If the vendor didn't request it, this is often how you find out.
The callback number must come from your master record. A number taken from the change request only confirms the attacker.
Apply the same workflow to every field that redirects money or information. That includes the remit-to address, the payment method, the email address for remittance advice, and the vendor's contact email. Attackers change the remittance email first so the real vendor never sees payment confirmations.
Keep bank accounts as separate child records with valid-from and valid-to dates. Never overwrite the old IBAN. When a payment goes wrong, you need to see which account was active on which day and who activated it.
Some banks expose VoP checks to corporate clients through APIs. Where that exists, run the check when the new IBAN enters the record, before any payment depends on it. A no match at that point costs a phone call. A no match discovered during a payment run costs a delayed batch.
There is a trade-off. Strict change controls slow down legitimate changes, and vendors with a real bank migration get frustrated. A documented turnaround time, such as two business days, keeps procurement from inventing workarounds.
Prepare Vendor Records For E-Invoicing
The EU adopted the VAT in the Digital Age (ViDA) package on 11 March 2025. Digital Reporting Requirements for cross-border B2B transactions start on 1 July 2030, and member states can already introduce mandatory domestic e-invoicing under specific conditions. Several countries use that option, each with its own platform and timeline.
E-invoices arrive as structured data, and machines match them against the vendor master. A mismatch between the seller VAT ID on the invoice and the one in your record blocks the invoice in an automated flow. That's useful, because an invoice with an unknown VAT ID from a known vendor is also a fraud signal.
Practical changes to the data model:
Store identifiers as a typed list, with a scheme and a value per entry. One generic "tax number" field breaks as soon as a vendor has a VAT ID, a national company registration number, and a Peppol participant ID. Validate EU VAT IDs against VIES at entry and on a schedule.
Use structured addresses with separate fields for street, postcode, city and an ISO country code. Free-text address blocks fail automated validation.
Record the e-invoicing channel per vendor: Peppol endpoint, national platform, or legacy PDF. AP teams in 2026 run mixed channels, and the vendor record is the place that says which one applies.
Record Who Verified What, And When
A vendor record usually stores values. It rarely stores how those values were confirmed. That gap matters during audits, fraud investigations, and VoP disputes, because "the IBAN is in the system" proves nothing about whether anyone checked it.
Store provenance for each critical attribute: the source, the verification method, the date, and the person or service that verified it. These attributes need it most:
- Legal name and company registration number, verified against a commercial register.
- Tax identifiers, each with its scheme and last validation date.
- Bank accounts, with currency, validity dates, the callback record, and the VoP result if available.
- Remit-to and contact email addresses, with the date of last confirmation by the vendor.
- Sanctions and ownership screening results, with the list version and screening date.
With this in place, a steward can filter for "bank accounts not verified in 12 months" and work through a list. Without it, re-verification means re-checking everything.
Screen On A Schedule Set By Risk
Sanctions lists change weekly. Vendors get acquired, change owners, and move registered offices. A vendor screened clean at onboarding in 2022 says little about 2026.
Tier vendors by spend, country risk, and payment method. Strategic and high-risk vendors get screened continuously or monthly. The long tail can run on an annual cycle. Events should trigger an immediate check regardless of tier: a legal name change, a new registered country, or a bank account in a country different from the registered one.
That last signal needs judgment. Factoring arrangements, shared service centers, and group treasury setups produce legitimate country mismatches. Flag them for review, and record the reason when a steward approves one, so the same question doesn't come back every quarter.
Block dormant vendors from payment after a fixed period without activity, often 12 or 18 months. Reactivation goes through the onboarding workflow again, including bank verification. A dormant record with valid bank details is an easy target, because nobody watches it.
Give AI And Automation Clean Inputs
AP automation and AI agents treat the vendor master as truth. An agent that auto-matches invoices will pay a manipulated record faster than a clerk would. The 17% of organizations already using AI against fraud are a minority, but invoice processing automation is far more widespread than fraud detection.
Two rules help. Give automated processes access to verified attributes only, and route anything unverified to a person. Use AI where it reads patterns: duplicate suggestions, unusual change sequences, a new IBAN followed by a remittance email change within a week. Keep merge and approval decisions with data stewards.
Expect false positives at the start. Tune thresholds on real change history before switching off manual review.
What We See In Projects
Our customers turn to us with vendor data spread across two or three ERPs and a procurement tool. A typical case is a manufacturer after an acquisition. Each ERP holds its own copy of shared suppliers, and bank changes get entered directly in whichever system the request reached. Nobody can say which change was approved by whom, and auditors ask exactly that.
In projects we implemented with AtroCore, the first step was moving the edit point out of the ERPs. Vendors and their bank accounts live in one configurable data model, with bank accounts as related records carrying validity dates and verification fields. Changes land in a staging area, a workflow requires a second approver, and the field history shows the old value, new value, and approver. The ERPs receive approved data through the REST API and no longer accept direct edits to payment-relevant fields. The result was one place to audit, instead of three systems to reconcile after an incident.
The software part was the smaller effort. Agreeing on who owns bank changes and getting procurement to stop editing vendors in the ERP took longer.
Metrics That Show Whether It Works
Track a short list of numbers monthly and show them to finance leadership:
- Share of active vendors with a bank account verified in the last 12 months.
- Bank changes completed without a logged callback. The target is zero.
- VoP no-match and close-match rates per payment run.
- Dormant vendors that are still payable.
- Duplicate candidates flagged per 100 new vendor requests.
- Days from vendor request to payment-ready status.
The last one matters more than it looks. When onboarding takes three weeks, buyers start using existing vendor records for new suppliers, and that's how a clean master decays.