Im Zahlungsverkehr ist derzeit eine Menge Bewegung 🏃. Werfen wir einmal einen Blick 🧐 in das Reporting und schauen uns dazu ein paar Änderungen an, die in diesem Jahr 📆 noch wirksam werden. So steht neben der Abkündigung der MT940- bzw. MT942-Formate auch der vollständige Wechsel auf die aktuellen CAMT.05x-Versionen an.
Damit verbunden müssen auch in SAP entsprechende Anpassungen 🛠️ durchgeführt werden. Zum einen sind bestehende XSLT-Transformationen 👩💻 aus den „02er“-Versionen gegen die „08er“-Versionen auszutauschen und gründlich zu testen. Zum anderen sind die bisherigen Geschäftsvorfallcodes (GVC) durch die neuen Business Transaction Codes (BTC) zu ersetzen.
Einige Banken 🏦 liefern derzeit zwar noch beide Schlüssel 🔑 parallel mit, was die Umstellung zunächst optional erscheinen lässt. Dennoch ist eine frühzeitige Migration ratsam – auch weil GVCs und BTCs inhaltlich nicht immer 1:1 abbildbar sind. Das Mapping ist also mit Sorgfalt durchzuführen.
In SAP selbst gibt es aktuell kein vollumfängliches Migrationstool 🪄 für die Tabelle T028G. Mit einem sauberen Excel-Mapping und entsprechender Dokumentation lässt sich die Umstellung aber gut bewerkstelligen.
Um einen reibungslosen Übergang zu gewährleisten, lassen Sie sich am besten die neuen XML-Kontoauszugsformate bereits heute parallel von Ihren Hausbanken anliefern 🚛. Fragen Sie auch nach, wie lange Ihnen Kontoauszüge 🧾 im alten MT-Format nach November 2025 noch bereitgestellt werden – das schafft Planungssicherheit 🧭 für Ihre Migration.
📨 Änderungen im Statusreporting – PAIN.002 goes 2025
Auch im Bereich der Rückmeldungen zu Zahlläufen (PAIN.002) ergeben sich im Herbst eine Reihe von Änderungen. Zahlungen, die mit der neuen Version PAIN.001.001.09 (AXZ) versendet werden, erhalten künftig Statusberichte im Format PAIN.002.001.10 zurück.
Daraus ergeben sich u. a. folgende Anpassungen:
- Neue Feldstrukturen gemäß der aktualisierten ISO-Versionen
- Gekürzte Freitextfelder aus der Einreichung
- Ein überarbeitetes Statuskonzept (Datei- vs. Gruppenebene)
SAP liefert für diese Umstellungen bereits die aktualisierten Mappings für APM und BCM mit. Es ist keine neuen XSL-Transformation, sondern eine erweiterte Logik zur Prüfung und Berücksichtigung des Namensraums. Eine rechtzeitige Überprüfung und ggf. Anpassung der eigenen Validierungslogik ist hier unbedingt anzuraten.
✅ Vorabvalidierung von Kontoinformationen – Verification of Payee (VoP)
Mit der Einführung der Instant-Payment-Verordnung wird VoP für europäische Finanzinstitute verpflichtend – Stichtag ist Oktober 2025. Die Idee dahinter: Zahlungen sollen nur dann ausgeführt werden, wenn Kontoname und IBAN übereinstimmen. Das schützt vor Fehlern und Betrugsversuchen.
Doch wie funktioniert VoP im Firmenumfeld, insbesondere bei Massen- oder EBICS-Zahlungen?
Hier liegt die Herausforderung: EBICS ist ein asynchrones Verfahren – die Freigabe der Datei erfolgt vor der Übertragung. Eine klassische, dialogbasierte VoP-Prüfung (wie bei Einzelüberweisungen im Onlinebanking) ist also technisch nicht vorgesehen.
Die Regulierung sieht für Nicht-Verbraucher (also Firmenkunden) daher ein Opt-in-Modell vor:
- Beim Opt-in erlaubt der Kunde der Bank, seine Zahldaten vorab gegen das VoP-System zu prüfen.
- Beim Opt-out wird die Zahlung ohne Namensabgleich ausgeführt – wie bisher.
Aktuell arbeiten wir an einer Erweiterung der SAP-Standard-App für Geschäftspartner, mit der eine Validierung von Kontoinformationen über verschiedene externe APIs möglich sein wird. Damit lassen sich VoP-Prüfungen bereits vor Erstellung der Zahldatei im SAP-System durchführen – ein echter Mehrwert für automatisierte Prüfprozesse im Firmenumfeld.
👉 Für weitere Informationen oder einen Demo-Termin schreiben Sie uns gerne an: info@payments.cc
📥 EBICS 3.0 – Goodbye Auftragsarten, hello BTF
Mit EBICS 3.0 beginnt eine neue Ära: Die klassischen Auftragsarten wie CCT, CCD oder ZSR werden durch sogenannte Business Transaction Formats (BTF) ersetzt.
Der Vorteil: BTFs sind deutlich flexibler und ermöglichen eine feinere Steuerung des Zahlungsverkehrs. Ein BTF setzt sich aus mehreren Bausteinen zusammen:
ServiceName(z. B. SCT) – Art des ZahlverfahrensMsgName(z. B. pain.001) – verwendeter NachrichtentypScope(optional, z. B. CGI) – definierter AnwendungsbereichServiceOption(optional, z. B. B2B) – spez. VerfahrenContainerFlag(optional, z. B. ZIP) – Art der Dateistruktur
Ein großer Unterschied zur bisherigen Version: Mit BTFs kann der Kunde aktiv steuern, wie ein Auftrag vom EBICS-Server verarbeitet wird – nicht nur die Bank.
Darüber hinaus unterscheidet EBICS 3.0 nun klar zwischen:
- BTU – Business Transaction Upload (für eingehende Zahlungen)
- BTD – Business Transaction Download (für Auszüge, Rückmeldungen etc.)
💡 Unser Interface EBICS unterstützt EBICS 3.0 vollständig, und einige unserer Kunden sind bereits erfolgreich auf die neue Version umgestiegen. Besonders praktisch: Mit unserem Interface ist auch ein hybrider Betrieb von EBICS 2.5 und EBICS 3.0 möglich – ideal, falls einzelne Hausbanken noch nicht migriert haben.
👉 Interesse an EBICS 3.0 oder Fragen zur Migration? Wir beraten Sie gerne: info@payments.cc