UTILMD und MSCONS einordnen

Kurzantwort

UTILMD und MSCONS sind Nachrichtentypen im EDIFACT-Format der Marktkommunikation. UTILMD transportiert energiewirtschaftliche Stammdaten und Zuordnungsinformationen, MSCONS übermittelt Messwerte und Energiemengen. Beide Typen decken viele Geschäftsvorfälle ab, und welcher gemeint ist, ergibt sich aus dem Inhalt der Nachricht.

Der Nachrichtentyp ist kein Prozess. Eine UTILMD kann einen Lieferbeginn, ein Lieferende oder eine Stammdatenänderung melden. Eine MSCONS kann Zählerstände, Lastgänge oder Zählerstandsgänge liefern. Welcher Vorgang vorliegt, entscheidet der Geschäftsvorfall in der Nachricht, beschrieben im Anwendungshandbuch.

Nachrichtentypen im Überblick

Die Marktkommunikation verwendet eine überschaubare Zahl von Nachrichtentypen. Jeder Typ hat einen festen Zweck, aber viele Verwendungen. UTILMD dient dem Austausch von Stammdaten und Prozessinformationen, MSCONS der Übermittlung von Werten. Dazu kommen Typen für Rechnungen, Rückmeldungen und weitere Zwecke.

Für die Einordnung hilft eine einfache Frage: Was transportiert die Nachricht? Geht es um eine Zuordnung oder um Stammdaten, ist UTILMD wahrscheinlich. Geht es um Messwerte, ist MSCONS im Spiel. Geht es um eine Rechnung, kommen INVOIC und verwandte Typen zum Einsatz. Diese grobe Einordnung ersetzt keine Prozessprüfung, gibt aber die Richtung vor.

Die Bundesnetzagentur veröffentlicht die Regeln zu den Formaten in den allgemeinen Festlegungen und den Mitteilungen zu den Datenformaten. Die konkreten Ausprägungen je Nachrichtentyp beschreiben die EDI@Energy-Dokumente. Allgemeine Festlegungen

Für Berater und Entwickler lohnt eine Übersicht, die Nachrichtentyp, typische Prozesse und die zuständige Nachrichtendatei zusammenführt. Eine solche Übersicht verhindert, dass bei jeder neuen Anforderung neu diskutiert wird, welcher Typ gemeint ist. Sie dokumentiert zugleich die Versionsstände, die das Unternehmen einsetzt. Ohne diese Übersicht wächst die Nachrichtenverarbeitung unkontrolliert.

UTILMD: Stammdaten und Zuordnung

UTILMD ist der Arbeitstyp der Zuordnungs- und Stammdatenprozesse. Ein Lieferant meldet damit einen Lieferbeginn an, ein Netzbetreiber bestätigt die Zuordnung, ein Messstellenbetreiber übermittelt Stammdaten zur Messlokation. Die Nachricht trägt die Marktlokation oder Messlokation, die beteiligten Marktpartner und die Zeitpunkte des Vorgangs.

Der entscheidende Inhalt ist der Geschäftsvorfall. In der UTILMD steckt ein Prüfidentifikator, der festlegt, welcher Use-Case gemeint ist. Ein Lieferbeginn nutzt einen anderen Prüfidentifikator als eine Kündigung oder eine Stammdatenänderung. Der Empfänger liest diesen Identifikator und startet den passenden Prozess.

Diese Struktur macht UTILMD flexibel, aber auch fehleranfällig. Eine Nachricht mit korrekter Syntax kann den falschen Geschäftsvorfall transportieren oder Felder enthalten, die zum gewählten Vorgang nicht passen. Die Prüfungen des Empfängers müssen deshalb über die Syntax hinausgehen und die fachliche Konsistenz sicherstellen. GPKE Teil 2

Die Zuordnung über den Prüfidentifikator prägt auch die Systemarchitektur. Ein Empfänger kann nicht jede UTILMD gleich verarbeiten. Er muss den Geschäftsvorfall erkennen, die passende Verarbeitung wählen und die Antwort mit dem richtigen Bezug erzeugen. Systeme, die diesen Schritt überspringen und alle UTILMD-Nachrichten über einen gemeinsamen Weg laufen lassen, verlieren die fachliche Steuerung. Der Prüfidentifikator ist daher ein zentrales Feld für Routing und Prozessauswahl.

MSCONS: Messwerte und Energiemengen

MSCONS übermittelt Messwerte. Ein Messstellenbetreiber liefert damit Zählerstände, Lastgänge oder Zählerstandsgänge an die berechtigten Empfänger. Die Nachricht trägt die Messlokation, den Zeitraum der Werte, die Werte selbst und ihre Qualitätsmerkmale.

Für die Verarbeitung zählt der Kontext der Werte. Jeder Wert gehört zu einer Messlokation und einem Zeitraum, besitzt eine Werteart und einen Status. Ein Zählerstand zur Abgrenzung hat eine andere Bedeutung als ein Lastgang für die Bilanzierung. MSCONS transportiert diese Angaben, und der Empfänger muss sie korrekt interpretieren. WiM Teil 2

