An OCPP label is a starting point for fleet charging procurement, not proof that a charger will work with every function in the chosen management system. The Open Charge Point Protocol provides a framework for communication between charging stations and their management software. A working depot still depends on the versions, implemented features, security settings and commercial access provided by the parties involved.

Fleet buyers should therefore test the actual charger and backend combination before committing to a large order. The objective is to verify the operations the depot needs, including charging authorization, scheduling, fault reporting and recovery after a communications interruption.

Define what the software must do

Begin with the depot's tasks rather than a protocol acronym. Specify who can authorize a charging session, how charging priorities are set and which information the duty manager needs before departure. Define the reports required by finance and dispatch.

Distinguish charger information from vehicle information. A charging station may report delivered energy and session status without knowing the vehicle's route assignment or required battery state of charge. Departure-aware scheduling may depend on an additional integration or on information entered by the operator.

For each requested function, identify the system that performs it. A fleet management platform, charging management system and local power controller can have different responsibilities. A single dashboard does not establish that all those functions are included in one supplier's scope.

Check versions and certification scope

Request the supported OCPP version and transport implementation for the quoted equipment. Ask for documentation tied to the actual model and software version, rather than a generic company-level statement.

The Open Charge Alliance's OCPP 1.6 certification framework distinguishes core functionality from additional profiles. Certification scope should therefore be reviewed alongside the features a fleet needs. A certificate or an OCPP-compatible description should not be interpreted as confirmation that every optional function has been supplied and enabled.

The EVB fleet charging page includes OCPP-compatible backend support among its fleet capabilities. A buyer can use that as the basis for an integration enquiry, then request the precise charger configuration, supported functions and intended management-system connection for the project.

Run a small integration test with representative vehicles

Use the proposed charger model, relevant firmware and selected backend. A test on different equipment can miss problems that matter in the production order. Include a representative vehicle and the authorization method intended for everyday use.

First demonstrate ordinary operation: connect a vehicle, authorize the session, deliver energy, stop the session and check the recorded result. Then confirm how the system identifies the connector, vehicle or driver and associates the session with the correct operational record.

Test a scheduled start and a change in charging power. If the depot needs local load control, verify how it interacts with backend instructions. Document which control takes precedence so that a remote scheduling command cannot undermine the site's approved power limit.

Test interruptions instead of assuming recovery

Disconnect the communication link during a controlled test and observe the documented behaviour. Check whether an existing session continues, whether new sessions are allowed and how the local power limit is maintained. Those behaviours should match the fleet's operating and security requirements.

Restore communication and inspect the session records. Confirm whether buffered data is uploaded, how duplicate records are avoided and which timestamps are used. Also test a charger restart and the return of the management platform after an outage.

Fault alerts need an operational test. Create an agreed safe test condition and confirm that the correct person receives a useful notification. A fault visible only inside a supplier's account will not help the depot manager respond during an overnight shift.

Make backend migration a practical contract item

Protocol support can make interoperability possible, but it does not settle every contractual or configuration issue. Determine who can change the backend endpoint, whether credentials are available and whether changing providers requires a fee or supplier intervention.

Define access to historical charging data and the format in which it can be exported. The fleet should know what happens to its records if a software subscription ends. Security credentials, certificate management and account permissions also need named responsibilities.

For larger orders, retain the successful integration test as an acceptance baseline. Identify the firmware version used and agree how later changes will be tested. This helps prevent a software update from changing charging behaviour without the operator understanding the consequences.

An OCPP procurement requirement becomes useful when it is translated into observable tests and deliverable responsibilities. The fleet then buys a working connection between equipment and operations, rather than relying on a compatibility label alone.