ISO 20022 & SAP S/4HANA: Der vollständige Praxisleitfaden für FI-Berater

Spätestens im November 2026 endet die Nutzung vieler heute noch verbreiteter Zahlungsformate. Unternehmen, die weiterhin MT940, DTAZV oder ältere pain-Versionen verwenden, werden ihre Zahlungen nicht mehr einreichen können. Für SAP-FI-Berater bedeutet das: Die Migration auf ISO 20022 ist kein optionales Upgrade – sondern ein verpflichtendes Projekt.

ISO 20022 ist mehr als ein neues Dateiformat – es ist die gemeinsame Sprache der globalen Finanzwelt. Als SAP-FI-Berater bist du direkt betroffen: Die Fristen rücken näher, und in S/4HANA warten konkrete Customizing-Aufgaben auf dich. Dieser Leitfaden erklärt den Standard von Grund auf und zeigt dir Schritt für Schritt, wo und wie du im System ansetzen musst.

1. Was ist ISO 20022?

Der offizielle Name lautet UNIFI – Universal Financial Industry Message Scheme. Entwickelt von der Internationalen Organisation für Normung (ISO) unter dem technischen Komitee ISO TC68, deckt er nicht nur Zahlungen ab, sondern auch Wertpapiere, Devisen und Karten.

Was ISO 20022 von seinen Vorgängern fundamental unterscheidet: Es ist kein proprietäres Bankenformat, sondern ein offener Standard, zu dem jeder beitragen kann. Die Nachrichten werden in XML übertragen – einer Technologie, die heute von jedem modernen ERP-System sauber verarbeitet werden kann.

Die drei zentralen Verbesserungen gegenüber Altformaten

• Reichere Daten: Strukturierte Felder für Verwendungszweck, Adresse und regulatorische Meldedaten – keine 35-Zeichen-Beschränkung mehr
• End-to-End-Tracking: Jede Transaktion erhält eine eindeutige UETR (Unique End-to-End Transaction Reference), die über alle beteiligten Banken hinweg nachverfolgbar ist
• Höhere STP-Quote: Strukturierte Daten ermöglichen mehr Straight-Through-Processing, weniger manuelle Eingriffe und schnellere Buchungsläufe

2. Die Nachrichtentypen: pain & camt

ISO 20022 kennt zwei große Nachrichtenfamilien, die für FI-Berater relevant sind:

• pain (Payment Initiation) – für ausgehende Zahlungsaufträge
• camt (Cash Management) – für eingehende Kontoinformationen

pain-Nachrichten (ausgehend)

camt-Nachrichten (eingehend)

Versionierung verstehen: Die Versionsnummern folgen dem Schema Nachricht.Variante.Version. Version 09 basiert auf dem ISO-Maintenance-Zyklus 2019 und enthält gegenüber Version 03 (ISO 2009) erhebliche strukturelle Unterschiede – kein einfaches Drop-in-Replacement!

Formatmapping auf einen Blick

3. Strukturierte Adressen – die unterschätzte Pflicht

Eines der inhaltlich bedeutendsten Elemente von ISO 20022 ist die Pflicht zur strukturierten Adressübermittlung. Was bisher als Freitext erlaubt war, muss künftig in dedizierte XML-Felder aufgeteilt werden.

Die drei Adresstypen

Strukturiert (bereits jetzt empfohlen) Vollständig in dedizierten Feldern: StrtNm, BldgNb, PstCd, TwnNm, Ctry.

Hybrid (ab November 2025 neue strategische Variante) Kombination aus dedizierten Elementen und bis zu zwei Freitextzeilen. Stadt und Land sind Pflichtfelder.

Unstrukturiert (ab November 2026 verboten) Nur Adresszeilen ohne dedizierte Felder. Nach November 2026 vom Interbanken-Zahlungsverkehr nicht mehr akzeptiert.

⚠️ Pflichtfelder ab November 2026: TwnNm (Stadt) und Ctry (Land) müssen für Auftraggeber, Begünstigten und ggf. Ultimate Debtor als dedizierte Datenelemente enthalten sein. Zahlungen ohne diese Felder werden vom Clearing abgelehnt.

