EV Charging Tariffs in India: Per kWh, Per Minute, Idle Fees and the Maths Behind the Bill

A driver plugs in, charges for forty minutes, and sees a number on the screen. Behind that number is a chain of decisions the operator made months earlier, usually in a hurry, usually on the day the first charger went live. Most billing disputes we have handled trace back to one of those decisions rather than to a bug. The tariff was set up in a way that made sense for the first charger and stopped making sense at the tenth.

We build and run PlugEV, an OCPP charging management system live on 40-plus chargers across two Indian cities, so the billing engine is something we operate rather than something we read about. This is the part of a charging business that nobody puts on the pitch deck: how the bill is actually computed, which pricing model is honest to the driver and which one quietly protects the operator, where the calculation breaks, and how the money gets split with whoever owns the parking bay. If you are setting up tariffs this month, read the last section first.

The four ways to price a session, and who each one is fair to

Every tariff engine we have seen boils down to four models, alone or combined. The choice matters more than the rate, because the model decides who pays for a slow car, an idle car, and a charger that stalls.

Per kilowatt-hour

The driver pays for the energy that went into the battery. This is the fairest model and the one drivers understand instinctively, because it is how they already buy petrol. It needs a meter reading you trust at the start and end of the session, and that is where the engineering lives. A car that charges slowly pays the same for the same energy as a car that charges fast, which is exactly right from the driver's side and mildly painful from the operator's, because a slow car occupies a bay that could have earned more.

Per minute

The driver pays for time connected. Operators like this because it prices the bay rather than the electrons, so a slow charger or a car that tapers still pays for the space. Drivers dislike it for the same reason. A car at 80 per cent state of charge draws a fraction of what it drew at 20 per cent, so the last quarter of a per-minute session buys very little energy at the same rate. On DC fast chargers where taper is steep, per-minute pricing can mean the driver pays twice as much per unit of energy in the final stretch as in the first, and they notice.

Flat per session

One price to plug in, whatever you take. Simple to explain, simple to bill, and wrong for almost everyone. A driver topping up 5 kWh subsidises a driver taking 40. It survives at a few destination sites where the charging is really a perk of the parking, and nowhere else.

Hybrid: per kWh plus an idle fee

This is where most operators end up once they have run a few hundred sessions and looked at the data. Energy is billed per kWh, which is fair. Time is billed only after the car has stopped drawing and is simply occupying the bay, which is the behaviour that actually costs the operator money. It takes more engineering, because the system has to know when charging ended rather than when the session ended, and those are different moments. The rest of this article is mostly about making that distinction reliable.

Where the number on the screen actually comes from

Under OCPP 1.6-J, which is what almost every charger in India speaks, the energy figure for a session comes from three places. If the message names below are new to you, our OCPP implementation guide covers the transaction lifecycle first. StartTransaction carries the meter reading when the session begins. StopTransaction carries the reading when it ends. In between, the charger can send MeterValues messages at an interval you configure, each carrying a sampled value for a measurand, and the one that matters for billing is Energy.Active.Import.Register, the cumulative energy imported in watt-hours.

Cumulative is the important word. The register only goes up. So the energy for a session is the stop reading minus the start reading, and the intermediate samples are there to show progress and to let you reconstruct a session if the stop message never arrives. If your billing code sums the intermediate samples instead of subtracting the endpoints, you will overbill, and it will look right in testing because the numbers are plausible.

Three things we learned the hard way about those readings:

• Some chargers report in Wh and some in kWh, and the unit is declared in the message. Read it every time. A tariff engine that assumes one unit will be off by a factor of a thousand on the first charger from a different vendor.
• Configure the sampling interval for the bill, not the dashboard. Every 60 seconds is fine for a live status page. For billing, what matters is that the final StopTransaction reading is correct; the samples only matter if that message is lost.
• Meter accuracy is a hardware question the software cannot fix. A DC charger's internal meter is measuring on the DC side after conversion losses; the DISCOM meter on the AC side will always read higher. You bill from the charger's meter and you pay the DISCOM from theirs, and the gap between them is your conversion loss, which belongs in your cost model rather than on the driver's invoice.

Idle fees, the tariff almost everyone gets wrong the first time

An idle fee charges a driver for staying plugged in after the car has finished charging. The intent is fair: a full car in a bay blocks a driver who needs it. The implementation is where it goes wrong, because the system has to decide when charging finished, and there are two signals for that and neither is perfect.

The first is the charger's status. Under OCPP 1.6-J a charger reports SuspendedEV when the vehicle has stopped drawing and SuspendedEVSE when the charger itself has paused. SuspendedEV is the one you want, and it is reasonably reliable on newer hardware. On older chargers it is sometimes never sent, or sent when the car pauses briefly for battery management and then resumes.

The second is power draw. If the MeterValues samples show the register barely moving for several consecutive intervals, the car is effectively done regardless of what status the charger reports. We use both: idle starts when the charger reports SuspendedEV or when power has been under a small threshold for a set number of samples, whichever comes first, and it does not start at all during the first few minutes of a session because some cars draw almost nothing while they negotiate.

