EV Roaming Settlement: How a Roamed Charging Session Gets Reconciled and Paid
EV roaming settlement explained: how a roamed charging session becomes an OCPI CDR, is reconciled between CPO and eMSP, and is invoiced and paid.
By YoHub10 min read
💡 EV Roaming Settlement: Key Highlights
- The charge detail record (CDR) is the invoice line: kWh, UTC times, tariffs and total cost, unchangeable once sent.
- Three stages: data exchange, reconciliation, invoicing and payment.
- Two models: the hub invoices and pays out (YoHub in India), or parties pay each other while the hub reconciles (YoHub in the UAE).
- Most mismatches come from six causes: missing CDRs, Wh/kWh errors, UTC month boundaries, mid-session tariff changes, rounding, and zero-energy sessions.
- Corrections go through a credit CDR, never an edit.
EV roaming settlement is the work that turns a charging session on one company’s charger, started by another company’s customer, into money moving between the two. The driver sees a single charge in their app. Behind it, the charge point operator (CPO) that owns the charger and the e-mobility service provider (eMSP) that owns the customer have to agree on what happened, what it cost and who pays whom.
Below, we follow one roamed session from the driver’s tap to the CPO’s payout, name the OCPI 2.2.1 fields that carry the money, compare the two settlement models in use today, and list why the two sides’ numbers disagree.
What EV roaming settlement covers
Roaming lets an eMSP’s customers charge on a CPO’s network. Settlement is what happens after the session for that agreement to pay out. It has three parts, each of which can fail on its own:
- Data exchange. The CPO sends the eMSP session data and, at the end, a charge detail record (CDR). No CDR, nothing to bill.
- Reconciliation. Both sides compare their records, session by session, on energy (kWh) and amount.
- Invoicing and payment. Agreed CDRs are invoiced for a period with local tax, and paid.
OCPI standardises the first part in detail, says little about the second and nothing about the third. Invoicing and payment are set by the roaming agreement, or by the hub both parties connect to.
One roamed session, end to end
A driver uses an eMSP’s app to start a DC fast-charging session on a CPO’s charger. Both companies connect to a roaming hub. Here is what moves, and when.
| Step | What happens | OCPI 2.2.1 module |
|---|---|---|
| 1. Authorise | The eMSP has shared its customer’s token. For app tokens the spec recommends whitelist = NEVER: the CPO checks with the eMSP in real time. | Tokens |
| 2. Start | The CPO creates a Session with the token, location, EVSE, connector and currency. | Sessions, Commands (for an app start) |
| 3. Update | The CPO sends updates with PUT or PATCH so the app shows live kWh and cost. The status moves from PENDING to ACTIVE to COMPLETED. | Sessions |
| 4. Close | The driver unplugs; the CPO prices the session against the tariff that applied. | Sessions, Tariffs |
| 5. CDR | The CPO POSTs the CDR to the eMSP. eMSPs without push support GET it instead. | CDRs |
| 6. Reconcile | Both sides match the CDR to their own records on kWh and amount. | Outside OCPI |
| 7. Invoice and pay | CDRs for the period are invoiced with tax, and money moves through the hub or directly. | Outside OCPI |
The life of one roamed charging session. Steps 1 to 5 are defined by OCPI 2.2.1. Steps 6 and 7 depend on the settlement model.
Two details matter for finance. The Session and the CDR are separate objects, so a session can show in the eMSP’s app and never produce a CDR if a POST fails. And while the spec prefers near-real-time push, it allows periodic delivery, even monthly, by agreement (OCPI 2.2.1 CDRs module). An agreed delay is fine; an unnoticed one is a reconciliation problem.
For engineers building the integration, see the YoHub OCPI 2.2.1 developer page.
The CDR fields that decide the money
A CDR has more than 25 fields. These decide the money:
| Field | What it carries | Why it matters for settlement |
|---|---|---|
country_code, party_id, id | The CPO that owns the CDR, and a unique ID per CPO | Matching key. Duplicate or reused IDs cause double billing |
cdr_token | The eMSP’s token: its own country code and party ID, uid, type and contract_id | Decides which eMSP is billed. Wrong party ID means the wrong counterparty |
start_date_time, end_date_time | Start and end of the session, always in UTC | Decides which day and which month the session falls in |
total_energy | Energy charged, in kWh | The kWh side of reconciliation |
tariffs, charging_periods | The tariffs that applied, and the periods with their dimensions | Lets the eMSP check the price instead of trusting the total |
currency, total_cost | ISO 4217 currency, total cost with and without VAT | The amount side of reconciliation |
credit, credit_reference_id | Marks a credit CDR and points to the original | The only spec-compliant way to correct a CDR already sent |
Key fields of the OCPI 2.2.1 CDR object. Field names as published in the OCPI 2.2.1 CDRs module.
One rule shapes everything downstream: once sent, a CDR cannot be changed, replaced or deleted. To fix an error the CPO sends a credit CDR with a new ID, credit set to true, credit_reference_id pointing to the original, and the total as a negative amount, then a corrected CDR with another new ID. Any process that edits CDRs in place drifts away from what the other side holds.
Two EV roaming settlement models: hub settles vs peer to peer
Once the CDRs are agreed, someone invoices and someone pays. There are two ways to set this up, and YoHub runs one of each, depending on the market.
| Hub settles | Peer to peer, hub reconciles | |
|---|---|---|
| Where YoHub uses it | India | UAE |
| Who invoices the eMSP | The hub | The CPO, directly |
| Who pays the CPO | The hub, after collecting from the eMSP | The eMSP, directly |
| Counterparties for a CPO | One: the hub | Every eMSP it roams with |
| Who carries credit risk | The hub | Each CPO, for each eMSP |
| Does the platform hold funds | Yes | No |
| What the hub provides | Interconnection, reconciliation, invoicing and payout | Interconnection, plus kWh and amount reconciliation that both parties can see |
The two settlement models compared from a CPO’s point of view.
Hub settles: one invoice, one payout
In India, YoHub sits in the money flow. It issues one invoice to each eMSP with GST, collects from the eMSP, and pays each CPO. A CPO roaming with twenty eMSPs has one counterparty instead of twenty receivables. The trade-off: the hub carries the credit risk and holds the funds. How this works for Indian operators is described on the YoHub India page.
Peer to peer: the hub reconciles, the parties pay each other
In the UAE, YoHub never holds funds. The CPO invoices each eMSP directly and is paid directly. The hub makes sure both parties see the same CDRs with kWh and amounts matched, so the invoice doesn’t start an argument. The platform stays out of the payment flow, which is regulated in many jurisdictions; the cost is one commercial relationship per eMSP. The UAE setup is described on the YoHub UAE page.
Invoicing and GST in India
Public EV charging in India is taxed as a service, not as a sale of electricity. In September 2024 the GST Fitment Committee kept the tax on the full amount charged at public stations, following the Ministry of Power’s view that charging is a service that consumes electricity rather than a sale of it (Business Today). In the hub-settles model the hub issues the invoice, so the eMSP receives one GST invoice for all its roamed sessions instead of one per CPO. OCPI prices are quoted before VAT with the rate as a separate field, so total_cost can be checked with and without tax.
Why CPO and eMSP numbers disagree
When monthly totals don’t match, the cause is rarely fraud. It is usually one of these, and each leaves a sign in the data.
Sessions that never became a CDR
The eMSP saw the session, and may have billed its customer, but the CDR never arrived. Sign: a completed Session on the eMSP side with no matching CDR. Check: match Sessions to CDRs by session_id every day, not at month end.
Energy in Wh where kWh was expected
OCPI defines total_energy in kWh. Chargers often report meter values in Wh, so a missed conversion turns a 24.6 kWh session into 24,600 kWh. Sign: sessions with energy 1,000 times the charger’s plausible output. Check: reject any CDR whose kWh divided by charging hours exceeds the EVSE’s rated power.
Sessions that cross midnight or month end
OCPI timestamps are always in UTC (OCPI 2.2.1 types). A session in India that runs from 23:40 IST on 31 October to 00:35 IST on 1 November ends at 19:05 UTC on 31 October. A CPO that closes its books in IST counts it in November. An eMSP that closes in UTC counts it in October. Sign: month totals that differ by a handful of late-night sessions. Check: agree in the roaming agreement which time zone and which timestamp (start or end) assigns a session to a period.
Tariff changes during a session
Drivers accept the tariff valid at session start, and CPOs usually don’t switch mid-session, but OCPI allows it (OCPI 2.2.1 Tariffs module). An eMSP that prices sessions from its cached copy of the tariff will disagree with a CPO that published a new version mid-session. Sign: amount mismatches with matching kWh. Check: price against the tariffs carried in the CDR, not against the latest tariff on file.
Rounding and step size
OCPI 2.2.1 rounds consumed amounts up to the next multiple of a price component’s step_size. Systems that round differently end up a few paise or fils apart on every session. Sign: small, constant differences across many sessions. Check: agree on a tolerance per CDR and recompute with the same rounding rules.
Invalid and zero-energy sessions
A Session with status INVALID is, in the words of the OCPI 2.2.1 Sessions module, declared invalid and will not be billed. The spec is silent on zero-energy sessions, so one CPO may send a zero-kWh CDR with a flat fee while another sends nothing. Sign: CDRs with total_energy of 0 and a non-zero total_cost. Check: write the rule into the roaming agreement: is a zero-energy session billable, and if so, for what?
A settlement checklist for CPO and eMSP teams
These checks remove most disputes before they reach an invoice, under either model.
For CPO teams
- Send every completed session as a CDR, and retry failed POSTs until the eMSP confirms receipt.
- Convert meter readings to kWh before they reach the CDR, and run a plausibility check on kWh per hour.
- Include the
tariffsthat applied in every CDR, and version your tariffs instead of editing them in place. - Correct mistakes only with a credit CDR followed by a new CDR. Never resend a changed CDR under the same ID.
For eMSP teams
- Match Sessions to CDRs every day, and pull missing CDRs by date range instead of waiting for month end.
- Price-check CDRs against the tariffs in the CDR, with an agreed tolerance for rounding.
- Make sure each token carries the correct
party_id, so CDRs reach the right account.
For both sides
- Agree on the time zone and the timestamp (start or end) that assigns a session to a period.
- Agree a dispute record format: CDR ID, disputed field, both values, evidence, deadline.
- Reconcile daily on kWh and amount, and leave month end for invoicing only.
If you run a charging network, YoHub for CPOs explains how roamed sessions reach you and get paid. If you run an app or a fleet platform, YoHub for eMSPs covers the eMSP side of the same flow.
Frequently Asked Questions
What is EV roaming settlement?
EV roaming settlement turns a session where one company’s customer charges on another company’s charger into an agreed amount and a payment. It covers the charge detail record (CDR), reconciling energy and amount between CPO and eMSP, then invoicing and payment.
What is a CDR in OCPI?
A charge detail record (CDR) is the final billing record the CPO sends the eMSP. In OCPI 2.2.1 it carries energy in kWh, times in UTC, the tariffs applied, the total cost and the customer’s token. Once sent, it cannot be changed.
Who pays whom in EV roaming?
The eMSP pays the CPO for its customers’ sessions. When the hub settles, it invoices the eMSP, collects and pays the CPO. In the peer-to-peer model the CPO invoices the eMSP directly and the hub reconciles.
How do you correct a wrong CDR?
A sent CDR can’t be edited or deleted. The CPO sends a credit CDR (new ID, credit set to true, credit_reference_id pointing to the original, negative total cost), then a corrected CDR with another new ID.
Why do CPO and eMSP totals not match?
Usually: missing CDRs, energy in Wh instead of kWh, sessions crossing month end in UTC, mid-session tariff changes, different step-size rounding, or different rules for zero-energy sessions. Daily reconciliation catches most early.
Sources: OCPI 2.2.1 CDRs module | OCPI 2.2.1 Sessions module | OCPI 2.2.1 Tariffs module | EVRoaming Foundation, OCPI | Business Today, GST on public EV charging (Sept 2024)