Die Abrechnungsfalle im Ex-Post Redispatch

Die Energiewende erzeugt nicht nur Strom. Sie erzeugt Abrechnungsfälle. Über 2.200 Redispatch-Maßnahmen allein im Januar 2026, mit einem Volumen von 3,3 TWh. Für jeden einzelnen Fall muss ein Verteilnetzbetreiber die Ausfallarbeit berechnen, die Entschädigungsansprüche zuordnen und die Abrechnung an den ÜNB weiterleiten. Die Physik dieser Maßnahmen ist trivial: Anlage abregeln, Leistung reduzieren, Engpass beseitigen. Die Administration ist es nicht.

Das operative Massengeschäft

Redispatch 2.0 ist seit Oktober 2021 verpflichtend. Jede Erzeugungsanlage ab 100 kW ist grundsätzlich redispatch-pflichtig. Für einen typischen städtischen Verteilnetzbetreiber bedeutet das ein Portfolio von 40 bis 80 Anlagen, die potenziell in Redispatch-Maßnahmen einbezogen werden können — Photovoltaik-Freiflächenanlagen, KWK-Anlagen, Biomassekraftwerke, Batteriespeicher und Notstromaggregate.

Jede Abregelungsmaßnahme erzeugt einen finanziellen Entschädigungsanspruch des Anlagenbetreibers. Die Ausfallarbeit — die Differenz zwischen der prognostizierten Einspeisung ohne Abregelung (Planwert) und der tatsächlichen Einspeisung während der Maßnahme (Ist-Wert) — muss berechnet, zugeordnet und abgerechnet werden. Das klingt nach einer Subtraktionsaufgabe. In der Praxis ist es ein Datenzuordnungsproblem, das über vier Systeme verteilt ist.

Die Ex-Post-Prozesskette: Wo sie bricht

Die Abrechnung einer einzelnen Redispatch-Maßnahme durchläuft einen Prozess, der sich in den meisten Verteilnetzbetreibern wie folgt darstellt:

Schritt 1: Abruf im Leitsystem. Der Übertragungsnetzbetreiber (ÜNB) oder der Verteilnetzbetreiber selbst initiiert eine Redispatch-Maßnahme. Das Netzleitsystem (SCADA) dokumentiert den Abruf: Zeitpunkt, betroffene Anlage (identifiziert über die technische Ressource), Sollwert der Leistungsreduktion und Dauer der Maßnahme.

Schritt 2: Identifikation der betroffenen Anlage. Die technische Ressource im Leitsystem muss einer kaufmännischen Einheit zugeordnet werden — dem Betreiber der technischen Ressource (BTR). Diese Zuordnung verknüpft die physische Abregelung mit dem wirtschaftlichen Anspruchsinhaber. In der Realität ist diese Zuordnung keineswegs trivial: Eine Erzeugungseinheit im MaStR kann einem anderen BTR zugeordnet sein als im ERP-System des Netzbetreibers. Der BTR kann gewechselt haben, ohne dass die Änderung in allen Systemen nachgezogen wurde.

Schritt 3: Berechnung der Ausfallarbeit. Die Ausfallarbeit ergibt sich aus dem Vergleich von Planwert (erwartete Einspeisung ohne Eingriff) und Ist-Einspeisung (gemessene Einspeisung während der Maßnahme). Der Planwert kommt typischerweise vom Einsatzverantwortlichen (EIV) oder wird vom Netzbetreiber selbst prognostiziert. Der Ist-Wert kommt aus dem Messsystem über die Marktlokation (MeLo) und den zugehörigen Zählpunkt. Beide Werte müssen derselben Anlage, demselben Zeitraum und demselben Messkonzept zugeordnet sein.

Schritt 4: Kaufmännische Abrechnung. Die berechnete Ausfallarbeit wird in das ERP-System (typischerweise SAP IS-U) überführt. Dort erfolgt die Erzeugung des Entschädigungsbetrags, die Zuordnung zum Bilanzkreis und die Erstellung der Abrechnungsnachricht im EDIFACT-Format — konkret über den Prozess der AAÜZ-Erzeugung (Ausfallarbeits-Übergangszahlungsanspruch). Die erzeugten Dateien werden per SFTP an den Übertragungsnetzbetreiber übermittelt.

Wo es in der Praxis scheitert

