Klärfälle im Marktprozess strukturiert bearbeiten

Kurzantwort

Ein Klärfall entsteht, wenn ein Marktprozess nach einer Rückmeldung nicht eindeutig oder nicht automatisiert abgeschlossen werden kann. Eine technische Rückmeldung zeigt zunächst, ob die Nachricht transportiert und strukturell verarbeitet werden konnte. Eine fachliche Ablehnung beantwortet dagegen die Frage, ob der übermittelte Vorgang in der konkreten Konstellation zulässig ist. Erst wenn die Beteiligten den offenen Sachverhalt, die Zuständigkeit und den nächsten Schritt geklärt haben, kann der Prozess fortgesetzt oder sauber beendet werden.

Für die Bearbeitung zählt die jeweils gültige Fassung der Geschäftsprozesse zur Kundenbelieferung mit Elektrizität (GPKE). Die Bundesnetzagentur veröffentlicht die Festlegungen und ihre Weiterentwicklungen. Ein Klärfall darf daher keine pauschale Standardantwort auslösen. Das Team muss den betroffenen Prozess, das Datum, die Marktrollen, die Nachricht und die anwendbare Version zusammenführen.

Was ein Klärfall von einer Ablehnung unterscheidet

Eine Ablehnung ist ein definiertes Prozessergebnis. Der Empfänger teilt mit, dass die Nachricht oder der Vorgang unter den übermittelten Bedingungen nicht verarbeitet werden kann. Der Absender kann den Grund prüfen, die Daten korrigieren und den vorgesehenen Prozess erneut ausführen. Die Ablehnung beantwortet also eine konkrete fachliche Prüfentscheidung.

Eine technische Rückmeldung liegt auf einer anderen Ebene. Sie kann die Annahme, Zurückweisung oder formale Prüfung einer Übertragung beziehungsweise Nachricht betreffen. Sie sagt allein noch nicht, ob der Geschäftsvorfall fachlich akzeptiert wurde. Ein System, das eine positive technische Rückmeldung als fachliche Bestätigung verbucht, kann einen Prozess zu früh abschließen.

Ein Klärfall beginnt dort, wo die vorhandenen Informationen für die nächste fachliche Entscheidung nicht ausreichen oder widersprüchlich sind. Typische Auslöser sind zum Beispiel:

• Die Marktlokation oder die zeitliche Zuordnung lässt sich nicht eindeutig bestimmen.
• Zwei Marktpartner bewerten den gleichen Vorgang mit unterschiedlichen Stammdatenständen.
• Eine Rückmeldung nennt einen Grund, der im konkreten Vorgang geprüft werden muss.
• Eine Folgeaktion hängt von einer Information ab, die noch nicht vorliegt.
• Ein Prozess ist durch eine neue oder geänderte Festlegung in einen Übergang geraten.

Ein Klärfall ist deshalb kein dritter Nachrichtentyp. Er ist ein bearbeitbarer Zustand mit Verantwortlichen, Belegen, Frist und Abschlusskriterium. Die GPKE beschreibt die Prozesslogik. Die operative Klärung braucht zusätzlich eine interne Arbeitsweise, die alle Entscheidungen dokumentiert.

Der Klärfall beginnt mit einer belastbaren Akte

Die erste Aufgabe ist die Rekonstruktion des Vorgangs. Das Team sichert die eingegangene Nachricht und ihre Antwort mit Zeitstempel, Richtung und Referenz. Es hält fest, welche Marktlokation, welcher Lieferbeginn oder welches andere Marktobjekt betroffen ist. Dazu kommen die beteiligten Rollen und der fachliche Anlass.

Eine gute Klärfallakte beantwortet mindestens diese Fragen:

Das Original sollte unverändert bleiben. Korrekturen gehören in eine neue Bearbeitungsversion mit Begründung. So kann ein Team später feststellen, ob die Ursache in der Eingabe, in einer Stammdatenänderung, in der Prozessauslegung oder in der Systemverarbeitung lag.

Die Bundesnetzagentur führt GPKE-Fassungen mit ihren Beschlussgrundlagen und Gültigkeitszeiträumen. Vor einer fachlichen Entscheidung muss deshalb geprüft werden, welche Fassung am relevanten Prozessdatum galt. Ein heute gültiges Regelwerk beantwortet nicht automatisch einen älteren Vorgang. Diese Versionsprüfung ist besonders wichtig, wenn ein Fall über einen Umsetzungstermin hinweg offen bleibt.

Die fachliche Ursache eingrenzen

