Warum Banken fehlerfreie Dateien trotzdem ablehnen

pain.001 validieren: Warum eine fehlerfreie Datei trotzdem abgewiesen wird

Eine Zahlungsdatei wird auf dem Weg zur Ausführung mehrfach geprüft. Die erste Prüfung können Unternehmen selbst durchführen: die XSD-Validierung gegen das Schema der Deutschen Kreditwirtschaft. Dabei wird geprüft, ob die Datei technisch korrekt aufgebaut ist. Dazu gehören zum Beispiel die Reihenfolge der XML-Elemente, Pflichtfelder, Datentypen und Feldlängen.

Was diese Prüfung nicht beantwortet, ist die wichtigere Frage: Ist der Inhalt der Datei auch fachlich korrekt? Die XSD erkennt nicht, ob eine Postleitzahl zum Land passt, ob die gewählte Adressvariante von der Bank akzeptiert wird oder ob die Zahlung später im Clearing abgewiesen wird. Deshalb bedeutet „Das Schema meldet keinen Fehler“ nur, dass die Datei technisch korrekt aufgebaut ist. Es bedeutet nicht, dass die Zahlung erfolgreich ausgeführt wird.

Dieser Beitrag zeigt deshalb den praktischen Teil der Formatumstellung im November 2026. Welche Prüfebenen gibt es, welche Testfälle sollten Unternehmen vorbereiten und an welchen Stellen scheitern Zahlungsdateien in der Praxis? Die Grundlagen zu Termin und Formaten stehen in Post 1 [LINK-POST-PAIN-009], die neuen Adressregeln im Detail in Post 2 [LINK-POST-STRUKTURIERTE-ADRESSE].

Was die XSD-Validierung prüft und was nicht

Die Deutsche Kreditwirtschaft stellt für ihre Zahlungsformate sogenannte Technical Validation Subsets, kurz TVS, bereit. Dabei handelt es sich um eingeschränkte XML-Schemata, die festlegen, welche Elemente und Belegungen für das jeweilige Format zulässig sind. Für den Auslandszahlungsverkehr gibt es zum Beispiel das Schema pain.001.001.09_AXZ_GBIC5. Solche Schema-Dateien lassen sich automatisiert in die eigene Verarbeitung einbauen.

Eine XSD-Validierung erkennt typische technische Fehler zuverlässig. Dazu gehören fehlende Pflichtelemente, eine falsche Reihenfolge von Elementen, zu lange Werte, falsche Datentypen und unbekannte XML-Elemente. Auch bestimmte ungültige Werte können erkannt werden, wenn das Schema den erlaubten Wertebereich entsprechend einschränkt.

Nicht erkannt werden dagegen viele fachliche Fehler. Ein Ort kann im falschen Feld stehen, eine Postleitzahl kann zum falschen Land gehören oder ein Empfängername kann durch einen Fehler im Stammdatensystem unbrauchbar sein. Auch die Frage, ob eine Bank eine bestimmte Schema- oder Adressvariante akzeptiert, kann eine reine XSD-Prüfung nicht beantworten.

Ein gutes Beispiel ist das Feld PstCd für die Postleitzahl. Steht dort für eine spanische Adresse „E-08001“ statt „08001“, kann die Datei technisch trotzdem gültig sein. Buchstaben sind in Postleitzahlen weltweit grundsätzlich möglich. Ob die Empfängerbank mit diesem konkreten Wert etwas anfangen kann, entscheidet erst ein späteres System.

Vier Prüfebenen bis zur Zahlung

Die erste Prüfebene findet im eigenen Unternehmen statt. Dort wird die Zahlungsdatei gegen das passende XML-Schema geprüft. Diese Prüfung ist schnell, kostenlos und beliebig oft wiederholbar. Sie sollte deshalb nicht nur während eines Migrationsprojekts genutzt werden, sondern dauerhaft Bestandteil jedes Zahllaufs sein.

Die zweite Ebene ist die Formatprüfung durch die Bank. Einige Banken bieten dafür eigene Testmöglichkeiten an, bei denen eine aus dem ERP erzeugte Datei gegen die bankeigene Prüflogik getestet wird. Diese Ebene ist besonders wertvoll, weil hier zum ersten Mal Regeln greifen, die über das allgemeine XML-Schema hinausgehen. Der Nachteil: Nicht jede Bank stellt eine solche Testmöglichkeit bereit.

Eine weitere Möglichkeit ist eine Testumgebung über SWIFT. Über entsprechende Services lassen sich pain.001-Nachrichten mit Test-BICs über FINplus simulieren. Dafür werden allerdings ein SWIFT-Zugang und die entsprechenden Berechtigungen benötigt. Für viele Unternehmen ohne eigene SWIFT-Anbindung ist diese Möglichkeit daher praktisch kaum nutzbar.

