Run your charging network in Turkey without writing Turkish regulation into your software
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.
- Connects over OCPI
- EPDK and GİB reporting
- No report is lost
- Can run on your own servers
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:
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.
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.
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
- 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
"The report went out" is never just a claim — every step is visible on screen.
EPDK Communication
Every report, its status, attempt count, EPDK record number and the body sent
Proof on screen that reports go out
EPDK Manual Reporting
Manual reporting of availability and price data that does not come from the CSMS
The operator can close the gap between the field and the system
Registry Matching
CSMS inventory and the EPDK registry side by side
The most critical setup step is visible; a wrong match does not stay silent
Reconciliation
What the regulator holds compared with what the system holds
Catches the "I thought I sent it" error
GİB Sales Report
Period sales, missing lines and why they are missing
The data going to the e-document integrator can be audited
Payment Institutions
Which charging network collects payments through which institution
In a multi-network business each network keeps its own agreement
Payment Terminals
Card readers at the charger and the status of the receipt address
The driver's QR code never leads to an empty page
Definitions
Licence holders, CSMS connections, roaming partners
A multi-network business is managed from one panel
Where it sits in the market
We solve regulatory reporting as a separate layer that connects to your charging network software by protocol.
An open-web scan on 24.09.2026 found no provider selling EPDK compliance as a separate product that plugs into another company's CSMS; existing offers provide it as a feature inside their own charging management software or as legal consultancy.
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.
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.
Run your charging network in Turkey within the rules
Let us show how it connects to your CSMS on your own scenario.
Part of the SmartŞarj family.