Beispiel: Strukturierte Adresse in pain.001.001.09

<!-- Strukturierte Adresse – pain.001.001.09 -->
<PstlAdr>
  <AdrTp>ADDR</AdrTp>
  <StrtNm>Musterstraße</StrtNm>
  <BldgNb>42</BldgNb>
  <PstCd>80331</PstCd>
  <TwnNm>München</TwnNm>  <!-- PFLICHT ab Nov 2026 -->
  <Ctry>DE</Ctry>          <!-- PFLICHT ab Nov 2026 -->
</PstlAdr>

4. Zeitplan: Fristen für Deutschland & SWIFT

🚨 Kein Puffer! Anders als bei der SEPA-Einführung gibt es diesmal keine verlängerte Parallelphase. Wer am 22. November 2026 noch im Altformat einreicht, dessen Zahlungen werden vom System abgewiesen.

5. ISO 20022 in SAP S/4HANA

Die Migration berührt in S/4HANA vier miteinander verzahnte Bereiche:

1. Ausgehende Zahlungen – DMEEX, Formatbaum pain.001.001.09, FBZP, F110
2. Kontoauszugsverarbeitung – camt.053/052, XSLT-Transformation, GVC → BTC Mapping
3. Stammdaten – Business Partner, strukturierte Adressen, IBAN-Qualität
4. Statusrückmeldung – pain.002.001.10, Bank Communication Management (BCM)

5a – Formatbäume: Von DMEE zu DMEEX

Die DMEE (Data Medium Exchange Engine, Transaktion DMEE) war das bisherige Werkzeug zur Pflege von Zahlungsträger-Formatbäumen. In SAP S/4HANA ab Release OP 1709 wurde sie durch die DMEEX ergänzt.

⚠️ Wichtig: SAP kündigt die Transaktion DMEE in kommenden S/4HANA-Releases ab und setzt allein auf DMEEX. Wer heute noch rein auf DMEE setzt, sollte die Migration einplanen.

DMEE vs. DMEEX im Vergleich:

SAP liefert den vordefinierten Formatbaum CGI_CT_V9 (via SAP Note 2784858) als Vorlage für pain.001.001.09. Für Auslandszahlungen (ehemals DTAZV) dient ein modifizierter CGI-Formatbaum als Basis für die neue AXZ-Auftragsart.

5b – Zahlungsverkehr-Customizing: FBZP & F110

Der Kern des Customizings liegt in der Transaktion FBZP:

ℹ️ BAdI-Pflege nicht vergessen: Falls am bisherigen Formatbaum ein kundeneigenes BAdI gepflegt war, wird dieses mit dem neuen Formatbaum nicht automatisch angesprungen. Das neue BAdI des Formats CGI_XML_CT_V9 muss neu befüllt werden.

5c – Elektronischer Kontoauszug: camt statt MT940

Der wesentlichste inhaltliche Unterschied: Der dreistellige GVC-Code (z. B. 051 für Überweisung) wird durch den alphabetischen ISO Bank Transaction Code (BTC) ersetzt. Alle Buchungsregeln, die auf GVC-Codes aufgebaut sind, müssen angepasst werden.

Technisch erfolgt die Verarbeitung über XSLT-Transformationen:

⚠️ DK vs. CGI: SAPs Standard-XSLT-Transformation basiert auf CGI. Die meisten deutschen Banken liefern jedoch im DK-Standard. An bestimmten Stellen weichen die XML-Tags ab – unbedingt mit einer echten Bankdatei testen.

5d – Stammdaten: Business Partner

✅ Empfehlung: Starte jetzt eine Massenauswertung aller aktiven Kreditoren- und Debitorenstammdaten auf fehlende Adressfelder. Erst nach vollständiger Bereinigung den neuen Formatbaum aktivieren.

5e – Statusrückmeldung: pain.002.001.10

