){kind=logo}
Freitagmorgen, 9 Uhr. Sie laden den wöchentlichen Zahlungslauf hoch: 120 Lieferantenrechnungen, EBICS-Übertragung, Warten auf Bestätigung. Stattdessen kommt eine Sammelablehnung. Drei Adressen ohne strukturierte Felder, ein Empfängername, der nicht zur IBAN passt – und der gesamte Lauf liegt still. Skontofristen ticken, Lieferanten rufen an.
Was bis 2025 ein technisches Randthema war, wird ab November 2026 zur operativen Falle: Drei regulatorische Anforderungen greifen zeitgleich in denselben Datensatz – Ihre Lieferantenstammdaten. Wer sie als getrennte Projekte behandelt, sortiert Adressen und übersieht veraltete Empfängernamen. Wer sie als ein gemeinsames Cleanup angeht, gewinnt sechs Wochen Vorlauf statt sechs Wochen Reparatur. Dieser Artikel zeigt, was sich konkret ändert, wo die typischen Bruchstellen liegen und wie ein realistischer Bereinigungsplan aussieht.
Drei Anforderungen, ein Datensatz
Auf die Frage „Ab wann ISO 20022?" gibt es einen einen gestaffelten Zeitplan:
)
Alle drei Anforderungen greifen auf denselben Bestand zu: Adresse, Format und Empfängername jedes einzelnen Lieferanten. Eine Adressbereinigung allein hilft nicht, wenn der hinterlegte Firmenname seit der Fusion vor zwei Jahren veraltet ist. Umgekehrt nützt ein VoP-konformer Name nichts, wenn die Adresszeile als Freitextblock vorliegt.
Strukturierte Adressen – was technisch wirklich verlangt wird
Der ISO-20022-Standard kennt drei Adressformate, doch nach November 2026 sind nur noch zwei davon zulässig. Ein vollständig strukturierter Datensatz führt Straße, Hausnummer, Postleitzahl, Stadt und Land als jeweils als eigenes XML-Element und ist die zukunftssichere Wahl. Das hybride Format kombiniert die strukturierten Pflichtfelder Stadt und Land mit bis zu zwei Freitextzeilen für die übrige Adresse – weiterhin erlaubt, aber als Übergangslösung gedacht. Der unstrukturierte Eintrag, also die gesamte Adresse als ein einziger Freitextblock, wird ab dem 15.11.2026 abgelehnt.
In typischen ERP-Beständen sind 40 bis 60 Prozent der Lieferantenadressen unstrukturiert oder hybrid, meist als Altlast aus Freitext-Erfassungen früherer Jahre. Die Anforderung gilt für alle in der Zahlungsdatei genannten Parteien, also Auftraggeber und Begünstigten sowie – falls vorhanden – den wirtschaftlich Zahlenden (Ultimate Debtor) und den wirtschaftlich Begünstigten (Ultimate Creditor) bei abweichenden Zahlungsketten.
Bei internationalen Lieferanten lauern zwei zusätzliche Stolperfallen. Länderkürzel müssen exakt ISO 3166 entsprechen (DE, FR, IT – nicht „Deutschland" als Klartext), und Sonderzeichen in Straßennamen oder Ortsbezeichnungen können je nach Bankschnittstelle zu Validierungsfehlern führen. Den genauen Aufbau dokumentiert der EPC-Leitfaden zur Adresse Bereitstellung.
Verification of Payee wenn der Name die Zahlung stoppt
VoP prüft seit Oktober 2025 bei jeder Einzelüberweisung, ob der angegebene Empfängername zum IBAN-Inhaber passt. Das Ergebnis fällt in drei Kategorien: Bei einem „Match" stimmt der Name überein und die Zahlung läuft durch. Ein „Close Match" signalisiert eine geringfügige Abweichung, etwa einen Tippfehler oder eine abgekürzte Rechtsform – die Zahlung wird nicht abgelehnt, der Auftraggeber muss die Ausführung aber aktiv bestätigen. Bei einem „No Match" passt der Name nicht zur IBAN, und die Zahlung wird zur manuellen Prüfung markiert.
Der typische Praxisfall: Ein Lieferant hat nach einer Fusion seinen Namen geändert, in Ihren Stammdaten steht noch der alte. VoP liefert „No Match", die Zahlung hängt. Mitten im laufenden Zahlungslauf muss eine Entscheidung getroffen werden – freigeben oder Stammdaten korrigieren.
Die Haftungslogik ist eindeutig: Die Bank haftet für die technische Korrektheit der Prüfung. Wer jedoch trotz „No Match"-Hinweis freigibt und an den falschen Empfänger überweist, trägt das Risiko selbst. Wichtig ist auch der Blick auf Massenzahlungen: Bei Sammelüberweisungen ist VoP formal optional, doch Banken können sie durchführen – und tun es zunehmend. Wer realistisch plant, geht davon aus, dass jede Zahlung geprüft wird. Die Grundlagen dazu liefern das VoP-Regelwerk des European Payments Council und die EU-Verordnung für Sofortzahlungen.
)
Warum eine Adresse den ganzen Lauf kippt
In vielen ERP-Systemen führt ein einziger ungültiger Datensatz dazu, dass die Bank den gesamten Zahlungslauf zurückweist – nicht nur den fehlerhaften Posten. 120 Rechnungen liegen still, weil drei Adressen Freitext enthalten. Skontofristen verstreichen (üblich sind zwei Prozent auf 14 Tage, ein signifikanter Liquiditätsverlust pro Zyklus), die Lieferantenbeziehung leidet, und der Nachmittag geht für manuelle Korrektur und Wiedereinreichung verloren. Zahlungsverzug wird so vom Einzelfall zum strukturellen Problem.
Drei Vorkehrungen senken dieses Risiko spürbar. Eine automatisierte Pre-Run-Validierung prüft vor jedem Zahlungslauf, ob alle Pflichtfelder strukturiert vorliegen. Ein gestaffelter Rollout mit zunächst zehn Pilotlieferanten reduziert das Risiko, beim ersten Echtlauf gleich den gesamten Bestand zu blockieren. Und eine klare Fallback-Logik im ERP – die fehlerhafte Datensätze aus dem Lauf isoliert, statt den ganzen Stapel abzubrechen – verhindert die Sammelablehnung im Ernstfall. Plattformen, die Lieferantendaten bereits vor der Dateigenerierung validieren, fangen fehlerhafte Einträge ab, bevor sie überhaupt zur Bank gelangen.
Sechs-Wochen-Plan für die Bereinigung
Der Plan ist ERP-unabhängig und funktioniert mit DATEV, SAP, Sage oder vergleichbaren Systemen.
In Woche eins steht die Bestandsaufnahme an: Ein vollständiger ERP-Export aller aktiven Lieferanten zeigt, wie sauber Ihre Datenbasis tatsächlich ist. Jeder Datensatz wandert in eine von drei Kategorien – bereits strukturiert, hybrid oder vollständig unstrukturiert. Bei mittelständischen Unternehmen liegen erfahrungsgemäß 40 bis 60 Prozent in den beiden unteren Gruppen und brauchen Nacharbeit.
Woche zwei gehört dem eigentlichen Adress-Cleanup. Die Freitext-Adressen werden in Einzelfelder gesplittet – bei überschaubaren Beständen manuell, bei mehreren hundert Datensätzen besser per Adressvalidierungstool oder Skript.
In Woche drei folgt der VoP-Risikoabgleich. Hier prüfen Sie, ob die hinterlegten Lieferantennamen noch zu den IBAN-Inhaberdaten der Bank passen. Besonderes Augenmerk verdienen alle Firmen, die in den letzten 24 Monaten übernommen, umfirmiert oder umstrukturiert wurden – genau dort entstehen die typischen „No Match"-Treffer. Den Prozess für DATEV-Nutzer beschreibt der DATEV-Leitfaden zu Verification of Payee.
Woche vier ist meist die aufwendigste: die Umstellung des ERP auf pain.001.001.09. Anders als die Stammdatenpflege betrifft sie nicht einzelne Datensätze, sondern eine zentrale Konfiguration, die oft tief im System verankert ist und intern wie extern abgestimmt werden muss.
In Woche fünf testen Sie das Ergebnis mit der Bank. Prüfen Sie zunächst, ob Ihre EBICS-Verbindung die neuen Formatversionen überhaupt unterstützt, und vereinbaren Sie einen Testlauf mit etwa fünf realen Überweisungen. Im Gespräch mit der Hausbank sollten drei Dinge geklärt werden: welche pain-Versionen die Bank bereits akzeptiert und ab wann ausschließlich die neuen durchgehen, ob eine Testumgebung oder Produktivtests mit Kleinstbeträgen möglich sind, und ob die EBICS-Verbindung selbst noch ein Update braucht.
Woche sechs verankert das Ganze im laufenden Betrieb. Damit die Bereinigung nicht innerhalb weniger Monate wieder verwässert, sollten bei der Neuanlage jedes Lieferanten strukturierte Adressfelder erzwungen werden. IBAN- und Adressänderungen laufen sinnvollerweise über einen mehrstufigen Freigabeworkflow – so wird Stammdatenpflege zur Routine, nicht zur Reparatur.
Weiterführende technische Dokumentation bieten die offizielle ISO 20022 Website und die ISO-20022-Informationen der Deutschen Bank. SWIFT hat die Migration für grenzüberschreitende Zahlungen bereits im November 2025 abgeschlossen, SEPA folgt jetzt demselben Standard.
Wo Spendesk im Bereinigungsprozess ansetzt
Der Sechs Wochen-Plan sind machbar, scheitert aber regelmäßig an der Datenpflege im laufenden Betrieb: Neue Lieferanten werden im Tagesgeschäft angelegt, und der hart erkämpfte Bereinigungsstand verwässert innerhalb weniger Monate wieder.
Spendesk erzwingt bei der Lieferantenanlage strukturierte Adressfelder, prüft IBAN-Änderungen über einen mehrstufigen Freigabeworkflow und generiert SEPA-Zahlungsdateien direkt im neuen ISO-20022-Format. Über die DATEV-Unternehmen-Online-Schnittstelle fließen die bereinigten Daten ohne manuelle Nacherfassung an den Steuerberater. Wie ein durchgängiger Prozess von der Bestellung bis zur Zahlung aussieht, beschreibt der verlinkte Leitfaden.SEPA 2026 ohne Stammdaten-Stress: Sehen Sie, wie Spendesk strukturierte Lieferantendaten, VoP-konforme Empfängernamen und ISO-20022-konforme Zahlungsdateien in einem Prozess bündelt. Demo vereinbaren
Neugierig, wie Spendesk funktioniert?
Testen Sie eine interaktive Demo und erleben Sie Ausgabenkontrolle und Freigaben von Anfang bis Ende.
Kostenlose Tour starten){kind=logo}
)
)
)
)
)