Das muss man wissen: Strukturierten Adressen bei SEPA und Auslandszahlungen

Strukturierte Adresse: Warum Ort und Land jetzt eigene Felder brauchen

Eine strukturierte Adresse im Zahlungsverkehr bedeutet, dass die einzelnen Bestandteile einer Anschrift getrennt gespeichert und übertragen werden. Straße, Hausnummer, Postleitzahl, Ort und Land stehen also nicht mehr nur gemeinsam als Freitext in einer Adresszeile. Ab dem 15. November 2026 dürfen Zahlungsaufträge im SEPA-Zahlungsverkehr und im Auslandszahlungsverkehr nur noch strukturierte oder hybride Anschriften enthalten. Die wichtigste Mindestanforderung ist dabei einfach: Ort und Land müssen in den dafür vorgesehenen Feldern stehen.

Der Aufwand entsteht allerdings weniger durch diese neue Regel. Das eigentliche Problem ist, dass viele Unternehmen ihre Adressen seit Jahren oder Jahrzehnten anders gespeichert haben. In vielen Systemen stehen Ort, Straße, Hausnummer und manchmal sogar das Land gemeinsam in einem Freitextfeld.

Was eine strukturierte Adresse von einer unstrukturierten unterscheidet

ISO 20022 verwendet für Anschriften den Baustein PostalAddress24. Er enthält zahlreiche einzelne Felder für verschiedene Bestandteile einer Adresse. In der Praxis haben sich daraus drei Varianten entwickelt: unstrukturierte, strukturierte und hybride Adressen.

Bei einer unstrukturierten Adresse steht die komplette Anschrift in freien Adresszeilen. Im XML werden dafür AdrLine-Elemente verwendet. Eine Adresse wie „Calle Mayor 14, 3º B“ und „08001 Barcelona, Spanien“ ist für einen Menschen problemlos verständlich. Für ein System ist sie aber zunächst nur eine Zeichenkette. Genau diese vollständig unstrukturierte Variante wird nach dem Stichtag nicht mehr akzeptiert.

Bei einer strukturierten Adresse erhält jeder Bestandteil ein eigenes XML-Feld. Die Straße steht zum Beispiel in StrtNm, die Hausnummer in BldgNb, die Postleitzahl in PstCd, der Ort in TwnNm und das Land in Ctry. Aus einer einzigen Adresszeile werden damit mehrere klar definierte Datenfelder. Das Land wird dabei nicht ausgeschrieben, sondern als zweistelliger Ländercode übertragen, bei Spanien zum Beispiel als ES.

Die hybride Adresse liegt zwischen diesen beiden Varianten. Freie Adresszeilen dürfen weiterhin verwendet werden, aber Ort und Land müssen zusätzlich in den dafür vorgesehenen Feldern stehen. Wer eine Adresse also nicht vollständig in Straße, Hausnummer und weitere Bestandteile zerlegen kann, darf einen Teil weiterhin als Freitext übermitteln. Wichtig ist nur, dass zum Beispiel Barcelona zusätzlich in TwnNm und ES in Ctry steht.

Dabei gibt es eine weitere Besonderheit: Die hybride Variante wird nicht von jeder Schema-Ausprägung unterstützt. In der deutschen Variante GBIC_4 war nur die vollständig strukturierte Adresse vorgesehen. Erst GBIC_5 erlaubt seit November 2025 auch hybride Anschriften. Dadurch können zwei Dateien dieselbe pain-Version verwenden und sich trotzdem unterscheiden. Eine Datei kann technisch korrekt gegen GBIC_5 geprüft worden sein und bei einer Bank trotzdem scheitern, wenn diese GBIC_4 erwartet.

Warum gerade Ort und Land wichtig sind

Auf den ersten Blick wirkt es ungewöhnlich, dass ausgerechnet Ort und Land verpflichtend strukturiert übertragen werden müssen. Der Grund liegt vor allem in Prüfprozessen rund um Sanktionen, Embargos und die eindeutige geografische Zuordnung einer Zahlung. Ort und Land liefern dafür die wichtigsten Grundinformationen.

Die übrigen Bestandteile einer Adresse sind für diesen Zweck weniger wichtig. Eine Postleitzahl wird empfohlen, wenn das jeweilige Land ein entsprechendes System verwendet, sie ist aber nicht grundsätzlich verpflichtend. Auch die Straße muss nicht in jedem Fall strukturiert vorliegen.

