CPMS selection by feature matrix: why every vendor can do everything.
Issue a CPMS tender and the responses come back with nearly every line of the requirements matrix marked yes. OCPP 2.0.1: yes. Calibration-law billing: yes. Roaming: yes. The problem with these matrices is structural: they ask whether a capability exists, not how deeply it is implemented – and that depth is exactly where platforms that look identical on paper drift apart.
A robust criteria catalogue therefore asks different questions: ones that can be verified before signing – through a demo, a proof of concept, or the draft contract. The twelve criteria in this article are distilled from selection and migration projects and sorted into four groups. Each follows the same pattern: why it matters in operation, and how to test it while there is still negotiating leverage.
- Protocol substance: OCPP versions without asterisks, vendor interoperability, simulator access.
- Operations: message-level monitoring, firmware campaigns, support reach.
- Commercial: calibration law with OCMF, XRechnung e-invoicing, exit clauses and data export.
- Future-proofing: OCPI roaming, ISO 15118 and Plug&Charge, extensibility via APIs.
Protocol substance: OCPP versions, interoperability, simulator access.
“Supports OCPP 2.0.1” appears on almost every datasheet – and surprisingly often it means only part of the protocol. OCPP 2.0.1 organises its functionality into function blocks, from security and provisioning to smart charging, and a backend can formally speak 2.0.1 without fully implementing the device model, the TransactionEvent logic, or the security profiles. Yet that depth is precisely what determines whether certificate management, Plug&Charge, and clean transaction handling work later on. The criterion becomes testable with a written list: which function blocks and security profiles run in production with existing customers, and which only exist on the roadmap. A vendor who answers precisely has done the work – one who points back to the datasheet usually has not.
Criterion two is vendor interoperability. Real fleets mix manufacturers, model generations, and firmware versions, and every device interprets OCPP slightly differently – in reconnect behaviour, MeterValues configuration, or the timing of status messages. A CPMS that has only ever seen a handful of model lines in the field shifts that integration work into the buyer's project. The test is inconvenient but simple: request a list of charge point models connected in production, and connect the exact devices from the existing fleet during the proof of concept – with the real firmware versions, not the vendor's demo unit.
The third criterion almost never appears in tenders: access to a simulator and test environment. A vendor that can only reproduce fault patterns against the production fleet ends up testing on paying customers. A vendor with its own simulation and test infrastructure can replay connection losses, offline catch-up, and load scenarios reproducibly – and can grant the buyer the same access. The tender should therefore include the right to run defined scenarios independently: a connection drop during an active transaction, delivery of buffered meter values after reconnection, a simultaneous reconnect of many charge points.
Operations: monitoring, firmware campaigns, and support reach.
An uptime dashboard is not monitoring. What counts in operation is how fast a stuck charging session can be diagnosed – and that requires visibility down to the message level: which StatusNotification arrived when, which request stayed open, how the charge point behaved before the fault. Without that depth, every incident turns into ticket ping-pong between operator, platform, and manufacturer. The practical test is a live demo with a concrete task: diagnose a real or simulated fault, rather than present the standard dashboard.
Firmware campaigns are the second operational criterion. Charging infrastructure lives for years, and security patches, protocol updates, and bug fixes arrive continuously – without campaign tooling, every update becomes manual work per charge point. A usable CPMS stages rollouts through pilot groups, shows success and failure rates per cohort, and can halt a running campaign. This is verifiable on a test fleet: a small campaign with a staged rollout and a deliberately provoked failure quickly shows whether the tooling deserves the name.
Criterion six is support reach. SLA response times say little about what support can actually see and do when a site fails at night. What matters is whether second-level support can access raw OCPP data and message timelines, and whether there is a defined escalation path to the charge point manufacturers. During selection, it pays to read the SLA definitions closely – resolution times rather than just response times – and to ask directly which diagnostic data support has in front of it during an incident.
Commercial: calibration law, e-invoicing, and a clean exit.
In Germany there is no way around billing that complies with calibration law (Eichrecht): signed meter values from MID-certified meters, stored and passed on in the OCMF format, verifiable through transparency software. Every gap in this chain becomes a billing and liability risk that is nearly impossible to repair afterwards. A datasheet yes is not enough here, because there is a world of difference between “Eichrecht-ready” and an unbroken signature chain. The practical test is an end-to-end demonstration: from the signed meter value at the charge point, through storage in the CPMS, to a successful verification of the record in the transparency software.
Criterion eight concerns everyone working with municipal utilities, local authorities, or public-sector clients: electronic invoicing. For invoices to German public bodies, the XRechnung format is mandatory, and in B2B business the staged e-invoicing obligation is being phased in. A CPMS whose billing exports only know PDF and CSV creates permanent manual effort or expensive follow-up projects in the ERP. The check is concrete: generate a sample invoice as XRechnung, validate it against the official rules, and walk through the handover to the existing ERP system.
The ninth criterion is uncomfortable because it thinks from the end: exit clauses and data export. The best moment to negotiate the separation is before signing – afterwards, the vendor decides format, timeline, and price. A clean exit includes documented export formats for all operational data and the technical freedom to reconfigure charge points to a different backend. Testing the data export during the proof of concept means knowing exactly what to expect when it matters.
- Complete export of master data, transactions, and OCMF records in documented, open formats.
- Vendor cooperation duties during a migration, with defined deadlines and effort.
- No technical lock-in: backend URLs and certificates on the charge points remain reconfigurable.
- Retention and deletion rules for calibration-law-relevant records after contract end.
- A test export during the proof of concept, not for the first time in a dispute.
Future-proofing: roaming, ISO 15118, and extensibility.
Roaming determines how visible and usable charge points are beyond the operator's own customer base. The de facto standard is OCPI, in practice mostly version 2.2.1 today, with modules for locations, sessions, tariffs, and CDRs. The interesting question is less whether than how: do productive roaming connections run directly to partners or through a hub, and how quickly do tariff and location changes propagate. The tender question is therefore: which OCPI connections are live today, which modules are implemented, and how is a tariff change tested end to end.
Since January 2026, ISO 15118 has been mandatory for new public AC charge points in the EU, and Plug&Charge is moving from future topic to requirements list. For the CPMS this means certificate management via OCPP 2.0.1, handling of contract certificates, and connections to the Plug&Charge ecosystems must either exist or have a credible roadmap. A vendor who can demonstrate installing a certificate via OCPP live is further along than one with an announcement slide. Exactly that can be required in the tender: a demonstration of certificate handling instead of a declaration of intent.
The twelfth criterion is extensibility. No CPMS covers every future requirement – what matters is whether missing functionality can be added through documented APIs, webhooks, and event streams without commissioning the vendor for every small change. This becomes testable through the API documentation before signing, sandbox access, and a clear versioning policy. Taken together, the twelve criteria turn a feature tender into a verifiable assessment that sorts vendors by substance rather than by datasheet. As a structured catalogue it serves as the starting point for a CPMS assessment in selection and migration projects – and where individual capabilities are missing, the deciding question is whether the gap can be closed through modular additions without a platform change.