EV Charging Management Software Problems: The 7 That Kill Uptime and Margin, and How to Avoid Them

Why does multi vendor OCPP support get underscoped so often?

Because the Open Charge Point Protocol is a standard, and standards read as though the work is done. A proposal says the platform speaks OCPP 1.6J and 2.0.1, everyone treats hardware support as a checkbox, and the price reflects one integration rather than five.

Then the messages arrive. One vendor reports energy in watt hours and another in kilowatt hours. One sends a Faulted status with a vendor error code you decode from a PDF, another simply stops sending heartbeats. StatusNotification transitions differ in order and in timing between brands. MeterValues sampling intervals differ, and one firmware release changes them without warning. Your fleet is Alpitronic, Kempower, ABB, Autel and Wallbox because you bought on price and lead time, which is the correct commercial decision and the reason this problem exists at all.

The fix is architectural and it has to be decided before the first sprint. Normalise at ingestion into one canonical model of site, electric vehicle supply equipment, connector, status, power and session, with a hardware abstraction layer mapping each vendor's error codes and units into your schema. A fault then means the same thing whether it came from Alpitronic or ABB, and when a firmware update changes behaviour you patch one adapter rather than every downstream feature. Insist that the proposal prices each vendor profile as its own line item, because that is what it is.

What goes wrong when you migrate sessions and charger identities?

Charger identity is the part that bites. Every incumbent platform assigns its own identifiers, and the mapping between a physical cabinet, its charge point identity on the network, its connectors and your asset register is rarely clean. Units get swapped under warranty and keep the old identity. A cabinet with four connectors is recorded as four chargers in one system and one in another. Sites get renamed after a rebrand. Two identifiers exist for the same unit because it was recommissioned after a power module replacement.

The session history matters more than operators expect, because it is the baseline for everything you will claim afterwards: uptime by site, revenue per connector, utilisation trends that justify the next capital request. Import it badly and you lose the ability to compare before and after, which is exactly the comparison that proves the project worked.

Do three things. Build the asset register first as its own deliverable, with a stable internal identifier per physical unit and a mapping table holding every external identifier it has ever carried. Import charge detail records rather than summaries, because a summary cannot be re-rated when you discover a tariff was applied wrongly. Then reconcile: total energy and total revenue per site per month in the new system must match the old platform, and every variance must be explained rather than absorbed. Do that before cutover, not after.

Why do payment, roaming and OCPP integrations break after launch?

Each one breaks for a different reason, and you need three different defences. Charger firmware breaks OCPP behaviour, usually after a vendor pushes an update to improve something unrelated. Payment processors change webhook payloads and settlement timing. Roaming hubs such as Hubject and Gireve evolve their interface versions and their partner onboarding rules, and a partner on the other side can change how they present tariffs.

The common failure is silence. A charger that stops sending MeterValues still looks online. A webhook that stops arriving does not raise an error, it simply leaves sessions unsettled. Nothing alerts, and finance discovers it during month end reconciliation three weeks later.

Defend with liveness checks rather than error handling. Alert when a charger's heartbeat gap exceeds its configured interval, when a site's session count drops materially against its own recent pattern, when the ratio of settled to rated sessions moves, and when an interface version is deprecated by a hub. Keep every raw OCPP message for a retention window, because when a vendor disputes a fault you need the transcript. Version your OCPP adapters and test a firmware release on one unit at one site before it reaches the fleet, which requires that your platform can pin firmware per site. Operators who skip that control learn about a bad firmware release from a whole region going dark at once.

What happens when uptime reporting and remediation are not covered?

You end up measuring a number you cannot influence. The federal National Electric Vehicle Infrastructure programme requires a 97 percent uptime minimum on funded sites, and the calculation has a defined shape including which outage causes are excluded. Most platforms will show you a status history. Far fewer compute uptime the way the programme defines it, track excluded causes, and produce the quarterly report a state department of transportation asks for. So the report is assembled by hand from exports, which is slow and, more importantly, produces a number nobody in operations recognises.