Für Migrationsprojekte ist das eine wichtige Vereinfachung. Unternehmen müssen nicht sofort sämtliche Adressen perfekt in fünf oder mehr Einzelbestandteile zerlegen. In vielen Fällen reicht es zunächst, Ort und Land zuverlässig aus den vorhandenen Daten zu ermitteln und in die richtigen Felder zu schreiben.

Für wen die neue Adressregel gilt

Bei diesem Thema lohnt sich ein genauer Blick, weil Banken die Anforderungen teilweise unterschiedlich erklären und umsetzen. Die europäische Leitlinie EPC153-22 bezieht sich vor allem auf zwei Parteien: den Zahler, also den Debtor, und den Zahlungsempfänger, den Creditor.

Andere Rollen wie eine abweichende zahlende Partei oder ein abweichender Begünstigter werden dort nicht ausdrücklich in gleicher Weise behandelt. Trotzdem können Banken auch für diese Parteien strukturierte Angaben verlangen. Einige Institute erwarten beispielsweise schon heute bei einem abweichenden Zahler oder Begünstigten mindestens Ort und Land in den vorgesehenen Feldern.

Für Unternehmen ist deshalb nicht nur der allgemeine Standard wichtig. Entscheidend ist am Ende auch, was die eigene Bank technisch prüft und akzeptiert. Der Standard beschreibt die gemeinsame Grundlage, einzelne Banken können darüber hinaus zusätzliche Anforderungen stellen.

Bei Banken und anderen beteiligten Instituten gibt es dagegen eine praktische Vereinfachung. Wenn ein BIC angegeben wird, muss die Adresse des Instituts häufig nicht zusätzlich geprüft werden. Wer Agenten und Empfängerbanken eindeutig über den BIC identifiziert, kann damit viele unnötige Adressprobleme vermeiden.

Müssen Unternehmen überhaupt jede Adresse umstellen?

Eine der wichtigsten Fragen lautet deshalb nicht: Wie strukturieren wir alle vorhandenen Adressen? Die bessere Frage ist oft: Warum schicken wir diese Adresse überhaupt mit?

Bei vielen SEPA-Überweisungen und SEPA-Lastschriften innerhalb des Europäischen Wirtschaftsraums ist die Anschrift des Zahlungsempfängers nicht verpflichtend. Für die Zahlung reichen in diesen Fällen grundsätzlich andere Angaben wie IBAN und Name. Trotzdem übertragen viele Systeme zusätzlich eine Adresse, weil sie im Stammdatensatz vorhanden ist und automatisch in die Zahlungsdatei übernommen wird.

Wenn diese Adresse fachlich nicht benötigt wird, kann es sinnvoll sein, sie gar nicht mehr zu übertragen. Dann entsteht für diese Zahlung auch kein Problem mit der neuen Adressstruktur. Die Regel greift nur dann, wenn eine Adresse tatsächlich mitgeliefert wird.

Diese Möglichkeit gilt allerdings nicht überall. Sobald ein Konto oder ein beteiligtes Institut außerhalb von EU und EWR liegt, können zusätzliche Adressangaben verpflichtend werden. Das betrifft zum Beispiel Zahlungen in die Schweiz oder nach Großbritannien.

Auch im Auslandszahlungsverkehr lässt sich die Adresse nicht einfach weglassen. Im deutschen EBICS-Standard sind Ort und Land des Empfängers bei pain.001.001.09 unter der Auftragsart AXZ verpflichtende Angaben. Wer heute noch DTAZV nutzt und auf das neue Format wechselt, muss sich deshalb mit strukturierten Adressdaten beschäftigen.

Zusätzlich gibt es Fälle, in denen eine Adresse fachlich benötigt wird. Manche Empfängerbanken außerhalb Europas nutzen sie zur Zuordnung eines Kontos oder für regulatorische Prüfungen. Auch länderspezifische Meldepflichten können eine Rolle spielen. Das Weglassen einer Adresse sollte deshalb immer bewusst entschieden und nicht nur als technische Abkürzung genutzt werden.

Für Unternehmen mit reinem Zahlungsverkehr innerhalb Deutschlands und des EWR kann das Abschalten unnötiger Adressfelder trotzdem eine sehr einfache Lösung sein. Bei einer internationalen Lieferantenbasis wird das dagegen meist nicht ausreichen. Dort bleibt die Qualität der Stammdaten ein zentraler Teil des Projekts.

Welche Felder neben der Adresse Probleme machen können

