Current Account: How UK Fleets Should Vet EV Charging Software Before Signing

Electrification projects are often presented as hardware programmes: chargers, cable runs, civil works and perhaps a new energy contract. In practice, the long-term control point is the software layer that sits above the equipment. The charge-point management system determines who can start a session, how power is allocated, what data is retained and whether a buyer can move to another supplier without stranding assets. For UK fleet and facilities teams, the procurement question is therefore not simply whether the chargers work on day one. It is whether the software contract leaves room to change course over the next five to ten years.

Start with a stack map, not a charger shortlist

Before comparing platforms, buyers should map the operational stack the software must join. That usually includes finance and leasing systems, fuel or expense cards, facilities management tools, building management systems, access control, HR records and, in some cases, telematics. A platform that looks competitive in isolation can become expensive if it requires manual reconciliation or duplicate data entry across those systems.

The map should also record who owns each interface. A fleet manager may control driver records, while a facilities team controls site access and an energy manager controls tariff data. If the charging platform assumes a single administrator, the buyer should test whether delegated roles and audit trails match the organisation’s actual structure.

OCPP support is a floor, not a ceiling

Open Charge Point Protocol support is routinely cited in tenders, but the declaration is only the beginning. Buyers should ask which version is supported, which profiles are implemented and whether the platform can manage a mixed estate from several hardware manufacturers. OCPP 1.6J remains common, while OCPP 2.0.1 introduces additional capabilities around device management and security. The practical test is not a specification line but a demonstration using the buyer’s intended charger models and back-office workflows.

Firmware management deserves equal scrutiny. The contract should state who may authorise updates, how staged rollouts are handled, what happens when an update fails and whether the buyer can refuse a change that has not been tested against its integrations. A platform that can push firmware remotely is useful; a platform that can do so without a clear change-control process is a risk.

Smart charging rules need evidence

Smart charging is often sold as a route to lower costs and better use of connection capacity. The value depends on the rules engine. Buyers should test how the platform responds to site load limits, tariff changes, driver priority, session deadlines and unexpected demand. A rule that works in a demonstration may behave differently when several vehicles arrive at once or when a site loses connectivity.

Tariff feeds are part of the same test. If the platform ingests half-hourly prices or site-specific energy rates, the contract should explain the source of that data, the refresh frequency and the fallback behaviour when a feed is delayed or incorrect. The buyer should also confirm whether the platform can export the charging events needed to reconcile invoices and internal cost allocation.

Roaming, payments and reconciliation

Roaming and payment features can make a workplace or depot estate more flexible, but they add reconciliation complexity. Buyers should ask which roaming networks are supported, how session data is matched to drivers or vehicles, and who bears the cost of failed or disputed transactions. For private fleets, the more important question may be whether public roaming is needed at all. A simpler configuration can reduce both cost and administrative overhead.

Where payments are taken, the contract should clarify settlement timing, refund handling and the treatment of transaction data. Finance teams should be able to trace a charging session from the driver or vehicle record through to the invoice without relying on a vendor’s manual report.

Data ownership and operational access

Data ownership is frequently asserted in sales material and rarely defined in operational terms. The contract should identify what constitutes buyer data, what the vendor may use for analytics or product improvement, and how aggregated or anonymised data is treated. It should also set out retention periods, deletion rights and the format of any export.

Access matters as much as ownership. Buyers should confirm that they can obtain a complete export of charging sessions, meter values, user records and configuration settings at any time, not only at contract end. Administrator rights should allow the buyer to add or remove users, change tariffs and review logs without waiting for vendor support. If the platform holds the only usable copy of the estate configuration, the buyer has a dependency rather than a service.

Service levels, firmware and security

The service level agreement should cover more than platform uptime. Buyers should look for defined response and restoration targets for different severity levels, including loss of charging at a site, failure of authentication and inability to export data. The contract should state how incidents are communicated, what root-cause information is provided and whether service credits reflect operational impact.

Security terms should address vulnerability disclosure, patching, access controls and incident notification. Firmware update rights and end-of-support dates should be explicit, particularly where chargers are expected to remain in service beyond the initial software term. Without those terms, a buyer may find that the hardware is sound but the software is no longer maintained.

Integrations that create hidden dependencies

The most consequential dependencies are often the least visible. A platform may integrate with a finance system through a connector that the vendor controls, or with a facilities system through a middleware layer that is not covered by the main service level. Buyers should ask for a dependency register: every integration, its owner, its version, its support status and its failure mode.

Where an integration is critical, the contract should include transition assistance and reasonable notice of material changes. API rate limits, schema changes and deprecation schedules should be disclosed before signature, not discovered during a renewal.

The exit plan belongs in the contract

Exit planning is not a sign of distrust; it is a test of whether the vendor has designed for portability. Buyers should require a documented offboarding process, a data export in a usable format, reasonable transition support and a clear decommissioning timetable. Where firmware or configuration data is needed to keep chargers operating, the contract should state how that information will be provided.

A sensible pre-signature test is to ask the vendor to walk through a hypothetical exit: how the buyer would move to another platform, what would happen to historical sessions and how long access would continue. The answers will reveal more than a generic clause about cooperation.

For UK fleets, charging software is infrastructure, not an accessory. It should be procured with the same discipline as any other multi-year technology service: mapped, tested, contracted and exit-ready. The charge points may be the visible investment, but the software terms determine whether the estate remains under the buyer’s control.