The e-invoicing mandate turns charging billing into a structural task.
Since January 2025, companies in Germany must be able to receive e-invoices for domestic B2B transactions. The obligation to issue them is phased in: transition rules run until the end of 2027, after which the structured format becomes mandatory across the board. The definition is what matters: an e-invoice is a structured data set compliant with the European norm EN 16931. A plain PDF does not meet this requirement, even when it is sent electronically.
For charging infrastructure, this mandate lands in a business that is already heavily regulated. AFIR has governed ad-hoc payment and price transparency at public charging points since 2024, and German calibration law (Eichrecht) defines how energy quantities are measured and evidenced. B2B billing — to fleet customers, employers, retail chains or public-sector clients — tends to get far less attention, even though that is where the larger invoice volumes accumulate.
In projects we frequently see billing treated as a PDF export at the end of the month: sum up sessions, fill a template, send it out. Under the e-invoicing mandate, that no longer holds. The invoice has to be machine-readable, validatable and reproducible from operational data — and this is exactly where the data chain from charging session to invoice line item is put to the test.
XRechnung and ZUGFeRD solve the same problem with different packaging.
Both formats implement the EN 16931 norm but differ in their carrier. XRechnung is a pure XML format (as UBL or UN/CEFACT CII) and the mandatory standard for invoices to public-sector clients in Germany. Recipients are addressed via the Leitweg-ID, and transmission typically runs through invoicing portals or Peppol. There is no visual component — whatever the recipient sees is rendered by their own system from the data.
ZUGFeRD is a hybrid format: a PDF/A-3 document with embedded XML. From the EN 16931 profile upwards it counts as a fully compliant e-invoice. Its strength lies in mixed recipient landscapes: accounting staff can read the PDF while the ERP system processes the XML. The precedence rule matters: the structured XML part is authoritative, and if PDF and XML diverge, the XML wins.
The recipient decides the format choice. Public-sector clients require XRechnung, while in classic B2B, ZUGFeRD is often the pragmatic route. Technically it is not an either-or: with an invoice data model aligned cleanly to EN 16931, both formats can be generated from the same data and configured per customer.
From charging session to invoice line item: the data chain decides.
Billing charging current is not a classic line-item invoice of quantity times price. It starts with OCPP transactions and MeterValues, which become Charge Detail Records (CDRs), and only their aggregation produces invoice line items — per contract, vehicle, cost center or site. Every step in this chain can introduce errors that are almost impossible to explain on the finished invoice.
The foundation comes from German calibration law: MID-compliant meters and OCMF-signed meter values that customers can verify with transparency software. The billed kWh figure must be traceable to exactly those signed values. Building invoices from unsecured intermediate readings or backend estimates creates discrepancies that surface at the latest when a customer audits the numbers.
Roaming adds another layer: CDRs also arrive via OCPI 2.2 or 2.3 and through hubs like Hubject, each with their own tariff dimensions and correction rules. Energy, charging time, blocking fees and per-session fees must be mapped as separate line items or follow clearly documented aggregation rules. E-invoicing enforces a precision no one would ever have noticed in a PDF: units, tax rates and rounding sit as structured fields in the XML and are validated by machines.
An often overlooked aspect here is the GDPR dimension: CDRs and the B2B invoices derived from them can contain personal data — charging-card and contract IDs, locations and timestamps of individual drivers; even vehicle references can be attributable to a person. This entails data minimization in invoice attachments (only what the recipient needs for verification), separate retention and deletion policies for tax-relevant invoice data (eight to ten years in Germany, depending on the document type) versus operational data, and — in roaming — clarified responsibilities between CPO and EMP for what data is passed on and for what purpose.
- Every invoice line item must be traceable to identifiable CDRs and signed meter values.
- Tariff dimensions such as kWh, charging time, blocking fees and session fees need separate line items or documented aggregation rules.
- Sessions spanning month boundaries must be assigned deterministically to one billing period.
- Roaming CDRs from OCPI or Hubject follow their own cancellation and correction processes.
- Rounding must be defined at line-item level, otherwise CDR totals and invoice amounts drift apart.
SEPA direct debit and the typical mistakes in practice.
In the B2B charging business, SEPA direct debit is the standard payment method, and it brings obligations of its own: a creditor identifier, mandate management with unique mandate references, pre-notification before collection and an orderly process for returned debits. Invoice and collection have to match, because XRechnung and ZUGFeRD carry payment information such as mandate reference and due date as structured fields. When invoice data and SEPA export come from separate systems, this is precisely where discrepancies emerge.
The failure patterns repeat across projects. The problem rarely lies in the format itself, since libraries for XRechnung and ZUGFeRD are mature. It almost always lies in the data chain before it: incomplete CDRs, unassigned mandates, corrections without a reference to the original invoice, or amounts that can no longer be derived from the meter values.
- A PDF without a structured data part is declared an e-invoice — and rejected by the recipient's system.
- ZUGFeRD profiles below EN 16931 are used, which do not satisfy the e-invoicing mandate.
- Invoice amounts are based on unsecured MeterValues instead of the signed OCMF values.
- The pre-notification is missing or states a different amount than what is actually collected.
- Corrections are sent as informal cancellation PDFs instead of structured invoice corrections with a reference.
What a CPMS billing module should cover.
A billing module for charging infrastructure does not start with the invoice layout but with the CDR pipeline: transactions from OCPP 1.6, 2.0.1 or 2.1 are normalized, linked to signed meter values and rated against tariffs. On top of that come aggregation according to customer logic, generation of XRechnung and ZUGFeRD from the same data model, and validation before dispatch — not first at the recipient. It also needs SEPA export, correction and cancellation processes with invoice references, and an audit trail that can trace every line item back to the charging session.
In practice, it pays to make validation a fixed step: every generated invoice runs against the EN 16931 rule set before it leaves the system. Equally important are tests against customers' real receiving systems, because portals and ERP systems interpret the norm's degrees of freedom differently. Establishing both early prevents format errors from surfacing only in the dunning process.
Billing is therefore not a year-end project but part of the operational architecture — just like OCPP connectivity or load management. Billing therefore belongs as a dedicated module on the same data foundation as the OCPP connectivity: CDR pipeline, calibration-law references, format generation and SEPA export can each be integrated individually into existing system landscapes. That keeps the invoice what it has to be: a reproducible result of operational data.