How does the OCPI billing chain work?
OCPI CDR billing settles money along a chain: the driver pays the eMSP, the eMSP pays the CPO, and the CPO pays for electricity and infrastructure. The Charge Detail Record is the document that authorizes each hop, so its accuracy decides whether settlement clears or stalls.
When a driver charges their EV on an OCPI roaming network, money flows through a chain of parties:
Driver pays the eMSP (their service provider), who pays the CPO (the network operator), who pays for the electricity and infrastructure.
OCPI CDRs (Charge Detail Records) are the documents that make this chain work. They're the invoices of the EV charging world. Get the CDR wrong and every party downstream inherits the error, which is why teams that have run live roaming settlement treat the CDR as a financial artifact, not a telemetry log. For protocol context on how sessions reach this point, see our OCPI overview and the OCPP-to-OCPI relationship.
What do finance and operations need before go-live?
Before go-live, finance and operations need a defined source of truth for each session, a tariff-versioning rule, audited rounding and tax logic, and a named owner for disputed CDRs. Without those four answers, OCPI billing is not launch-ready even when every endpoint returns 200.
Most CDR problems are not discovered by protocol engineers. They are discovered when finance cannot reconcile invoices, support cannot explain a charge, or a roaming partner rejects a settlement file.
Before launch, rollout teams should be able to answer:
- which session record is the source of truth when charger data and backend data disagree
- how tariff versions are linked to a session at the moment charging starts
- how rounding and tax rules are applied and audited
- who investigates missing, duplicated, or disputed CDRs
If those answers do not exist, billing is not launch-ready even if the OCPI endpoints respond correctly.
OCPI CDR fields and structure
An OCPI CDR captures everything needed to calculate and verify a charging session's cost: session identity, location, energy and metering data, and the tariff applied. Each block exists so the receiving eMSP can independently recompute the total rather than trust the CPO's number blindly.
A CDR captures everything needed to calculate and verify a charging session's cost:
Session identification
- CDR ID — unique identifier
- Session ID — links to the real-time session record
- Start/stop timestamps — when charging began and ended
- Auth reference — which token was used and how
Location details
- Location ID, EVSE UID, Connector ID — exactly where the charging happened
- Connector type and power — AC/DC, kW rating
Charging data
- Total energy — kWh delivered
- Charging periods — time segments with different tariff conditions
- Meter values — start and end meter readings
Cost calculation
- Tariff ID — which pricing structure was applied
- Total cost — the final amount including taxes
- Currency — ISO 4217 currency code
How do OCPI charging periods affect billing?
OCPI charging periods split one session into time segments that each carry their own pricing dimensions, so a single charge can mix peak energy rates, off-peak rates, and parking fees. The CDR sums these periods, and mismatched period boundaries are a frequent root cause of CPO-versus-eMSP total disputes.
This is where OCPI billing gets interesting. A single session can have multiple charging periods, each with different pricing rules.
Consider this scenario: a driver charges for 2 hours at a station with time-of-day pricing.
Period 1: 17:00 - 18:00 (peak rate)
- Energy: 15 kWh × €0.45/kWh = €6.75
- Time: 60 min × €0.10/min = €6.00
Period 2: 18:00 - 19:00 (off-peak rate)
- Energy: 20 kWh × €0.30/kWh = €6.00
- Time: 60 min × €0.05/min = €3.00
Total: €21.75
Each period has dimensions that describe what's being charged:
ENERGY— per kWhTIME— per minute of chargingPARKING_TIME— per minute after charging completesFLAT— one-time fee
The OCPI CDR lifecycle
The OCPI CDR lifecycle runs from session start to settlement: the CPO streams real-time session updates, finalizes cost when charging stops, generates the canonical CDR, pushes it via the CDRs module, and the eMSP validates before paying. Each stage has a failure mode that surfaces later as a billing exception.
1. Session starts
When a roaming session begins, the CPO creates a session record and pushes real-time updates to the eMSP via the OCPI Sessions module.
2. Session ends
When the driver stops charging, the CPO finalizes the session and calculates the total cost.
3. CDR generation
The CPO generates a CDR with the complete cost breakdown. This is the canonical billing record.
4. CDR delivery
The CDR is pushed to the eMSP via the OCPI CDRs module, the settlement record standardized by the EVRoaming Foundation. The eMSP validates it against the session data they received during charging.
5. Settlement
The eMSP invoices the driver and remits payment to the CPO (minus their commission). Settlement terms vary by agreement — typically monthly.
What are the most common OCPI tariff calculation pitfalls?
The most common OCPI tariff calculation pitfalls are rounding at the wrong level, unhandled step tariffs, ambiguous parking-time start, and mismatched VAT treatment. In mixed-fleet roaming rollouts, these rarely fail loudly: they surface as cent-level drift that only becomes visible once monthly settlement volumes magnify it into a reconciliation gap.
The table below maps each pitfall to where it bites and how teams typically catch it during integration testing rather than in production.
| Pitfall | Where it goes wrong | How to catch it early |
|---|---|---|
| Rounding level | Rounding per dimension instead of per charging period | Replay sample sessions and diff totals against the partner |
| Step tariffs | Threshold pricing (first 50 kWh, then a lower rate) not modeled | Test sessions that straddle each threshold boundary |
| Parking time | Start of parking time defined differently across partners | Align the trigger event in the roaming agreement, then test |
| VAT handling | Tax-inclusive total_cost interpreted differently per side | Compare itemized cost fields, not just the grand total |
Rounding errors
The OCPI specification defines that costs should be calculated per charging period and rounded to the smallest currency unit. Rounding at the wrong level (per dimension instead of per period) causes discrepancies between CPO and eMSP calculations.
Step tariffs
Some tariffs have thresholds: "First 50 kWh at €0.30, then €0.25/kWh." If your tariff engine doesn't handle step functions, you'll overcharge or undercharge.
Parking time ambiguity
When does parking time start? OCPI says it starts when energy delivery stops but the vehicle remains connected. Some implementations start it when the session is authorized but before energy flows. Align with your roaming partners.
VAT handling
OCPI CDRs include total_cost (with tax) and optionally total_fixed_cost, total_energy_cost, total_time_cost, total_parking_cost. Ensure your tax calculations match your roaming partner's expectations.
Why does OCPI CDR reconciliation matter?
OCPI CDR reconciliation matters because the CPO and the eMSP each compute totals independently, and any divergence becomes a payment dispute. Reconciliation compares both sides field by field, flags outliers, and resolves them before a settlement file is rejected. Teams that bolt it on after launch usually end up reconciling in spreadsheets under deadline pressure.
CDR reconciliation is the process of ensuring that CPO and eMSP records agree. Discrepancies happen due to:
- Clock drift — charger and backend clocks diverge
- Meter accuracy — physical meters have tolerances
- Tariff interpretation — different implementations of the same tariff specification
- Network issues — CDRs lost in transit
Build reconciliation into your system from day one. Compare CDRs against session data, flag outliers, and investigate discrepancies before they become financial disputes.
Which acceptance tests should pass before settlement starts?
Before settlement starts, five tests should pass: session-to-CDR matching, deterministic tariff replay, rounding checks on edge-case sessions, partner reconciliation on sample CDRs, and an exception workflow that needs no spreadsheets. We treat these as go-live gates because each one maps to a dispute pattern we have seen recur across roaming integrations.
Treat these as go-live gates, not optional QA:
- Session-to-CDR matching: every completed roaming session should produce exactly one expected billing record.
- Tariff replay: rerun known sample sessions against the tariff engine and confirm the same totals are produced repeatedly.
- Rounding checks: test low-value, edge-threshold, and long-duration sessions where small mistakes compound.
- Partner reconciliation: exchange sample CDRs with at least one roaming partner and compare totals field by field.
- Exception workflow: verify teams can identify, reprocess, and annotate a disputed or missing CDR without manual spreadsheet work.
If your vendor cannot walk through these tests, the platform is not proving billing readiness. It is only proving API availability.
How EV Cloud handles OCPI CDR billing
EV Cloud automates the OCPI CDR lifecycle so finance, support, and partner operations work from one record. It generates CDRs from OCPP transaction data, applies a tariff engine covering every OCPI pricing model, syncs sessions with eMSP partners, and surfaces discrepancies in a reconciliation dashboard before they become disputes.
EV Cloud can automate the CDR lifecycle and reduce manual billing work:
- Automatic CDR generation from OCPP transaction data
- Tariff engine supporting all OCPI pricing models (energy, time, parking, flat, step)
- Real-time session sync with eMSP partners
- Reconciliation dashboard showing CDR status and discrepancies
- Export in OCPI-compliant JSON format
That matters most when finance, support, and partner operations need one place to inspect how a total was produced and where a discrepancy started.
How should buyers turn OCPI billing into a platform decision?
Buyers should treat OCPI CDR billing as a platform-selection criterion, not just a partner-integration task. The data model, tariff engine, and reconciliation tooling decide how painful billing operations become, so evaluate them as deliberately as charger connectivity.
If roaming billing is central to your business model, do not evaluate vendors only on charger connectivity.
Use the EV charging software RFP checklist to pressure-test tariff handling, reconciliation, and export workflows. Then use the comparison hub and the pricing page to move from protocol fit into rollout and commercial fit.
