Zwei Wochen vor einem Formatwechsel ist die Frage nicht mehr, ob alles fertig wird. Sie lautet: Was muss fertig werden, damit am Stichtag nichts liegen bleibt? Zum 01.10.2026 gelten die mit BNetzA-Mitteilung Nr. 56 vom 01.04.2026 beschlossenen Formatstände verbindlich, eine Übergangsfrist nennt die Mitteilung nicht. Dieser Beitrag ordnet, was jetzt noch geht, was Sie bewusst liegen lassen können und an welcher Nahtstelle Umstellungen in SAP IS-U regelmäßig kippen. Stand: September 2026.
Was am Stichtag tatsächlich passiert
Ein Formatwechsel ist kein weicher Übergang, bei dem alte und neue Versionen eine Weile nebeneinander laufen. Ab dem 01.10.2026 prüft jeder Marktpartner eingehende Nachrichten gegen die neuen Versionsstände. Wer an diesem Tag noch eine UTILMD in der Vorversion sendet, bekommt keine fachliche Antwort, sondern eine Ablehnung.
Daraus folgt eine Unterscheidung, die in der Hektik gern verschwimmt: Senden und Empfangen sind zwei getrennte Risiken. Beim Senden entscheidet die Gegenseite, ob Ihre Nachricht durchkommt. Beim Empfangen entscheidet Ihr eigenes System, ob aus der eingehenden Nachricht ein Prozess wird oder ein Klärfall. Beide Richtungen können unabhängig voneinander scheitern, und sie scheitern unterschiedlich sichtbar: Ein abgelehnter Ausgang fällt sofort auf, ein nicht verarbeiteter Eingang erst, wenn jemand die Klärfallliste ansieht.
Triage: drei Klassen statt einer Liste
Wer spät dran ist, braucht keine vollständige Liste, sondern eine Priorisierung entlang der eigenen Marktrolle. Diese Nachrichtentypen entscheiden über die Handlungsfähigkeit am Stichtag:
| Rolle | Was mindestens auf dem neuen Stand laufen muss |
|---|---|
| Lieferant | UTILMD Strom AHB 2.2 / MIG S2.2 und Gas AHB 1.2 / MIG G1.2, MSCONS-Empfang (MIG 2.5 / AHB 3.2), APERAK-Verarbeitung (MIG 2.2 / AHB 1.1) |
| Netzbetreiber | UTILMD in beiden Sparten, MSCONS-Versand, ORDERS / ORDRSP (MIG 1.4c / AHB 1.1b), Entscheidungsbaum-Diagramme 4.3 |
| Messstellenbetreiber | MSCONS MIG 2.5 / AHB 3.2, ORDERS / ORDRSP, UTILTS AHB 1.1 |
| alle | Allgemeine Festlegungen 6.1d, Regelungen zum Übertragungsweg 1.10 mit AS4-Profil 1.2 |
Alles, was in dieser Tabelle nicht steht, ist in den verbleibenden zwei Wochen eine Kandidatenliste für „später". Das gilt ausdrücklich auch für Komfortfunktionen: Reports, Automatisierung von Sonderfällen und die Feinarbeit an den neuen CTA- und COM-Segmenten für Kontaktinformationen lassen sich im Oktober nachziehen, ohne dass ein einziger Marktprozess stehen bleibt.
Was in zwei Wochen realistisch noch geht
- Den Patchstand verifizieren statt annehmen. Die Frage ist nicht, ob der Dienstleister geliefert hat, sondern ob der Stand im Produktivsystem angekommen ist. Ein Abgleich der eingespielten Korrekturen gegen die Liefer- und Hinweisliste des Herstellers dauert Stunden, nicht Tage, und bringt regelmäßig eine Lücke ans Licht.
- Den Eingang vor dem Ausgang testen. Eingehende Nachrichten in neuer Version kommen ab dem Stichtag unabhängig davon, ob Sie bereit sind. Eine eingespielte Testnachricht je relevantem Typ zeigt schneller als jeder Projektplan, ob Prüfung und Verarbeitung greifen.
- Auf die häufigsten Vorgänge eingrenzen. Statt alle Prozessvarianten abzudecken: die Nachrichtentypen mit dem höchsten Mengenanteil der letzten Monate auswerten und genau diese durchtesten. In den meisten Häusern deckt eine einstellige Zahl von Vorgangsarten den Großteil des Volumens ab.
- Einen echten Marktpartner-Test statt zwanzig geplanter. Ein vollständiger Durchlauf mit einer Gegenpartei, die selbst umgestellt hat, ist aussagekräftiger als zwanzig Termine, von denen keiner zustande kommt.
- Den Rückfallplan aufschreiben. Wer am 01.10. entscheidet, wer eine Strecke stilllegt, wie Marktpartner informiert werden und welche Vorgänge manuell auflaufen dürfen, braucht das am Stichtag nicht zu diskutieren.
Was jetzt nicht mehr geht
Ebenso wichtig ist die ehrliche Gegenliste. Eine vollständige Regressionsprüfung über alle Marktprozesse ist in zwei Wochen nicht zu leisten und bindet genau die Leute, die am Stichtag verfügbar sein müssen. Neue Schnittstellen oder zusätzliche Automatisierung gehören in dieser Phase nicht in den Scope. Und auf eine kurzfristige Sonderlieferung des MaKo-Dienstleisters zu hoffen, ist kein Plan: Zwei Wochen vor einem Stichtag arbeitet dessen Support an denselben Themen für alle Kunden gleichzeitig.
Die Fallen liegen an der Nahtstelle, nicht im Format
In der Praxis scheitern Formatwechsel selten am Format selbst. Sie scheitern an Vorgängen, die über den Stichtag hinweglaufen. Vier Konstellationen, die in IS-U-Landschaften regelmäßig auffallen:
- Antworten auf Anfragen von vorgestern. Eine am 29.09. gesendete Anfrage wird am 02.10. beantwortet. Maßgeblich ist der Stand zum Zeitpunkt des Versands, nicht der des ursprünglichen Vorgangs. Ihr System muss also für eine Übergangszeit Vorgänge bedienen, die in der alten Welt begonnen haben.
- Die Ausgangsstrecke vor dem Umschalten leerfahren. Nachrichten, die vor dem Stichtag erzeugt, aber erst danach übertragen werden, gehen im alten Stand hinaus und werden abgelehnt. Wer die noch nicht versendeten IDocs vor dem Umschalten abarbeitet, spart sich die erste Klärfallwelle.
- Customizing mit Gültigkeitszeitraum. Wo Einstellungen datumsabhängig gepflegt sind, entscheidet nicht der Patchstand, sondern der gesetzte Gültigkeitsbeginn. Ein Eintrag ab dem 01.11. sieht im System korrekt aus und greift am Stichtag trotzdem nicht.
- Offene Klärfälle aus dem September. Sie werden im Oktober weiterbearbeitet und gegen die neuen Entscheidungsbaum-Diagramme bewertet. Ein großer Rückstand vor dem Stichtag ist damit kein reines Mengenproblem, sondern wird zum Bewertungsproblem. Details zur Fehlerlogik im Beitrag APERAK-Fehler verstehen.
Wer spät dran ist, gewinnt nichts durch Vollständigkeit. Er gewinnt durch die bewusste Entscheidung, was am 1. Oktober laufen muss und was warten darf.
Der 1. Oktober und die Tage danach
Am Stichtag zählt Sichtbarkeit. Wer den ein- und ausgehenden Nachrichtenverkehr in kurzen Abständen prüft, erkennt eine klemmende Strecke in Stunden statt in Tagen. Zwei Kennzahlen reichen für den Anfang: die Zahl der fehlerhaft abgebrochenen Eingänge und die Zahl der Nachrichten, die den Ausgang nicht verlassen haben. Beides lässt sich über die üblichen Monitore der Datenaustauschprozesse ablesen, wie im Beitrag Marktkommunikation in SAP beschrieben.
Bei der Abarbeitung hat sich eine Reihenfolge bewährt: zuerst die fristgebundenen Wechsel- und Anmeldeprozesse, danach Messwerte, zuletzt alles mit Abrechnungsbezug. Fristen laufen unabhängig davon weiter, ob die Umstellung geglückt ist. Ein liegen gebliebener Lieferantenwechsel kostet später deutlich mehr Aufwand als eine verspätete Messwertverarbeitung, die sich nachholen lässt.
Und für die Einordnung des Gesamtbilds: Das Oktober-Release ist ein Konsolidierungs-Release ohne neue Geschäftsprozesse. Welche Versionsstände genau gelten und was inhaltlich dahintersteckt, steht im Beitrag MaKo-Release Oktober 2026.
Das Wichtigste in Kürze
- Zum 01.10.2026 gelten die Formatstände aus BNetzA-Mitteilung Nr. 56 verbindlich, eine Übergangsfrist ist nicht vorgesehen.
- Senden und Empfangen sind getrennte Risiken: Ein abgelehnter Ausgang fällt sofort auf, ein nicht verarbeiteter Eingang erst in der Klärfallliste.
- Priorisieren Sie entlang der Marktrolle: UTILMD, MSCONS, ORDERS / ORDRSP und APERAK im jeweils passenden Stand, dazu Allgemeine Festlegungen 6.1d und AS4-Profil 1.2.
- In zwei Wochen machbar: Patchstand verifizieren, Eingang testen, auf die mengenstärksten Vorgänge eingrenzen, ein echter Partnertest, schriftlicher Rückfallplan.
- Die typischen Fehler liegen an der Nahtstelle: Antworten auf Vorgänge von vor dem Stichtag, nicht versendete Nachrichten in der Ausgangsstrecke, datumsabhängiges Customizing und offene Klärfälle aus dem September.