OCPP middleware is a fuzzy term – the distinction starts with responsibility.
Search for OCPP middleware and the results range from protocol libraries to full billing platforms. In practice, most projects mean a layer between charge points and backends that makes connections, states and message flows manageable. This is exactly where the confusion starts: an OCPP broker and a CPMS solve different problems, even though both speak OCPP.
The broker is a decoupling layer. It terminates OCPP connections, holds charge point state, normalizes vendor differences and routes messages to one or more target systems. It does not decide what a kilowatt hour costs, who is allowed to charge or what an invoice looks like.
The CPMS is the business layer. It knows users, contracts, tariffs, authorization lists, roaming relationships and billing processes. In projects we frequently see both roles blended into a single platform. That is precisely where migration, testing and scaling problems emerge later.
What an OCPP broker does technically.
The broker's core job is to handle the quirks of the field in one place. Charge points differ in firmware, timing, reconnection behavior and how they interpret individual OCPP messages. The broker absorbs these differences before they propagate into downstream systems.
Then there is the state cache: the broker knows at all times which charge points are connected, which sessions are running and which messages are pending. StatusNotification, MeterValues and transaction events are buffered when a target system is briefly unreachable. Downstream systems therefore receive a consistent model instead of a patchy raw data trail.
The protocol level matters as well. OCPP 1.6 and 2.0.1 are not compatible with each other, whereas OCPP 2.1 is backward compatible with 2.0.1. A broker can cleanly separate mixed fleets, version them per charge point and migrate them step by step, without every backend having to master every variant.
- Routing: one charge point connection, multiple target systems such as CPMS, monitoring and analytics.
- State cache: current state of connectors, sessions and pending messages.
- Normalization of vendor-specific OCPP interpretations and firmware quirks.
- Queueing and replay of events during backend outages.
- Version handling for mixed fleets running OCPP 1.6 and OCPP 2.x.
What a CPMS does – and why that is a different discipline.
The CPMS answers the question of what a charging session means commercially. It manages users and contract accounts, checks authorizations, calculates tariffs and generates receipts. On top come roaming via OCPI 2.2 or 2.3, for example towards Hubject, plus reporting and operator views.
Regulatory requirements belong in this layer too. Calibration-law-compliant billing in Germany requires MID-compliant meters and OCMF-signed meter values that can be verified with transparency software. B2B invoicing adds formats such as XRechnung or ZUGFeRD, and since 2024 AFIR mandates ad-hoc payment and data provision at public charge points, among other things.
None of this is a broker's job. A broker that calculates tariffs is no longer a broker but a second CPMS with unclear responsibility. Keeping the layers cleanly separated keeps both replaceable, testable and independently migratable.
When a broker alone is enough – and when both are needed.
A broker alone is sufficient when the business logic already exists and the real problem lies in field connectivity. Typical cases are migrations between CPMS platforms, multi-vendor fleets with divergent OCPP behavior, test environments for manufacturers, or mirroring the message stream into monitoring and analytics. The broker solves these cases without touching tariffs or user management.
Both are needed as soon as an organization does its own billing or roaming while operating a heterogeneous, growing infrastructure. The CPMS then carries users, tariffs, receipts and roaming relationships, while the broker encapsulates the field complexity. The interface between the two stays narrow and stable because the CPMS only sees a normalized message stream.
In projects we see a simple decision pattern. The more often backends, tenants or OCPP versions change, and the more mixed the fleet, the more the decoupling layer pays off. If the landscape stays small and homogeneous, a direct CPMS connection is often the more pragmatic choice.
- Broker only: a CPMS exists, but there are migration, parallel-operation or multi-vendor problems in the field.
- CPMS only: a small, homogeneous fleet with a single stable backend.
- Both: own billing and roaming plus a heterogeneous, growing field.
- Clear broker signal: every new target system requires changes to the charge points themselves.
Combination architectures: broker in front of, next to or between CPMS platforms.
The most common architecture is a broker in front of a CPMS. All charge points connect to the broker, which delivers a normalized message stream to the backend. Migrations then become routing changes instead of field rollouts, because the charge points never have to switch their connection.
Beyond that, the broker is establishing itself as a distributor: production, staging, monitoring and analytics attach to the same message stream as separate target systems. For operators with multiple tenants or multiple CPMS platforms, the broker can route messages rule-based per site, vendor or contract. New requirements such as ISO 15118 – mandatory for new public AC charge points in the EU since January 2026 – or Plug&Charge under ISO 15118-20 can also be introduced step by step without converting the entire fleet at once.
A clean cut looks exactly like this: the OCPP broker handles decoupling, state cache and normalization, and CPMS modules add tariffs, billing and roaming where they are actually needed. The distinction remains the key point: OCPP middleware is not a stripped-down CPMS, but a separate architectural layer with its own responsibility.