Je houdt een laadpas tegen een publieke laadpaal en het lijkt simpel: pas geaccepteerd, kabel erin, laden begint.
Maar onder dat ene moment zit een behoorlijk drukke keten van systemen en bedrijven. De laadpaal moet met een backoffice praten. De laadpas of app moet herkend worden. Iemand moet de sessie autoriseren. Er moet een tarief worden toegepast. De laadsessie moet worden opgeslagen. En ergens verderop moet daar een factuur, settlementbestand of vergoeding uit rollen.
Daarom voelt EV-laadfacturatie in Europa vaak verwarrend. De bestuurder ziet een laadsessie. De markt ziet een hele stapel rollen.
Wat gebeurt er eigenlijk wanneer iemand een laadpas scant?
Een publieke laadsessie loopt meestal ongeveer zo:
- 2.Een bestuurder tikt een RFID-laadpas of start via een app.
- 4.De laadpaal stuurt een autorisatieverzoek omhoog in de keten.
- 6.Een backoffice of billing-operator controleert of die token geldig is.
- 8.De sessie start en de verbruiksdata wordt vastgelegd.
- 10.Wanneer het laden stopt, wordt de sessie een transactierecord met tijden, kWh, connectorgegevens en kaartinformatie.
- 12.Die transactie vormt daarna de basis voor facturatie, vergoeding, rapportage of roaming-settlement.
Dat is het deel dat de meeste mensen nooit zien. Een laadsessie is niet alleen "een auto kreeg stroom". Het wordt een echt data-object. En juist dat bepaalt uiteindelijk wie wat in rekening brengt.
Wat doen een CPO, eMSP en backoffice precies?
Hier begint meestal de afkortingenjungle.
Een CPO, of Charge Point Operator, is de partij die de laadpunten en de technische inrichting ervan beheert. Aan de publieke kant kan dat een merk zijn als Allego of Shell Recharge. Maar het merk op de laadpaal vertelt niet altijd het hele verhaal. Het zichtbare merk, het operationele platform en de roaminglaag kunnen best drie verschillende partijen zijn.
Een eMSP of MSP is de mobiliteitsaanbieder aan de bestuurderskant. Dat is de partij die de app, het account, de laadpas, het prijsoverzicht of de factuur levert. Denk aan namen als Plugsurfing, DKV Mobility, Shell Recharge of een Virta-account. Het belangrijke punt: een eMSP kan toegang geven tot laadpunten die het bedrijf zelf niet bezit.
Een backoffice is de softwarelaag achter de laadinfrastructuur. Daar worden statussen bijgehouden, sessies geautoriseerd, transacties opgeslagen, kaarten beheerd en exports gemaakt. Simpel gezegd: het is het operationele brein rond de laadpaal.
Afhankelijk van de opzet zitten partijen zoals Last Mile Solutions, GreenFlux, Virta of Monta vaker dichter op die platform-, backoffice- of roamingservice-laag.
Waar passen OCPP en OCPI in de billing-keten?
Twee termen worden voortdurend door elkaar gehaald: OCPP en OCPI.
Dat zijn niet dezelfde dingen.
OCPP is de communicatielaag tussen de laadpaal en een centraal systeem of backoffice. Het is het protocol, onderhouden door de Open Charge Alliance, waarmee een laadpaal status doorgeeft, opdrachten ontvangt en sessiegegevens omhoog stuurt.
OCPI, beheerd door de EVRoaming Foundation, zit hoger in de keten. Dat protocol wordt gebruikt voor gegevensuitwisseling tussen laadbedrijven, zoals CPO's en eMSP's. Daar loopt roaminggerelateerde informatie overheen: welke laadpunten beschikbaar zijn, of een token geldig is, wat een sessie kostte en hoe records tussen partijen worden uitgewisseld.
De simpelste manier om het te onthouden:
De laadpaal praat OCPP. De roamingwereld praat vaak OCPI.
Dat verschil is belangrijk, omdat mensen roaming vaak zien als "een functie van de laadpaal". Dat is het niet. Roaming is een commerciele en datalaag boven op de communicatie van de laadpaal zelf.
Waarom publieke roaming simpel voelt, maar dat niet is
Publieke roaming voelt een beetje als mobiele roaming. Je hebt een laadpas of app, maar je kunt bij veel netwerken terecht.
Alleen is de facturatie erachter een stuk rommeliger.
Je kunt bijvoorbeeld laden bij een Allego-laadpunt met een DKV Mobility-laadpas. De sessie kan worden herkend via een roamingrelatie. Data kan direct tussen partijen lopen, of via een hub zoals Hubject of Gireve. Ondertussen praat de laadpaal zelf nog steeds via OCPP met het eigen platform. En de uiteindelijke sessiedata moet ook nog op de juiste plek terechtkomen voor settlement en facturatie.
Daarom is er niet een partij die EV-roaming in Europa "bezit". Het is een netwerk van operators, mobiliteitsaanbieders, protocollen, hubs en commerciele afspraken. Sommige koppelingen zijn direct. Andere lopen via hubs. En vaak is het een mix.
Daar komt nog iets bij: niet elke publieke sessie start met een laadpas. Voor publiek toegankelijke laadinfrastructuur zijn ad-hoc laden en transparante prijzen onder Europese regelgeving zoals AFIR ook belangrijk. Dus de publieke facturatie-infrastructuur draait niet alleen om abonnementen en laadpassen, maar ook om eenmalige betaalstromen.
Thuisladen vergoeding is niet hetzelfde als publieke roaming
Ook hier worden dingen vaak op een hoop gegooid.
Thuisladen vergoeding is meestal overzichtelijker. Een bekende laadpaal, een bestuurder, een zakelijke auto-regeling, een billing- of vergoedingsstroom. Landspecifieke regels kunnen nog steeds belangrijk zijn, bijvoorbeeld rond metering en compliance, maar de architectuur is meestal compacter.
Laden op een prive bedrijfslocatie zit daar een beetje tussenin. Een bedrijf wil misschien medewerkers en bezoekers laten laden, eventueel met RFID-kaarten en tarieven, zonder meteen een volledig publieke roamingopzet te worden.
Publieke roaming is gelaagder. De laadpaal kan van partij A zijn, de laadpas van partij B en de settlementroute van partij C. Voeg daar ad-hoc betalingen aan toe, en de billinglogica wordt snel breder.
Thuisladen vergoeding, laden op een prive bedrijfslocatie en publieke roaming hangen samen, maar het zijn niet dezelfde billingproblemen.
Dus ja, die scenario's raken elkaar. Maar het zijn niet gewoon dezelfde billingproblemen in een andere verpakking.
Waar Plugchoice past als je flexibiliteit wilt
Hier wordt het praktisch.
Veel eigenaren van laadpalen willen niet alleen dat laden vandaag werkt. Ze willen ook voorkomen dat ze voor altijd vastzitten aan een billingopzet.
Daar past Plugchoice het best in het verhaal: als open, OCPP-native launchpad en flexibiliteitslaag. Praktisch betekent dat een OCPP Proxy en managementlaag die laadpalen kan verbinden met third-party backoffices en billingproviders, in plaats van alles in een vaste route te duwen.
Dat betekent niet dat Plugchoice zelf elk onderdeel van billing uitvoert. Het is beter om Plugchoice te zien als de laag die opties openhoudt: laadpaalcommunicatie, platformflexibiliteit, integraties en minder vendor lock-in.
Voor installateurs, bedrijven en locatie-eigenaren is dat belangrijker dan het misschien klinkt. Billingmodellen veranderen. Roamingrelaties veranderen. Operatorrollen veranderen. De saaie architectuurkeuze die je vroeg maakt, bepaalt later vaak hoeveel vrijheid je nog over hebt.
De simpele versie om te onthouden
Als dit ecosysteem rommelig voelt, komt dat omdat het ook echt rommelig is.
Maar het heldere mentale model is dit:
- De bestuurder ziet een laadpas, app of betaalscherm.
- De eMSP of betaalstroom vertegenwoordigt de gebruiker.
- Roamingdata kan direct lopen of via hubs zoals Hubject en Gireve.
- De CPO en backoffice regelen de laadpaaloperatie, autorisatielogica en transactierecords.
- De laadpaal zelf praat omhoog via OCPP.
- Het eindresultaat is niet alleen een laadsessie, maar een factureerbare transactie.
Zodra je die lagen los van elkaar ziet, wordt publiek EV-laden ineens veel logischer.
En dan wordt ook duidelijker waar Plugchoice waarde toevoegt: niet als "de partij die alles doet", maar als de laag die helpt om de juiste onderdelen te verbinden zonder dat je vastloopt in de verkeerde setup.