Calibration law turns every kilowatt hour into a verifiable measurement.
Anyone billing charging sessions by kilowatt hour in Germany falls under the national calibration law, known as Eichrecht (MessEG/MessEV). The core idea is simple: measurements must come from conformity-assessed, MID-compliant meters, and the customer must be able to verify the billed value, even long after the session. A price per kWh without a verifiable measurement is not a valid billing basis.
For public and semi-public charge points, a MID meter alone is not enough. The charging station must be assessed as a whole, meter values must be cryptographically signed, and those values must be accessible to the driver. For DC charge points there is an additional requirement: measurement must happen on the DC side so that conversion losses are not billed to the customer.
In projects we rarely see Eichrecht fail at the meter itself. It fails in the chain behind it: signatures get lost in the backend, public keys are poorly managed, invoices do not reference the signed data set. Since AFIR requires ad-hoc payment and price transparency, a broken measurement chain surfaces faster. The metrological layer remains its own discipline that AFIR does not replace.
OCMF is the format, OCPP is the transport.
OCMF (Open Charge Metering Format) has established itself as the de facto standard for signed metering data. An OCMF data set contains meter readings, timestamps, identifiers for the charging session and a signature generated by the meter or metering capsule itself. This makes the measurement verifiable independently of the backend, because the signature is created where the measurement happens.
How this data flows through OCPP depends on the version. In OCPP 1.6, signed values are typically transported as a SampledValue with format SignedData, in practice usually carrying an OCMF payload in StopTransaction or MeterValues. OCPP 2.0.1 and the backward-compatible OCPP 2.1 provide a dedicated signedMeterValue type in TransactionEvent, including fields for the signing method, encoding and public key. Since OCPP 1.6 and 2.0.1 are not compatible with each other, a backend must handle both paths as long as a mixed fleet exists.
The end-to-end principle is what matters: the signature protects the measurement from the meter all the way to the driver. The backend must therefore never normalize, reformat or enrich the data set; it must store it byte for byte. Even the most well-intentioned transformation renders the signature worthless.
- Store OCMF data sets with start and end readings, timestamps and signature unchanged.
- Manage and publish public keys per charge point and meter, with versioning.
- Support OCPP 1.6 (SignedData as a SampledValue format) and OCPP 2.0.1/2.1 (signedMeterValue in TransactionEvent) in parallel.
- Link signed values to transaction, tariff and invoice without touching the raw data.
Transparency software: verification from the driver's perspective.
From the driver's point of view, Eichrecht works like this: along with the invoice or in the portal, the driver receives the signed metering data set and the meter's public key. Using transparency software, such as the tool published by the S.A.F.E. initiative, the driver loads the data set, validates the signature and compares the measured energy values with the invoice. If signature and values match, the session is metrologically proven.
In practice this path rarely fails at the cryptography and often fails at accessibility. The data set cannot be found in the portal, comes in the wrong format, the public key is not published anywhere, or the invoice cannot be matched to a transaction. For the driver the result is the same as a missing signature: verification is impossible.
We recommend that CPOs regularly walk this verification path themselves, from charging session through invoice to a successful validation in the transparency software. If it takes more than a few steps, the chain is not clean. This driver perspective is the most honest quality benchmark for any Eichrecht implementation.
Recalibration and verification periods for existing hardware.
A conformity assessment does not last forever. Measuring instruments are subject to verification periods under the MessEV; after that, re-verification or a meter swap is required. For operators the first step is an inventory of the installed base: which meter sits in which charge point, with which production year, which approval and which deadline?
There is also a notification duty: anyone using measuring instruments must report this to the responsible calibration authority. Interventions during operation matter too, because a meter swap, hardware modifications or firmware changes to the metering capsule can affect conformity and must be documented. Reconstructing all of this only when market surveillance shows up is a losing game.
In projects we see that recalibration is rarely hard technically, but organizationally. Deadlines are not tracked centrally, meter serial numbers are missing from the backend, an on-site swap never makes it into the data model. A backend that treats meters as first-class entities with their own history turns the verification period into a plannable maintenance process instead of a compliance risk.
What the backend must be able to do in 2026.
Eichrecht is not a single feature but a property of the entire data chain. The backend must accept signed meter values unchanged, store them in an audit-proof way, link them to transaction and invoice, and make them retrievable for drivers, support and authorities. The same applies in roaming: OCPI 2.2/2.3 allows signed data to be passed along in CDRs to EMPs and hubs such as Hubject, so that roaming drivers can verify as well.
The invoicing side is part of the picture too. In B2B business, XRechnung or ZUGFeRD invoices should reference the signed data sets unambiguously, so that measurement and receipt can be audited together. And the ISO 15118 mandate for new public AC charge points in the EU since January 2026 changes none of this: Plug & Charge makes authorization more convenient, but the measurement chain must remain signed and verifiable.
Signed meter values should therefore be treated as their own data class: passed through unchanged, anchored in the transaction timeline, and linked to public key management and meter history. That keeps Eichrecht what it should be: a reliable process, not a project risk.
- Store signed OCMF data sets byte-exact and audit-proof.
- Maintain a public key register per charge point and meter, with change history.
- Link measurement, transaction, tariff and invoice, including XRechnung/ZUGFeRD for B2B.
- Pass signed data along in OCPI CDRs to roaming partners.
- Provide exports for driver requests, support cases and calibration audits.