White-Label bedeutet eigene Marke, aber nicht automatisch eigene Kontrolle.
Ein White-Label CPMS erlaubt es, Ladeinfrastruktur unter eigener Marke zu betreiben, ohne die Plattform selbst zu entwickeln: eigene Domains, eigene Tarife, eigene Portale, aber fremde Software darunter. Die eigentliche Weichenstellung liegt dabei selten in der Feature-Liste. Sie liegt im Beschaffungsmodell: SaaS-Miete, Kauf mit eigenem Betrieb oder ein Source-Code-Modell mit voller technischer Hoheit.
In Projekten sehen wir häufig, dass diese Frage zu spät gestellt wird. Erst wenn die Gebühren pro Ladepunkt mit dem Portfolio wachsen, eine Konzernrichtlinie plötzlich On-Prem-Betrieb verlangt oder der Anbieter seine Roadmap anders priorisiert, wird das Betriebsmodell zum Thema. Zu diesem Zeitpunkt ist ein Wechsel fast immer teurer als eine saubere Entscheidung am Anfang.
Dazu kommt die Regulatorik: AFIR gilt seit 2024 und verlangt unter anderem Ad-hoc-Zahlung und Datenbereitstellung, seit Januar 2026 ist ISO 15118 für neue öffentliche AC-Ladepunkte in der EU Pflicht, und das Eichrecht setzt MID-konforme Zähler mit OCMF-signierten Messwerten voraus. Wer diese Pflichten in welchem Modell umsetzt und aktuell hält, ist eine der wichtigsten Fragen bei der Auswahl.
SaaS, Kauf, Source Code: drei Modelle, drei ehrliche Kompromisse.
Die SaaS-Miete ist der schnellste Weg in den Produktivbetrieb. Hosting, Updates, Monitoring und Compliance-Pflege liegen beim Anbieter, die Kosten sind pro Ladepunkt planbar und das interne Team bleibt klein. Die Kehrseite: Die Gebühren wachsen linear mit dem Portfolio, die Roadmap gehört dem Anbieter, individuelle Anforderungen konkurrieren mit denen aller anderen Mandanten und die Betriebsdaten liegen außerhalb der eigenen Infrastruktur.
Der Kauf mit On-Prem- oder Private-Cloud-Betrieb bringt Datenhoheit und die Möglichkeit, das CPMS in eigene IT-, Security- und Netzwerkstandards zu integrieren. Dafür übernimmt der Betreiber Verantwortung für Verfügbarkeit, Backups, Patches und Skalierung, was ein eigenes Betriebsteam voraussetzt. Kritisch wird es bei Compliance-Updates: Neue AFIR-Auslegungen, Eichrecht-Anpassungen oder Formatänderungen bei XRechnung und ZUGFeRD müssen zuverlässig eingespielt werden, sonst altert das System schneller als geplant.
Das Source-Code-Modell bietet maximale Unabhängigkeit: eigene Features, eigene Release-Zyklen und Schutz gegen Anbieterinsolvenz oder Strategiewechsel. Es ist aber auch das anspruchsvollste Modell, denn es setzt dauerhafte Entwicklungskapazität mit OCPP-, Eichrecht- und Roaming-Know-how voraus. Wer den Code forkt, übernimmt die Pflege selbst, inklusive Themen wie OCPP-2.1-Unterstützung oder ISO 15118-20 mit Plug&Charge und V2G, die in den nächsten Jahren an Gewicht gewinnen.
TCO: Die Lizenz ist selten der größte Kostenblock.
Eine ehrliche TCO-Betrachtung rechnet über mindestens fünf Jahre und stellt alle Kostenarten nebeneinander. Bei SaaS dominieren laufende Gebühren, die mit jedem Ladepunkt steigen. Beim Kauf verschiebt sich das Gewicht auf Anfangsinvest, Infrastruktur und Personal für den Betrieb. Beim Source-Code-Modell kommt ein Entwicklungsteam dazu, das die Plattform nicht nur betreibt, sondern weiterentwickelt. Der Break-even zwischen den Modellen hängt fast immer an Portfoliogröße und Wachstumstempo, nicht am Listenpreis.
Die teuersten Positionen verstecken sich oft in Integrationen und regulatorischer Pflege, die in keinem Angebotsvergleich prominent auftauchen. In Projekten sehen wir regelmäßig, dass genau diese Punkte später den Unterschied zwischen kalkuliertem und realem TCO ausmachen.
Ein pauschales Ergebnis gibt es nicht: Für kleine und mittlere Portfolios ist SaaS meist die wirtschaftlichste Option, während Kauf und Source Code erst mit Skalierung oder strategischen Anforderungen ihre Stärken ausspielen. Entscheidend ist, welche dieser Kosten eine Organisation dauerhaft intern tragen kann und will.
- Eichrechtskonforme Kette aus MID-Zählern, OCMF-signierten Messwerten, Transparenzsoftware und Langzeitarchivierung.
- B2B-Abrechnung mit XRechnung und ZUGFeRD, inklusive laufender Formatpflege.
- Roaming über OCPI 2.2/2.3 oder Hubject mit wiederkehrenden Test- und Abstimmungsaufwänden.
- Protokoll-Migrationen, etwa von OCPP 1.6 auf 2.0.1, die nicht kompatibel zueinander sind.
- AFIR-Pflichten wie Ad-hoc-Zahlung und Datenbereitstellung, die dauerhaft aktuell gehalten werden müssen.
Vendor-Lock-in entsteht in Daten und Konfiguration, nicht im Vertrag.
Kündigungsfristen sind selten das Problem. Der echte Lock-in steckt in den Ladepunkten und Daten: Backend-URLs und Zertifikate in der Ladepunkt-Konfiguration, historische Sessions, eichrechtliche Archive mit signierten Messwerten, Tarif- und Vertragsdaten, Autorisierungslisten und Roaming-Registrierungen. Eichrechtsdaten müssen auch nach einem Anbieterwechsel prüfbar bleiben, was ohne dokumentierte Exportpfade schnell zum Risiko wird.
Vor der Unterschrift gehören deshalb konkrete Fragen auf den Tisch: In welchen Formaten lassen sich Sessions, Zählerstände und Konfigurationen exportieren? Gibt es vollständigen API-Zugriff auf die eigenen Daten? Wer darf die Backend-URL der Ladepunkte umkonfigurieren, und wie läuft das bei tausenden Geräten ab? Da OCPP 1.6 und 2.0.1 nicht kompatibel sind, wird eine Backend-Migration bei gemischtem Bestand schnell zusätzlich zum Protokollprojekt.
Lock-in entsteht außerdem in Prozessen: Support-Workflows, Reporting, Schulungen und Schnittstellen zu ERP oder Buchhaltung wachsen über Jahre an die Plattform. Eine Entkopplungsschicht wie ein OCPP Broker reduziert das technische Risiko deutlich, weil Ladepunkte gegen eine stabile Adresse verbunden bleiben, während Zielsysteme dahinter wechseln können. Wer Wechselkosten von Anfang an realistisch bewertet, verhandelt bessere Bedingungen.
Kriterienkatalog: identischer Funktionsumfang über alle Betriebsmodelle.
Die Auswahl sollte nicht nur den heutigen Bedarf abdecken, sondern die wahrscheinlichen Entwicklungen der nächsten Jahre: mehr Ladepunkte, neue Regulatorik, mögliche On-Prem-Anforderungen von Großkunden oder Konzernmüttern. Ein belastbarer Kriterienkatalog macht die Entscheidung nachvollziehbar und schafft eine Verhandlungsbasis, bevor Abhängigkeiten entstehen.
Ein Kriterium verdient besondere Aufmerksamkeit: identischer Funktionsumfang über alle Betriebsmodelle. Wenn SaaS-, Kauf- und Source-Code-Variante auf demselben Codestand basieren, wird das Betriebsmodell zu einer rein kaufmännischen Entscheidung, die sich später revidieren lässt. Ein Betreiber kann als SaaS-Mandant starten und mit wachsendem Portfolio auf eigenen Betrieb wechseln, ohne Funktions- oder Datenbruch. Unterscheiden sich die Varianten dagegen im Funktionsumfang, wird jeder Modellwechsel zum Migrationsprojekt mit neuen Tests, Schulungen und Risiken.
Ideal ist deshalb ein Baukasten, in dem derselbe Funktionsstand gemietet, gekauft oder mit Source Code betrieben werden kann. So bleibt die Modellfrage eine Frage der Strategie und nicht der Technik.
- Exit-Szenario: dokumentierte Exportpfade für Sessions, eichrechtliche Archive, Tarife und Ladepunkt-Konfigurationen.
- Protokoll-Roadmap: OCPP 1.6, 2.0.1 und 2.1 parallel betreibbar, dazu ISO 15118 mit Plug&Charge.
- Regulatorik als Produktleistung: AFIR, Eichrecht, XRechnung und ZUGFeRD im Standard statt als Individualprojekt.
- Echte Mandanten- und White-Label-Fähigkeit: eigene Marken, Domains, Tarife und Rollen pro Mandant.
- Wechselpfad zwischen Miete, Kauf und Source Code ohne Re-Implementierung und ohne Datenbruch.