Wer pain.001.001.09-Zahlungen sendet, erhält pain.002.001.10 als Rückmeldung. Diese neue Version liefert alle Transaktionsreferenzen zurück, überträgt aber nicht mehr alle Textfelder (Verwendungszweck, Adressfelder). Das kann bestehende Matching-Logiken beeinflussen und sollte im BCM getestet werden.

6. Customizing-Fahrplan: Schritt für Schritt

Schritt 1 – System-Analyse & SAP-Hinweise einspielen

• SAP Note 2784858 einspielen → liefert Formatbaum CGI_CT_V9 für pain.001.001.09
• SAP Note 2881354 einspielen → XSLT-Transformation für camt.053.001.08
• SAP Note 2253571 prüfen → Grundfunktionalitäten ISO 20022
• Systemrelease prüfen – ist DMEEX verfügbar?
• Hausbank-Anforderungen klären: DK-Standard oder CGI? Welche Formatversion?

Schritt 2 – Formatbaum anlegen / anpassen (DMEEX)

• DMEEX aufrufen → Formatbaum CGI_XML_CT_V9 als Vorlage kopieren
• Kundeneigene Erweiterungen aus dem alten Baum (DMEE) übertragen
• Neues BAdI für CGI_XML_CT_V9 befüllen, falls bisher ein kundeneigenes BAdI genutzt wurde
• Für Auslandszahlungen: Separaten Formatbaum für Auftragsart AXZ erstellen
• Deaktivierte Knoten bewusst prüfen

Schritt 3 – Zahlungsprogramm anpassen (FBZP)

• FBZP → Zahlwege im Buchungskreis: Formatbaum CGI_XML_CT_V9 hinterlegen
• FBZP → Hausbanken: Auftragsart DTAZV auf AXZ umstellen; IBAN/BIC prüfen
• FBZP → Zahlwege im Land: 35-Zeichen-Beschränkungen prüfen und ggf. lockern
• Begleitzettel-Formular in OBPM1 und FBZP auf aktuellen Stand bringen

Schritt 4 – Kontoauszugsverarbeitung umstellen

• XSLT_TOOL: SAP-Standard-XSLT für camt.053.001.08 prüfen; bei DK-Abweichung kundeneigene Transformation anlegen
• XSLT: Transformation mit echter Bankdatei testen
• Alle Buchungsregeln und Interpretationsalgorithmen auf BTC-Codes umstellen
• Paralleltest mit Bank vereinbaren: camt.053 V08 und MT940 parallel einlesen und vergleichen

Schritt 5 – Stammdaten bereinigen (Business Partner)

• Massenauswertung: Welche BPs haben unvollständige Adressdaten?
• Fehlende Felder über LSMW, BDC oder Migration Cockpit befüllen
• IBAN-Qualität und BIC-Vollständigkeit sicherstellen
• Erst nach Bereinigung den neuen Formatbaum in FBZP aktivieren

Schritt 6 – Testen & Go-Live vorbereiten

• Testzahlungen (pain.001.001.09) erzeugen und an den Bankformatprüfer senden
• pain.002.001.10 im BCM verarbeiten und prüfen
• camt.053 Version 08 einlesen, Buchungen validieren
• Sonderfälle testen: Auslandszahlung (AXZ), SCTInst, Lastschrift (pain.008)
• Rollback-Prozedur dokumentieren

Relevante SAP-Hinweise

7. Typische Fallstricke & wie du sie vermeidest

Formatbaum aktiviert, bevor Stammdaten bereinigt sind Der neue Formatbaum überträgt Adressdaten so, wie sie im BP stehen – also auch unvollständige. Ergebnis: Zahlungen werden abgewiesen, weil TwnNm oder Ctry fehlen. → Immer erst Stammdaten vollständig bereinigen, dann neuen Formatbaum aktivieren.

BAdI aus altem Formatbaum greift nicht mehr Kundeneigene BAdI-Implementierungen, die im alten DMEE-Formatbaum registriert waren, werden beim neuen CGI_XML_CT_V9 nicht automatisch aufgerufen. → BAdI-Implementierung analysieren und im neuen Formatbaum-spezifischen BAdI neu registrieren.