Die vierte Ebene ist die echte Einreichung über EBICS. Sie ist der vollständigste Test, weil die Datei tatsächlich durch die Systeme der Bank läuft. Die fachlichen Prüfungen finden dabei oft erst in nachgelagerten Zahlungsverkehrssystemen statt. Eine Rückmeldung kommt beispielsweise über pain.002.001.10 oder über EBICS-Protokolle wie PTK beziehungsweise HAC. Zwischen Einreichung und Fehlermeldung können dadurch durchaus mehrere Stunden liegen.

Auch mit diesen vier Ebenen lässt sich nicht alles testen. Das Verhalten einer Empfängerbank, die Verarbeitung durch Zwischeninstitute oder mögliche Kürzungen von Daten auf dem weiteren Zahlungsweg liegen außerhalb des eigenen Einflusses. Auch eine technisch korrekte Adresse kann fachlich falsch sein. Diese Unsicherheit lässt sich nicht vollständig beseitigen, sondern muss im Testkonzept berücksichtigt werden.

Der gefährlichste Status ist nicht immer die Ablehnung

Viele Unternehmen haben vor allem Sorge davor, dass ein einzelner Fehler dazu führt, dass eine komplette Zahlungsdatei abgewiesen wird. Das kann passieren, ist aber häufig der einfachere Fall. Eine vollständige Ablehnung fällt sofort auf.

Wichtiger sind Statusmeldungen, bei denen eine Datei nur teilweise oder mit Änderungen verarbeitet wird. Der Status RJCT bedeutet, dass ein Auftrag abgewiesen wurde. PART bedeutet dagegen, dass nur ein Teil der enthaltenen Transaktionen abgelehnt wurde. Andere Zahlungen aus derselben Datei können trotzdem ausgeführt werden. ACWC zeigt an, dass ein Auftrag mit Änderungen oder Anpassungen ausführbar ist.

Gerade PART kann teuer werden. Ein Zahllauf mit 1.400 Zahlungen kann im Vorsystem erfolgreich aussehen, obwohl drei einzelne Zahlungen nicht ausgeführt wurden. Wenn niemand die pain.002-Rückmeldung auswertet, fällt das unter Umständen erst Wochen später auf, wenn sich ein Lieferant wegen einer offenen Rechnung meldet.

Deshalb sollte bei der Umstellung im November 2026 nicht nur geklärt werden, wie Zahlungsdateien erstellt und validiert werden. Mindestens genauso wichtig ist die Frage, wer die Rückmeldungen der Banken liest und verarbeitet. Auch ACWC sollte nicht ignoriert werden, denn dieser Status bedeutet, dass die Bank etwas verändert hat, damit eine Zahlung verarbeitet werden konnte. Was genau geändert wurde, steht in der Rückmeldung.

Zehn Testfälle, die sich wirklich lohnen

Beim Testen sollten Unternehmen nicht nur perfekte Beispieldaten verwenden. Wichtiger sind Datensätze, die typische Schwachstellen aus dem eigenen Bestand abbilden. Besonders häufig entstehen Probleme bei Postleitzahlen, Ländercodes, Ortsangaben, Sonderzeichen und langen Freitextfeldern.

Ein klassischer Testfall ist eine Postleitzahl mit führender Null. Spanien und Italien haben beispielsweise Postleitzahlen wie 08001 oder 00185. Werden solche Werte in einer Tabellenkalkulation oder einem numerischen Datenfeld gespeichert, kann aus 08001 schnell 8001 werden. Die XML-Datei kann trotzdem technisch gültig sein, obwohl der Inhalt verändert wurde.

Auch Postleitzahlen mit Buchstaben sollten getestet werden. Beispiele gibt es unter anderem in den Niederlanden, Großbritannien, Kanada und Irland. Ein Datenfeld, das nur Zahlen zulässt, kann diese Werte nicht korrekt speichern. Ein reines Textfeld wiederum akzeptiert zwar alles, erkennt aber keine falschen Eingaben.

Ein weiterer Testfall sind Länder oder Regionen ohne verpflichtend verwendete Postleitzahl. Dabei sollte geprüft werden, was das eigene System macht, wenn kein Wert vorhanden ist. Ein leerer Textwert, ein Bindestrich oder ein Wort wie „keine“ sind keine saubere Lösung. Wenn ein optionales Element keinen Wert hat, sollte es in der Regel gar nicht übertragen werden.

Auch der Ländercode sollte bewusst getestet werden. Das Feld Ctry erwartet einen zweistelligen Code nach ISO 3166-1 alpha-2. Für Deutschland ist das DE und nicht DEU oder „Deutschland“. Für Großbritannien lautet der Code GB und nicht UK. Gerade Systeme aus Logistik oder Versand arbeiten teilweise mit anderen Länderformaten.

Ein besonders wichtiger Testfall ist ein fehlender Ort. Sobald eine Adresse übertragen wird, ist TwnNm eines der entscheidenden Felder. In älteren Stammdatensätzen, bei Postfachadressen oder bei aus Freitext übernommenen Daten kann dieses Feld leer oder falsch belegt sein.

