Das Eichrecht macht aus jeder Kilowattstunde einen prüfbaren Messwert.
Wer in Deutschland Ladevorgänge nach Kilowattstunden abrechnet, unterliegt dem Mess- und Eichrecht (MessEG/MessEV). Der Kern ist schnell erklärt: Die Messung muss mit konformitätsbewerteten, MID-konformen Zählern erfolgen, und der Kunde muss den abgerechneten Messwert nachvollziehen und auch nachträglich prüfen können. Ein Preis pro kWh ohne prüfbaren Messwert ist damit keine zulässige Abrechnungsgrundlage.
Für öffentliche und halböffentliche Ladepunkte reicht ein MID-Zähler allein aber nicht. Die Ladeeinrichtung muss als Ganzes bewertet sein, Messwerte müssen kryptografisch signiert werden und dem Fahrer zugänglich sein. Bei DC-Ladepunkten kommt hinzu, dass gleichstromseitig gemessen werden muss, damit Wandlungsverluste nicht dem Kunden angelastet werden.
In Projekten sehen wir, dass Eichrecht selten am Zähler scheitert, sondern an der Kette dahinter: Signaturen gehen im Backend verloren, Public Keys sind nicht sauber verwaltet, Rechnungen referenzieren den signierten Datensatz nicht. Seitdem AFIR zusätzlich Ad-hoc-Zahlung und Preistransparenz verlangt, fällt eine brüchige Messkette schneller auf. Die messrechtliche Ebene bleibt dabei eine eigene Disziplin, die AFIR nicht ersetzt.
OCMF ist das Format, OCPP der Transportweg.
OCMF (Open Charge Metering Format) hat sich als De-facto-Standard für signierte Messdaten etabliert. Ein OCMF-Datensatz enthält Zählerstände, Zeitstempel, Identifikationsmerkmale des Ladevorgangs und eine Signatur, die der Zähler beziehungsweise die Messkapsel selbst erzeugt. Damit ist der Messwert unabhängig vom Backend prüfbar, denn die Signatur entsteht dort, wo gemessen wird.
Durch OCPP fließen diese Daten je nach Version unterschiedlich. In OCPP 1.6 werden signierte Werte üblicherweise als SampledValue mit dem Format SignedData übertragen, in der Praxis meist mit OCMF-Payload in StopTransaction oder MeterValues. OCPP 2.0.1 und das abwärtskompatible OCPP 2.1 bringen dafür einen dedizierten signedMeterValue-Typ im TransactionEvent mit, inklusive Feldern für Signaturverfahren, Encoding und Public Key. Da OCPP 1.6 und 2.0.1 nicht kompatibel zueinander sind, muss ein Backend beide Wege beherrschen, solange Mischbestand existiert.
Entscheidend ist der End-to-End-Gedanke: Die Signatur schützt den Messwert vom Zähler bis zum Fahrer. Das Backend darf den Datensatz deshalb nicht normalisieren, umformatieren oder anreichern, sondern muss ihn byte-genau speichern. Jede noch so gut gemeinte Transformation macht die Signatur wertlos.
- OCMF-Datensätze mit Start- und Endzählerstand, Zeitstempeln und Signatur unverändert speichern.
- Public Keys je Ladepunkt und Zähler versioniert verwalten und veröffentlichen.
- OCPP 1.6 (SignedData als SampledValue-Format) und OCPP 2.0.1/2.1 (signedMeterValue im TransactionEvent) parallel unterstützen.
- Signierte Werte mit Transaktion, Tarif und Rechnung verknüpfen, ohne die Rohdaten anzufassen.
Transparenzsoftware: die Prüfung aus Fahrersicht.
Aus Fahrersicht funktioniert das Eichrecht so: Mit der Rechnung oder im Portal erhält der Fahrer den signierten Messdatensatz und den Public Key des Zählers. Mit einer Transparenzsoftware, etwa der der S.A.F.E.-Initiative, lädt er den Datensatz, validiert die Signatur und vergleicht die gemessenen Energiewerte mit der Abrechnung. Stimmen Signatur und Werte, ist der Ladevorgang messrechtlich belegt.
In der Praxis scheitert dieser Weg selten an der Kryptografie und oft an der Zugänglichkeit. Der Datensatz ist im Portal nicht auffindbar, liegt im falschen Format vor, der Public Key ist nirgends veröffentlicht oder die Rechnung lässt sich keiner Transaktion zuordnen. Für den Fahrer ist das Ergebnis dasselbe wie eine fehlende Signatur: Er kann nicht prüfen.
Wir empfehlen CPOs, den Prüfpfad regelmäßig selbst durchzuspielen, vom Ladevorgang über die Rechnung bis zur erfolgreichen Validierung in der Transparenzsoftware. Braucht dieser Weg mehr als wenige Schritte, ist die Kette nicht sauber. Diese Fahrerperspektive ist der ehrlichste Qualitätsmaßstab für die eigene Eichrechts-Umsetzung.
Rekalibrierung und Eichfristen im Bestand.
Eine Konformitätsbewertung gilt nicht unbegrenzt. Messgeräte unterliegen Eichfristen nach MessEV, danach ist eine Nacheichung oder ein Tausch des Zählers erforderlich. Für Betreiber heißt das zuerst: Bestand inventarisieren. Welcher Zähler steckt in welchem Ladepunkt, mit welchem Baujahr, welcher Zulassung und welcher Frist?
Dazu kommt die Anzeigepflicht: Wer Messgeräte verwendet, muss dies der zuständigen Eichbehörde anzeigen. Auch Eingriffe im Betrieb sind relevant, denn ein Zählertausch, Umbauten oder Firmware-Änderungen an der Messkapsel können die Konformität berühren und gehören dokumentiert. Wer das erst bei einer Marktüberwachung rekonstruiert, hat verloren.
In Projekten sehen wir, dass Rekalibrierung selten technisch schwer ist, aber organisatorisch. Fristen sind nicht zentral erfasst, Zähler-Seriennummern fehlen im Backend, ein Tausch vor Ort landet nie im Datenmodell. Ein Backend, das Zähler als eigene Entität mit Historie führt, macht aus der Eichfrist einen planbaren Wartungsprozess statt eines Compliance-Risikos.
Was das Backend 2026 können muss.
Eichrecht ist kein einzelnes Feature, sondern eine Eigenschaft der gesamten Datenkette. Das Backend muss signierte Messwerte unverändert annehmen, revisionssicher speichern, mit Transaktion und Rechnung verknüpfen und für Fahrer, Support und Behörden abrufbar machen. Im Roaming gilt das genauso: Über OCPI 2.2/2.3 lassen sich signierte Daten in CDRs an EMPs und Hubs wie Hubject weitergeben, damit auch der Roaming-Fahrer prüfen kann.
Auch die Rechnungsseite gehört dazu. Im B2B-Geschäft sollten XRechnung- oder ZUGFeRD-Rechnungen die signierten Datensätze eindeutig referenzieren, damit Messwert und Beleg zusammen auditierbar sind. Und die ISO-15118-Pflicht für neue öffentliche AC-Ladepunkte seit Januar 2026 ändert daran nichts: Plug & Charge macht die Autorisierung komfortabler, die Messkette muss weiterhin signiert und prüfbar bleiben.
Signierte Messwerte gehören deshalb als eigene Datenklasse behandelt: unverändert durchgereicht, in der Transaktions-Timeline verankert und mit Public-Key-Verwaltung und Zählerhistorie verknüpft. So bleibt Eichrecht das, was es sein sollte: ein verlässlicher Prozess, kein Projektrisiko.
- Signierte OCMF-Datensätze byte-genau und revisionssicher speichern.
- Public-Key-Register je Ladepunkt und Zähler mit Änderungshistorie führen.
- Messwert, Transaktion, Tarif und Rechnung verknüpfen, inklusive XRechnung/ZUGFeRD im B2B.
- Signierte Daten in OCPI-CDRs an Roaming-Partner weitergeben.
- Exporte für Fahreranfragen, Support und eichrechtliche Prüfungen bereitstellen.