Kurzantwort
Ein Formatwechsel ist im Unternehmen ein Projekt mit festem Endtermin: Der Stichtag am 1. April oder 1. Oktober, 00:00 Uhr, ist nicht verhandelbar. Was die Marktregeln ändern, steht in Versionswechsel in der Marktkommunikation absichern. Hier geht es um die Organisation: Betroffenheit klären, die Lieferung von SAP einspielen, im Testsystem gegen das Zukunftsformat prüfen, per Transport nach Produktion bringen, am Stichtag beobachten und einen Weg zurück kennen. Die knappste Phase ist der Test: SAP nennt für seine Cloud-Lösung als Beispiel eine Lieferung Mitte bis Ende August, vier bis sechs Wochen vor dem Wechsel zum 1. Oktober.
Wer liefert was
Die Umsetzung eines Formatwechsels kommt für den Versorger aus drei Richtungen, und für jede gibt es einen eigenen Termin im Plan.
- Die Vorgaben liefern Bundesnetzagentur und EDI@Energy. Für den 01.10.2026 sind das die verbindlichen Fassungen aus Mitteilung Nr. 56 vom 01.04.2026, also rund sechs Monate vorher. Mitteilung Nr. 58 vom 01.10.2026 gehört schon zum nächsten Wechsel am 01.04.2027.
- Die Software liefert SAP. Die SAP-Hilfe zu Intercompany Data Exchange (IDE) führt für den Elektrizitätsmarkt eine Version „gültig ab 1. Oktober 2026“ mit eigenem Softwarepaket (SAPK-61842INIDEXDE, Voraussetzung IS-U Enhancement Package 8 oder höher), für den Gasmarkt einen Eintrag „Legal changes valid from 2026-10-01“ (Produktseite IDE Strom, What’s New Gas). In S/4HANA Utilities for German Billing Enhancements stehen die Änderungen je Support Package, zum Beispiel die Prüfungen der Netznutzungsrechnung nach den Codelisten E_0406 und E_0407 (Support Package 2). Wer SAP Market Communication for Utilities als Cloud-Lösung nutzt, bekommt zusätzlich eine neue Version der Cloud-Anwendung.
- Die eigenen Anpassungen sind Sache des Hauses: kundeneigene Mappings, Erweiterungen des Datenaustauschs, Berichte, Schnittstellen zu Partnern und Dienstleistern.
Aus dieser Verteilung folgt die Arbeitsteilung. Der Fachbereich liest die Änderungshistorien und entscheidet, welche Anwendungsfälle das Unternehmen sendet oder empfängt. Die Anwendungsbetreuung spielt Lieferungen ein und prüft die eigenen Erweiterungen. Die Basis-Betreuung transportiert und importiert. Wer diese drei Rollen nicht benennt, entdeckt die fehlende am Stichtag.
Vorlauf: ab der Mitteilung
Mit der Mitteilung der Bundesnetzagentur beginnt der eigentliche Plan, nicht erst mit der SAP-Lieferung. Die Fassungen liegen sechs Monate vor dem Stichtag vor. Der Fachbereich geht die Änderungshistorien durch und legt je Änderung fest, welches System sie berührt: SAP-Standard (kommt mit der Lieferung), eigene Erweiterung (muss angepasst werden) oder Partnerabstimmung (braucht Termine mit Marktpartnern). Eine Änderung, die nur im Standard liegt, kostet Testzeit. Eine, die eine eigene Erweiterung trifft, kostet Entwicklungszeit und muss deshalb früh bekannt sein. Wie die Betroffenheit aus den Änderungshistorien abgelesen wird, zeigt Versionswechsel absichern; wie daraus Testumfang und Teststufen werden, steht in Teststrategie für AHB-Änderungen.
Lieferung einspielen und im Testsystem prüfen
Die Lieferung wandert durch die Systemlandschaft: zuerst Entwicklung oder Sandbox, dann Test, am Ende Produktion. Das Testsystem ist der Ort, an dem das Zukunftsformat erstmals in der Landschaft läuft, und dafür gibt es bei SAP eine eigene Funktion. Die Dokumentation zu SAP Market Communication for Utilities beschreibt, dass sich Prozesse in den Testsubkonten und Testsystemen schon vor dem Stichtag mit den künftigen Versionen durchspielen lassen. Dort bestimmt in Testsystemen die eingehende Marktnachricht den „Version Timestamp for Test“ eines ausgelösten Marktprozesses (SAP Help, Test Future Process Versions and Data Formats). Das gilt für diese Cloud-Lösung. Wie ein klassisches IDE-System im Test auf die Zukunftsversion schaltet, steht in der geprüften Quelle nicht; das ist im eigenen System und im SAP-Hinweis zur Lieferung zu klären.
Zeit ist der Engpass. Das SAP-Beispiel rechnet mit Lieferung Mitte bis Ende August und bis zum 1. Oktober vier bis sechs Wochen Test. Das Testkonzept muss deshalb vor der Lieferung stehen, mit Testfällen aus den Änderungshistorien und mit gebuchten Partnerterminen.
Transport nach Produktion
Customizing- und Entwicklungsänderungen laufen über Transportaufträge: Sie werden in der Entwicklung in einem Auftrag gesammelt (SE09, SE10), freigegeben und über die Importqueue des Zielsystems eingespielt (STMS); SE07 zeigt vorher, ob das Zielsystem aufnahmebereit ist (Transaktion SE09, STMS, SE10). Der Datenaustausch hat seine Einstellungen unter „Unternehmensübergreifender Datenaustausch“ im Einführungsleitfaden (Customizing-Baum); kundeneigene Basisprozesse und Deregulierungsprozesse liegen unter „Werkzeuge, Systemanpassung“. Gültigkeiten sind teilweise Teil der Daten: Die EBD-Codelisten tragen in der SAP-Hilfe ein Gültigkeitsdatum je Eintrag (Defining EBD Code Lists). Für den Transportplan heißt das: Aufträge mit Customizing und Codelisten gehören in die Reihenfolge, in der sie auch getestet wurden, und ein Import vor dem Stichtag ist möglich, wenn die Gültigkeit der Einträge erst zum Stichtag beginnt. Ob das für ein bestimmtes Objekt zutrifft, zeigt sein Gültigkeitsfeld im Test.
Cut-over am Stichtag
Der Stichtag ist bei SAP kein Schalter, den jemand umlegt. In SAP Market Communication for Utilities tragen Prozess- und Nachrichtenversionen einen Zeitpunkt „Valid As Of“, der in den meisten Fällen dem Moment des BDEW-Formatwechsels entspricht, zum Beispiel 1. Oktober 2023, 00:00:00 Uhr (SAP Help, Determination of Process and Message Versions). Die Dokumentation weist darauf hin, dass das Folgen für Abläufe hat, die über diesen Zeitpunkt hinweg laufen. Für den Cut-over folgt daraus:
- Vor dem Stichtag sind alle Importe erledigt, die Version mit dem künftigen Gültig-ab-Zeitpunkt ist vorhanden, und niemand ändert mehr Customizing ohne Freigabe (Änderungssperre für die Cut-over-Woche).
- Am Stichtag stehen Verantwortliche aus Fachbereich und Betrieb bereit. Sie prüfen die ersten Nachrichten mit der neuen Version und die ersten Antworten der Partner.
- Vorgänge über der Grenze, die vor 00:00 Uhr begonnen und danach fortgesetzt werden, liest der Betrieb gesondert. Welches Datum einer Nachricht darüber entscheidet, ob die alte oder die neue Fassung gilt, ist nach dem Stand der Allgemeinen Festlegungen 6.1d ungeklärt (siehe Versionswechsel absichern); die Überwachung läuft deshalb über die Klärfälle im Prozessmonitoring.
Rückfallplan
Ein Rückfall auf die alte Version ist am Markt keine Option, weil die Partner ab dem Stichtag die neue erwarten. Der Rückfallplan beschreibt deshalb, was passiert, wenn die neue Version im eigenen System nicht funktioniert: Verarbeitung anhalten, eingehende Nachrichten sicher puffern, Fehler beheben, kontrolliert nachverarbeiten. Er benennt, wer die Entscheidung trifft und bis wann. Vor dem Stichtag gehört ein Rücktransport in den Plan, wenn ein importierter Auftrag das Testergebnis verschlechtert. Wer einen Rückfall ernsthaft plant, hat dazu einen Importstand der Vorwoche dokumentiert und weiß, welche Aufträge zurück müssten.
Nach dem Stichtag
In den ersten Tagen werden Ablehnungen, Klärfälle und Fristüberschreitungen täglich gegen die Vorperiode gelesen. Ein Anstieg abgelehnter Nachrichten deutet auf einen Fehler im Mapping, ein Rückgang eingehender Nachrichten auf einen Fehler beim Partner oder im Eingangskanal (IDoc-Monitoring, Prozessdokumente). Danach folgt eine kurze Auswertung: Was hat Testzeit gekostet, welche Änderung kam zu spät an, welcher Partner war nicht erreichbar. Die Antworten fließen in den Plan für den nächsten Stichtag ein.
Beispiel: Oktober 2026
Ein Versorger mit IS-U und IDE legt im April die Betroffenheit fest: Der Standard deckt die Mitteilung 56 ab, zwei eigene Erweiterungen für die Rechnungsprüfung brauchen eine Anpassung. Im August liefert SAP das Paket, es kommt zuerst ins Entwicklungssystem. Im September läuft der Test mit den Fällen aus den Änderungshistorien; zwei Partner testen mit. Ende September werden die freigegebenen Aufträge in Produktion importiert, danach gilt die Änderungssperre. Am 1. Oktober beobachtet ein Team die ersten Nachrichten. Die Zahlen und Termine sind ein vereinfachtes Beispiel.
Typische Missverständnisse
„Release-Management ist eine IT-Aufgabe.“ Der Anstoß kommt aus dem Fachbereich: Er liest die Änderungshistorien. Die IT setzt um und transportiert.
„SAP liefert, dann ist der Wechsel erledigt.“ Die Lieferung deckt den Standard ab. Eigene Mappings, Erweiterungen und Partnerabsprachen bleiben Aufgaben des Hauses.
„Am Stichtag wird umgeschaltet.“ Bei SAP Market Communication for Utilities tragen die Versionen einen Gültig-ab-Zeitpunkt; die Arbeit liegt davor, im Import und im Test.
„Wenn es schiefgeht, nehmen wir die alte Version.“ Die Partner erwarten ab dem Stichtag die neue. Der Rückfall ist Pufferung und Nachverarbeitung, kein Zurück.
Offen
- Wie ein klassisches IDE-System im Test auf eine Zukunftsversion schaltet, ist hier nicht belegt (nur die Cloud-Lösung ist dokumentiert).
- Welches Datum einer Nachricht über alte oder neue Fassung entscheidet, steht in den geprüften Quellen nicht.
Quellen und Pflegehinweis
Marktdaten aus den Mitteilungen Nr. 56 und 58 der Bundesnetzagentur, SAP-Aussagen aus der SAP-Hilfe zu SAP Market Communication for Utilities, Intercompany Data Exchange und den Billing Enhancements. Transaktionen aus der Transaktionswerkbank. Geprüft am 05.10.2026; die Planzeiten der SAP-Hilfe sind Beispiele und können sich mit dem Release ändern.