How to Evaluate EV Charging Station Management Software for Multi-Site Networks
The EV charging management software market is projected to reach $6.81 billion by 2032, according to Grand View Research, growing at 25.9% annually from its 2026 base of $1.68 billion. That growth is attracting a flood of vendors, each claiming comprehensive features and seamless scalability. For charge point operators (CPOs) managing networks of 100 or more chargers across multiple sites, the vendor selection process demands a different level of scrutiny.
Most published comparisons of EV charging station management software reduce the evaluation to feature checklists. They list OCPP support, a mobile app, and a billing module, then rank vendors by interface design. That approach works for a single-site deployment. It fails for multi-site networks where protocol depth, architectural flexibility, and grid-services readiness determine whether the platform becomes a competitive advantage or an operational ceiling.
This guide provides a technical evaluation framework for CPOs operating at scale. It covers the dimensions that vendor marketing pages rarely address: protocol version specifics, multi-tenant architecture, grid-services integration, API extensibility, and the total cost of ownership when per-unit SaaS fees compound across hundreds of charge points.
Protocol Compliance: Beyond “We Support OCPP”
Every charging station management system claims OCPP compatibility. The meaningful question is which version, and how deeply.
The Open Charge Point Protocol (OCPP) has evolved significantly since version 1.6J, which remains the most widely deployed in the industry. OCPP 2.0.1 introduced a fundamentally different device model, mandatory TLS security, improved smart charging profiles, and support for ISO 15118 Plug & Charge. In late 2024, OCPP was ratified as IEC 63584, giving procurement teams an IEC standard to reference in contracts. OCPP 2.1, released in 2025 and published by IEC, added bidirectional power transfer support for V2G-ready infrastructure.
The distinction matters operationally. A platform that implements only OCPP 1.6J cannot support device-level security certificates, transaction-level energy metering, or the smart charging profiles required for multi-site load orchestration. For networks receiving NEVI funding in the United States, the Federal Highway Administration mandates OCPP compliance as a condition of the National Electric Vehicle Infrastructure program.
What to evaluate:
- Request the vendor’s OCA (Open Charge Alliance) certification status and certificate numbers for each OCPP version
- Test whether smart charging profiles work across mixed-firmware fleets (1.6J and 2.0.1 chargers on the same backend)
- Confirm ISO 15118 Plug & Charge readiness if the network’s roadmap includes automated authentication
Beyond charger-to-backend communication, evaluate interoperability protocols. OCPI 2.2.1 (Open Charge Point Interface) enables e-roaming between networks. The EU’s Alternative Fuels Infrastructure Regulation (AFIR) mandates cross-network roaming, making OCPI support a regulatory requirement for European deployments.
Multi-Tenant Architecture: The Invisible Requirement
Single-site operators rarely think about tenancy. Multi-site CPOs think about it constantly.
A multi-tenant architecture isolates data, billing configuration, user permissions, and operational dashboards for each organizational entity. For CPOs operating across utility territories, managing sub-brands, or offering white-label charging services to site hosts, multi-tenancy is not a feature request. It is an architectural prerequisite.
The implementation depth varies dramatically between vendors. Some platforms offer multi-tenancy through shared database tables with row-level access filters. Others provide schema-level or service-level isolation with independent configuration per tenant. The difference becomes apparent when tenants need distinct billing engines, regional compliance settings, or separate API keys for third-party integrations.
What to evaluate:
- Ask whether tenants share a database or operate on isolated schemas
- Test hierarchical role-based access control (RBAC): can you scope permissions to a site group, a single site, or a specific charger?
- Verify that tenant-level configuration extends to billing rules, tariff structures, notification settings, and reporting exports
| Evaluation Dimension | What to assess | Key question for the vendor |
|---|---|---|
| Protocol compliance: OCPP version depth and certification | OCA-certified OCPP 2.0.1 (IEC 63584) support; ISO 15118 readiness; OCPI 2.2.1 for roaming | Which OCPP versions are you OCA-certified for? Provide certificate numbers. |
| Multi-tenant architecture: Data and configuration isolation | Schema-level or service-level tenant isolation; hierarchical RBAC; per-tenant billing configuration | Do tenants share a database, or does each tenant operate on an isolated schema? |
| Grid-services readiness: Demand response and V2G support | Native OpenADR VEN/VTN; IEEE 2030.5 for Rule 21 markets; ISO 15118-20 bidirectional support | How does your platform participate in utility demand response programs? |
| API extensibility: Integration depth and programmability | Full CRUD API with documentation; webhook event notifications; versioned endpoints | What percentage of platform functionality is accessible via API? |
| Billing flexibility: Pricing engine configurability | Dynamic tariffs; TOU rate integration; fleet contracts; multi-currency; split billing | Can we implement custom pricing formulas that respond to real-time grid signals? |
| Data portability: Migration and export capabilities | Full session history export; user data portability; configuration backup; no vendor lock on data | If we terminate the contract, what data can we export and in what format? |
| Total cost of ownership: Scaling economics | Per-charger fee trajectory at 500/1,000/5,000 CPs; customization IP ownership; migration costs | What is the per-charger monthly cost at 500, 1,000, and 5,000 charge points? |
Grid-Services Readiness: The Dimension No One Covers
This is the single largest blind spot in EV charging station management software evaluations.
OCPP handles communication between a charger and its backend. It does not address communication between the backend and the grid. For CPOs planning to participate in demand response programs, offer V2G services, or monetize flexible load capacity, the charging management system must integrate grid-side protocols that most SaaS platforms do not support.
Three protocol families matter:
OpenADR (Open Automated Demand Response) enables the CSMS to receive and respond to utility demand response signals. A CSMS with an embedded OpenADR VEN (Virtual End Node) can curtail or shift charging load during grid stress events. Without it, DR participation requires manual intervention or a separate integration layer.
IEEE 2030.5 governs DER communication in markets like California (Rule 21, CSIP). For CPOs with sites in California or states adopting similar frameworks, IEEE 2030.5 support enables direct participation in grid optimization programs.
ISO 15118-20 extends the Plug & Charge standard to bidirectional power transfer. AFIR mandates ISO 15118 for V2G-capable chargers from January 2026. OCPP 2.1 includes the functional blocks for V2G, but implementing them requires deep coordination between the CSMS, the charger firmware, and the grid-side protocol stack.
The Pacific Northwest National Laboratory’s 2025 assessment of EV standards for grid services confirms that no single protocol covers all three layers. The CSMS must orchestrate multiple protocols simultaneously, which requires purpose-built integration architecture rather than a plugin marketplace.
What to evaluate:
- Does the platform natively support OpenADR VEN/VTN, or does DR participation require a third-party middleware?
- Can the system manage bidirectional energy flows for V2G, including settlement logic and energy accounting?
- Is dynamic load management capable of responding to real-time grid signals (OSCP, utility API), or is it limited to static power distribution?
Integration Architecture: API-First or API-Afterthought
A charging management system does not operate in isolation. It connects to payment processors, fleet management platforms, ERP systems, CRM tools, energy trading systems, and hardware diagnostics interfaces. The quality of those connections determines the operational ceiling.
Evaluate the API layer with the same rigor applied to the core product. An API-first architecture exposes the full platform functionality through documented, versioned endpoints with webhook support. An API-afterthought provides a handful of read-only endpoints, incomplete documentation, and no event-driven notifications.
What to evaluate:
- Request API documentation before signing. Assess endpoint coverage: can you programmatically manage sessions, users, tariffs, chargers, and reporting?
- Test webhook support for real-time event notifications (session start/stop, charger faults, payment completion)
- Evaluate payment processor flexibility: is the billing engine locked to a single payment provider, or can you integrate Stripe, Adyen, or direct bank connections?
- Confirm data export capabilities: full historical session data, user records, and configuration must be exportable without vendor assistance
For CPOs managing a diverse fleet of chargers from multiple hardware manufacturers, integration architecture also determines how gracefully the platform handles protocol translation and firmware heterogeneity. Codibly’s engagement building a scalable OCPP server for the IMP PAN research consortium required managing V2G protocols, RFID authentication, and multi-site coordination across three European countries. That kind of mixed-protocol, multi-vendor environment is increasingly common for enterprise CPOs.
Total Cost of Ownership: When Per-Unit Fees Compound
SaaS pricing models for EV charging station management software typically charge per charger per month, per session, or a combination of both. At 50 chargers, the economics are straightforward. At 500, per-unit fees become a material line item. At 2,000, they can exceed the cost of building a custom platform.
The total cost of ownership (TCO) calculation must account for more than the subscription fee:
- Scaling penalties: How does pricing change at 500, 1,000, and 5,000 charge points? Are volume discounts contractual, or subject to annual renegotiation?
- Customization costs: When the standard platform cannot accommodate a business requirement, what does custom development cost, and who owns the resulting IP?
- Migration risk: If the operator switches vendors in year three, what is the data migration cost? Are session histories, user accounts, and tariff configurations portable?
- Vendor dependency: Does the operator own any part of the platform, or does termination mean rebuilding from scratch?
The alternative to perpetual SaaS fees is a custom-built CSMS platform where the operator owns the source code. The upfront engineering investment is higher, but there are no per-charger scaling costs, no feature gates, and no contractual dependency on a single vendor. For CPOs whose networks are central to their business model, source code ownership is not an engineering preference. It is a risk management decision.
| Factor | SaaS CSMS Platform | Custom-Built CSMS |
|---|---|---|
| Upfront cost: Initial investment to deploy | Low (configuration fees, onboarding) | Higher (engineering engagement, 4-12 weeks) |
| Recurring cost: Ongoing fees as network grows | Per-charger or per-session fees compound linearly with scale | Infrastructure hosting only; no per-unit vendor fees |
| 3-year TCO at 500 CPs: Total cost comparison | Subscription fees can exceed custom build cost at this threshold | Fixed engineering cost amortized; marginal cost per charger minimal |
| Source code ownership: Who controls the asset | Vendor retains all IP; operator licenses access | Operator owns source code outright after delivery |
| Customization ceiling: What can be modified | Limited to vendor-supported configuration; custom dev requires vendor engagement | Any layer modifiable: UI, business logic, protocols, integrations |
| Grid-services integration: DR, V2G, IEEE 2030.5 | Rarely supported natively; requires third-party middleware | Built into architecture from the start; protocol stack fully controllable |
| Vendor dependency: Switching cost and risk | High; termination means rebuilding platform and migrating data | Low; operator retains code, data, and infrastructure control |
| Best fit: When this model wins | Networks under 200 CPs, standard billing, single region, fast launch priority | Multi-site operators, grid-services requirements, custom billing, scale-oriented CPOs |
The Evaluation Framework Reveals the Architecture Decision
The seven dimensions above constitute a comprehensive evaluation for EV charging station management software at multi-site scale. Most SaaS platforms satisfy the first two or three dimensions adequately. Few satisfy all seven.
That gap is diagnostic, not accidental. SaaS charging platforms are designed for the median customer: a single-region CPO with standard billing, basic load management, and no grid-services requirements. They are optimized for speed of deployment and breadth of market, not for the operational depth that multi-site, multi-protocol networks demand.
When the evaluation reveals persistent gaps, particularly in grid-services integration, multi-tenant architecture, or API extensibility, the gaps are structural. They reflect architectural decisions made early in the platform’s development and cannot be resolved through feature requests or custom development engagements within the vendor’s environment.
The evaluation framework itself becomes the build-versus-buy decision. If a SaaS platform checks every box, it is the right choice. If it does not, the missing capabilities define the requirements for a purpose-built system.
Frequently Asked Questions
Evaluate across seven dimensions: protocol compliance depth (not just OCPP, but which version and certification), multi-tenant architecture, grid-services readiness, API extensibility, billing flexibility, data portability, and total cost of ownership at your projected scale. Request OCA certification numbers, API documentation, and a detailed SLA definition before shortlisting.
OCPP 2.0.1 (now IEC 63584) should be the minimum for new deployments. OCPP 1.6J lacks device-level security, advanced smart charging profiles, and ISO 15118 support. If your roadmap includes V2G or bidirectional charging, evaluate OCPP 2.1 readiness. Networks receiving NEVI funding must comply with federal OCPP requirements.
It depends on your operational complexity. SaaS platforms work well for single-region networks with standard billing and basic load management. Multi-site CPOs with grid-services integration needs, multi-tenant requirements, custom billing logic, or plans for V2G will likely encounter structural limitations in SaaS offerings. Run the full seven-dimension evaluation to identify where gaps emerge.
Custom development carries higher upfront engineering investment but eliminates per-charger SaaS fees. At 500+ charge points, the three-year TCO of a custom platform is typically lower than a SaaS subscription. The critical distinction is source code ownership: a custom platform is an asset that appreciates with the network, while SaaS is an expense that scales linearly with it.