Every paid charging session ends in a single document that decides who pays whom and how much: the charge detail record, or CDR. Drivers never see it directly, but it drives invoices, roaming settlements, tax reporting and disputes. When CDRs are wrong, money is lost quietly and partner relationships suffer.
This guide explains what a CDR contains, how a CSMS builds it from OCPP data, and how to reconcile CDRs with partners.
- A CDR is the final, immutable record of a completed charging session.
- It is built from OCPP transaction and meter data plus the applicable tariff.
- CDRs are never edited after sending; corrections are made with credit CDRs.
- Monthly reconciliation against your own session data prevents silent revenue leakage.
What a CDR is
A CDR describes a charging session after it has ended: who charged, where, when, how much energy was delivered, which prices applied and what the total cost is. In roaming, the CPO sends CDRs to the eMSP, which uses them to bill its driver and to pay the CPO. Internally, the same record is the basis for your own invoices and reports. The live counterpart during charging is the session object, explained in our guide to OCPI 2.2.1 modules.
Key fields in an OCPI CDR
| Field | What it contains |
|---|---|
| id | Unique CDR identifier from the CPO |
| start_date_time / end_date_time | Session start and end in UTC |
| session_id | Link to the related session |
| cdr_token | The token used: RFID UID, app token and its contract ID |
| auth_method | How the session was authorised, e.g. whitelist or real-time |
| cdr_location | Address, coordinates, EVSE ID and connector details at the time of charging |
| currency and tariffs | Currency and the tariffs that were applied |
| charging_periods | Time blocks with energy, time and parking dimensions |
| signed_data | Optional signed meter values for verification |
| total_cost, total_energy, total_time, total_parking_time | Totals used for billing |
| credit, credit_reference_id | Marks a credit CDR and links it to the original |
How a CSMS builds a CDR from OCPP
- Start: the charger sends StartTransaction (OCPP 1.6J) or a TransactionEvent with eventType Started (OCPP 2.0.1) with a start meter value and the authorised ID.
- During charging: MeterValues report energy, power and sometimes state of charge at configured intervals.
- Stop: StopTransaction or TransactionEvent Ended provides the final meter value, stop reason and, if configured, transaction data.
- Pricing: the CSMS applies the tariff that was valid at session start to the energy, duration and idle time.
- Finalisation: the CDR is created, stored and sent to partners or used for invoicing.
The message flow is described in our article on StartTransaction and StopTransaction.
Charging periods: the hidden detail
A CDR is not just a total. Charging periods split the session into blocks whenever a price-relevant dimension changes, for example when a time-of-use window ends or when the car stops charging but stays plugged in. Partners use these periods to recompute the price. If your periods do not match your published tariff, the eMSP cannot verify your total and will dispute it.
Credit CDRs and corrections
A sent CDR is final. If something was wrong, such as a meter error or a wrongly applied tariff, you send a credit CDR that negates the original, then a new correct CDR. This keeps an audit trail that both sides can follow. Never silently change totals in your own database without a matching credit.
Signed meter values
In markets with strict metrology rules, chargers can sign meter readings so that the driver or a third party can verify that energy values were not altered. These signed values can be carried in the CDR's signed data field. Check your local rules and your hardware's capabilities, as signing must be supported by the meter and firmware.
Common causes of wrong CDRs
- Missing stop transactions when a charger reboots or loses connectivity, leaving sessions open.
- Meter values that jump or reset after a firmware update.
- Clock drift on the charger, producing wrong times and wrong time-of-use pricing.
- Tariff changes applied to sessions that started before the change.
- Idle fees calculated on cable connection time instead of charging end time, see idle fees.
- Duplicate CDRs sent after retries without idempotency checks.
Reconciliation checklist
- Count sessions per partner in your CSMS and compare with CDRs sent and acknowledged.
- Compare total energy per partner per month with the partner's statement.
- Investigate sessions with zero energy, very long durations or negative values.
- Check that every credit CDR references an existing original.
- Agree a dispute window and process with each partner and document it.
Retention and privacy
CDRs contain personal data such as token identifiers and locations linked to a person. Keep them as long as tax and contractual obligations require, restrict access, and apply your data protection rules to exports and partner sharing.
Frequently asked questions
Who creates the CDR?
The CPO's platform creates it, because it controls the charger and the meter data. The eMSP receives and uses it for billing.
Can an eMSP reject a CDR?
An eMSP can dispute a CDR under the partner agreement. Clean tariffs, accurate meter data and clear charging periods reduce disputes.
How quickly should a CDR be sent?
As soon as the session is finalised. Delays create billing lags for the eMSP and make reconciliation harder.
Üreticy creates CDRs from OCPP meter data, applies your tariffs and keeps full logs for audits and partner reconciliation. See billing and reporting features or contact us.