Skip to main content

📄 Charge Detail Records (CDRs)

A Charge Detail Record (CDR) encapsulates the final details of a completed charging session for invoicing. Unlike the Session object, which is dynamic and reflects the current state of an ongoing session, a CDR is immutable – it captures the situation as it was at the start and throughout the session【343458627312853†L6813-L6827】.

Purpose​

CDRs are the basis for billing between the CPO and eMSP. The record must contain enough information for the eMSP to verify that the charge was calculated correctly. Gireve’s guidelines require CDRs to be sent immediately after a session ends so that the eMSP can show the price to the customer without delay【826352846409834†L1345-L1348】.

Composition​

A CDR must include the following:

  • Location, EVSE and Connector information – Identical to the values used at session start. If a street name changes after the session, the CDR must still include the original name【343458627312853†L6818-L6827】.
  • Tariff information – Tariff IDs and price components applicable during the session. Tariff data should reflect what was valid at the start of the session【343458627312853†L6818-L6827】.
  • Token details – The token used to start the session.
  • Charging periods – A list of periods with start/end times, dimensions (ENERGY, TIME, PARKING_TIME) and volume. A CPO must start a new charging period whenever a relevant price component changes (e.g. a different rate after 17:00 or a different power tier)【343458627312853†L6832-L6841】. Additional periods may be added at intermediate points.
  • Total cost – The final cost calculated by summing the cost of each price component, taking into account step_size rules. When switching from charging to parking or between tariff elements, only the step_size of the new price component is applied【343458627312853†L6857-L6883】.
  • Total time – Duration of the session, including both charging and parking. Gireve notes that out‑of‑order periods (when the EVSE cannot supply service) should not be charged【826352846409834†L1349-L1355】.

Store‑and‑forward​

As with Sessions and Tariffs, CPOs should implement a store‑and‑forward mechanism for CDRs. If a POST /cdrs request fails, the CDR must be stored locally and resent when connectivity is restored【826352846409834†L1369-L1378】.

Direct Payment integration​

When sessions are initiated through the Direct Payment module (EVRF), the CDR must include the authorization_reference from the StartSession request【661383774245363†L1749-L1783】. After sending the CDR, the payment terminal provider (PTP) may send a financial‑advice‑confirmation containing the settled amount and electronic funds transfer (EFT) data【661383774245363†L606-L637】. See the Direct Payment section for more details.

CDRs ensure transparent and accurate billing for both roaming and direct‑payment sessions.