Een korte uitleg van de techniek achter Joulo: waar je gegevens staan, hoe we ERE-credits kunnen onderbouwen en wie meekijkt.

In het kort

Joulo rust op twee gescheiden lagen:

Voorkant een edge-netwerk (Cloudflare) dat de site, het dashboard en het verkeer naar je laadstation afhandelt: dichtbij jou, dichtbij waar het laden gebeurt.
Achterkant een PostgreSQL-database in een Europees datacenter voor accountgegevens, laadsessies en uitbetalingen.

Elke sessie, elke registratie en elke uitbetaling laten we terug te herleiden niet uit hobbyisme, maar omdat de NEa, een externe auditor en jijzelf er op een gegeven moment naar kunnen vragen.

Wil je zien wat er live gebeurt op het platform (deploys, codevolume, counters)? Kijk op /status. Het uitgebreidere vier-lagenplaatje staat op /platform.

Waar staat je data

Wat	Waar	Wie kan erbij
Account, e-mail, instellingen	Database in een Europees datacenter	Jij, met je inlog. Wij alleen voor support na jouw verzoek.
Laadsessies (datum, kWh, laadstation)	Idem	Idem.
IBAN voor uitbetaling	Versleutelde kluis, los van de database	Alleen de uitbetalingsroutine kan dit gebruiken met de juiste sleutel niet zichtbaar als platte tekst in je accountrecord.
Tokens van je gekoppelde account bij een laadmerk	Idem	Idem.
Foto's van je MID-meter	Privé-opslag	Alleen jij, via tijdelijke links (1 uur geldig).
Ruwe OCPP-berichten van je laadstation	Alleen-toevoegen archief	Audit-bewijs; inhoudelijk niet door ons aan te passen.

We bewaren niets wat we niet nodig hebben voor registratie, uitbetaling of ondersteuning. IBAN en tokens leven niet naast je overige profielvelden in platte vorm.

Hoe we ERE-credits onderbouwen

ERE-credits vertegenwoordigen waarde. Waarde moet zich laten verantwoorden. Daarom leggen we elke relevante laadsessie vast op twee plekken:

Werklaag de database, met mutatiegeschiedenis. Hier rekenen we mee; hier zie jij je sessies in het dashboard (per laadstation en met bronlabel).
Archief een alleen-toevoegen laag. Geen achteraf edit voor wie dan ook.

Als de NEa of een auditor vraagt om onderbouwing, zetten we beide naast elkaar. Zonder bewijs geen registratie, zonder correcte registratie geen uitbetaling zo hoort het bij een inboekdienstverlener.

In het dashboard zie je per sessie hoe de meting is binnengekomen:

🟢 Server-geverifieerd gemeten via onze eigen OCPP-koppeling met je laadstation.
🟡 Geïmporteerd aangeleverd via een gekoppelde API (Tesla, Easee, Wallbox, Zaptec, V2C, 50five, Plugchoice, …).
⚪ Handmatig door jou ingevoerd; lager vertrouwensniveau voor downstream-validatie.

MID: onder de Regeling energie vervoer verschilt het vereiste bewijs per laadpunt-categorie. Voor typische net-lading met levering aan een gemeten leverpunt hoort een geregeld meetinstrument (in de praktijk: MID-certificering waar dat van toepassing is). Die grens zit strak in het product: zonder die meter niet ineens “gewoon toch ERE” zie ook /wat-zijn-eres en de artikelen in /kennisbank.

Drie controles die je niet ziet, maar een verificateur wel

De bewijsketen loopt van meter naar sessie naar aansluiting naar inboeking. Op elke overgang zit een harde controle.

MID-bewijs per model, niet per belofte elk laadstationmodel dat bij ons als MID te boek staat, heeft een beoordeeld bewijsstuk in de catalogus. Dat is een conformiteitsverklaring, typecertificaat of datasheet van de fabrikant. Twijfel betekent "onbekend", nooit "ja". Bij een OCPP-koppeling lezen we merk, model en metertype uit de eerste melding van het laadstation zelf (BootNotification). Die toetsen we aan de catalogus met een vaste, versiegenummerde regelset.
Meterserienummer moet kloppen heb je het serienummer van je MID-meter opgegeven, dan vergelijken we het met wat het laadstation bij het verbinden meldt. Komt het niet overeen, dan weigeren we de verbinding. Die weigering leggen we vast vóórdat we hem teruggeven, dus ook het "nee" is bewijs.
Eén machtiging per aansluiting, zonder achterdeur per EAN kan één machtiging actief zijn; dat dwingt de database af. De machtigingshistorie is alleen-toevoegen: een correctie is een nieuwe regel, nooit een aanpassing van de oude. Bij het koppelen en bij het indienen controleren we bovendien of dezelfde EAN of hetzelfde laadstation al op een ander account actief is. Dubbel inboeken strandt dus vóór de NEa het ziet.