Dieser Vier-Schritt-Prozess funktioniert genau dann reibungslos, wenn die Stammdaten in allen beteiligten Systemen konsistent sind. Das sind sie in der Praxis selten. Die typischen Fehlermuster:

Fehlende BTR-Zuordnung. Die Anlage wurde im Leitsystem abgeregelt, aber die aktuelle BTR-Zuordnung liegt im kaufmännischen System nicht vor. Der BTR hat gewechselt (z. B. durch Verkauf der Anlage), die EDIFACT-Meldung des neuen BTR ist noch nicht verarbeitet, oder der BTR wurde im MaStR aktualisiert, aber nicht im SAP. Resultat: Die Abrechnung kann nicht erzeugt werden, weil der Zahlungsempfänger nicht identifiziert ist.

NAP-MeLo-Fehlzuordnung. Eine reale Herausforderung entsteht, wenn mehrere Erzeugungseinheiten denselben Netzanschlusspunkt (NAP) nutzen, aber unterschiedliche Marktlokationen (MeLo) haben. Ein Fernheizkraftwerk mit vier Dampfturbinen und einem Batteriespeicher kann an einem einzigen NAP angeschlossen sein, aber über vier separate MeLo-IDs verfügen. Wenn das Leitsystem die Abregelung auf NAP-Ebene dokumentiert, die Abrechnung aber auf MeLo-Ebene erfolgen muss, entsteht ein Zuordnungsproblem, das manuell aufgelöst werden muss: Welche MeLo-ID gehört zu welchem Abruf? Welcher Anteil der Leistungsreduktion entfällt auf welche Einheit?

Planwert-Ist-Wert-Diskrepanz. Der Planwert (die prognostizierte Einspeisung ohne Abregelung) stammt aus einem anderen Quellsystem als der Ist-Wert (die gemessene Einspeisung). Wenn der Planwert auf einem veralteten Erzeugungsprofil basiert — etwa weil die Anlage erweitert wurde, aber die Aktualisierung des Profils im Prognosesystem noch nicht erfolgt ist — wird die Ausfallarbeit systematisch falsch berechnet. Der Anlagenbetreiber erhält zu viel oder zu wenig Entschädigung, und die Differenz wird erst sichtbar, wenn die Monatsabrechnung im SAP läuft.

Das Notfallverfahren: Telefon und Excel

Wenn einer dieser Bruchpunkte eintritt — und in einem Portfolio von 50+ Anlagen tritt mindestens einer pro Abrechnungszyklus ein —, greifen Verteilnetzbetreiber auf das zurück, was intern als Notfallverfahren bezeichnet wird. Der Sachbearbeiter identifiziert den fehlerhaften Datensatz manuell, klärt die korrekte BTR-Zuordnung per Telefonat mit dem Einsatzverantwortlichen oder dem Anlagenbetreiber, dokumentiert die Korrektur in einer Excel-Tabelle und vermerkt den Vorgang im Betriebshandbuch.

Dieses Verfahren hat drei Eigenschaften, die es als Dauerlösung disqualifizieren. Erstens ist es nicht auditierbar: Ein Excel-Vermerk im Betriebshandbuch erfüllt nicht die Anforderungen an eine revisionssichere Dokumentation, die bei regulatorischen Prüfungen oder Streitigkeiten mit Anlagenbetreibern standhält. Zweitens skaliert es nicht: Bei steigendem Redispatch-Volumen — national hat sich das Volumen seit Einführung von Redispatch 2.0 vervielfacht — wächst die manuelle Nacharbeit linear mit der Anzahl der Maßnahmen. Und drittens ist es reaktiv: Der Fehler wird erst sichtbar, wenn die Monatsabrechnung scheitert. Wochen nach der eigentlichen Maßnahme. Wochen, in denen der fehlerhafte Datensatz weitere Folgefehler erzeugen kann.

Die Umsetzung in der SAP-Welt — intern oft als „A96-Prozess" referenziert (nach dem SAP-Transaktionscode für die AAÜZ-Erzeugung) — wird in vielen Stadtwerken als kritischster Einzelprozess im Redispatch beschrieben. Nicht wegen der technischen Komplexität der SAP-Transaktion selbst, sondern weil sie am Ende einer Datenkette steht, deren vorgelagerte Glieder nicht synchronisiert sind.