Auch ein Ort im falschen Feld ist typisch. Bei historischen Datenmigrationen kann der Ortsname zum Beispiel im Straßenfeld gelandet sein. Eine XSD-Prüfung erkennt einen solchen Fehler normalerweise nicht, weil beide Felder technisch Text enthalten dürfen.

Sonderzeichen und Umlaute gehören ebenfalls in den Testbestand. Straßennamen mit ß, ø, é oder ç sowie Ortsnamen mit anderen Zeichensätzen zeigen schnell, wie Bank und Vorsystem mit nicht erlaubten Zeichen umgehen. Entscheidend ist dabei nicht nur, ob ein Zeichen akzeptiert wird, sondern auch, was passiert, wenn es nicht akzeptiert wird: Wird es ersetzt, entfernt oder führt es zum Abbruch?

Lange Werte sind ein weiterer wichtiger Fall. Ortsnamen, Firmennamen mit langen Rechtsformzusätzen oder sehr ausführliche Adressangaben können Feldlängen überschreiten. Manche Systeme brechen dann ab, andere schneiden Werte still ab. Beides sollte vor dem produktiven Wechsel bekannt sein.

Bei hybriden Adressen sollte außerdem geprüft werden, ob Ort und Land wirklich in den strukturierten Feldern stehen. Eine Datei mit gefüllter Adresszeile, aber leerem TwnNm und Ctry kann zwar wie eine vollständige Adresse aussehen, erfüllt aber die neue Anforderung nicht.

Schließlich sollte auch eine Dopplung getestet werden. Wenn der Ort bereits in TwnNm steht und zusätzlich noch einmal in einer freien Adresszeile übertragen wird, kann die Datei zwar schemakonform sein, trotzdem aber gegen die erwartete Marktpraxis verstoßen.

Neben diesen konstruierten Testfällen lohnt sich ein Blick in den echten Datenbestand. Besonders aufschlussreich sind häufig der älteste noch aktive Lieferantenstammsatz und der Datensatz mit der längsten Freitextadresse. Solche Fälle zeigen oft schneller als künstliche Testdaten, wo die tatsächlichen Probleme liegen.

Wie Sie testen, wenn jede Bank anders weit ist

Ein einheitlicher Testplan für alle Banken ist in vielen Unternehmen kaum möglich. Manche Institute unterstützen die neuen Formate bereits vollständig, andere befinden sich noch in einer Übergangsphase. Auch die bereitgestellten Testmöglichkeiten unterscheiden sich deutlich.

Deshalb sollte zunächst für jede Bank schriftlich geklärt werden, wann die alte Formatversion tatsächlich abgeschaltet wird und welche Schema-Variante erwartet wird. Für die interne Planung sollte nicht der späteste, sondern der früheste Termin im eigenen Bankenkreis verwendet werden.

Auch die Reihenfolge der Tests sollte bewusst gewählt werden. Sinnvoll ist es, zuerst die Banken zu testen, über die das größte Zahlungsvolumen läuft. Eine kleinere Bank mit einer besonders komfortablen Testplattform ist weniger kritisch als die Hausbank, über die 80 Prozent aller Zahlungen laufen.

Solange alte und neue Formatversionen parallel akzeptiert werden, lohnt sich außerdem ein direkter Vergleich. Derselbe Zahllauf kann einmal im alten und einmal im neuen Format erzeugt werden. Der Vergleich der beiden Dateien macht Mappingfehler häufig schneller sichtbar als eine reine Schema-Prüfung.

Zusätzlich sollte vor dem Stichtag eine klare Fallback-Entscheidung getroffen werden. Wer entscheidet, wenn eine produktive Datei nach der Umstellung nicht durchgeht? Welche alternative Einreichung ist möglich und wer darf sie auslösen? Solche Fragen sollten beantwortet sein, bevor der erste Fehler auftritt.

Im Banking Connector läuft die Prüfung vor der Einreichung je Bankverbindung gegen die dort erwartete Formatversion und Adressvariante. Zusätzlich werden die Statusrückmeldungen ausgewertet.

Eine gültige Datei ist noch keine erfolgreiche Zahlung

Eine Schema-Prüfung beantwortet eine klar begrenzte Frage: Entspricht diese XML-Datei der vereinbarten technischen Struktur? Diese Prüfung ist notwendig und sollte immer durchgeführt werden.

Sie beantwortet aber nicht die entscheidende Frage: Kommt das Geld beim richtigen Empfänger an? Zwischen einer technisch gültigen Datei und einer erfolgreichen Zahlung liegen weitere Prüfungen der Bank, Regeln des Clearings und die Qualität der eigenen Stamm- und Zahlungsdaten.

Ein grüner Haken bei der XSD-Validierung bedeutet deshalb nur, dass die Datei richtig gebaut wurde. Ob sie auch richtig gefüllt ist und am Ende verarbeitet wird, zeigt sich erst auf den nächsten Prüfebenen.