Türkiye
Built for Türkiye’s regulatory reality
The fields local reporting and tax rules need travel with the CDR as an OCPI extension. European hubs bolt this on afterwards; the hub started there. This page covers the extension, the binding reading of the specification, the fields captured at onboarding and the two gates.
Attribution
Whose specification it is
The extension is not the hub’s invention. E-Gridium implements the published specification; its reading of the open points is in the table below and is agreed with each partner in writing before integration.
OCPI-TR Custom Modules · v1.0.0The OCPI-TR custom module specification was authored by ZES. E-Gridium implements it as published and credits ZES for opening it to the ecosystem; where the specification leaves room for interpretation, the hub’s binding reading is listed below and agreed with each partner in writing before integration.
Source: ocpi-adapter · tr-cdr-additionals.controller.ts; docs/integration/TR_CDRADDITIONALS_PROFILE.mdInspect evidence
Türkiye CDR extension (tr-cdr-additionals)· Source code review
A dedicated controller and integration profile carry the utility rate in TRY/kWh, VAT breakdown and reporting identifiers next to each CDR. The underlying OCPI-TR custom module specification (v1.0.0, January 2026) was authored by ZES; E-Gridium implements it as published and credits ZES for the work.
Supports:That the Türkiye profile exists as an OCPI extension on both sender and receiver side.
Does not show:Regulatory acceptance by any authority; the fields are what the parties need for their own reporting.
Source: OCPI-TR Custom Modules specification v1.0.0 (ZES, 19 January 2026) and the hub source repository (private) · Verified4 October 2026
All evidence records →Türkiye profile: binding interpretation of tr-cdradditionals· Document
Eight rules the hub applies where the specification leaves room: unit price semantics and precision, VAT handling, versioned corrections, idempotency responses, discovery via version details, eventual matching with a 24-hour compliance-gap report, serial-number reading, transport security. Open points are confirmed with the specification’s author before integration.
Supports:The rule table on the Türkiye page.
Does not show:Regulatory acceptance; the profile is a technical agreement between integrating parties.
Source: OCPI-TR Custom Modules specification v1.0.0 (ZES, 19 January 2026) and the hub implementation profile docs/integration/TR_CDRADDITIONALS_PROFILE.md · Verified4 October 2026
Profile
Binding reading
The 8 rules the hub applies where the specification leaves room. Field names, status codes and units are written as they appear in the specification.
| Topic | Rule | Key |
|---|---|---|
| Utility rate | The active energy unit price valid for the location on the day of the session, in TRY per kWh with four decimals. Where a location has a time-of-use tariff, the session-weighted average is expected. | TRY/kWh · 4 decimals |
| VAT | The VAT-inclusive field is optional and is never derived when absent; the record is then marked as excluding VAT only. A VAT-inclusive value below the exclusive value is rejected. | VAT incl. · optional |
| Corrections | The object is immutable in the specification. On the receiving side the hub applies versioned append: a newer last_updated for the same CDR key is a correction; the latest version counts and earlier ones stay as an audit trail. As a sender the hub never re-sends an object. | last_updated · versioned |
| Idempotency | First record: 201 with a Location header. An identical retry: 200 with the same Location. Same last_updated with different content, or an older last_updated: 400 with OCPI status 2001. | 201 · 200 · 400/2001 |
| Discovery | The module is advertised in the OCPI version-details catalogue as tr-cdradditionals in the receiver role; partner support is discovered from the partner’s own version details, no extra configuration. | version details · receiver |
| Matching with the CDR | No ordering guarantee between the CDR and its additional record; matching is eventual on the CDR key. A Türkiye-scope CDR without its additional record after 24 hours is reported as a compliance gap, not rejected. Türkiye scope is decided by the location’s country. | CDR key · 24 h |
| Serial number | Read as the meter serial number; the EVSE is taken from the CDR’s own location data. | meter serial |
| Transport and security | The module uses the carrying OCPI channel’s authentication (Token B/C after the handshake); no extra credentials. Country and party codes are normalised to upper case; CiString fields accept printable ASCII only. | Token B/C · TLS |
Inspect evidence
Türkiye CDR extension (tr-cdr-additionals)· Source code review
A dedicated controller and integration profile carry the utility rate in TRY/kWh, VAT breakdown and reporting identifiers next to each CDR. The underlying OCPI-TR custom module specification (v1.0.0, January 2026) was authored by ZES; E-Gridium implements it as published and credits ZES for the work.
Supports:That the Türkiye profile exists as an OCPI extension on both sender and receiver side.
Does not show:Regulatory acceptance by any authority; the fields are what the parties need for their own reporting.
Source: OCPI-TR Custom Modules specification v1.0.0 (ZES, 19 January 2026) and the hub source repository (private) · Verified4 October 2026
Türkiye profile: binding interpretation of tr-cdradditionals· Document
Eight rules the hub applies where the specification leaves room: unit price semantics and precision, VAT handling, versioned corrections, idempotency responses, discovery via version details, eventual matching with a 24-hour compliance-gap report, serial-number reading, transport security. Open points are confirmed with the specification’s author before integration.
Supports:The rule table on the Türkiye page.
Does not show:Regulatory acceptance; the profile is a technical agreement between integrating parties.
Source: OCPI-TR Custom Modules specification v1.0.0 (ZES, 19 January 2026) and the hub implementation profile docs/integration/TR_CDRADDITIONALS_PROFILE.md · Verified4 October 2026
Module
The module
The module is advertised in the OCPI version-details catalogue in the receiver role; the CPO sends, the eMSP receives. It uses the carrying OCPI channel’s authentication and asks for no extra credentials.
OCPI modules →CPO: Sender · eMSP: Receiver
Türkiye profile: the CDR fields local regulation and tax rules need, carried as an OCPI extension.
Utility rate in TRY/kWh, VAT breakdown and the identifiers both parties need for reporting; sent by the CPO alongside the CDR. The profile was authored by ZES as the OCPI-TR custom module specification; E-Gridium implements it and thanks ZES for opening it to the ecosystem.
- Carries
- Unit price in TRY/kWh, VAT breakdown, reporting identifiers
- Matching
- On the CDR key, eventual; compliance-gap report after 24 hours
- Discovery
- version details · tr-cdradditionals · receiver
Last verified: 4 October 2026 · Source: ocpi-adapter · tr-cdr-additionals.controller.ts; docs/integration/TR_CDRADDITIONALS_PROFILE.md
Inspect evidence
Türkiye CDR extension (tr-cdr-additionals)· Source code review
A dedicated controller and integration profile carry the utility rate in TRY/kWh, VAT breakdown and reporting identifiers next to each CDR. The underlying OCPI-TR custom module specification (v1.0.0, January 2026) was authored by ZES; E-Gridium implements it as published and credits ZES for the work.
Supports:That the Türkiye profile exists as an OCPI extension on both sender and receiver side.
Does not show:Regulatory acceptance by any authority; the fields are what the parties need for their own reporting.
Source: OCPI-TR Custom Modules specification v1.0.0 (ZES, 19 January 2026) and the hub source repository (private) · Verified4 October 2026
Türkiye profile: binding interpretation of tr-cdradditionals· Document
Eight rules the hub applies where the specification leaves room: unit price semantics and precision, VAT handling, versioned corrections, idempotency responses, discovery via version details, eventual matching with a 24-hour compliance-gap report, serial-number reading, transport security. Open points are confirmed with the specification’s author before integration.
Supports:The rule table on the Türkiye page.
Does not show:Regulatory acceptance; the profile is a technical agreement between integrating parties.
Source: OCPI-TR Custom Modules specification v1.0.0 (ZES, 19 January 2026) and the hub implementation profile docs/integration/TR_CDRADDITIONALS_PROFILE.md · Verified4 October 2026
Onboarding and sandbox
Captured at onboarding
So that the extension fields can be populated on every CDR, both parties’ identity is captured at commercial onboarding. The technical gate opens the handshake and data flow; the financial gate opens real money.
Party record
- 01Legal name and tax number (VKN) of every party, recorded on the party record at commercial onboarding.
- 02Charging network operator licence number where the party holds one.
- 03Data processing agreement under KVKK with every partner before any personal data flows.
Technical gate
- Signed roaming participation agreement and data processing agreement
- Legal name, tax number and, where applicable, charging network operator licence number
- An OCPI versions endpoint reachable from the hub and a Token A for the handshake
- Sender implementations for locations, tariffs, sessions and CDRs; receiver for tokens and commands
Financial gate
Offered, settlement in dry-run- tr-cdr-additionals populated on every CDR
- Collection and invoicing details as set out in the agreement
The financial gate also closes on the hub side: a data processing agreement with every partner, regulatory registrations and the e-invoice rail. Until then settlement runs in dry-run and no invoice is issued.
Settlement and clearing →The hub’s output is a reconciliation summary, not a fiscal document; VAT and e-invoicing are the responsibility of the party that issues the CDR.
Why
Why Türkiye first
The roaming core was built on top of the local reporting fields, not the other way round.
Reporting starts in the CDR
The unit price, VAT breakdown and identifiers needed to report a charging session in Türkiye are not in the standard OCPI CDR. Instead of mapping them afterwards, the hub carries them with the CDR.
Both parties see the same data
CPO and eMSP look at the same CDR and the same extension fields; reconciliation is done from one record, not from different tables.
European hubs bolt it on later
Pan-European hubs solve local tax and reporting fields as an outer layer. ChargeBridge started from these fields; the roaming core was built on top of them.
How it proceeds
- 01Apply with your role and versions endpoint
- 02Sign the participation agreement and DPA
- 03Handshake in the sandbox, then accept relationships