EV Charger Billing Systems: Pricing, Records and Settlement

A billing engine decides what a session costs, keeps the record auditable, and moves money to the operator. Get one layer wrong and every other layer looks broken.

Billing is the layer of a charging network that turns energy into revenue. A driver plugs in, power flows, a price appears in an app or on an invoice, and money eventually reaches the operator. Between those steps sit meters, OCPP messages, tariff rules, taxes, payment providers and accounting systems. When any link is weak, the symptom is usually a complaint about a wrong price, a missing receipt or a payout that does not match the session report.

The focus here is public and commercial charging, where several drivers, tariffs and currencies can share one site.

Billing Is More Than a Price List

A billing system has five jobs, and they fail in different ways. Metering produces the raw energy and time data. Tariff calculation converts that data into a price. Transaction records preserve what happened and why. Settlement moves money between the driver, the payment provider, the roaming partner and the operator. Reporting and audit give the operator a version of events that can survive a tax review or a customer dispute.

• Metering: energy delivered, start and stop time, and the meter identity
• Tariff calculation: energy price, time price, session fees, idle fees, taxes and discounts
• Transaction records: the immutable link between a session, a driver and an amount
• Settlement: authorization, capture, refunds, payouts and reconciliation
• Reporting: revenue, energy, tax, carbon and exception reports for the operator

Payment is only the front end of this chain. A card terminal or app wallet authorizes a payer, but the billing engine decides how much that payer owes. That is why a charger can accept a card and still produce the wrong invoice: the payment worked, the calculation did not.

Where the Billing Data Comes From

The charger is the primary source of truth. Under OCPP 1.6J, the charger sends a start transaction, periodic meter values and a stop transaction with a final reading. Under OCPP 2.0.1, the same events are carried as transaction events, and signed meter values can provide stronger evidence that a reading was not altered. In both versions the protocol transports data; it does not calculate a price.

The backend therefore needs a tariff engine that can map a session to the correct rule set. That mapping depends on the site, the connector, the account, the time of day and sometimes the vehicle. A single charger can serve a public walk-in driver, a fleet card and a roaming user in the same afternoon, each with a different price.

Data quality decides whether the final invoice is defensible. Clock drift between charger and backend can shift a session across a price change or a tax boundary. Missing meter intervals leave gaps that have to be estimated. A charger that goes offline can hold sessions locally and upload them later, so the billing system must accept late records instead of rejecting them. The OCPP 1.6J and 2.0.1 comparison covers how each version handles transaction data and the features available to the backend.

Tariff Models and Their Traps

Most operators combine a few simple models rather than inventing a complicated one. The table below summarizes the common options and the operational risk each one carries.

Tariff versioning is where many systems break. Prices change, taxes change and promotional rates expire. The system must define whether a session is priced with the tariff that was active at the start or with the latest version at the stop, and it must apply that rule consistently. Mixing both rules creates invoices that no one can explain.

Tax handling deserves the same discipline. A price can be tax inclusive for consumers and tax exclusive for business accounts, and the invoice has to show the difference. Discounts should be applied in a defined order, usually before tax. Fleet rates, sub-account permissions and promotional codes all feed the same calculation, so the platform needs explicit rules for who receives which price.

From Meter Stop to Invoice: The Transaction Lifecycle

A clean billing lifecycle has a fixed sequence. Authorization identifies the payer and reserves or confirms a payment method. The session opens and the charger begins reporting meter values. At the stop, the backend calculates the price from the recorded data, applies tax and discounts, and stores the result as a transaction record before requesting capture. Settlement then moves funds, and reconciliation matches each transaction to a payout.

• Authorize the driver or vehicle before energy is delivered
• Open the session and bind it to a charger, connector, account and tariff
• Store meter intervals with timestamps and a stable session identifier
• Calculate the final price once, and freeze the calculation in the transaction record
• Capture payment, issue a receipt, and reconcile the amount against the settlement batch

Exceptions are normal, not rare. A session may stop because the cable is unplugged, the charger loses power or the driver cancels in the app. The billing system should classify the stop reason, because a failed session and a completed session may have different pricing rules. If the charger lost contact, the backend may price from the last known meter value and flag the record for review.

Refunds should be equally explicit. A refund is not a delete. The original transaction stays in place, and a linked adjustment records who approved the refund, when, and why. That history is what protects the operator when a driver disputes a charge months later.

The payment systems guide covers card terminals, QR flows, Plug and Charge and roaming in more detail. Billing assumes those layers work and focuses on the calculation and the record that follows.

Settlement Across Currencies, Taxes and Time Zones

Operators who expand across borders discover that billing is a localization problem as much as a software problem. The tariff may be set in one currency, the driver may pay in another, and the operator may receive a third after provider fees. Each conversion needs a defined exchange rate and the moment it is captured, otherwise two reports for the same month will never agree.

Tax rules add another layer. Different markets apply different rates to electricity, services and parking, and some require the tax to appear separately on the invoice. A platform that only stores a single price cannot produce a compliant document for every market, so tax rates and invoice templates should be configurable per country or region.

Time zones affect more than display. A session can cross a day boundary, a price period or a reporting period. The system needs a consistent rule for which timestamp drives each calculation, and daylight saving changes are a common source of one-hour errors in monthly reports.

Settlement itself has to reconcile in both directions. The operator needs to see what the payment provider actually paid out, what fees were deducted, and which sessions are included in each batch. Roaming partners add their own statements. A session identifier should be traceable from the charger log to the invoice, the payment record and the payout line.

Records, Audit Trails and Compliance

Transaction records are evidence. They should be append-only, timestamped and exportable, with enough detail to reconstruct the price: meter values, tariff version, discounts, taxes, currency and the identity used for authorization. If a record can be edited without leaving a trace, the audit trail is decorative.

Several reporting obligations sit on top of the billing data. Public charging support schemes may require energy and carbon reports, tax authorities may require invoices in a local format, and site owners may require monthly revenue statements per charger. The billing system should generate these from the same underlying records rather than a hand-maintained spreadsheet.

Access control belongs here too. Operator accounts are often split by company, store or department, and sub-accounts should only see the sites and financial data they are responsible for. Refund approval, tariff changes and exports are sensitive actions and should be logged with the user who performed them.

Reporting and Revenue Visibility

Operators do not need every possible report. They need a small set that answers operational questions: revenue by site and connector, energy sold, utilization, failed sessions, refunds, average revenue per session and a tax summary. When those numbers come from one source, a site owner can compare a slow charger with a busy one and decide where to add capacity.

Billing also interacts with energy strategy. Time-of-use tariffs and scheduled charging can shift demand to cheaper hours, and the billing engine has to price those sessions correctly. Demand charges are a separate cost layer, explained in the guide to peak shaving and demand charges, but they shape the tariff design that billing implements. The charging station ROI model shows how small pricing errors grow at scale.

Deployment and White-Label Billing

Billing platforms are sold in several shapes. A hosted service is fast to launch and shifts maintenance to the vendor. An on-premises deployment gives the operator control over data location and integration with local systems, at the cost of running the infrastructure. White-label deployment adds the operator's own domain, interface, invoices and notification templates, so drivers see one brand rather than a software vendor.

The commercial terms matter as much as the feature list. Ask whether pricing is per port, per transaction or a share of revenue, whether setup and upgrades are included, and whether payment processing or roaming carries extra fees. Also ask who owns the transaction data and how it can be exported if the operator changes platforms.