The remediation half is where the money is. Detection without an automatic response is just faster bad news. A fault should be fingerprinted against a known error library, then an auto remediation playbook fires first: RemoteReset, ChangeAvailability, and a remote command to release a locked connector. Only when the automatic attempt fails does a ticket open in your service desk, carrying the fault code, the site, the last MeterValues and the unit's recent fault history, so the technician rolls with the right part rather than a guess.

Get both into the first release rather than deferring reporting to phase two. Compliance reporting built after the fact tends to discover that the underlying events were never stored at the granularity the calculation needs, and retrofitting event granularity is a migration, not a feature.

Should you build custom or configure what you already own?

Stay on a subscription platform, and be content about it, if you run under roughly 50 chargers across one or two hardware brands, on standard public tariffs, with no roaming settlement and no federally funded sites. AMPECO, Monta and EV Connect are competent products, the per charger fee is cheaper than owning a platform at that scale, and building to feel sophisticated is an expensive habit.

The middle path deserves more attention than it gets. Many operators do not need to replace the charge point management system at all. They need a layer above it that owns the asset register, the rating and reconciliation, and the operational alerting, while the vendor keeps handling the OCPP connection. That is a materially smaller build and it removes the two most painful problems, which are usually money reconciliation and fault response, without a migration.

Build the platform outright when the vendor's model is the constraint. You cannot consolidate your hardware onto one certified list. Your tariffs include idle fee grace rules, negotiated fleet contracts or demand pass through that the vendor cannot express. You need roaming settled on your own contract terms. Your stacked per charger and per transaction fees now exceed an amortised build at your volume. Or the vendor's roadmap is gating decisions about your own network, which is the point at which the platform has stopped being a convenience and become your profit and loss.

How do hidden costs get into the quote?

Six places, and they are predictable. Each additional vendor hardware profile is real integration work rather than configuration, and the second OCPP version is close to a second project because 2.0.1 does not model the same things 1.6 does. Payment plus tax plus reconciliation is its own workstream, not a line item, because rating, settlement matching and dispute handling are three separate problems.

High availability is the one most often understated. A charger that loses its websocket is a dead charger earning nothing, so the reliability bar here sits above ordinary business software. That means redundant message brokers, connection draining on deploy, and a tested failover, all of which cost money that a demonstration never shows.

Then site level load management tied to a specific utility rate schedule, which is bespoke per tariff and per site electrical design. Compliance reporting, if it is added late. And historical migration with its reconciliation. What holds the number down is scope order: a focused first release covering live OCPP ingestion across your actual hardware, one clean billing flow and an operations dashboard with fault alerting runs $60,000 to $130,000 in 12 to 16 weeks. Roaming, smart charging and full reconciliation belong in the $150,000 to $400,000 phase across 6 to 12 months, priced against real sessions rather than assumptions.

What separates a build that works from one that fails here?

Four markers, in our delivery experience. The first is that the team treats a dropped connection as a revenue incident. Ask a prospective developer what happens when a charger reconnects mid session after a websocket drop. If they have built this before, they will describe session resumption, duplicate transaction handling and how MeterValues gaps are reconciled. If they have not, you will discover the answer in production during a busy weekend.

The second is that every billed kilowatt hour traces to a specific meter reading. That single property is what lets you win a fleet customer's invoice dispute, re-rate a session when a tariff was misconfigured, and reconcile against a processor payout instead of writing off variances. Systems that store a rated total and discard the underlying readings can never do any of it.

The third is migration by waves rather than by date. Point a subset of chargers at the new backend, verify that sessions, billing and faults match the incumbent, then move sites in groups. No location sees meaningful downtime and every wave de-risks the next. A big bang cutover across a network is how operators lose a weekend of revenue and their reconciliation baseline at the same time.

The fourth is owning the code, the repository and the cloud accounts from the first commit, with the right to bring in another firm. That is the structural difference between a build and a subscription with extra steps, and it is the whole reason for taking on the work.