ELPO Compliance · Turkey Compliance Layer
Your CSMS. Turkey-ready.
EPDK and GİB compliance without rebuilding your platform. The ELPO Turkey Compliance Package is a separate layer between your charging network software (CSMS) and Turkey's energy regulator EPDK and revenue administration GİB. Your CSMS speaks the language it already knows — OCPI — and the package takes on every Turkey-specific report.
Running a charging network in Turkey does not end with installing chargers
You have to report to two institutions, in two different formats, without delay:
EPDK
Is the connector available, did the session start, did it end, how much energy was delivered, what is the price — each a separate call with its own order and timing.
GİB
Registration of every charger and a sales report signed with the electronic seal.
A foreign CSMS knows none of this. The price of writing the regulation into your own code: the software changes whenever the rules change, a separate version per country and, worst of all, a dropped report that nobody notices.
The fix: a layer that separates regulatory reporting from your software
The Compliance Package sits between your CSMS and the regulator. Your CSMS sends data over the standard OCPI flow; the package prepares, sends and tracks the reports to EPDK and the sales report to GİB. For a CSMS that does not speak OCPI there is a simple REST gateway with five events.
Not a single line of Turkey-specific code in your CSMS.
Who it is for
Foreign CSMS and CPO software entering Turkey
Meet EPDK and GİB obligations without writing Turkey-specific code into your product.
Local charging network operators with their own software
When the rules change your software does not; the change is made in the package.
We solve regulatory reporting as a separate layer that connects to your charging network software by protocol.
Why you can rely on it — what has been measured
Everything below works in the product today and has been verified in the test environment.
| Reports really reach EPDK | Acceptances returned with a record number from the EPDK test environment |
|---|---|
| Reports go out on their own, not by hand | The queue is emptied every 30 seconds; the screen shows the time of the last send |
| A report that fails is not lost | Retried at growing intervals; every attempt is logged with its body and the regulator's reply |
| A rejected report can be fixed and resent | Once the registry data is corrected, the record goes back into the queue |
| The same report is never sent twice | Each record is claimed in a single transaction; a second pass does not touch it |
| A screen to match EPDK's official records | CSMS inventory on the left, EPDK registry on the right; unmatched records stand out |
| Each charging network picks its own payment institution | Defined per licence holder |
| Sessions of a CSMS that cannot push are reported too | The package reads completed sessions from the connected CSMS every hour; a record read this way is never reported twice |
| The real outcome of each report goes back to the CSMS | The result is delivered, signed, to the address the CSMS defines |
| The CSMS can read back from us what it sent | Every receiver-side endpoint of OCPI 2.2.1 and 2.3.0 works: locations, sessions, charge detail records (CDRs) and tariffs are sent and read back; each endpoint was tested one by one with a real CSMS key |
| The charging record of a station without an EPDK number is not lost | The record is not rejected but held; once the number is entered it goes to EPDK on its own, and the CSMS does not need to resend it |
| A CSMS without OCPI can connect too | A five-event REST surface: session started, ended, consumption, tariff, fault |
| The GİB sales report is produced and signed when a seal is configured | Without a seal the document is still produced and the screen says it is unsigned |
Screens and what they prove
- EPDK Communication
- Proof on screen that reports go out
- EPDK Manual Reporting
- The operator can close the gap between the field and the system
- Registry Matching
- The most critical setup step is visible; a wrong match does not stay silent
- Reconciliation
- Catches the "I thought I sent it" error
- GİB Sales Report
- The data going to the e-document integrator can be audited
- Payment Institutions
- In a multi-network business each network keeps its own agreement
- Payment Terminals
- The driver's QR code never leads to an empty page
- Definitions
- A multi-network business is managed from one panel
Common questions
- Do we have to change our CSMS?
- No. If your CSMS speaks OCPI it has nothing new to learn; the roles are the same as the standard CPO→eMSP flow. For a CSMS without OCPI there is a plain REST/webhook gateway.
- What happens when the regulation changes?
- The change is made in the Compliance Package; your CSMS is not affected. That is the reason this product exists.
- Will we know if a report fails?
- Yes. Every attempt is logged with the regulator's raw reply. If the queue stops, the indicator on screen shows for how many minutes it has been silent.
- Where is our data kept?
- The product can also be installed on your own servers. Work that touches customer data, such as signing with the electronic seal, is done on site and not sent out.
- Do we need to use SmartŞarj?
- No. The Compliance Package works with any CSMS; a charging network that does not use SmartŞarj can buy it too.