Nach der Aktenbildung trennt das Team die Ebenen. Zuerst prüft es, ob die Nachricht technisch lesbar und der Austausch vollständig ist. Danach untersucht es die fachliche Verarbeitung. Hier geht es beispielsweise um Identifikation, Rollen, Zeitpunkte, Zuordnungen und die Frage, ob der Prozess im aktuellen Zustand zulässig ist.

Für jede Ebene gelten andere Prüfungen:

1. Transport und Eingang: Ist die Nachricht beim vorgesehenen Empfänger eingegangen und referenzierbar?
2. Struktur: Kann das System den Nachrichtentyp und seine Segmente verarbeiten?
3. Fachlicher Kontext: Passt der Geschäftsvorfall zur Marktlokation, Rolle, Richtung und zum Zeitpunkt?
4. Prozessentscheidung: Welche Anerkennung, Ablehnung, Korrektur oder Folgeaktion sieht die GPKE vor?
5. Klärung: Welche Information fehlt, und welcher Marktpartner kann sie verbindlich liefern?

Diese Reihenfolge verhindert eine häufige Fehlersuche: Das Team ändert Stammdaten, obwohl die Nachricht bereits an einer strukturellen Prüfung gescheitert ist. Ebenso problematisch ist die Gegenrichtung. Eine technisch fehlerfrei eingegangene Nachricht kann fachlich weiterhin unzulässig sein.

Eine Klärfrage sollte konkret formuliert werden. „Bitte prüfen“ reicht nicht. Besser ist: „Welche Marktlokation war am 15. September dem Netzgebiet zugeordnet, und welcher Lieferbeginn ist für den Vorgang mit dieser Referenz zulässig?“ Die Frage nennt Objekt, Zeitpunkt und erwartete Information. Dadurch kann der Empfänger gezielt antworten und die Antwort später als Entscheidungsbeleg dienen.

Zuständigkeit, Frist und Abschluss

Ein offener Vorgang braucht einen benannten Eigentümer. Die Marktrolle, die eine Information liefern muss, ist nicht automatisch die interne Stelle, die den Fall überwacht. Der Lieferant kann die Klärung gegenüber dem Netzbetreiber führen, während ein Fachteam die Stammdaten prüft und ein Integrationsteam die Nachricht erneut übermittelt.

Die Frist stammt aus dem jeweils einschlägigen GPKE-Prozess und der konkreten Prozessausprägung. Das Team sollte sie nicht aus einer allgemeinen Bearbeitungserwartung ableiten. Es dokumentiert den Fristbeginn, das Fristende, mögliche Werktagsregeln und den Zeitpunkt der eigenen Wiedervorlage. Wenn die Regelwerksfassung oder der Prozess nicht eindeutig ist, muss die zuständige Fachverantwortung die Auslegung freigeben.

Ein Klärfall ist abgeschlossen, wenn das Ergebnis fachlich feststeht und die erforderliche Folgeaktion nachweisbar ausgeführt wurde. Je nach Fall bedeutet das:

• Die ursprünglichen Daten waren korrekt, und der Vorgang kann regulär fortgesetzt werden.
• Ein Stammdatum oder ein Zeitpunkt wurde korrigiert und erneut übermittelt.
• Der Prozess ist für diesen Anlass beendet, weil eine zulässige Zuordnung nicht vorliegt.
• Ein anderer Marktpartner ist zuständig und hat den Vorgang übernommen.
• Die Rückmeldung war technisch, und die fachliche Nachricht wird nach erfolgreicher Korrektur erneut versendet.

„Antwort gesendet“ ist kein ausreichendes Abschlusskriterium. Das System muss zusätzlich erfassen, ob die Antwort fachlich angenommen wurde und welche Folgeaktion daraus entstand. Ein Klärfall kann durch eine neue Rückmeldung wieder geöffnet werden, wenn der Sachverhalt noch nicht erledigt ist.

SAP-IS-U-Perspektive: Klärfälle als Prozessobjekt

SAP IS-U sollte den Klärfall mit dem fachlichen Vorgang verbinden. Ein isolierter Fehlertext im Eingangspuffer reicht für die Bearbeitung nicht aus. Die zuständige Person muss von der Rückmeldung zur betroffenen Marktlokation, zum Vertrag, zum Geschäftspartner und zum ursprünglichen Prozess navigieren können. Welche Standardobjekte und Erweiterungen dafür eingesetzt werden, hängt von der Systemausprägung ab.

Ein sinnvolles internes Modell enthält mindestens:

• eine eindeutige Klärfallnummer,
• die Referenz auf Nachricht und Geschäftsvorfall,
• betroffene MaLo, MeLo oder andere fachliche Objekte,
• Rollen von Absender, Empfänger und internem Bearbeiter,
• ursprüngliche und korrigierte Datenstände,
• Rückmeldung inklusive Code und Klartext,
• Regelwerks- und Formatstand,
• Fristen, Wiedervorlagen und Eskalationen,
• Entscheidung, Folgeaktion und Abschlusszeitpunkt.

