This is part 2 of a 3-part blog series on Verification of Payee (VoP). Click here to read the first part ‘’Why VoP Doesn’t Protect You From the Fraud You’re Actually Worried About.’’
It is month-end. Your payment run is loaded, reviewed, and ready to go. Hundreds of supplier payments queued up — payroll support, outstanding invoices, cross-border transfers. You release the batch.
Then it stops.
One supplier, a vendor you have paid reliably for several years, has returned a No Match on the new Verification of Payee (VoP) check your bank rolled out recently. In your ERP, the name is recorded as a shortened or anglicized version. At the bank, it’s stored under the full legal entity name. Same company. Different string. The system doesn’t recognize the equivalence.
Under the Deutsche Kreditwirtschaft’s EBICS specification, a single mismatch in a bulk payment file means organizations may need to recreate the file with corrected data after the entire file has been rejected. The regulation requires signing or rejecting the entire payment batch in case of a ‘No Match’ response. To exclude a certain transaction, the typical approach is to cancel the batch, amend the payment file, and resubmit it.
VoP didn’t create a new problem. It attached regulatory and liability consequences to a problem that was already there. It is the operational reality that treasury and finance teams across Europe are beginning to walk into and without a clear picture of where their own vendor data is exposed.
Why vendor data is the real VoP compliance problem
When the EU Instant Payments Regulation mandated Verification of Payee for all eurozone Payment Service Providers from October 2025, the coverage in the financial press focused on what banks needed to build: PSP infrastructure, inter-bank messaging, scheme compliance timelines.
Almost nothing was written about what corporates needed to fix.
VoP works by comparing the name you include in a payment instruction against the name legally registered with the payee’s bank for that IBAN. That comparison is exact — or close to exact. It does not accommodate the way vendor data typically accumulates in ERP systems over years of business operations.
The numbers are not encouraging. Industry data suggests more than 70% of payment exceptions already stem from formatting errors or invalid account details. VoP did not create that problem. It attached regulatory and liability consequences to a problem that was already there.
The five ways vendor master data goes wrong
In working with treasury and finance teams across Europe, the same categories of vendor data failure come up consistently:
1. Abbreviations entered at onboarding
When a vendor is added to the system, the name entered is often a shortened version of the legal entity name. “Müller & Partner” instead of “Müller und Partner Steuerberatungsgesellschaft mbH.” Probably convenient at the time, but its a VoP mismatch waiting to happen.
2. Trading name instead of legal entity name
Many businesses operate under a trading name that differs from their registered legal name. A supplier may invoice under “BlueSky Freight” while their bank account is registered to “Horizon Transport Solutions Limited.” VoP has no concept of trading names.
3. Account changes that updated the IBAN but not the name
When a supplier changes banks, they typically notify their customers by email with a new IBAN. The update gets made in the ERP. The name field that is already populated often goes untouched. If the new bank holds the account under a slightly different legal name format, the mismatch is now baked in.
4. Names copied from invoices
Vendor records are frequently built from invoice data. If a supplier’s invoices contain their trading name, a name abbreviation, or even a typographical error, that error gets imported into the ERP and stays there until someone notices.
5. Legacy records from acquisitions
Mergers and acquisitions leave behind inherited vendor master data built in different systems, by different teams, under different naming conventions. Rationalising it is expensive and slow, so it often gets deferred — until VoP forces the issue.
What a vendor master audit looks like
The instinct of most finance teams when they hear “vendor master audit” is to file it under “important but not urgent.” After October 2025, that calculus has changed.
A practical VoP-readiness audit does not require reviewing every vendor record simultaneously. It requires a prioritized approach:
- Start with high-value, high-frequency vendors. These carry the most payment risk and the most operational disruption if a run is blocked.
- Focus on cross-border SEPA relationships. Domestic payment names are typically more stable; cross-border records are where inconsistencies accumulate.
- For each priority vendor, request written confirmation of their bank-registered legal name. Not their invoice name. Not their trading name. The exact legal string their bank holds.
- Cross-check against national company registries where available — particularly for DACH-region counterparties where the Handelsregister provides reliable legal name data.
- Update onboarding templates so that every new vendor is required to provide their bank-registered legal name at the point of onboarding, not after the first payment fails.
Governance matters as much as the initial clean-up. A vendor master that is accurate today can degrade quickly if account change processes do not include a name verification step. Whoever owns the vendor master — AP, treasury, procurement — needs a documented procedure for how changes are reviewed and approved.
The inbound risk most teams haven’t modelled
Vendor master hygiene addresses outbound payment risk. But VoP creates an inbound exposure that receives far less attention.
If your own company name on sales invoices does not exactly match the legal name registered with your bank, your customers’ VoP checks will return a mismatch when they try to pay you. A No Match result gives their system grounds to cancel or delay the payment. Most finance teams have not yet audited what name is on their own invoices versus what name their bank holds.
Clean vendor data is a necessary foundation. But even clean data cannot protect against an account change you haven’t been told about yet.
Why data hygiene alone is not enough
A well-governed vendor master significantly reduces VoP mismatch risk. But it does not eliminate it.
Even organizations with clean, well-maintained vendor data face a specific vulnerability: suppliers who change their banking details without adequate notice. An updated IBAN sent by email, a new entity name following a restructuring, a bank migration that changes how the legal name is formatted — any of these can introduce a mismatch between your records and reality, with no warning until a payment fails.
The only reliable defence against that scenario is validating account details at the moment of payment — not from static ERP records, but against live data from the payee’s bank. That validation needs to happen before the payment executes, not after.
TIS Account Validation verifies that the account exists, and the payee name matches in real-time — before any payment is executed — across 46 markets globally. It runs automatically within your existing TIS payment workflow, with no process changes for your team.
To learn more about TIS Account Validation, request a personalized demo.
