pain.001.001.09 gegenüber .03: was sich konkret ändert

ARLing s. r. o. · 6. September 2026

Ihr Buchhaltungsprogramm oder das Online-Banking hat vielleicht schon „pain.001.001.09" erwähnt, während Sie bisher pain.001.001.03 verwenden. Beide tragen dieselbe Bezeichnung Customer Credit Transfer Initiation nach ISO 20022, die Ziffer nach dem zweiten Punkt ist die Version des Schemas. Was sich zwischen den beiden Versionen in der Datei konkret ändert, und was der Stichtag im November 2026 damit zu tun hat, steht unten.

Die vier konkreten Unterschiede in der XML

Namensraum (xmlns)

Das Wurzelelement <Document> trägt in jeder Version einen eigenen Namensraum. Daran erkennt die verarbeitende Stelle, welche Struktur die Nachricht hat.

.03  xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.03"
.09  xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.09"

BIC heißt in .09 BICFI

Der Bankleitcode von Auftraggeber- oder Empfängerbank steht in .03 im Element <BIC>. In .09 heißt dasselbe Feld <BICFI>. Der Wert und das Format des Codes ändern sich dabei nicht, nur der Elementname.

.03  <FinInstnId><BIC>COBADEFFXXX</BIC></FinInstnId>
.09  <FinInstnId><BICFI>COBADEFFXXX</BICFI></FinInstnId>

Ausführungsdatum ist anders verpackt

In .03 ist ReqdExctnDt ein einfacher Datumstext. In .09 ist dasselbe Feld vom Typ DateAndDateTime2Choice: Der Wert muss noch einmal in <Dt> eingepackt werden, oder in <DtTm>, wenn eine Bank auch die Uhrzeit verlangt. Das ist ein häufiger Grund, warum eine sonst korrekte .09-Datei beim ersten Versuch zurückgewiesen wird: Das Ausführungsdatum steht dann noch als nackter Text direkt im Element statt in der verschachtelten Form.

.03  <ReqdExctnDt>2026-11-20</ReqdExctnDt>
.09  <ReqdExctnDt><Dt>2026-11-20</Dt></ReqdExctnDt>

Adresse: PostalAddress6 gegenüber PostalAddress24

Die Adresse von Auftraggeber und Empfänger ist in .03 vom Typ PostalAddress6, in .09 vom Typ PostalAddress24. Die Reihenfolge der Hauptfelder (StrtNm, BldgNb, PstCd, TwnNm, Ctry) ist in beiden gleich. PostalAddress24 fügt nur zusätzliche, optionale Felder hinzu (zum Beispiel BldgNm, Flr, Room, TwnLctnNm) und begrenzt die Freitextzeilen AdrLine auf zwei. Für eine gewöhnliche Firmenadresse in einer Sammelüberweisung macht das praktisch keinen Unterschied.

Der Stichtag 15. November 2026 betrifft die Adresse, nicht die Version

Hier entsteht der meiste Verwechslung. Der 15. November 2026 stammt aus dem SEPA Credit Transfer Rulebook des European Payments Council (Version 1.1) und betrifft ausschließlich die Postadresse: Ab diesem Datum darf eine in der Zahlung enthaltene Adresse nicht mehr rein als Freitext stehen. Sie muss mindestens Ort (TwnNm) und einen zweibuchstabigen Ländercode (Ctry) in eigenen Feldern tragen, entweder vollständig strukturiert oder in hybrider Form (bis zu zwei Freitextzeilen plus Ort und Land in eigenen Feldern). Die Adresse selbst bleibt in der SEPA-Überweisung optional: Eine Datei ganz ohne Adresse ist von der Regel nicht betroffen.

Zur Nachrichtenversion sagt dieser Stichtag nichts. Sowohl .03 als auch .09 können eine strukturierte oder hybride Adresse tragen, wie oben gezeigt: Der Typ PostalAddress6 aus .03 hat dieselben Kernfelder wie PostalAddress24 aus .09. Trägt Ihre Buchhaltungssoftware Ort und Land bereits heute in getrennten Feldern ein, erfüllen Sie den Stichtag auch ohne Wechsel der Nachrichtenversion. Ob eine Datei diese Felder korrekt und vollständig füllt, lässt sich mit einem XML-Prüfwerkzeug wie unserem oder direkt in der eigenen Buchhaltungssoftware kontrollieren.

