EV Charging Billing Integration: Wiring Charging Revenue Into Your Finance Stack

EV Charging Billing Integration

Most charging platforms can take a payment. Very few can tell your finance team, on the fifth working day of the month, exactly which of last month’s 36,000 sessions were billed, which were settled, and which quietly went missing in between. That gap is what EV charging billing integration describes: not the card reader at the charge point, but the plumbing carrying a metered session from the charger, through your payment provider, into your ledger, your site-host payouts and your GST filings.

This is for CPOs and eMSPs with a finance or back-office function, and for enterprise and fuel-retail operators whose charging revenue has to land in an ERP that existed long before the first charger did. It stays deliberately clear of three neighbours: how drivers pay (EV charging payment options), how charging is taxed (GST on EV charging), and how a forecourt till talks to a charger (POS integration for fuel retailers). What follows is the back office.

Why EV Charging Billing Integration Is A Back-Office Problem, Not A Payments Problem

A single charging session produces four records in four systems, none authoritative for everything: an OCPP transaction from the charge point (start meter reading, stop meter reading, timestamps); a priced session in the platform; an authorisation, capture and settlement line at the payment provider, arriving a day or more apart; and eventually a journal entry, invoice and IRN in the ERP. Two hundred charge points at six sessions a day is 1,200 sessions daily and roughly 144,000 records a month, each capable of disagreeing with the other three. That is why billing integration for EV chargers stops being an IT nicety around the fiftieth charge point and starts deciding whether your revenue number is defensible.

The Four Integration Surfaces Between Chargers And Finance

Scope the work by surface, not by system. Each has its own cadence, failure mode and internal owner.

Surface 1 — Payment gateway and PSP

Charging is one of the few retail transactions where the amount is unknown when the customer commits. The near-universal answer is a pre-authorisation hold — a fixed reserve at session start, the real amount captured at stop. That is industry practice, not an RBI mandate, and it leaves two things to absorb.

First, authorised value and captured value are different numbers, so any dashboard reporting “revenue” from authorisations overstates it — several times over on a network where a ₹1,000 hold routinely captures at ₹212. Second, failed sessions run on a regulated clock: under the RBI’s turnaround time circular (RBI/2019-20/67, 20 September 2019), a failed card transaction must be auto-reversed within T+5 days, with ₹100 per day of delay payable to the customer suo motu, without them asking; UPI failures carry a tighter T+1. If your platform cannot raise a reversal straight from a session record, someone is doing it by hand against a deadline.

On settlement timing, check your contract rather than the internet. The Reserve Bank of India (Regulation of Payment Aggregator) Directions, 2025, issued on 15 September 2025, leave merchant credit timelines to the PA–merchant agreement, requiring only that it be fair and transparent about them. The widely repeated “T+1 is the rule” is no longer safe to hard-code; your reconciliation job should read the settlement window off your own agreement.

Surface 2 — Accounting and ERP

Sessions are not invoices, and the first decision is how many of the former become one of the latter. Three patterns cover almost every operator: a per-session invoice for walk-up retail; a daily summary journal per site, with session count and kWh as statistical quantities; and a monthly consolidated invoice per B2B account for fleets and corporates. Most networks run all three at once, which is why the mapping is agreed with finance before anyone writes code.

At SME scale that ERP is Tally or Zoho Books; at enterprise scale SAP or Oracle, fed by a nightly file or an API-posted journal. Either way the mapping debits a payment-provider clearing account — the cash has not arrived yet — and credits charging revenue split by site and tariff class, plus GST output tax. The site-host revenue share is accrued separately, as an expense. Netting it against revenue is the most common error here, and it understates your topline and your cost base in one stroke.

Surface 3 — Settlement to third parties

Site hosts come first, and Indian policy has already fixed the shape of that calculation on public land. The Ministry of Power’s revised consolidated guidelines make government and public land available for public charging stations on a revenue-sharing basis at a fixed ₹1 per kWh used for charging, paid to the land-owning agency quarterly, under an agreement that may initially run 10 years — ₹1/kWh also being the floor price where such land is bid out. Read that as an engineering requirement: the obligation is metered on energy dispensed, so a session delivered and never collected still owes ₹1 per kWh. Payout logic runs off the meter, not the bank statement.

Roaming settles differently. Under OCPI the Charge Detail Record is the only billing-relevant object in the protocol — issued by the CPO to the eMSP once a session concludes, carrying start and stop timestamps, total energy, total time, total cost and the tariff applied. Your roaming receivable is the sum of CDRs you issued, your partner’s payable the sum they accepted, and the gap between them is a dispute queue needing a named owner. Franchise payouts are the simplest of the three, provided everyone agrees the session table is the system of record.

Surface 4 — Tax and e-invoicing