OCPP: drie dingen die voor jou uitmaken

Laadstations die rechtstreeks met ons praten via OCPP 1.6J hangen op onze eigen Central System (CSMS), op hetzelfde edge-netwerk als de rest van Joulo. Drie garanties:

Eigen proces per laadstation elk laadpunt krijgt een eigen vast proces aan de rand van het netwerk. Geen gedeelde verbinding of geheugen met andere klanten. Tussen berichten door slaapt het proces bij inkomend verkeer wordt het wakker.
Niets kwijt bij DB-onderhoud inkomende berichten gaan eerst naar een lokale wachtrij (outbox), daarna naar Supabase. Loopt de database even vast, dan groeit de wachtrij mee en wordt alsnog verwerkt. Berichten hebben een idempotency-sleutel duplicaten worden niet dubbel geboekt.
Elk frame wordt weggeschreven naast de tabellen bewaren we elk in- en uitgaand OCPP-frame als los bestand in een alleen-toevoegen archief, zonder vervaldatum. De frames blijven beschikbaar als bewijs.

Van StartTransaction via MeterValues tot StopTransaction kun je het traject per sessie reconstrueren twee onafhankelijke sporen (database + framearchief).

Wie ziet wat

De database handhaaft per rij wie data mag zien. Jouw sessies en gekoppelde gegevens komen niet bij een andere gebruiker terecht, ook niet als er ergens een fout in de frontend sluipt het beleid zit in Postgres (RLS), niet alleen in de browser.

Voor beheerders geldt een aparte rolstructuur; relevante acties schrijven we weg in een aparte audit-tabel.

Beveiliging aan de rand

Firewall en regels aan de rand van het netwerk filteren schadelijk verkeer.
Botbeleid: scrapers en misbruik worden tegengehouden; gangbare zoekmachine-crawlers en een beperkte set AI-crawlers kunnen expliciet worden toegelaten.
Partners en API-gebruikers: OAuth 2 met scopes en rate limits per token.
Wachtwoorden worden gehasht; inloggen kan ook met een magic link.
Geen wachtwoorden, tokens of IBAN's in applicatielogs.

Wie controleert ons

NEa Joulo B.V. staat op de officiële lijst van inboekdienstverleners. De REV-rekening voor technische indiening is een aparte stap na erkenning als inboekdienstverlener.
Capptions compliance-softwarepartner; auditspoor onder ERE-claims.
Externe auditor bij de eerste batch en daarna jaarlijks.
Jij in het dashboard zie je sessies en uitbetalingen tot op kWh-niveau.

Opzeggen, exporteren, account sluiten

Opzeggen in het dashboard. Jaarcontract: jaarlijks opzegbaar (Wet van Dam). Geen opzegkosten.
Exporteren sessies en uitbetalingen als CSV of JSON.
Account sluiten zelf te doen zolang er nog geen ERE-registraties namens jou bij de NEa zijn ingediend die een retentieplicht geven. Is dat wél gebeurd, dan sluiten we het account en minimaliseren we persoonsgegevens tot wat de wet en de audittrail vereisen; de registratiehistorie blijft beschikbaar voor toezicht.

Meer over het bedrijf en het team: /over-joulo.
Compatibiliteit van je hardware kun je checken via /check-laadstation.

Korte samenvatting

Onderdeel	Wat
Marketing + dashboard	SSR via React Router 7; ingelogd deel als SPA
Voorkant	Cloudflare-edge; eigen CSMS-proces per laadstation voor OCPP
Achterkant	PostgreSQL in de EU, RLS per rij, plus alleen-toevoegen audit-archief
Mobiele app	iOS en Android, dezelfde backend
Protocollen	OCPP 1.6J onder eigen beheer
Cloudkoppelingen	Tesla, Easee, Wallbox, Zaptec, V2C, 50five, Plugchoice (live) en Enphase
Releases	CI/CD via GitHub geen handmatige productie-deploys
Observability	Externe uptime, gestructureerde logs, /status

Verder lezen

/platform vier-lagen platform en live statistieken
/wat-zijn-eres wat ERE's zijn en hoe ze werken
/kennisbank FAQ en achtergrondartikelen
/status live counters en transparantie

Vragen? Mail info@joulo.nl of bel ons.

Joulo B.V. Brummen, NL KvK 42023359

Hoe Joulo gebouwd is