DK-Standard vs. CGI-Standard bei XSLT SAPs XSLT-Transformation ist auf CGI ausgerichtet; deutsche Banken liefern im DK-Standard. Bestimmte XML-Tags weichen ab, was zu Buchungsfehlern führt. → Echte camt.053-Datei der Hausbank besorgen, mit XSLT-Tool testen, kundeneigene Transformation anlegen.

GVC-Code-Mapping in Buchungsregeln vergessen Bestehende Buchungsregeln referenzieren GVC-Codes (z. B. „051"). camt.053 liefert diese nicht mehr – stattdessen BTC-Codes. → Vollständiges GVC-zu-BTC-Mapping anlegen. Die Deutsche Kreditwirtschaft stellt eine Zuordnungsliste bereit.

DTAZV-Auftragsart nicht auf AXZ umgestellt Wer Auslandszahlungen bisher über DTAZV abgewickelt hat, muss die Auftragsart in FBZP auf AXZ umstellen. → In FBZP → Hausbanken die Auftragsart ändern und mit der Hausbank den neuen Prozess abstimmen.

Zu spät mit Banktests gestartet Banken haben begrenzte Testkapazitäten. Wer erst im Q3 2026 beginnt, riskiert die November-Deadline. → Tests mit Hausbanken so früh wie möglich vereinbaren – viele bieten Online-Formatprüfer an.

8. Checkliste für dein Projekt

Phase 1 – Analyse & Vorbereitung

• Aktuell eingesetzte Zahlungsformate inventarisieren (DTAZV? pain.001.001.03? MT101?)
• Systemrelease prüfen – ist DMEEX verfügbar?
• SAP Notes 2784858, 2881354, 2253571 einspielen
• Hausbank-Anforderungen klären: Welche Formatversion? DK oder CGI?
• Kundeneigene DMEE-Anpassungen und BAdIs dokumentieren

Phase 2 – Stammdaten

• Massenauswertung aller Business Partner auf Adresskomplettheit (TwnNm + Ctry)
• Stammdaten bereinigen – LSMW / Migration Cockpit / BAPI
• IBAN-Qualität und BIC-Vollständigkeit prüfen

Phase 3 – Formatbaum & Customizing

• Neuen Formatbaum CGI_XML_CT_V9 in DMEEX anlegen und anpassen
• BAdI des neuen Formatbaums befüllen (falls kundeneigenes BAdI vorhanden)
• FBZP: Formatbaum den Zahlwegen zuordnen
• FBZP: Hausbank-Auftragsart DTAZV → AXZ umstellen
• XSLT-Transformation für camt.053 Version 08 anlegen / anpassen
• GVC → BTC-Mapping in Buchungsregeln umstellen
• Begleitzettel-Formular prüfen (OBPM1 + FBZP)

Phase 4 – Test & Go-Live

• Testzahlungen (pain.001.001.09) erzeugen und an Bankformatprüfer senden
• pain.002.001.10 im BCM verarbeiten und prüfen
• camt.053 Version 08 einlesen, Buchungen validieren
• Sonderfälle testen: Auslandszahlung, SCTInst, Lastschrift pain.008
• Rollback-Prozedur dokumentiert und getestet
• Key-User-Schulung durchgeführt

Fazit

ISO 20022 ist kein reines Compliance-Projekt – es ist eine Modernisierung der gesamten Zahlungsinfrastruktur. Wer es strukturiert angeht, gewinnt sauberere Daten, höhere Automatisierung und deutlich mehr Transparenz im Zahlungsverkehr. Die kritischen Fristen sind gesetzt, die Werkzeuge in S/4HANA vorhanden. Jetzt ist der richtige Zeitpunkt zum Handeln.

Kurz zusammengefasst:

Du möchtest dein ISO-20022-Projekt nicht alleine angehen?

Ich unterstütze dich gerne – ob als Sparringspartner, bei der konkreten Umsetzung im System oder mit gezielten Schulungen für dein Team. Von der Analyse bis zum Go-Live.

Jetzt Zusammenarbeit anfragen →