Die Arbeitsliste sollte Fälle nach Frist und Auswirkung priorisieren. Ein falscher Lieferbeginn kann andere Prozesse blockieren als ein rein informatives Stammdatenproblem. Diese Priorisierung ist eine betriebliche Regel und darf die regulatorische Reihenfolge des eigentlichen Marktprozesses nicht verändern.

Für Tests braucht das Projekt mindestens drei Fallklassen: eine technisch fehlerhafte Nachricht, eine fachlich ablehnungsfähige Nachricht und einen mehrdeutigen Fall mit manueller Klärung. Jeder Test dokumentiert erwarteten Status, Antwort, Zuständigkeit und Abschluss. Das macht sichtbar, ob das System nur Fehler protokolliert oder tatsächlich einen steuerbaren Klärprozess unterstützt.

Praxisbeispiel: Unterschiedliche Stammdatenstände

Ein Lieferant meldet einen Vorgang für eine Marktlokation. Der Netzbetreiber antwortet, dass die Zuordnung zum gewünschten Zeitpunkt nicht verarbeitet werden kann. Im Lieferantensystem sieht die Marktlokation dagegen korrekt aus. Beide Seiten besitzen damit zunächst eine plausible, aber widersprüchliche Sicht.

Das Team legt die Nachricht und Antwort unverändert ab. Es prüft, ob die MaLo-ID, der Prozesszeitpunkt, die Rolle des Absenders und die verwendete GPKE-Fassung zusammenpassen. Anschließend vergleicht es die zeitliche Historie der eigenen Stammdaten mit dem im Prozess erwarteten Zustand. Es stellt eine konkrete Klärfrage an den zuständigen Marktpartner und setzt eine Wiedervorlage vor Ablauf der einschlägigen Frist.

Die Antwort bestätigt einen zeitlich späteren Zuordnungsstand. Der Lieferant korrigiert den Folgeprozess, erstellt eine neue Nachricht und verknüpft sie mit dem ursprünglichen Klärfall. Erst die fachlich bestätigte Folgeantwort beendet den Vorgang. Im SAP-IS-U-System bleiben ursprüngliche Meldung, Entscheidung und neue Übermittlung gemeinsam auffindbar.

Das Beispiel zeigt, warum ein Klärfall mehr ist als eine E-Mail. Ohne Referenz, Version, Frist und Abschlusskriterium kann ein Team zwar kommunizieren, aber den Prozess nicht belastbar nachweisen.

Typische Missverständnisse

„Jede Ablehnung ist automatisch ein Klärfall.“
Eine eindeutig begründete Ablehnung kann direkt zu Korrektur und erneuter Übermittlung führen. Ein Klärfall ist erforderlich, wenn die Entscheidung oder Zuständigkeit offen bleibt.

„Eine positive technische Rückmeldung erledigt den Prozess.“
Sie bestätigt nur die jeweils geprüfte technische Ebene. Die fachliche Verarbeitung und das Geschäftsergebnis müssen separat bewertet werden.

„Der jüngste Stammdatenstand gilt immer.“
Marktprozesse arbeiten mit zeitlich gültigen Zuständen. Für den Vorgang zählt der relevante Zeitpunkt und die dazu gültige Regelwerksfassung.

„Ein Klärfall darf bis zur nächsten Nachricht liegen bleiben.“
Offene Vorgänge brauchen eine Frist, einen Verantwortlichen und eine Wiedervorlage. Sonst kann eine kleine Unklarheit Folgeprozesse blockieren.

„Freitext im Ticketsystem genügt als Nachweis.“
Ein Freitext erklärt den Fall, ersetzt aber nicht Originalnachricht, Referenz, Code, Version und dokumentierte Entscheidung.

Quellen und Pflegehinweis

Die GPKE-Seiten und Beschlüsse der Bundesnetzagentur bilden die Grundlage für Prozessrollen, Rückmeldungen und Gültigkeitsstände. Der BDEW ordnet die Marktkommunikation und ihre standardisierten Austauschprozesse fachlich ein. Konkrete Codes, Antwortfristen und Pflichtfelder müssen bei jeder Bearbeitung aus der am Prozessdatum gültigen GPKE- und Formatdokumentation gelesen werden.

• Bundesnetzagentur: GPKE und Lieferantenwechsel
• Bundesnetzagentur: Beschluss BK6-22-128
• BDEW: Marktkommunikation

Abrufdatum der Quellen: 9. September 2026.