ISO 20022: Was bis November 2026 in SAP-Zahlungsprozessen erledigt sein muss

Mit dem 22. November 2026 endet die Co-Existenzphase der SWIFT-MX-Migration: Ab diesem Stichtag akzeptieren das Eurosystem (TARGET2/T2) und SWIFT für grenzüberschreitende Zahlungen ausschließlich noch ISO 20022. Wer bis dahin noch MT-Nachrichten (MT103, MT202 & Co.) versendet oder hauseigene Schnittstellen auf den alten Formaten betreibt, hat ein Problem. Auch im SEPA-Umfeld werden die nationalen DK-Spezifikationen schrittweise auf die neuen ISO-20022-Versionen gehoben.

Für SAP-Anwender — und insbesondere im Vertragskontokorrent (FI-CA) der Energiewirtschaft, wo täglich SEPA-Lastschriften und -Überweisungen in fünfstelliger Anzahl entstehen — sind das nicht nur kosmetische Änderungen am XML. Dieser Beitrag fasst zusammen, woran ich in laufenden Projekten gerade typischerweise arbeite.

Was wirklich neu ist (jenseits der Formatumstellung)

Die Migration von MT- und alten pain.001/pain.008-Versionen auf die neuen ISO-Releases ist keine reine Strukturanpassung. Drei Punkte unterschätzen die meisten Projekte:

• Strukturierte Adressen statt Freitext. Empfänger- und Auftraggeberadressen müssen in einzelnen XML-Elementen (Straße, Hausnummer, PLZ, Ort, Land) gepflegt sein. Wer bislang in einem AdrLine-Freitextfeld arbeitete, muss seine Stammdaten zerlegen — was in SAP-IS-U-Welten oft Geschäftspartner-Massendatenarbeit bedeutet.
• Strukturierte Verwendungszwecke (Remittance Information). Statt unstrukturiertem Text rückt Strd/RmtInf ins Zentrum: Belegnummer, Buchungsdatum, Steuerbeträge — alles in eigenen Feldern. Das hat direkte Auswirkung auf die Rechnungseingangsprüfung und das automatische Zuordnen offener Posten im FI-CA.
• Erweiterte Zeichenmenge. Das alte SWIFT-Set (lateinische Buchstaben, Ziffern, Sonderzeichen-Subset) wird durch UTF-8 ersetzt. Umlaute werden offiziell, aber das eröffnet auch neue Fehlerquellen bei Konvertierungen zwischen Systemen.

Was im SAP-System konkret anzupassen ist

In Projekten dieser Größe tauchen immer wieder dieselben Baustellen auf. Eine grobe Reihenfolge, in der ich sie üblicherweise abarbeite:

1. Bestandsaufnahme aller ausgehenden Formate: pain.001 (Überweisung), pain.008 (Lastschrift), camt.053 (Kontoauszug), camt.054 (Avis). Welche Versionen werden aktuell erzeugt? Welche werden vom Hausbank-Konverter unterstützt?
2. Datenqualität der Geschäftspartner-Adressen prüfen. Wieviele Adressen sind unzerlegt im Freitextfeld? Wie sieht der Migrationspfad aus — Massenkorrektur per Report oder kontrollierter Stammdaten-Cleanup?
3. Mapping der Verwendungszwecke. Welche Belegarten/Mahn-Texte landen heute im Freitext? Welche Felder bilden wir künftig strukturiert ab?
4. Anpassung der Format-Bausteine in FI-CA (Druck-Workbench / Format-Klassen) sowie der Konverter beim Bank-Service-Provider.
5. Testpaket aufbauen: pro Format (pain.001, pain.008, camt.053, camt.054) mindestens je ein Beispielfall mit Inland, Ausland, Storno, Rücklastschrift, Steuer- und Skontobeleg.

Tests: Validierung ist Pflichtprogramm

Ein häufiges Versäumnis in Migrationsprojekten ist, dass die erzeugten XML-Dateien nur gegen die eigene Bank getestet werden — und die Probleme erst auffallen, wenn ein anderer Empfänger oder Verband sie anders interpretiert.

Externe Validatoren gegen das offizielle ISO-20022-Schema sind dafür Gold wert. Ein praktisches Werkzeug, das ich aktuell in Projekten zur Kontrollvalidierung von SAP-erzeugten XMLs einsetze, ist der ISO 20022 XML Validator: Datei hochladen, Format und Version wählen, sofort Schema-Validierung gegen die aktuellen Releases.

Was sich damit zuverlässig finden lässt — und im Hausbank-Test gerne übersehen wird:

• Pflichtfelder, die in der alten SAP-Konfig optional gesetzt waren
• Reihenfolge von XML-Elementen, die in neueren Schemas strenger geprüft wird
• Längenbegrenzungen (z. B. Max70Text vs. Max140Text)
• Falsche Datums- oder Währungsformate aus Konvertierungen

Wer pro relevanter Belegart einen validierten Referenz-XML als Regressionsbasis ablegt, spart sich später viel Arbeit bei Format-Updates oder Patches.

Tipp für die Zeitplanung

Der 22. November 2026 mag noch weit weg klingen, ist er aber nicht: Erfahrungsgemäß brauchen Geschäftspartner-Datenbereinigung und Lieferantenabstimmung zusammen schnell drei bis sechs Monate. Wer im Sommer 2026 noch keinen produktiven Testlauf mit der eigenen Hausbank gefahren ist, wird es eng.