Die wichtigsten Erkenntnisse
Vendor Master Data steht heute an vorderster Front bei Zahlungsbetrug. Die meisten Angriffe auf B2B-Zahlungen enden damit, dass ein Feld in einem echten Lieferantendatensatz bearbeitet wird – meist das Bankkonto. Im Euroraum prüfen Banken nun den Namen des Zahlungsempfängers gegen die IBAN vor Kreditüberweisungen, sodass locker erfasste Firmennamen als Zahlungswarnung sichtbar werden. E-Invoicing-Vorschriften drängen dieselben Datensätze in Richtung strukturierter, maschinenlesbarer Steuern und Adressdaten. Die Best Practices für Vendor Master Data Management konzentrieren sich auf die Kontrolle von Änderungen in zahlungsrelevanten Feldern und die Dokumentation, wer jedes Attribut wann verifiziert hat.
Warum Vendor Data zum Payment-Security-Problem wurde
Die Association for Financial Professionals befragte im Januar 2026 465 US-Treasury-Praktiker. In ihren Organisationen erlebten 76% versuchte oder tatsächliche Zahlungsbetrügereien im Jahr 2025, und 74% wurden von Business Email Compromise getroffen. Nur 17% nutzen AI gegen Zahlungsbetrug.
Business Email Compromise endet meist im Vendor Master. Der Angreifer gibt sich als bekannter Lieferant aus und sendet ein Schreiben über ein „neues Bankkonto". Jemand in der Kreditorenverwaltung aktualisiert die IBAN. Das ERP überweist dann eine korrekte Rechnung auf das falsche Konto. Es sind weder ein doppelter Datensatz noch ein gefälschter Vendor beteiligt. Jede nachgelagerte Kontrolle sieht einen legitimen Lieferanten mit einer legitimen Rechnung.
Schecks bleiben die am häufigsten angegriffene Zahlungsmethode, genannt von 58% der Befragten in derselben Umfrage. Und 68% der Organisationen, die Schecks weiterhin nutzen möchten, nennen Lieferantenanforderungen als Grund. Das Zahlungsmethoden-Feld im Lieferantendatensatz trägt also auch Betrugsrisiko und benötigt die gleiche Änderungskontrolle wie das Bankkonto.
Die meisten Vendor-Zahlungsbetrügereien im Jahr 2026 benötigen keinen gefälschten Vendor. Sie benötigen ein bearbeitetes Bankfeld auf einem echten.
Verification of Payee macht den Firmennamen zu einer Kontrolle
Gemäß der EU-Instant-Payments-Regulation müssen Zahlungsdienstleister im Euroraum ab 9. Oktober 2025 Verification of Payee (VoP) anbieten. Das EPC-Regelwerk für das VoP-Schema ist am 5. Oktober 2025 in Kraft getreten. Die Prüfung gilt für reguläre SEPA-Überweisungen und Instant Payments gleichermaßen.
Die Bank des Zahlers sendet Name und IBAN des Zahlungsempfängers an die Bank des Empfängers. Die Antwort kommt als Übereinstimmung, nahe Übereinstimmung, keine Übereinstimmung oder Prüfung nicht möglich zurück. Bei naher Übereinstimmung sieht der Zahler den Namen, den die empfangende Bank tatsächlich führt.
Geschäftskunden, die Sammelzahlungsdateien versenden, können sich von VoP abmelden. Viele Treasury-Teams taten das, um Warnungen zu vermeiden, die Zahlungsläufe verlangsamen. Diese Entscheidung verlagert die Prüfung auf Ihre eigenen Daten. Abmeldung bedeutet, Sie vertrauen Ihrem Vendor Master mehr als dem Kontoregister der Bank, was nur sinnvoll ist, wenn der Master das verdient.
Was dies für den Datensatz bedeutet:
Speichern Sie den Firmennamen exakt wie beim Vendor registriert bei seiner Bank in einem eigenen Feld. Handelsnamen, Abkürzungen und der Name, den Ihre Käufer verwenden, gehen in separate Felder. „Müller Stahl GmbH & Co. KG" und „Mueller Steel" können der gleiche Lieferant sein. Nur einer passt zum Konto.
Leiten Sie jede „keine Übereinstimmung" bei einem bestehenden Vendor an den Datensatzverantwortlichen weiter, bevor die Zahlung erfolgt. Das bedeutet entweder, der Vendor hat etwas geändert, oder jemand hat Ihren Datensatz geändert. Beides verdient einen Blick.
Nahe Übereinstimmungen häufen sich, wenn Firmennamen über Jahre hinweg locker erfasst wurden. Einmalige Namensbereinigung kostet weniger als die gleichen Warnungen bei jedem Zahlungslauf zu überprüfen.
Ihr Vendor Master sollte den Namen halten, den die Bank hält. Alles andere ist ein Spitzname.
Bankdetail-Änderungen absichern
Der Änderungsantrag sieht meist routine aus. Ein PDF auf echtem Briefkopf, ein bekannter Kontaktname, eine höfliche Notiz über den Bankwechsel. Angreifer übernehmen oft ein echtes Postfach beim Lieferanten, sodass die E-Mail jeden Absendercheck besteht. Voice Cloning deckt auch das anschließende Telefonat ab. Die AFP-Umfrage schaute sich AI-gestützten Betrug und Deepfakes zum ersten Mal in diesem Jahr an, und Organisationen, die AI gegen Betrug nutzen, berichteten von besserer Deepfake-Erkennung.
Die Kontrolle muss also im Prozess sitzen, weil die Anfrage selbst echt aussieht. Diese Kontrollen halten in der Praxis:
- Bankänderungen nur über einen Kanal akzeptieren, z. B. ein authentifiziertes Vendor-Portal oder ein unterzeichnetes Formular. E-Mail kann den Prozess auslösen, aber nie abschließen.
- Auf eine Nummer zurückrufen, die bereits im Master-Datensatz gespeichert ist. Verwenden Sie nie die Nummer oder den Kontakt, der in der Änderungsanfrage benannt ist.
- Aufgaben trennen. Die Person, die eine Bankänderung eingibt, kann sie nicht genehmigen und auch nicht die erste Zahlung auf das neue Konto freigeben.
- Die erste Zahlung auf ein geändertes Konto zur Überprüfung einbehalten oder eine Abkühlungsfrist von einigen Tagen einführen, bevor das neue Konto zahlbar wird.
- Den bisher bekannten Vendor-Kontakt benachrichtigen, dass eine Änderung vorgenommen wurde. Wenn der Vendor sie nicht angefordert hat, erfahren Sie es auf diese Weise oft.
Die Callback-Nummer muss aus Ihrem Master-Datensatz kommen. Eine Nummer aus der Änderungsanfrage bestätigt nur den Angreifer.
Wenden Sie denselben Workflow auf jedes Feld an, das Geld oder Informationen umleitet. Das umfasst die Remittieradresse, die Zahlungsmethode, die E-Mail-Adresse für Zahlungsmitteilungen und die Vendor-Kontakt-E-Mail. Angreifer ändern zuerst die Remittierungs-E-Mail, damit der echte Vendor nie Zahlungsbestätigungen sieht.
Halten Sie Bankkonten als separate Unterdatensätze mit Gültig-ab- und Gültig-bis-Daten. Überschreiben Sie nie die alte IBAN. Wenn eine Zahlung schiefgeht, müssen Sie sehen, welches Konto an welchem Tag aktiv war und wer es aktiviert hat.
Einige Banken machen VoP-Prüfungen Geschäftskunden über APIs verfügbar. Wo das existiert, führen Sie die Prüfung durch, wenn die neue IBAN in den Datensatz eintritt, bevor eine Zahlung davon abhängt. Eine Nichtübereinstimmung zu diesem Zeitpunkt kostet ein Telefonat. Eine Nichtübereinstimmung, die während eines Zahlungslaufs entdeckt wird, verzögert einen Batch.
Es gibt einen Kompromiss. Strikte Änderungskontrollen verlangsamen legitime Änderungen, und Vendors mit echter Bankenmigration werden frustriert. Eine dokumentierte Bearbeitungszeit, z. B. zwei Geschäftstage, hält Beschaffung davon ab, Workarounds zu erfinden.
Vendor-Datensätze für E-Invoicing vorbereiten
Die EU verabschiedete das VAT in the Digital Age (ViDA) Paket am 11. März 2025. Digitale Meldepflichten für grenzüberschreitende B2B-Transaktionen beginnen am 1. Juli 2030, und Mitgliedstaaten können bereits verbindliches inländisches E-Invoicing unter bestimmten Bedingungen einführen. Mehrere Länder nutzen diese Option, jedes mit seiner eigenen Plattform und seinem eigenen Zeitplan.
E-Rechnungen kommen als strukturierte Daten an, und Maschinen gleichen sie gegen den Vendor Master ab. Eine Nichtübereinstimmung zwischen der Verkäufer-MwSt-ID auf der Rechnung und der im Datensatz blockiert die Rechnung in einem automatisierten Ablauf. Das ist nützlich, weil eine Rechnung mit einer unbekannten MwSt-ID von einem bekannten Vendor auch ein Betrugssignal ist.
Praktische Änderungen am Datenmodell:
Speichern Sie Identifikatoren als typisierte Liste, mit einem Schema und einem Wert pro Eintrag. Ein generisches „Steuernummern"-Feld bricht, sobald ein Vendor eine MwSt-ID, eine nationale Handelsregisternummer und eine Peppol-Teilnehmer-ID hat. Validieren Sie EU-MwSt-IDs gegen VIES bei Eingabe und turnusgemäß.
Verwenden Sie strukturierte Adressen mit separaten Feldern für Straße, Postleitzahl, Stadt und einen ISO-Ländercode. Freitext-Adressblöcke scheitern bei automatisierter Validierung.
Erfassen Sie den E-Invoicing-Kanal pro Vendor: Peppol-Endpunkt, nationale Plattform oder Legacy-PDF. AP-Teams im Jahr 2026 laufen gemischte Kanäle, und der Vendor-Datensatz ist der Ort, der sagt, welcher zutrifft.
Dokumentieren Sie, wer was und wann verifiziert hat
Ein Vendor-Datensatz speichert meist Werte. Er speichert selten, wie diese Werte bestätigt wurden. Diese Lücke spielt eine Rolle bei Audits, Betrugsermittlungen und VoP-Streitigkeiten, weil „die IBAN ist im System" nichts darüber beweist, ob jemand sie überprüft hat.
Speichern Sie Herkunft für jedes kritische Attribut: die Quelle, die Verifizierungsmethode, das Datum und die Person oder den Service, der es verifiziert hat. Diese Attribute benötigen es am meisten:
- Firmenname und Handelsregisternummer, verifiziert gegen ein Handelsregister.
- Steuerkennzeichen, jeweils mit seinem Schema und letztem Validierungsdatum.
- Bankkonten, mit Währung, Gültigkeitsdaten, dem Callback-Datensatz und dem VoP-Ergebnis falls verfügbar.
- Remittierungs- und Kontakt-E-Mail-Adressen, mit dem Datum der letzten Bestätigung durch den Vendor.
- Sanktions- und Eigentumsscreening-Ergebnisse, mit Listenversion und Screening-Datum.
Mit diesem Setup kann ein Datenverantwortlicher nach „Bankkonten nicht verifiziert seit 12 Monaten" filtern und eine Liste abarbeiten. Ohne es bedeutet Re-Verifizierung, alles erneut zu prüfen.
Screening nach risikobasiertem Zeitplan durchführen
Sanktionslisten ändern sich wöchentlich. Vendors werden akquiriert, wechseln Eigentümer und verschieben registrierte Sitze. Ein Vendor, der bei der Onboarding 2022 screening-frei war, sagt wenig über 2026.
Priorisieren Sie Vendors nach Ausgaben, Länderrisiko und Zahlungsmethode. Strategische und hochriskante Vendors werden kontinuierlich oder monatlich gescreent. Der lange Schwanz kann einen jährlichen Zyklus laufen. Ereignisse sollten unabhängig von Priorisierung eine sofortige Überprüfung auslösen: eine Firmennamenänderung, ein neues registriertes Land oder ein Bankkonto in einem anderen Land als dem registrierten.
Dieses letzte Signal benötigt Urteilskraft. Factoring-Vereinbarungen, Shared Service Center und Konzern-Treasury-Setups erzeugen legitime Länderunkohärenzen. Markieren Sie sie zur Überprüfung, und dokumentieren Sie den Grund, wenn ein Datenverantwortlicher einen genehmigt, damit die gleiche Frage nicht alle Quartale zurückkommt.
Blockieren Sie inaktive Vendors von Zahlungen nach einer festen Periode ohne Aktivität, oft 12 oder 18 Monate. Reaktivierung durchläuft den Onboarding-Workflow erneut, einschließlich Bankverifizierung. Ein inaktiver Datensatz mit gültigen Bankdetails ist ein leichtes Ziel, weil niemand ihn überwacht.
Geben Sie AI und Automation saubere Eingaben
AP-Automation und AI-Agenten behandeln den Vendor Master als Wahrheit. Ein Agent, der Rechnungen automatisch abgleicht, bezahlt einen manipulierten Datensatz schneller als ein Sachbearbeiter würde. Die 17% der Organisationen, die bereits AI gegen Betrug nutzen, sind eine Minderheit, aber Rechnungsverarbeitungsautomation ist viel verbreiteter als Betrugsbekämpfung.
Zwei Regeln helfen. Geben Sie automatisierten Prozessen nur Zugriff auf verifizierte Attribute, und leiten Sie alles Unverifizierte an eine Person weiter. Nutzen Sie AI wo sie Muster liest: Duplikatvorschläge, ungewöhnliche Änderungssequenzen, neue IBAN gefolgt von Remittierungs-E-Mail-Änderung innerhalb einer Woche. Halten Sie Merge und Genehmigungsentscheidungen bei Datenverantwortlichen.
Erwarten Sie zu Beginn falsch-positive Ergebnisse. Stimmen Sie Schwellwerte auf echte Änderungsverlauf ab, bevor Sie die manuelle Überprüfung abschalten.
Was wir in Projekten sehen
Unsere Kunden kommen zu uns mit Vendor-Daten, die über zwei oder drei ERPs und ein Beschaffungstool verteilt sind. Ein typischer Fall ist ein Hersteller nach einer Akquisition. Jedes ERP hält seine eigene Kopie gemeinsamer Lieferanten, und Bankänderungen werden direkt in welchem System auch immer die Anfrage erreichte eingegeben. Niemand kann sagen, welche Änderung von wem genehmigt wurde, und Auditors fragen genau danach.
In Projekten, die wir mit AtroCore implementiert haben, war der erste Schritt, den Bearbeitungspunkt aus den ERPs zu verschieben. Vendors und ihre Bankkonten leben in einem konfigurierbaren Datenmodell, wobei Bankkonten verwandte Datensätze mit Gültigkeitsdaten und Verifizierungsfeldern sind. Änderungen landen in einem Staging-Bereich, ein Workflow erfordert einen zweiten Genehmiger, und der Feldverlauf zeigt den alten Wert, neuen Wert und Genehmiger. Die ERPs erhalten genehmigte Daten über die REST-API und akzeptieren keine direkten Änderungen an zahlungsrelevanten Feldern mehr. Das Ergebnis war ein Ort zum Audieren, anstatt drei Systeme nach einem Incident zu reconcilieren.
Die Software war die kleinere Aufgabe. Sich darauf zu einigen, wer Bankänderungen besitzt und Beschaffung dazu zu bringen, die Bearbeitung von Vendors im ERP zu stoppen, dauerte länger.
Metriken, die zeigen, ob es funktioniert
Verfolgen Sie eine kurze Liste von Zahlen monatlich und zeigen Sie sie der Finanzleitung:
- Anteil aktiver Vendors mit einem Bankkonto, das in den letzten 12 Monaten verifiziert wurde.
- Bankänderungen, die ohne angemeldetem Callback abgeschlossen wurden. Das Ziel ist Null.
- VoP-Nichtübereinstimmungs- und Nahübereinstimmungsraten pro Zahlungslauf.
- Inaktive Vendors, die noch zahlbar sind.
- Kandidaten für Duplikate pro 100 neue Vendor-Anfragen gekennzeichnet.
- Tage von Vendor-Anfrage bis zahlungsbereit.
Das letzte ist wichtiger, als es aussieht. Wenn Onboarding drei Wochen dauert, beginnen Käufer, bestehende Vendor-Datensätze für neue Lieferanten zu verwenden, und so verfällt ein sauberer Master.