Customer onboarding
How customers enter the white-label portal and complete their ERE registration.
Customer onboarding
Customers can enter the portal through three routes. All three end up in the same onboarding wizard, so on tenants with open signup a customer can start via one route and return via another.
Entry routes
SSO links
Your backend mints a signed, single-use login link and presents it in your own portal, app, or email. The customer clicks and lands in the portal already identified: name, address, and (if you include it) the MID meter serial are prefilled. This is the smoothest route because the customer never types anything you already know.
See SSO links for the token specification and code examples.
Open signup (/aanmelden)
For tenants with open signup enabled, customers register themselves with:
- Customer number • the label is configurable per tenant (for example "Accountnummer"). This becomes the stable key that later data delivery matches on, so instruct customers to use the number from your invoice or contract.
- Contract number • optional per tenant. If your tenant has a contract number label configured, the field is required: it is the fallback key for matching delivered charging data.
- Email address • required; it is also the key for magic-link logins later.
- Name and address • the EAN code of the connection is looked up automatically in the EAN Codeboek when the address resolves to exactly one match.
A returning customer submits the same form: an existing customer number with a matching name and postal code (and contract number when both sides have one) logs the customer back in and resumes where they left off. On a mismatch the form shows a generic error without hinting which field was wrong. The email field must be filled in like on any submit, but it is not used for the match • returning works on the number-plus-details check above.
The public forms are protected against bots with Cloudflare Turnstile, a honeypot, and rate limiting.
Magic link (/inloggen)
Customers who linked an email address can request a login link by email. The link is single-use and short-lived, the response never reveals whether an account exists, and at most one email per minute is sent per user.
The onboarding wizard
Your details
For tenants with an identification step (and for open signup), the wizard starts with the customer's details: name, address, and the connection's EAN • prefilled from SSO or the signup form and editable until the machtiging is signed.
Link a charger
Only in customer-linked data mode: the customer selects their charger brand so the sessions can be synced. The full charger-account link is rolled out per brand; where a brand is not live yet, the wizard records the charger and Joulo completes the connection with the customer. In CPO-delivered mode this step does not exist • not in the stepper, no gate.
IBAN
The account the quarterly payout goes to, stored encrypted. Only shown when payouts run through Joulo: for tenants whose earnings run through their own billing, this step disappears entirely.
Machtiging
The customer confirms their identity (CPO-supplied fields are shown read-only), confirms or corrects the EAN code, and signs the authorization that allows Joulo to submit the ERE records for that connection. The accepted clauses are versioned and recorded per customer.
Link an email
Open-signup customers already provided their email address at signup, so this step simply confirms it. It remains as a separate step (with a dashboard reminder) for older accounts that never linked an email. SSO customers whose link included an email never see it.
After the machtiging is signed the customer receives a confirmation email in your branding, including the authorized EAN, and lands on the dashboard.
iDIN verification (planned)
iDIN verification is on the roadmap and not yet available in the portal. This section describes the intended design; contact Joulo if you want to be part of the rollout.
Tenants will be able to enable iDIN as the identity step. The customer selects their bank and logs in as they would for online banking; the bank returns verified data to the portal:
- Name and address • confirmed against what you supplied via SSO or what the customer entered at signup. The verified address also feeds the automatic EAN lookup, so the right connection is found without manual document checks.
- IBAN • the account the customer selects during the bank login becomes the payout account, verified including account holder.
A mismatch between the bank-verified data and the prefilled data will not block the customer; it will be flagged on the customer record in the admin portal so you and Joulo can review it before ERE submission.
iDIN verifies the person and the payout account, not who holds the energy contract on the connection. The machtiging step remains the place where the EAN and the authorization are confirmed.
An EAN connection can be authorized to only one party at a time. The machtiging step is the legal anchor of the whole flow • Joulo records who signed what, when, and under which clause version. The machtiging always names Joulo B.V. as the authorized registration provider (inboekdienstverlener), also on fully white-label tenants: the attribution setting only affects marketing copy, never the grant text.
The dashboard
After onboarding the customer sees sessions, estimated earnings, and registration status. In CPO-delivered mode the dashboard shows a charger card ("via your brand name") with the date of the latest data processing, so customers understand where their numbers come from; their customer number is shown on the registration card.
White-label CPO portal
Offer ERE payouts to your customers under your own brand • Joulo runs the registration and compliance rails; payouts run through Joulo or through you, per agreement.
SSO links
Mint single-use, signed login links from your own backend so customers land in the portal already identified.