Deftpower documented a case in which a Volkswagen ID.3 was billed for 800 kWh of charging which is ten times its battery 1. Errors like this one, along with invoice lines that have no charging record behind them and sessions that never end, usually reach an eMSP months after the fact, in a dispute with a partner and over a CDR that can no longer be changed, when the money is hard to recover. This article describes five places where eMSPs lose money in roaming and the signals in their own data that point to each of them.
Why These Losses Are Hard to See
According to Deftpower, up to 8% of EV charging invoices contain errors 2, and some of them have no CDR behind them at all. The same source reports that 80 to 90% of sessions still start with an RFID card 3, many of them unencrypted.
Part of the reason lies in how roaming is built. The charger communicates with the CPO over OCPP, the CPO communicates with you over OCPI, and you bill the driver in your own system, often at the end of the month. You never see the charger itself, only station status, sessions and CDRs. A CDR cannot be changed once it has been sent 4, so any correction arrives as a separate credit CDR 5, sometimes after the customer has already paid.
Leak 1. One Card in Two Places at Once
Cloning a charging card takes little effort. Many cards are unencrypted and identified only by a serial number stored on the chip, and some providers even print that number on the plastic., and cloned car-sharing cards have been sold online as “free charging” 6. When the CPO does not recognise a card, it may ask you for authorization in real time, and your approval stays with the session until it is billed.
Who pays. The cardholder, the fleet and you, with fleet cards being the most exposed, because the person who sees the bill isn’t the person holding the card.
Warning signs. Look for a card that charges in two locations at the same time, for consecutive sessions too far apart to drive between in the time that passed, and for a sudden rise in sessions and new locations over a few days. Another signal is a card that suddenly starts charging without a real-time check.
Blind spot.
The weak point is the offline window. If the operator allows offline charging, a disconnected charger can start a session with a card it cannot verify. The operator may learn about it only after the charger reconnects and the session arrives flagged WHITELIST. False alarms carry their own cost: customers with several cards and drivers who travel frequently can also look suspicious. Blocking an honest customer costs money, just as letting a cloned card through does.
What to do. Confirm the case, replace the card and plan a gradual move of customers to app-based charging.
Leak 2. Check Before You Pay
After every session, the CPO sends a CDR with the energy delivered, charging time, parking time and total cost, which you then pay. The 800 kWh billed for a Volkswagen ID.3 came through exactly this route. To check the price, compare the charging periods in the CDR with the applicable rate: the tariff the CPO publishes over OCPI or, where relevant, the price set out in your roaming agreement. Apply the relevant time-of-day, kWh and duration rules to work out what the session should have cost before paying for it.
Who pays. The eMSP. If it pays an incorrect CDR without checking it first, it may absorb the loss. GreenFlux reports a growing share of disputed CDRs in roaming traffic and notes that some of this revenue is never recovered.
Warning signs. The typical discrepancies are a price that does not match the tariff published for that time of day, more energy than the connector could deliver at full power in that time, a session billed twice, and an invoice line without a CDR. Further checks compare total energy with the sum of the charging periods and the CDR timestamps with the last session update, and look for CDRs that have no matching session. Some eMSPs already set minimum rules for their roaming partners. Plugsurfing, for example, accepts CDRs only for customers authorized in real time and only when the energy, price and time values are positive.
Blind spot. Many CDRs are still checked by hand – so small errors slip through at volume. 7 Since a CDR cannot be edited once sent, every correction has to come as a separate credit CDR.
What to do.
Introduce a shadow calculation that recalculates each CDR using the applicable pricing data available for that partner and session date, whether from OCPI or a structured roaming agreement. Route CDRs without usable pricing data for manual review. Set tolerances, in money or as a percentage, so that your team spends time only on differences worth disputing.
Leak 3. Sessions That Never Turn Into Revenue
A session ends and the energy has been delivered, but the CDR arrives late or does not arrive at all. If your system was unavailable when the CDR was sent, you may need to retrieve it from the CPO for that date range. But this only happens if someone notices it is missing. Outages, repeated send attempts and corrections issued as credit CDRs add further delays.
In most cases the CPO bears the loss, because a session that never becomes a CDR is energy that nobody invoices. For you, the risk lies in timing: a CDR that arrives late or has to be retrieved again may become billable only in a later cycle, or not at all, and the same gap can leave you with invoice lines that have no record behind them. 8
Signs of this leak include completed sessions that still have no CDR after several days, partners whose CDRs regularly arrive late, and credit CDRs for sessions that have already been invoiced. 9 These cases are easy to miss during month-end reconciliation, where data quality problems delay cash 10, and CDR errors often come to light only months later, as disputes 11. Telecom operators faced the same issue, because roaming records that arrive after the billing cycle closes often can no longer be re-rated, and late records and re-rating are among the reasons revenue assurance became a separate discipline in telecoms.
A practical first step is to measure the gap. Match each session to its CDR by session ID and authorization reference, use token, EVSE and time where those are missing, and count the sessions left without a match. Track CDR latency for each partner at the median and at the 95th percentile.
Any completed session that still has no CDR after a set number of days should be treated as a cost still on its way to you. Estimate it using the applicable tariff or agreed roaming price, so you can bill the driver on time and reconcile the amount when the CDR arrives.
Leak 4. Allow or Deny: Accounts That Were Never Going to Pay
In roaming, you vouch for every session in real time, or through the token list you’ve shared., often about an account you know very little about.
Deftpower describes the pattern 12: someone opens an account with a card that holds almost no money, passes the small test charge at sign-up, shares access with other drivers and disappears when the bill arrives. Some accounts are opened with a low limit, access is resold, and a new account appears after each block. You carry the cost, because you owe the CPO for every session you approved, while you collect from the driver only later.
The first signals appear early. A new account may charge far more in its first days than a typical customer, or across many locations in a short time, before a payment fails. Resold access usually shows up as one account running parallel sessions at several stations, which means they were started from your app. Over the same period, the value of unpaid sessions on the account grows.
The approval step is where this is hardest to catch. Not every CPO requests authorization in real time, and not for every session 13, so part of this charging becomes visible only in a session update or a CDR, after the energy has been used.
Payment holds at session start, prepaid wallets and per-session billing are common safeguards. Each limits exposure in a different way, but also adds friction. Holds, for example, tie up money on the driver’s card, and drivers dislike amounts such as €40 14. Set approval, hold and refusal rules according to the potential exposure and the account’s payment history, with a clear threshold for unpaid balances.
Leak 5. Station or Card: Telling Failures From Fraud
A session that never ends may point to a broken charger or to a cloned card.
Charger failures are common. More than one in eight charging attempts in Sweden fails, and half of drivers in Norway report having found a fast charger out of order 15. In OCPP 1.6, the charger reports such problems to the CPO as a Faulted status with an error code, or as a session stopped with a reason such as PowerLoss or Reboot 16.
Who bears the cost depends on the cause. A meter that reads too low costs the CPO, because energy is delivered but never billed. A meter that reads too high costs you and your driver until someone disputes the CDR. A cloned card on a working charger costs you, since you pay the CPO for every session. A wrong diagnosis moves the cost to the wrong party, or to an honest driver who has been blocked.
Failures and fraud leave similar traces in charging data, for example:
- a session that runs for a day without delivering energy,
- sessions that deliver no energy at all,
- two simultaneous sessions on one card,
- more energy than the connector can deliver (where the connector’s maximum power is published),
- a meter reading lower than the energy delivered.
To tell them apart, check for each anomaly what share of a station’s sessions and drivers it affects and at how many stations it appears for the same card. An anomaly concentrated at one station points to the station and should go to the CPO with evidence. An anomaly that follows one card across many stations points to the card and should go to your analyst.
For an eMSP this is harder than for a CPO. The CPO receives heartbeats, error codes and meter values over OCPP, while you receive only station status, sessions and CDRs over OCPI, and station status can be delayed or show as “unknown”.
What It Takes to Close These Leaks
Each of these leaks can be traced in data you already hold, in OCPI and in your own billing system. Each of them also sits where two systems meet, so a partner who understands only one side is likely to misread the data, for example by blocking customers who travel a lot, paying a CDR that nobody recalculated or blaming a driver for a faulty charger. Before you hand responsibility for your revenue to an external partner, check that they understand how money moves between OCPP, OCPI and your billing.
ChargeGuard is built on this approach. It assigns each card a risk rating with reasons an analyst can confirm, recalculates every CDR against the published tariff and separates station failures from fraud.
Over the coming weeks we will publish a separate article on each of these five leaks, starting with cloned cards. Want to talk about your issue?
Contact Bartosz: Calendly – Bartosz Drzewinski | SPM @ Fabres
.
Sources
- Deftpower: Intentional and unintentional fraud in EV charging (Oct 2024)
- Tap Electric: RFID charge card fraud case study (2025)
- ChargeUp Europe: The security layers behind EV charging fraud protection (Jul 2026)
- GreenFlux: EV roaming maturity
- Swift Charging: EV charging roaming checklist (2026)
- Umbrex: Roaming settlement in EV charging (2026)
- Simplico: OCPI explained (Aug 2026)
- EVRoaming Foundation: OCPI versions (Aug 2025)
- Plugsurfing: Roam OCPI Tokens module (2026)
- Plugsurfing: Technical requirements
- Dagens PS / Symbioen: failed charging attempts in Sweden (Jul 2026)
- NRK: Norwegian drivers and out-of-order chargers (Aug 2025)
- OCPI 2.2.1: CDRs module and
- . Tokens module
- OCPP 1.6J reference (ocpp.md) and
- OCPP reference (Plugchoice)
Want to read our Case Study for NAF? Click here!
Want to discuss with our Strategic Partnership Manager about increasing your business?
Contact Bart, author of this article!
