White label means your own brand, but not automatically your own control.
A white-label CPMS makes it possible to operate charging infrastructure under your own brand without building the platform yourself: your own domains, your own tariffs, your own portals, but someone else's software underneath. The decisive choice, however, is rarely the feature list. It is the procurement model: SaaS rental, purchase with self-operation, or a source-code model with full technical ownership.
In projects we often see this question raised too late. Only when per-charge-point fees grow with the portfolio, a corporate policy suddenly demands on-premises operation, or the vendor reprioritizes its roadmap does the operating model become a topic. At that point, switching is almost always more expensive than a clean decision at the start.
Regulation adds pressure: AFIR has applied since 2024 and requires, among other things, ad-hoc payment and data provision; since January 2026, ISO 15118 is mandatory for new public AC charge points in the EU; and German calibration law (Eichrecht) requires MID-compliant meters with OCMF-signed meter values. Who implements and maintains these obligations in which model is one of the most important selection questions.
SaaS, purchase, source code: three models, three honest trade-offs.
SaaS rental is the fastest route to production. Hosting, updates, monitoring, and compliance maintenance sit with the vendor, costs per charge point are predictable, and the internal team stays small. The flip side: fees grow linearly with the portfolio, the roadmap belongs to the vendor, individual requirements compete with those of every other tenant, and operational data lives outside your own infrastructure.
Purchasing with on-premises or private-cloud operation brings data sovereignty and the ability to integrate the CPMS into your own IT, security, and network standards. In return, the operator takes responsibility for availability, backups, patches, and scaling, which requires a dedicated operations team. Compliance updates are the critical point: new AFIR interpretations, Eichrecht changes, or format updates for XRechnung and ZUGFeRD must be applied reliably, or the system ages faster than planned.
The source-code model offers maximum independence: your own features, your own release cycles, and protection against vendor insolvency or strategy shifts. It is also the most demanding model, because it requires permanent development capacity with OCPP, Eichrecht, and roaming expertise. Whoever forks the code takes over maintenance, including topics such as OCPP 2.1 support or ISO 15118-20 with Plug & Charge and V2G, which will gain weight in the coming years.
TCO: the license is rarely the biggest cost block.
An honest TCO analysis spans at least five years and puts all cost types side by side. With SaaS, recurring fees dominate and grow with every charge point. With a purchase, the weight shifts to upfront investment, infrastructure, and operations staff. With the source-code model, a development team is added that not only runs the platform but evolves it. The break-even between the models almost always depends on portfolio size and growth pace, not on the list price.
The most expensive items often hide in integrations and regulatory maintenance that never appear prominently in a quote comparison. In projects we regularly see that exactly these items later make the difference between calculated and actual TCO.
There is no universal answer: for small and mid-sized portfolios, SaaS is usually the most economical option, while purchase and source code only play to their strengths with scale or strategic requirements. What matters is which of these costs an organization can and wants to carry internally over the long term.
- The Eichrecht-compliant chain of MID meters, OCMF-signed meter values, transparency software, and long-term archiving.
- B2B invoicing with XRechnung and ZUGFeRD, including ongoing format maintenance.
- Roaming via OCPI 2.2/2.3 or Hubject, with recurring testing and coordination effort.
- Protocol migrations, for example from OCPP 1.6 to 2.0.1, which are not compatible with each other.
- AFIR obligations such as ad-hoc payment and data provision, which must be kept up to date permanently.
Vendor lock-in lives in data and configuration, not in the contract.
Notice periods are rarely the problem. The real lock-in sits in the charge points and the data: backend URLs and certificates in charge point configurations, historical sessions, Eichrecht archives with signed meter values, tariff and contract data, authorization lists, and roaming registrations. Eichrecht data must remain verifiable even after a vendor change, which quickly becomes a risk without documented export paths.
Concrete questions therefore belong on the table before signing: In which formats can sessions, meter readings, and configurations be exported? Is there full API access to your own data? Who is allowed to reconfigure the charge points' backend URL, and how does that work across thousands of devices? Since OCPP 1.6 and 2.0.1 are not compatible, a backend migration with a mixed fleet quickly becomes a protocol project on top.
Lock-in also grows in processes: support workflows, reporting, training, and interfaces to ERP or accounting attach themselves to the platform over years. A decoupling layer such as an OCPP broker significantly reduces the technical risk, because charge points stay connected to a stable address while target systems behind it can change. Whoever assesses switching costs realistically from the start negotiates better terms.
Selection criteria: identical feature scope across all operating models.
The selection should cover not only today's needs but the likely developments of the next few years: more charge points, new regulation, possible on-premises requirements from key accounts or parent companies. A solid list of criteria makes the decision traceable and creates a negotiating position before dependencies take hold.
One criterion deserves special attention: identical feature scope across all operating models. If the SaaS, purchase, and source-code variants are based on the same code base, the operating model becomes a purely commercial decision that can be revised later. An operator can start as a SaaS tenant and move to self-operation as the portfolio grows, without a break in features or data. If the variants differ in scope, however, every model change turns into a migration project with new tests, training, and risks.
The ideal is therefore a building-block system in which the same feature set can be rented, bought, or operated with source code. That keeps the model question a matter of strategy, not of technology.
- Exit scenario: documented export paths for sessions, Eichrecht archives, tariffs, and charge point configurations.
- Protocol roadmap: OCPP 1.6, 2.0.1, and 2.1 operable in parallel, plus ISO 15118 with Plug & Charge.
- Regulation as a product capability: AFIR, Eichrecht, XRechnung, and ZUGFeRD as standard, not as custom projects.
- Real multi-tenant and white-label capability: own brands, domains, tariffs, and roles per tenant.
- A migration path between rental, purchase, and source code without re-implementation and without data loss.