Tax treatment belongs elsewhere; the integration point matters here because it constrains everything upstream. GST e-invoicing applies from ₹5 crore of annual aggregate turnover, and from 1 April 2025 a taxpayer at ₹10 crore or more cannot report an invoice, credit note or debit note older than 30 days to the Invoice Registration Portal. A billable session found in a quarterly review is, past that window, no longer e-invoiceable — revenue you can no longer legally document. That is why the cadence below is weekly.

Reconciliation Is The Real Work: The Three-Way Match

Everything above you install once. Reconciliation is the operating cost you carry forever, and it is a three-way match: meter values, settlement files, invoices issued. Two-way matching — cash against invoices — is the trap, because it silently accepts every session that never became an invoice at all.

Why kWh and cash never tie exactly

Five structural reasons, none of which are bugs:

1. Rounding. OCPP carries meterStart and meterStop as integer watt-hours, so a session is 23,456 Wh — 23.456 kWh. At ₹18.50/kWh the true value is ₹433.936 and you bill ₹433.94. Small, permanent, and it does not net to zero across 36,000 sessions a month.
2. Failed and aborted sessions. A charger faults at 0.4 kWh, a vehicle ends the session itself, a cable unlocks early. Energy was metered; the capture was voided or reversed.
3. Partial captures. Hold ₹1,000, capture ₹212. The ₹788 is neither revenue nor a discount, and booking it as either is how a network talks itself into a pricing problem it does not have.
4. Chargebacks cross periods. A March session reversed in April pulls cash out of a month whose books are closed.
5. Tariff-config drift. A site’s price changed at 14:00; a session ran 13:58 to 14:26. Unless the platform stores the tariff version actually applied against that session, the two sides of the match price the same kWh differently and nobody can prove which was right.

The reconciliation cadence a growing network needs

Daily: session count and kWh from the platform against authorisations and captures from the PSP — this catches dead chargers, stuck sessions and misconfigured connectors inside 24 hours. Weekly: captures against settlement files against invoices and IRNs issued; weekly rather than monthly, because a session that slips past the 30-day IRP window cannot be recovered. Monthly: revenue-share accruals and roaming CDR balances against partner statements, at close. Quarterly: the land-owning-agency share falls due, so accrual and payment must agree by then or the variance is already a quarter old.

Set a tolerance and enforce it: anything beyond, say, 0.5% of daily kWh or ₹500 of daily cash opens a ticket with a named owner. A reconciliation that reports a difference is a report. One that assigns it is a control.

What To Demand From A Charging Platform

Evaluate charging software against the back office, not just the driver app.

The data contract

• A per-session record exposing meter start and stop values and their timestamps — not a total kWh figure you have to take on trust
• An immutable session ID that survives re-pricing, refunds and re-issued invoices, so the audit trail walks in either direction
• The tariff version applied, stored against the session rather than looked up later
• Session state modelled as four distinct things — metered, priced, captured, settled — because conflating them is exactly how unbilled sessions hide
• Machine-readable settlement reports by site, tariff and partner, exportable without raising a support ticket

The API contract

• Documented REST endpoints plus webhooks for session start, stop and failure, so your ERP is event-driven instead of polling — see the EV charging API documentation for the shape this should take
• Idempotency on every write endpoint, so a retried webhook cannot double-post a journal entry
• The ability to re-issue an invoice without rewriting the session — a credit note against the original, never an edit in place
• Bulk export with pagination and stable ordering, so a re-run produces the same file twice

YoCharge’s payment and billing software is built around exactly this contract — gateway integration, per-session invoicing and exportable settlement records as one layer rather than four bolt-ons, sitting on the same session ledger as the rest of YoCharge’s charging management platform. It is the unglamorous half of the product, and the half a demo will not show you unless you ask. Ask.

The CPO Revenue Assurance Checklist

Six exception reports. Schedule them, give each an owner.

Build The Integration, Or Buy The Platform?

There is a clean line through this decision, and it is not the usual one. Build the mapping into your chart of accounts — cost centres, site codes, approval workflow. That is genuinely yours, it changes when the business changes, and no vendor can guess it.

Do not build the session ledger, the CDR exchange, the IRN queue, the pre-auth lifecycle or the retry logic beneath them. None of it differentiates you from another operator, all of it must be right on the first day of close, and each piece carries a regulatory clock — T+5 on reversals, 30 days on the IRP, quarterly on land revenue share. Our build vs buy analysis for EV charging software covers the cost and timeline side; the back-office view just narrows it. Buy the ledger, build the mapping.

Frequently Asked Questions

Sources: Ministry of Power — Revised Consolidated Guidelines & Standards for EV Charging Infrastructure | RBI — Harmonisation of Turn Around Time and customer compensation for failed transactions (RBI/2019-20/67) | RBI (Regulation of Payment Aggregator) Directions, 2025 | GST e-Invoice Portal — 30-day reporting limit for AATO ₹10 crore and above | OCPI 2.2.1 — CDRs module | Open Charge Alliance — OCPP