Die E-Rechnungspflicht macht Ladestrom-Abrechnung zur Strukturaufgabe.
Seit Januar 2025 müssen Unternehmen in Deutschland E-Rechnungen im inländischen B2B-Geschäft empfangen können. Die Pflicht zum Versand kommt gestaffelt: Übergangsregelungen laufen bis Ende 2027, danach ist das strukturierte Format durchgängig verpflichtend. Entscheidend ist die Definition: Eine E-Rechnung ist ein strukturierter Datensatz nach der europäischen Norm EN 16931. Ein normales PDF erfüllt diese Anforderung nicht, auch wenn es elektronisch verschickt wird.
Für Ladeinfrastruktur trifft diese Pflicht auf ein Geschäft, das ohnehin stark reguliert ist. AFIR regelt seit 2024 Ad-hoc-Zahlung und Preistransparenz an öffentlichen Ladepunkten, das Eichrecht bestimmt, wie Energiemengen gemessen und nachgewiesen werden. Die B2B-Abrechnung an Flottenkunden, Arbeitgeber, Filialisten oder öffentliche Auftraggeber bekommt dagegen oft weniger Aufmerksamkeit, obwohl dort die größeren Rechnungsvolumina entstehen.
In Projekten sehen wir häufig, dass Abrechnung als PDF-Export am Monatsende gedacht wird: Sessions zusammenzählen, Vorlage befüllen, verschicken. Unter der E-Rechnungspflicht reicht das nicht mehr. Die Rechnung muss maschinenlesbar, validierbar und aus den Betriebsdaten reproduzierbar entstehen — und genau daran entscheidet sich, ob die Datenkette vom Ladevorgang bis zur Rechnungsposition trägt.
XRechnung und ZUGFeRD lösen dieselbe Aufgabe mit unterschiedlicher Verpackung.
Beide Formate setzen die Norm EN 16931 um, unterscheiden sich aber im Träger. XRechnung ist ein reines XML-Format (als UBL oder UN/CEFACT CII) und der verbindliche Standard für Rechnungen an öffentliche Auftraggeber in Deutschland. Adressiert wird über die Leitweg-ID, übertragen typischerweise über Rechnungsportale oder Peppol. Eine Sichtkomponente gibt es nicht — was der Empfänger sieht, erzeugt sein System aus den Daten.
ZUGFeRD ist ein Hybridformat: ein PDF/A-3-Dokument mit eingebettetem XML. Ab dem Profil EN 16931 gilt es als vollwertige E-Rechnung. Der Vorteil liegt in gemischten Empfängerlandschaften: Die Buchhaltung kann das PDF lesen, das ERP-System verarbeitet das XML. Wichtig ist die Rangfolge: Der strukturierte XML-Teil ist führend, bei Abweichungen zwischen PDF und XML zählt das XML.
Für die Formatwahl entscheidet der Empfänger. Öffentliche Auftraggeber verlangen XRechnung, im klassischen B2B ist ZUGFeRD oft der pragmatische Weg. Technisch ist das kein Entweder-oder: Wer das Rechnungsdatenmodell sauber an EN 16931 ausrichtet, kann beide Formate aus denselben Daten erzeugen und pro Kunde konfigurieren.
Vom Ladevorgang zur Rechnungsposition: Die Datenkette entscheidet.
Ladestrom-Abrechnung ist keine klassische Positionsrechnung mit Stückzahl mal Preis. Am Anfang stehen OCPP-Transaktionen mit MeterValues, daraus entstehen Charge Detail Records (CDRs), und erst deren Aggregation ergibt Rechnungspositionen — pro Vertrag, Fahrzeug, Kostenstelle oder Standort. Jeder Schritt dieser Kette kann Fehler einführen, die auf der fertigen Rechnung kaum noch erklärbar sind.
Die Basis liefert das Eichrecht: MID-konforme Zähler und OCMF-signierte Messwerte, die der Kunde mit Transparenzsoftware prüfen kann. Der abgerechnete kWh-Wert muss auf genau diese signierten Werte zurückführbar sein. Wer Rechnungen aus ungesicherten Zwischenständen oder Backend-Schätzungen baut, erzeugt Differenzen, die spätestens bei einer Kundenprüfung auffallen.
Dazu kommt Roaming: CDRs erreichen das Billing auch über OCPI 2.2 oder 2.3 und über Hubs wie Hubject, mit eigenen Tarifdimensionen und Korrekturregeln. Energie, Ladezeit, Blockiergebühren und Sessionpauschalen müssen als getrennte Positionen oder nach klaren Aggregationsregeln abgebildet werden. Die E-Rechnung erzwingt dabei eine Präzision, die einem PDF nie jemand angesehen hätte: Einheiten, Steuersätze und Rundungen stehen als strukturierte Felder im XML und werden maschinell validiert.
Oft übersehen wird dabei die DSGVO-Dimension: CDRs und die daraus erzeugten B2B-Rechnungen können personenbezogene Daten enthalten — Ladekarten- und Vertrags-IDs, Standorte und Zeitstempel einzelner Fahrer; auch Fahrzeugbezüge können personenbeziehbar sein. Daraus folgen Datenminimierung in Rechnungsanhängen (nur, was der Rechnungsempfänger zur Prüfung braucht), getrennte Aufbewahrungs- und Löschkonzepte für steuerlich aufbewahrungspflichtige Rechnungsdaten (je nach Belegart acht bis zehn Jahre) und operative Betriebsdaten sowie im Roaming die geklärte Verantwortlichkeit zwischen CPO und EMP dafür, welche Daten zu welchem Zweck weitergegeben werden.
- Jede Rechnungsposition muss auf identifizierbare CDRs und signierte Messwerte rückführbar sein.
- Tarifdimensionen wie kWh, Ladezeit, Blockiergebühr und Sessionpauschale brauchen getrennte Positionen oder dokumentierte Aggregationsregeln.
- Sessions über Monatsgrenzen müssen deterministisch einem Abrechnungszeitraum zugeordnet werden.
- Roaming-CDRs aus OCPI oder Hubject folgen eigenen Storno- und Korrekturprozessen.
- Rundung gehört auf Positionsebene definiert, sonst weichen CDR-Summe und Rechnungsbetrag ab.
SEPA-Einzug und die typischen Fehler in der Praxis.
Im B2B-Ladestromgeschäft ist die SEPA-Lastschrift der übliche Zahlweg, und sie bringt eigene Pflichten mit: Gläubiger-Identifikationsnummer, Mandatsverwaltung mit eindeutiger Mandatsreferenz, Pre-Notification vor dem Einzug und ein geordneter Umgang mit Rücklastschriften. Rechnung und Einzug müssen zusammenpassen, denn XRechnung und ZUGFeRD transportieren Zahlungsinformationen wie Mandatsreferenz und Fälligkeit als strukturierte Felder. Kommen Rechnungsdaten und SEPA-Export aus getrennten Systemen, entstehen genau hier Abweichungen.
Die Fehlerbilder wiederholen sich über Projekte hinweg. Selten liegt das Problem im Format selbst, denn Bibliotheken für XRechnung und ZUGFeRD sind ausgereift. Es liegt fast immer in der Datenkette davor: unvollständige CDRs, nicht zugeordnete Mandate, Korrekturen ohne Bezug zur Ursprungsrechnung oder Beträge, die sich aus den Messwerten nicht mehr herleiten lassen.
- Ein PDF ohne strukturierten Datenteil wird als E-Rechnung deklariert — und vom Empfängersystem abgelehnt.
- ZUGFeRD-Profile unterhalb von EN 16931 werden verwendet, die die Anforderungen der E-Rechnungspflicht nicht erfüllen.
- Rechnungsbeträge basieren auf ungesicherten MeterValues statt auf den signierten OCMF-Werten.
- Die Pre-Notification fehlt oder nennt einen anderen Betrag als der tatsächliche Einzug.
- Korrekturen laufen als formlose Storno-PDFs statt als strukturierte Rechnungskorrektur mit Referenz.
Was ein CPMS-Billing-Modul abdecken sollte.
Ein Billing-Modul für Ladeinfrastruktur beginnt nicht beim Rechnungslayout, sondern bei der CDR-Pipeline: Transaktionen aus OCPP 1.6, 2.0.1 oder 2.1 werden normalisiert, mit signierten Messwerten verknüpft und gegen Tarife bewertet. Darauf aufbauend folgen Aggregation nach Kundenlogik, Erzeugung von XRechnung und ZUGFeRD aus demselben Datenmodell und die Validierung vor dem Versand — nicht erst beim Empfänger. Dazu gehören außerdem SEPA-Export, Korrektur- und Stornoprozesse mit Rechnungsreferenz und ein Audit-Trail, der jede Position bis zum Ladevorgang zurückverfolgen kann.
In der Praxis bewährt es sich, Validierung als festen Schritt einzubauen: Jede erzeugte Rechnung läuft gegen die EN-16931-Prüfregeln, bevor sie das System verlässt. Ebenso wichtig sind Tests mit den realen Empfängersystemen der Kunden, denn Portale und ERP-Systeme interpretieren Spielräume der Norm unterschiedlich. Wer beides früh etabliert, verhindert, dass Formatfehler erst im Mahnprozess auffallen.
Abrechnung ist damit kein Jahresendprojekt, sondern Teil der Betriebsarchitektur — genauso wie OCPP-Konnektivität oder Lastmanagement. Billing gehört deshalb als eigenständiges Modul auf dieselbe Datenbasis wie die OCPP-Konnektivität: CDR-Pipeline, Eichrecht-Referenzen, Formaterzeugung und SEPA-Export lassen sich einzeln in bestehende Systemlandschaften integrieren. So bleibt die Rechnung das, was sie sein muss: ein reproduzierbares Ergebnis der Betriebsdaten.