Zur Einordnung: Die ursprüngliche Fassung des Regelwerks (Version 1.0, 2025) nannte für dieselbe Regel noch den 22. November 2026. In Version 1.1 wurde das Datum auf den 15. November 2026 korrigiert. Den genauen Grund für die Korrektur nennt unsere Quelle nicht. Ein Teil der Webseiten zum Thema SEPA-Zahlungen zitiert deshalb noch das ältere Datum 22. 11.; gültig ist der 15. 11. 2026.

Wer die Nachrichtenversion tatsächlich abschaltet, entscheidet jede Bank für sich

Das ist eine von der Adresse getrennte Frage: Welche Version Ihre Bank bei einer Sammelüberweisung als Datei überhaupt noch annimmt, bestimmt ausschließlich die Bank. Zwei konkrete Beispiele, die sich zum 6. September 2026 direkt anhand der jeweiligen Bankquelle prüfen ließen:

Deutschland, Genossenschaftsbanken (Atruvia-Netzwerk). Für Banken im Atruvia-Verbund, zu dem unter anderem Volksbanken, Raiffeisenbanken und die GLS Bank gehören, wird der 14. November 2026 als konkretes Datum genannt, ab dem pain.001.001.03 bei Sammelaufträgen nicht mehr angenommen wird. Für Sparkassen wird ebenfalls November 2026 als Umstellungszeitraum genannt, allerdings ohne einen ebenso genauen Tag.

Tschechien, Komerční banka. Die Bank kündigt auf ihrer eigenen Support-Seite und in einem Kundenschreiben geänderte Regeln für die strukturierte Adresse bei SEPA- und Auslandszahlungen an, gültig ab dem 1. November 2026, sowie eine künftige Version 5.0 ihres MultiCash-Clients mit voller Kompatibilität zu pain.001.001.09. Ein konkretes Datum, ab dem pain.001.001.03 nicht mehr angenommen wird, nennt diese Seite nicht.

Für andere Banken in Deutschland, Österreich oder Tschechien haben wir das nicht einzeln geprüft. Wenn Sie sicher wissen wollen, welche Version Ihre Bank beim Sammelauftrag akzeptiert oder ab wann sie eine bestimmte Version verlangt, ist die eigene Banktechnische Dokumentation oder eine direkte Nachfrage bei der Bank der verlässlichste Weg. Der Stichtag 15. November 2026 selbst zwingt Sie dazu nicht: Er verlangt eine strukturierte Adresse, keine bestimmte Nachrichtenversion.

Praktisch für die Buchhaltung

1. Prüfen Sie zuerst, ob Ihre exportierte Datei überhaupt eine Adresse (PstlAdr) enthält. Wenn nicht, betrifft Sie der Stichtag 15. 11. 2026 nicht.
2. Enthält die Datei eine Adresse, prüfen Sie, ob Ort und Land in eigenen Feldern stehen (TwnNm, Ctry), nicht nur als Teil eines Freitexts.
3. Wenn das bereits der Fall ist, müssen Sie wegen dieses Stichtags nicht auf pain.001.001.09 wechseln, unabhängig davon, welche Version Sie aktuell verwenden.
4. Bietet Ihre Software oder Bank einen Export als .09 an, prüfen Sie drei Stellen: den Namensraum am Document-Element, ob der Bankleitcode in <BICFI> statt <BIC> steht, und ob ReqdExctnDt das Datum in <Dt> oder <DtTm> verpackt.
5. Fragen Sie im Zweifel direkt bei Ihrer Bank nach, welche Version sie beim Sammelauftrag aktuell erwartet und ob sich das ändert. Diese Antwort finden Sie zuverlässiger dort als in allgemeinen Artikeln, auch in diesem.

Wer eine eigene Datei gegen diese Punkte prüfen möchte, kann das kostenlos und ohne Hochladen mit dem SEPA pain.001 Doctor tun: Er erkennt die Version der Datei und weist auf eine fehlende Adressstruktur hin.