Then there is the grace period, and this is a policy decision rather than a technical one. Ten minutes is common. It exists because a driver cannot teleport back to the car the moment it hits 100 per cent, and an idle fee that starts instantly generates a complaint for every session rather than revenue. Publish the grace period on the charger and in the app, put the idle rate on the same screen as the energy rate, and show the idle time as a separate line on the invoice. An idle fee the driver did not know about is not a tariff, it is a dispute.

Offline sessions are where billing actually breaks

A charger on a mobile data connection in a basement car park will lose connectivity. Not might. Will. What happens to the session that was running when it dropped is the single biggest source of billing errors we have seen, and the protocol handles it better than most operators' code does.

OCPP 1.6-J chargers are required to queue transaction-related messages while offline and send them when the connection returns. So a session that ran entirely offline will typically arrive as a StartTransaction and a StopTransaction, both with correct meter readings and correct timestamps, some time after the driver has left. The bill is computable. The problem is what your system did in the meantime.

1. If you billed the driver when the connection dropped, using the last sample you had, you underbilled, and now you have a second amount to collect from someone who has driven away.
2. If you showed the session as ended on the dashboard when the charger went dark, the site host may have already sent someone to unplug the car, and you have a different kind of dispute.
3. If the charger lost power rather than just connectivity, the StopTransaction may never come. Then you have a StartTransaction, some samples, and nothing else, and you need a rule for it.

The honest policy, which we use: a session with no StopTransaction is billed from the last MeterValues sample received, marked as estimated on the invoice, and never rounded up. If the charger later sends the real StopTransaction, the estimate is replaced and the difference is settled, in the driver's favour if it went down and as a separate line if it went up. Drivers accept an estimated bill that says it is estimated. They do not accept a confident bill that turns out to be wrong.

Time-of-day pricing: when it is worth the complexity

Several state electricity regulators in India publish time-of-day tariffs for commercial connections, and some have specific tariff categories for EV charging stations, with cheaper units in off-peak hours. If your DISCOM bills you that way, passing a version of it to drivers is reasonable: a lower rate late at night encourages the fleet and depot charging that is your steadiest revenue anyway.

Two cautions. First, check your own tariff order before you design anything, because the categories, the hours and whether EV charging even has its own slab vary by state and change with each tariff year. Second, a session that starts at 9:55 pm and ends at 11:10 pm crosses a boundary, and your engine has to split the energy across the two rates using the samples, not just apply whichever rate was active at the start. That is easy to get wrong and easy to test for, so test for it.

If your DISCOM bills you a flat commercial rate, time-of-day pricing on the driver side is mostly complexity for its own sake. Skip it until you have a reason.

Splitting the money with the site host

Most public chargers sit on land the operator does not own. A mall, a hotel, a housing society, a fuel station. The site host wants a share, and the arrangement you agree decides what your billing system has to be able to report. We have seen three shapes:

• Revenue share. The host takes a percentage of session revenue, usually after payment gateway fees. Simplest to agree, and it means your system has to produce a per-site revenue statement the host can audit, session by session, not just a monthly total.
• Fixed rent. You pay for the bay and keep everything. Cleanest for the software, riskiest for a new site where you do not yet know the utilisation.
• Energy pass-through. The host's electricity connection powers the charger, the host pays the DISCOM, and you reimburse energy at cost plus a margin. This is where the meter gap from earlier matters: you are reimbursing from the DISCOM meter and billing drivers from the charger meter, and the difference is real money that has to be in the agreement.

Whichever model, the requirement on the software is the same: every session must carry the site it happened at, the energy delivered, the amount billed, the gateway fee, and the amount actually settled, in a form you can hand to the host without editing. Operators who reconcile this in a spreadsheet at month end stop being able to at around the fifth site.

The GST question, and what the software has to do about it

Whether EV charging is treated as a supply of electricity or as a service has been argued both ways in India, and the answer affects what rate, if any, sits on the invoice. We are not going to tell you which applies to you, because it depends on your registration, your state and how your business is structured, and this is exactly the kind of question a chartered accountant should answer once, in writing, before you invoice anyone. Our post on OCPP and UPI payments goes further into reconciliation if that is the part you are stuck on.

What we can say is what the billing system has to do regardless of the answer. The tax rate is configuration, not code, per site if necessary, so that a change in treatment is a settings edit rather than a deployment. The invoice itemises energy, idle time and tax as separate lines. And every invoice is generated from the same session record the host statement is generated from, so the numbers agree with each other without anyone reconciling them.

If you are setting up tariffs this month

1. Bill energy per kWh. It is the model drivers trust, and every serious operator ends up here.
2. Add an idle fee with a published grace period, and start it from SuspendedEV or a power threshold, not from the session end.
3. Compute energy as stop reading minus start reading. Never sum the samples. Read the unit from every message.
4. Decide your offline rule now, before the first basement charger, and make estimated bills say they are estimated.
5. Keep the tax rate and the host split as per-site configuration so the next agreement is a settings change.
6. Make every session carry its site, energy, billed amount, fee and settled amount. That one record is your invoice, your host statement and your dispute log.

None of this is exotic. It is the difference between a charging network that earns what its chargers deliver and one that leaks a few per cent on every session without knowing where.