Die neue Adressstruktur bekommt viel Aufmerksamkeit, aber der Wechsel auf die neue Formatversion bringt noch weitere Änderungen mit. Gerade bei selbst entwickelten Schnittstellen können kleine technische Unterschiede dazu führen, dass eine Datei plötzlich nicht mehr gültig ist.

Ein Beispiel ist der Ländercode. Das Feld Ctry erwartet einen zweistelligen Code nach ISO 3166-1 alpha-2. Für Deutschland muss also DE übertragen werden, nicht „Deutschland“, GER oder DEU. Für Großbritannien lautet der Code GB und nicht UK. Das klingt einfach, wird aber zum Problem, wenn ein ERP-System Länder bisher als Klartext oder mit dreistelligen Codes speichert.

Auch einige XML-Feldnamen haben sich geändert. Das bisherige Element BIC heißt jetzt BICFI, aus BICorBEI wurde AnyBIC. Fachlich ändert sich dadurch wenig, aber bestehende Mappings müssen angepasst werden. Andernfalls kann ein Feld leer bleiben, obwohl die Information im Vorsystem vorhanden ist.

Eine weitere Änderung betrifft das Ausführungsdatum ReqdExctnDt. Dieses Element kann jetzt je nach Anwendung ein Datum oder einen Zeitstempel enthalten. Technische Schnittstellen, die weiterhin von der bisherigen einfachen Struktur ausgehen, können dadurch ungültiges XML erzeugen.

Auch bei hybriden Adressen sollte darauf geachtet werden, Informationen nicht unnötig doppelt zu übertragen. Wenn der Ort bereits im strukturierten Feld TwnNm steht, sollte er nicht zusätzlich nochmals als Bestandteil einer freien Adresszeile mitgegeben werden. Strukturierte Daten haben Vorrang vor Freitext.

Was mit den Adressdaten auf dem weiteren Zahlungsweg passiert

Ein weiterer Punkt wird in vielen Migrationsprojekten übersehen: Selbst wenn ein Unternehmen seine Zahlungsdatei sauber nach ISO 20022 erstellt, heißt das nicht automatisch, dass alle Informationen bis zum Ende der Zahlung unverändert erhalten bleiben.

Im internationalen Zahlungsverkehr unterstützen noch nicht alle beteiligten Zahlungsdienstleister ISO 20022 vollständig. Deshalb kann es vorkommen, dass eine Nachricht unterwegs in ein älteres Format umgewandelt werden muss. Dabei steht teilweise weniger Platz für Namen und Adressinformationen zur Verfügung.

Wenn die vorhandenen Informationen diesen Platz überschreiten, können sie gekürzt werden. Eine solche Kürzung kann mit einem Pluszeichen am Ende der betroffenen Zeile gekennzeichnet werden. Ein Pluszeichen am Ende eines Empfängernamens oder einer Adressangabe ist deshalb nicht automatisch ein Tippfehler. Es kann darauf hinweisen, dass Informationen bei einer Formatumwandlung gekürzt wurden.

Gerade deshalb lohnt es sich, Adressdaten bereits am Anfang der Verarbeitung sauber zu strukturieren. Je klarer die Ausgangsdaten sind, desto geringer ist das Risiko, dass später wichtige Informationen verloren gehen oder falsch interpretiert werden.

Im Banking Connector wird die Adressbelegung je Bankverbindung gegen die dort erwartete Variante geprüft, bevor eine Datei an die Bank übertragen wird.

Zwei Felder, aber viele Jahre Datenpflege

Die neue Regel selbst lässt sich sehr einfach zusammenfassen: Ort und Land gehören in eigene Felder. Technisch ist das in vielen Systemen relativ schnell umgesetzt.

Deutlich schwieriger ist die Frage, woher die richtigen Werte für diese Felder kommen. In vielen Stammdatensystemen stehen sie heute irgendwo innerhalb einer freien Adresszeile, zusammen mit Hausnummern, Gebäudeteilen, Stockwerken oder Ansprechpartnern. Teilweise werden Ländernamen unterschiedlich geschrieben oder verwenden Bezeichnungen, die heute nicht mehr aktuell sind.

Der 15. November 2026 ist deshalb vor allem der technische Termin, an dem das Problem sichtbar wird. Die eigentliche Arbeit beginnt viel früher und liegt in den Stammdaten. Unternehmen müssen nicht nur ihre XML-Dateien anpassen. Sie müssen sicherstellen, dass Ort und Land in ihren vorhandenen Daten zuverlässig erkannt und korrekt übertragen werden können.