Welche Segmente und Qualifier diese Angaben im Einzelnen tragen, steht in MSCONS verstehen: Aufbau und Qualifier einer Messwertnachricht.

Mit der Digitalisierung der Messung wächst die Bedeutung von MSCONS. Seit dem 6. Juni 2025 werden Last- und Zählerstandsgänge für Marktlokationen mit intelligenten Messsystemen umfassend übermittelt. Die Datenmengen steigen, und die Systeme müssen die Werte in hoher Auflösung verarbeiten. Wer MSCONS nur für jährliche Zählerstände kennt, muss sein Bild erweitern.

Empfänger von MSCONS-Werten müssen außerdem unterscheiden, für welchen Zweck sie die Werte verwenden dürfen. Ein Netzbetreiber nutzt die Werte für die Netznutzung, ein Übertragungsnetzbetreiber für die Bilanzierung, ein Lieferant für die Abrechnung. Die Werte sind nicht für jeden Zweck gleichermaßen bestimmt. Wer Werte aus einem Zweck in einen anderen übernimmt, muss prüfen, ob die Werteart und der Status das erlauben.

Weitere Typen im Umfeld

Neben UTILMD und MSCONS existieren weitere Nachrichtentypen. INVOIC transportiert Rechnungen, etwa Netznutzungsrechnungen zwischen Netzbetreiber und Lieferant. REMADV begleitet Zahlungen. CONTRL und APERAK liefern Rückmeldungen zur Übertragung und Verarbeitung. Jeder Typ hat seine Rolle, und keiner ersetzt die Prozesslogik.

Die Abgrenzung zwischen den Typen folgt dem Inhalt, nicht dem Regelwerk. Eine Rechnung kann aus GPKE-Prozessen stammen, eine Messwertlieferung aus WiM-Prozessen. Umgekehrt nutzt ein Regelwerk mehrere Nachrichtentypen. Wer Nachrichtentypen an Regelwerken festmacht, baut falsche Erwartungen auf.

Für SAP-IS-U-Berater heißt das: Die Nachrichtenverarbeitung braucht eine Zuordnung von Nachrichtentyp und Geschäftsvorfall. Ein eingehender Typ allein genügt nicht, um den Prozess zu starten. Erst die Kombination aus Typ, Prüfidentifikator und fachlichem Inhalt bestimmt die Verarbeitung.

Wer eine solche Zuordnung dokumentiert, legt damit zugleich die Grundlage für Berechtigungen und Prüfungen. Nicht jeder Marktpartner darf jede Nachricht empfangen oder senden. Die Zuordnung zeigt, welche Typen für welche Rollen relevant sind und welche Prüfungen der Empfänger durchführen muss.

Einordnung über das Anwendungshandbuch

Die verbindliche Einordnung eines Nachrichtentyps liefert das Anwendungshandbuch. Es beschreibt für jeden Prozess, welche Nachricht zu senden ist, welche Felder sie enthält und welche Prüfidentifikatoren gelten. Wer eine Nachricht erzeugt oder verarbeitet, findet im AHB die Regeln für seinen Fall.

Das AHB trennt dabei zwischen der Struktur und der Anwendung. Die Struktur beschreibt die MIG, die Anwendung das AHB. Ein Lieferbeginn in UTILMD nutzt bestimmte Segmente und Codes; das AHB zeigt, wie sie im konkreten Fall zu füllen sind. Diese Dokumentation ist die Grundlage für Mapping und Tests.

Wer sich nur an Beispielnachrichten orientiert, riskiert Fehler. Eine Beispielnachricht zeigt einen gültigen Fall, aber nicht die Grenzen. Das AHB zeigt die Regeln und erlaubt es, Randfälle zu erkennen. In Projekten sollte deshalb jede Nachrichtenart auf das AHB zurückgeführt werden.

Die Rückführung auf das AHB lohnt sich besonders bei Ablehnungen. Lehnt ein Empfänger eine Nachricht ab, liefert das AHB die Kriterien, um die Ursache zu finden: ein fehlender Pflichtwert, ein nicht zulässiger Code oder eine falsche Kombination. Ohne diese Referenz bleibt die Fehlersuche auf Vermutungen angewiesen. Mit ihr wird aus einer Ablehnung ein nachvollziehbarer Befund.

Bedeutung für SAP IS-U

In SAP-IS-U-Systemen laufen UTILMD und MSCONS über verschiedene Wege. UTILMD-Nachrichten stoßen Prozesse im Datenaustausch an, MSCONS-Nachrichten landen in der Werteverwaltung. Beide brauchen ein sauberes Mapping auf die internen Strukturen: Marktlokationen, Messlokationen, Profile und Verträge.

