Vom Notfallverfahren zur Automatisierung

Die Ex-Post-Abrechnung im Redispatch 2.0 ist kein Randprozess. Sie ist finanziell signifikant, regulatorisch geprüft und volumetrisch wachsend. Auf nationaler Ebene wurden allein im Januar 2026 über 2.200 Redispatch-Maßnahmen mit einem Gesamtvolumen von 3,35 TWh dokumentiert — davon 83,5 % strombedingter Redispatch und 12,1 % grenzüberschreitender Countertrade. Diese Volumina sind nicht rückläufig. Sie steigen mit jedem Megawatt erneuerbarer Kapazität, das ans Netz geht.

Für den einzelnen Verteilnetzbetreiber bedeutet das: Die Anzahl der redispatch-pflichtigen Anlagen im Portfolio wächst, die Frequenz der Abrufmaßnahmen nimmt zu und die Komplexität der Stammdatenzuordnung steigt mit jeder neuen Anlage, jedem BTR-Wechsel und jeder ERP-Migration.

Das Notfallverfahren — Telefonat, Excel-Tabelle, Betriebshandbuch-Vermerk — kann in einem Portfolio von 20 Anlagen funktionieren. Es kann auch bei 40 Anlagen noch funktionieren, wenn die Personalkapazität in der Netzabrechnung entsprechend dimensioniert ist. Aber es hat drei strukturelle Grenzen, die durch mehr Personal nicht überwindbar sind.

Grenze 1: Keine präventive Wirkung. Das Notfallverfahren repariert Fehler, die bereits in der Abrechnung gelandet sind. Es verhindert nicht, dass fehlerhafte Datensätze überhaupt in den Abrechnungslauf gelangen. Jeder Fehler, der den SAP-Lauf erreicht, hat Folgekosten: manuelle Korrektur, Nachbuchung, Kommunikation mit dem Anlagenbetreiber und möglicherweise eine Korrekturnachricht an den ÜNB.

Grenze 2: Kein Audit-Trail. Eine Excel-Tabelle ist kein revisionssicheres Medium. Wenn die Bundesnetzagentur oder ein Anlagenbetreiber die Nachvollziehbarkeit einer Abrechnungskorrektur einfordert, kann der Netzbetreiber auf Zellenverweise und Tabellenblätter verweisen — aber nicht auf ein maschinenlesbares Protokoll, das Quellsysteme, Zeitstempel und Entscheidungslogik lückenlos dokumentiert.

Grenze 3: Kein Lerneffekt. Das Notfallverfahren behandelt jeden Fehler als Einzelfall. Es erkennt keine Muster. Wenn dieselbe Fehlerklasse (z. B. fehlende BTR-Daten nach Betreiberwechsel) systematisch bei einem bestimmten Anlagentyp oder in einem bestimmten Netzsegment auftritt, bleibt das unsichtbar. Der Sachbearbeiter löst das Problem jedes Mal neu, statt die Ursache zu beseitigen.

Agentic Asset-MDM als Skalierungslogik

Die agentische Methodik, wie sie in den vorherigen Abschnitten beschrieben wurde, adressiert alle drei Grenzen gleichzeitig:

Der Portfolio-Validierungsagent (täglicher Prüfzyklus) verhindert, dass inkonsistente Stammdaten den Abrechnungslauf erreichen. Er arbeitet proaktiv und erkennt Probleme Tage oder Wochen vor dem SAP-Lauf. Der Tagesabgleich-Agent (Maßnahmen-Zuordnung) stellt sicher, dass jede einzelne Redispatch-Maßnahme vollständig und konsistent den richtigen kaufmännischen Entitäten zugeordnet ist, bevor sie in die AAÜZ-Erzeugung einfließt. Und der Quarantäne-Mechanismus entkoppelt die fehlerfreien Maßnahmen von den problematischen — der SAP-Lauf wird nicht mehr durch Einzelfehler blockiert.

Das Ergebnis ist eine Prozesskette, die nicht mehr am Monatsende unter Zeitdruck manuell zusammengeklebt wird, sondern die kontinuierlich einen konsistenten, abrechnungsfähigen Datenbestand vorhält.

Die drei Optionen: Manuell, Batch, Agentisch

Wie beim Netzanschluss-Use-Case (→ Kapitel 1: Rechtssichere Netzanschlussentscheidungen) lässt sich der Reifegrad der Redispatch-Abrechnung in drei Stufen beschreiben:

Kriterium	Manuell (Notfallverfahren)	Batch-MDM (Nachtlauf)	Agentic Asset-MDM
Fehlererkennung	Erst im SAP-Lauf	Nächster Batch-Lauf (T+1 bis T+7)	Kontinuierlich (T+0)
BTR-Validierung	Per Telefonat	Report + manuelle Nacharbeit	Autonomer MaStR/UTILMD-Abgleich
NAP-MeLo-Prüfung	Nicht systematisch	Regelbasiert, aber ohne Kontext	Kontext-aware mit MaStR-NAP-Graph
Planwert-Aktualität	Unkontrolliert	Periodisch, aber ohne MaStR-Abgleich	Automatischer Kapazitäts-Profilabgleich
SAP-Lauf-Blockade	Häufig (Einzelfehler blockiert Gesamtlauf)	Reduziert	Eliminiert durch Quarantäne
Audit-Trail	Excel + Betriebshandbuch	Datenbankprotokoll	Maschinenlesbar, revisionssicher
Skalierung bei +20 Anlagen	+1 FTE	Konfigurationsaufwand	Automatisch

Build vs. Buy

Die in diesem Kapitel beschriebene Methodik ist vollständig offengelegt. Ein Verteilnetzbetreiber, der über die entsprechenden Schnittstellen verfügt — MaStR-API, SFTP-Anbindung für EDIFACT-Nachrichten, Leitsystem-Export und SAP-RFC-Konnektivität — kann die Agenten-Logik auf Basis eigener Infrastruktur implementieren. Die technische Kernkomponente ist dabei weniger die einzelne Abfrage als die Orchestrierung: der kontinuierliche, getaktete Abgleich über Systemgrenzen hinweg, die Pflege der NAP-MeLo-Zuordnungsgraphen und die Erzeugung revisionssicherer Entscheidungsobjekte.

Wer diese Orchestrierungskomplexität nicht selbst aufbauen und betreiben möchte, findet mit Cernion eine schlüsselfertige B2B-SaaS-Plattform, die genau diese Methodik operationalisiert.

Cernion bietet autonome Validierungsagenten für den Redispatch-Kontext, die sich in bestehende VNB-Systemlandschaften integrieren. Die Plattform umfasst den kontinuierlichen Abgleich von MaStR, ERP und Leitsystem, die automatische BTR-Validierung, die NAP-MeLo-Konsistenzprüfung und die Erzeugung abrechnungsfähiger Datensätze mit vollständigem Audit-Trail. Für Verteilnetzbetreiber, deren Redispatch-Portfolio über die manuelle Beherrschbarkeit hinauswächst, ist das der Weg vom Notfallverfahren zum auditierbaren Regelprozess — ohne den Aufwand einer internen Eigenentwicklung.

---

Datenquellen: Netztransparenz.de (Redispatch-Maßnahmen 2026), Marktstammdatenregister (mastr.bundesnetzagentur.de), BNetzA-Festlegungen BK6-20-059 / BK6-20-061. Abrufdatum: März 2026.

Datenquellen: Netztransparenz.de (Redispatch-Maßnahmen 2026), Marktstammdatenregister (mastr.bundesnetzagentur.de), BNetzA-Festlegungen BK6-20-059 / BK6-20-061. Abrufdatum: März 2026.