EV charger metering and billing: reconcile the session before scaling the site

1. Draw the measurement boundary before comparing numbers

Identify exactly what each number represents. A utility meter may cover the whole property. A charger input meter may include conversion and auxiliary consumption. A session record may describe energy at a different measurement point. Vehicle battery data is another boundary again. Ask for the selected model's measurement arrangement; do not assume that two reports with the word “energy” measure the same thing.

For every source, record meter identity, location, unit, direction, time zone, reporting interval and whether values are cumulative registers or interval quantities. Then align the time window. A month's utility bill and a dashboard export ending at a different hour are not a valid like-for-like comparison. Keep other property loads and any shared equipment visible rather than labelling every difference a charger fault.

For a simple register-difference check, end minus start is meaningful only for compatible readings from the same register with a continuous, valid interval. Confirm how resets, replacement meters and incomplete sessions are handled. Do not silently substitute an estimated quantity for an approved billable measurement.

2. Request one joined evidence record

The lowest-cost time to discover that two systems cannot match their records is during the pilot, not after a customer dispute. Ask the integration team to supply a small, redacted sample export with an explicit mapping between identifiers. Charger transaction IDs, management-platform session IDs and payment references may have different formats; the mapping must not depend on somebody guessing from a date and an amount.

This is a proposed buyer acceptance dataset, not a claim that OCPP mandates every field or that every Xiaochong configuration already exports it. Agree which system supplies each item and whether an export or API is included in the commercial scope.

3. Freeze the tariff explanation for the pilot

Ask the operator to write down how the displayed price becomes a final amount. Identify which system is authoritative, how the customer sees the applicable tariff, and what happens when prices change during an active session. If the project uses time-based or idle charges, define the relevant start and stop events instead of treating plug-in time, energy-delivery time and parking time as interchangeable.

Keep currency, units and rounding explicit. Use a synthetic example reviewed by the operator and its payment/accounting specialists; it should reproduce the customer's document from retained evidence. Do not insert an invented local tax rate or assume that one country's rules apply across Africa, Central Asia or the Middle East. Record both the original calculation and any correction rather than overwriting history without explanation.

4. Separate communication from metrology and payment approval

The Open Charge Alliance describes OCPP as communication between charging stations and management systems. That is an important integration layer, but a protocol label alone does not establish the complete project's meter approval, receipt rules, tariff configuration or payment-provider settlement behaviour.

OCA's signed-meter-values application-note announcement describes sharing signed measurement evidence between a station and its management system to support consumer validation of chargeable quantities. Where such evidence is required for your project, ask about the actual meter, format, verification workflow and retention scope. Do not infer that every OCPP charger supplies signed values or that signing alone makes a complete installation compliant.

Keep three acceptance owners distinct: equipment measurement evidence, management-platform billing logic and payment-provider processing. A successful message exchange is not proof that a customer's payment has settled. Likewise, successful collection of a payment does not prove the underlying metered quantity is correct.

5. Test the exception queue, not only a successful session

In an approved pilot environment, agree scenarios with the equipment and software providers. Include a normal completed session, a session crossing a reporting boundary, a tariff-change case if supported, delayed records after a communications interruption, duplicate record delivery, a missing final record and a refund/correction case. Payment tests should use the provider's approved test arrangements; do not generate live customer charges without authorization.

For each case, retain the input evidence, expected result, actual result, responsible party and closure note. A retransmitted event must not silently become a second customer charge. An incomplete session should remain visibly unresolved until the agreed process decides how to handle it. Agree when human review is required and what the customer will be told.

Do not impose an arbitrary universal discrepancy percentage. Set acceptance limits and investigation criteria with the relevant specialists, based on the actual measurement boundaries and applicable requirements. Differences caused by mismatched periods or unrelated loads need a different remedy from missing or duplicated transaction records.

6. Make reconciliation repeatable after handover

Ask who reviews exceptions, how often reports are produced and who can export them after a supplier change. Define access control, retention, supported file formats and the process for tracing a complaint without exposing unnecessary customer or payment data. Limit shared samples to the information required; never put payment secrets or access credentials into a supplier discussion.

Record software and configuration versions alongside the pilot result. Repeat the relevant checks after a material change to firmware, tariff logic, metering hardware, management platform or payment integration. The aim is not a more impressive dashboard: it is a support team that can explain a session consistently without costly manual reconstruction.

Related buyer guides

• Offline operation and recovered transaction evidence
• Backend migration and exit readiness
• Factory and site acceptance

Primary OCA sources reviewed 14 September 2026. The procurement workflow and proposed evidence table are Xiaochong's original guidance, not OCA requirements or endorsement.