Die Qualität der Verarbeitung hängt von der fachlichen Zuordnung ab. Ein eingehender Lieferbeginn muss die richtige Marktlokation finden und den richtigen Vertrag fortschreiben. Ein eingehender Lastgang muss der richtigen Messlokation und dem richtigen Zeitraum zugeordnet werden. Fehler in dieser Zuordnung verursachen Klärfälle und falsche Abrechnungen.

Dazu kommt die Unterscheidung der Werte. Ein System, das alle MSCONS-Werte gleich behandelt, verwechselt Zählerstände mit Lastgängen und Abgrenzungswerte mit Verbrauchswerten. Die Werteverarbeitung muss Werteart, Zeitraum und Status führen und für die Abrechnung die richtigen Werte auswählen.

Für die Qualitätssicherung empfiehlt sich ein Monitoring, das die eingehenden Nachrichtentypen nach Geschäftsvorfall und Ergebnis auswertet. Wie viele Lieferbeginne wurden bestätigt, wie viele abgelehnt? Welche Messwertlieferungen fehlen für welche Messlokation? Solche Auswertungen machen Auffälligkeiten sichtbar, bevor sie zu Klärfällen werden. Sie verbinden die Nachrichtenebene mit der Prozessebene und geben dem Betrieb ein Frühwarnsystem an die Hand.

Praxisbeispiel: Wertefluss nach einem Lieferantenwechsel

Ein Kunde wechselt den Lieferanten. Der neue Lieferant meldet den Lieferbeginn per UTILMD an den Netzbetreiber, der die Zuordnung bestätigt. Für die Abgrenzung benötigt der neue Lieferant die Messwerte der Marktlokation.

Der Messstellenbetreiber übermittelt die Werte per MSCONS. Er liefert den Abgrenzungswert zum Wechselzeitpunkt und, soweit bestellt, die folgenden Lastgänge oder Zählerstände. Der Lieferant ordnet die Werte der Marktlokation zu und rechnet ab dem Zuordnungsbeginn ab.

Im Beispiel arbeiten zwei Nachrichtentypen zusammen: UTILMD für die Zuordnung, MSCONS für die Werte. Wer die Typen vertauscht oder ihre Inhalte falsch interpretiert, bringt die Prozesskette durcheinander.

Die Praxis zeigt, dass viele Störungen an den Übergängen zwischen den Nachrichtentypen entstehen. Eine Zuordnung ist bestätigt, aber die Werte kommen nicht, oder die Werte kommen, lassen sich aber keiner Zuordnung zuordnen. Ein gutes Monitoring verknüpft deshalb die Prozesssicht mit der Wertesicht und macht solche Lücken sichtbar, bevor sie zu Klärfällen werden.

Für den Test eines solchen Ablaufs lohnt ein Ende-zu-Ende-Szenario: vom Vertragsschluss über die Anmeldung bis zur ersten Werteübermittlung. Das Team prüft dabei die gesamte Kette aus Bestätigungen, Folgeprozessen und Abrechnungsdaten und nicht nur einzelne Nachrichten. Erst dieser Test zeigt, ob die Systeme die beiden Nachrichtentypen im Zusammenspiel richtig verarbeiten.

Typische Missverständnisse

„UTILMD ist der Lieferantenwechsel.“
Nein. UTILMD transportiert viele Geschäftsvorfälle. Welcher gemeint ist, bestimmt der Prüfidentifikator.

„MSCONS liefert nur Zählerstände zur Abrechnung.“
Nein. MSCONS übermittelt auch Lastgänge und Zählerstandsgänge für unterschiedliche Zwecke.

„Ein Nachrichtentyp gehört zu genau einem Regelwerk.“
Nein. Nachrichtentypen werden in mehreren Regelwerken verwendet. Die Einordnung folgt dem Inhalt, nicht dem Regelwerk.

„Syntaktisch korrekt heißt fachlich richtig.“
Nein. Erst die Prüfung des Geschäftsvorfalls und der fachlichen Inhalte entscheidet über die Verarbeitung.

„UTILMD und MSCONS decken die gesamte Marktkommunikation ab.“
Nein. Für Rechnungen, Rückmeldungen und weitere Zwecke gibt es weitere Nachrichtentypen.

Quellen und Pflegehinweis

Die Struktur und Verwendung der Nachrichtentypen beschreiben die allgemeinen Festlegungen und die EDI@Energy-Dokumente. Die fachliche Verwendung je Prozess steht in den AHB. Die Nachrichtentypversionen ändern sich mit den Umsetzungsterminen. Vor jeder Umsetzung die gültigen Versionen prüfen.

• Bundesnetzagentur: Allgemeine Festlegungen zu den EDIFACT- und XML-Nachrichten
• Bundesnetzagentur: GPKE Teil 2 (Lesefassung)
• Bundesnetzagentur: WiM Teil 2 (Lesefassung)
• Bundesnetzagentur: Gemeinsame Mitteilungen zu Datenformaten
• EDI@Energy: Datenformate für die Marktkommunikation
• Bundesnetzagentur: Netzzugang Strom und Marktkommunikation

Abrufdatum aller Quellen: 7. September 2026.