تسوية بيانات تجوال شحن المركبات الكهربائية: من سجلات بيانات المكالمات إلى التسوية

EV charging roaming reconciliation is the process of matching charging sessions, Charge Detail Records (CDRs), agreed prices, partner invoices and payment records to establish what each party owes and whether that amount has been paid. It connects the technical record of a charging event with the commercial record of settlement.

A driver may finish charging without noticing any problem, while the businesses behind that session still disagree about the energy delivered, the applicable tariff or the invoice total. Successful charging and successful data delivery do not, by themselves, mean the transaction is ready for settlement.

This guide explains how CPOs, eMSPs and finance teams can investigate those differences, prevent duplicate billing and close a settlement period with an auditable record. For protocol fundamentals and connection models, see our complete guide to OCPI and EV charging roaming.

What does EV charging roaming reconciliation actually check?

Reconciliation answers five practical questions: Did the session happen? Is its final record complete? Was it priced correctly? Was it included once in the right invoice? Has the resulting balance been settled?

Start by separating three activities that are often grouped together. مصالحة compares records and identifies differences. Clearing establishes the financial obligations between participants under their commercial arrangement. مستعمرة discharges those obligations through the agreed payment process. A roaming hub may perform some of these functions, but its role depends on the service and contract.

There are also two different prices to consider. The amount owed by an eMSP to a CPO can differ from the amount the eMSP charges its driver. Membership discounts, subscriptions and retail markups can create legitimate differences. Compare the partner invoice with the agreed partner pricing; reconcile the driver bill separately against the driver's terms.

A useful operating model maintains three linked checks: session-to-CDR reconciliation, CDR-to-invoice reconciliation and invoice-to-payment reconciliation. Keeping them distinct makes it easier to see whether an exception belongs to engineering, commercial operations or finance.

Session, CDR, invoice and payment: use each record for the right purpose

A Session object provides changing information about a charging event. A CDR records the completed event for billing. An invoice groups the financial charges under an agreement, while a payment record shows the money received or sent. Each answers a different question.

On smaller screens, swipe within the table to read all columns.

Do not use a live session estimate as a substitute for a missing CDR. Equally, do not interpret a missing Session cost as a zero charge: OCPI distinguishes an omitted cost from an explicitly free session. The official Sessions module describes this distinction.

Receiving a CDR confirms a data event, not financial approval. Give the record separate delivery, validation, invoicing and settlement states. For example, a record can be received successfully while remaining on hold because the tariff cannot be verified.

What data should a roaming reconciliation ledger contain?

Build a ledger that connects the original partner payload to your internal session, invoice and payment references. Preserve the received payload alongside normalized fields so an investigator can reconstruct a decision without relying on a dashboard that has since changed.

The following groups are a practical starting point. Some fields are protocol fields; others are internal accounting references. Their availability and mandatory status must be checked against the negotiated protocol version.

• Identity: record owner, country code, party ID, CDR ID, Session ID when supplied, receiving partner and internal transaction reference.
• Charging evidence: location, EVSE and connector identifiers, start and end timestamps, energy quantity, relevant charging periods and meter evidence where available.
• Commercial basis: tariff snapshot or historical reference, contract version, currency, reported cost, expected cost, tax basis and any separately agreed fees.
• Processing history: source route, receipt timestamp, validation outcome, duplicate classification, exception owner and approval history.
• Financial references: invoice and line reference, credit linkage, settlement batch, due date, remittance reference and cash allocation.

Use the record owner's identity together with the CDR ID to avoid collisions between different CPOs. Keep the receiving partner and route as additional context. An HTTP request identifier is useful for tracing delivery, but it should not become the business key for a charge.

OCPI 2.2.1 can carry an optional session_id in a CDR. Where it is available, preserve the association. Where it is missing, use a documented mapping based on other evidence, such as authorization reference, token, EVSE and timestamps. An ambiguous match should enter a review queue rather than become an automatic invoice line.

For the operational source of this ledger, review your نظام إدارة نقاط الشحن and determine which session, pricing and export records it can supply. A finance workflow cannot resolve evidence that was never retained.

A practical workflow from session records to settlement

1. Define the period and the commercial rules

Agree on the settlement currency, billing period, cutoff timezone, pricing source, fee treatment, correction process and payment terms before processing records. Specify whether period eligibility depends on session completion, CDR receipt or another contractual event.

Keep the operational event time and the receipt time separate. A session completed at the end of a month may arrive after the cutoff because a system was offline. Record it as a late arrival and apply the agreed catch-up rule; do not silently alter a previously approved batch.

2. Collect records and normalize them without losing evidence

Import local charging records, partner CDRs and invoice detail. Normalize units, decimal precision and identifiers while preserving their originals. Store timezone-aware timestamps and the location's timezone for checks that depend on local tariff hours.

Make ingestion repeatable. Reprocessing the same export or receiving a retry should update the processing history without creating a second payable charge. Keep a record of import coverage so a failed page of data does not look like an empty period.

3. Match sessions and CDRs

First identify completed sessions that should have a CDR but do not. Then check CDRs that have no local match. These are different exceptions: one suggests missing final data; the other may indicate incomplete local records, incorrect routing or a mapping problem.

Use exact identifiers before secondary evidence. If two candidates share similar times and energy, do not choose the closest one automatically. Ask the source owner for the missing reference. Charging quantities are evidence, but they are not reliable unique identifiers.

4. Validate quantities and expected cost

Check that the record is structurally valid, its timestamps are plausible, the currency matches the agreement and the energy and billable time can be explained. Zero energy does not automatically mean an invalid charge; investigate whether an agreed start, reservation or parking fee applies.

Recalculate the expected partner amount using the pricing basis valid for the event. Flag differences by component rather than showing only a total mismatch. An energy-price exception requires different evidence from a parking-duration exception.

5. Resolve exceptions and freeze the approved batch

Assign each exception a reason, owner, value and next action. Release a record only after the evidence or an approved adjustment explains the difference. A possible internal sequence is received, validated, held, approved, invoiced and settled.

Freeze a versioned manifest of the approved CDRs and adjustments. Later records should appear in a subsequent batch or a separately approved revision. This gives both partners an exact list to compare when an invoice is disputed.

6. Reconcile the invoice, then allocate payment

Compare invoice detail with the approved manifest. Check record count, component totals, credits and separately billed fees. Matching grand totals alone is insufficient: one omitted charge and one duplicate charge can cancel each other out.

Finally, match remittance and bank records to the invoice. Keep partial payments, bank fees and currency-conversion differences visible. Close the cash reconciliation only when the remaining balance is explained and approved under your finance controls.

Why do CDR amounts and partner invoices disagree?

The first check is whether both amounts describe the same transaction, price basis, currency and tax treatment. Many apparent errors arise because one report includes tax or retail pricing while another represents the partner amount before tax.

Historical tariffs and contract pricing

Keep the pricing evidence that applied to the charging event. Recalculating a past transaction against today's tariff can produce a credible but incorrect result. If the commercial agreement applies a separate wholesale formula, retain that formula and explain how it relates to the exchanged tariff.

For sessions spanning a pricing boundary, inspect the relevant periods and conditions. Do not assume that one rate applies to the entire session or that every tariff change requires the same calculation treatment. Establish the applicable rule from the actual tariff and agreement.

Energy, charging time and parking time

A total based only on kWh can miss legitimate time or fixed charges. Separate charging duration from time connected without charging, and verify any grace period. If the system cannot establish the necessary boundaries, flag the missing evidence instead of inventing a duration.

For example, a charging event might contain 35 minutes of charging and another 10 minutes connected after energy transfer stops. Billing all 45 minutes as charging time can produce a different result from applying the agreed charging and parking components separately.

Billing increments and rounding

Quantity rounding and money rounding are separate checks. In OCPI 2.2.1, tariff price components include step_size. For a single time component billed in five-minute blocks, six billable minutes become ten. The official Tariffs module also explains why transitions between tariff elements need careful treatment.

Use decimal arithmetic for monetary calculations. Document whether the agreed process rounds components, session totals or invoice totals, and at what precision. A tolerance should reflect an approved rounding rule; it should not conceal a repeated pricing error.

Taxes, currency and separately billed fees

Compare amounts on a consistent basis before calculating a variance. Keep tax lines, service charges and hub fees identifiable. If currency conversion is part of the agreement, retain the rate source, conversion date and original amount so the calculation can be reproduced.

An agreed commercial adjustment should have its own reference. Do not rewrite charging energy to make an invoice balance. For the surrounding payment architecture, see TrendPower's حلول دفع رسوم شحن المركبات الكهربائية; confirm the required billing and settlement scope for your project.

Worked example: finding a duplicate, a missing record and a price variance

The simplified ledger below illustrates a reconciliation run for one partner in one currency. All amounts are before tax. It excludes hub fees, foreign exchange and other adjustments so the record-level differences remain easy to follow.

The raw received amounts sum to €66.80 because the S-102 delivery is counted twice. Deduplication reduces the received charge total to €54.20. The expected total across all four sessions is €62.00, but the batch is still incomplete and includes a disputed amount.

At this stage, only S-101 and S-102 are approved, giving a settlement-ready amount of €31.00. The missing €9.80 record and the disputed S-104 charge remain visible in the exception ledger. Neither should disappear simply because the approved invoice excludes it.

Suppose the investigation confirms S-104 used the wrong pricing basis and the partner supplies a valid correction to €21.20. If S-103's valid €9.80 CDR also arrives before the agreed cutoff, the approved total becomes €62.00. If it arrives after cutoff, the current batch and the next catch-up batch must show the split explicitly.

The reversal and replacement in this equation belong to the same correction chain. If the original charge was already invoiced in an earlier period, account for the adjustment in the appropriate later period rather than pretending the original invoice never existed.

How to handle duplicate, missing and late CDRs

Duplicate delivery: preserve the trace, avoid a second charge

A sender may retry after a timeout even though the receiver stored the first request. Your ingestion design should recognize the repeated business record and retain the additional delivery trace without creating another billable item.

Classify repeats carefully. The same owner and CDR ID with identical content suggests a delivery duplicate. The same key with different content is a conflict requiring investigation. Different CDR IDs that appear to describe the same event require review too, but may belong to a legitimate credit-and-replacement chain.

Never deduplicate solely by token, energy or rounded start time. One driver can perform multiple similar sessions, and legitimate records may share those attributes. Use stable identity and correction references, with secondary evidence supporting the decision.

Missing CDR: identify where the record stopped

Check whether the CPO generated the CDR, attempted delivery and received a successful application response. In a hub route, distinguish receipt by the hub from onward delivery to the intended recipient. Keep these checkpoints visible instead of treating the route as one opaque connection.

Request the original record through the partner's agreed recovery method. Do not create a final partner charge from the last live estimate just to close the month. If finance needs an accrual, keep it separate from the operational CDR and reconcile it when the final evidence arrives.

Late CDR: retain the original event date

Maintain a queue for valid records received after the period cutoff. Show the service period, receipt date and invoice period separately. This lets finance explain a prior-period charge without changing the factual time of the charging event.

During data recovery, check pagination and the meaning of date filters. In OCPI 2.2.1, CDR list filtering uses last_updated, which is not the session completion time. A recovery query therefore needs to collect the relevant updates before your own process assigns records to the agreed billing period.

How should disputes and CDR corrections be resolved?

Open an exception with a specific claim. “The amount is wrong” is difficult to investigate; “CDR X includes €2.00 in parking cost without the agreed billable parking period” gives both teams a testable issue.

A useful dispute packet contains the record identity, original payload, relevant session or meter evidence, historical tariff, agreement reference, expected calculation, received calculation and invoice line. Add an owner, response deadline and proposed action. Share only the token or customer information necessary for the investigation.

For an already sent OCPI 2.2.1 CDR, preserve the original. The protocol correction mechanism uses a new credit CDR referencing the original, with negative original values in total_cost; a corrected charge can then use a new unique CDR ID. Do not negate every quantity or cost field indiscriminately. Check the official CDR correction specification against the version in use.

A credit CDR and a financial credit note serve related but different purposes. Connect the protocol correction to the accounting documents required by the agreement and your finance process. Confirm whether the driver also needs a retail bill adjustment; a wholesale correction does not automatically explain the customer's position.

Resolve records individually where possible. Whether undisputed amounts can be invoiced or paid while a dispute remains open depends on the contract. Avoid holding an entire partner balance by default when only a small, identifiable subset is unresolved.

Who owns each part of roaming reconciliation?

Give every exception one coordinating owner, even when several teams contribute evidence. Otherwise, engineering may consider delivery complete while finance waits indefinitely for a commercially approved amount.

• CPO operations: establish what happened at the charger and supply the final charging record, pricing evidence and corrections within the agreed role.
• eMSP operations: associate partner records with the correct customer event and manage any separate retail billing issue.
• Integration team: investigate routing, application responses, missing pages, retries and identifier mapping.
• Commercial owner: resolve the interpretation of partner prices, fees, deadlines and dispute rules.
• Finance: approve invoice treatment, allocate cash and maintain the remaining balance and audit trail.
• Roaming hub, where involved: provide the routing, reconciliation or financial evidence included in its contracted service.

These are suggested responsibilities, not a universal allocation of liability. The contract must identify the legal invoice issuer, debtor and settlement party. A software provider does not become a clearing or settlement counterparty merely by supplying an OCPI connection.

A settlement close checklist for charging operators

Run lightweight exception checks throughout the period, then use a controlled close process. Finding a missing tariff while the evidence is readily available is easier than rebuilding it weeks after the invoice has been issued.

1. Confirm collection coverage. All expected sources, pages and recovery windows have been processed; failed imports are visible.
2. Confirm identity and eligibility. Each payable record belongs to the correct partner and period, with duplicate and credit treatment checked.
3. Confirm the commercial basis. Currency, historical pricing, tax treatment and separately billed fees are documented.
4. Document exceptions. Held records retain their count, financial exposure, owner and next action.
5. Freeze the approved manifest. Record its version, approval time, CDR list, corrections and component totals.
6. Match invoice detail. Trace each charge or adjustment to the manifest and explain any invoice-only item.
7. Allocate remittance. Record full or partial payment and separately explain remaining balances, fees and conversion differences.
8. Preserve the audit trail. Keep the evidence and approvals required by your contractual and retention policies.

Useful metrics include completed sessions awaiting CDRs, unresolved price-variance value, invoice lines without approved evidence and overdue settlement balances. Define the denominator and reporting window for every percentage. An automatic match rate becomes misleading if difficult records are simply excluded from the population.

What should reconciliation software demonstrate?

Evaluate a reconciliation workflow with sample transactions, not just a dashboard screenshot. Ask the team to process a clean session, a duplicate delivery, a missing CDR, a tariff boundary, a credit-and-replacement chain and a partial payment.

The demonstration should show how the system preserves original evidence, identifies the business record, explains the expected cost and prevents an unresolved item from being paid accidentally. Ask for an export that lets finance reproduce the approved totals outside the application.

Also test what happens after a batch has been approved. Can a user silently edit it? Can the next batch accidentally include the same CDR? Does a late credit remain linked to the original invoice? These questions reveal whether the workflow remains reliable after the first successful run.

Automate stable comparisons and route ambiguous decisions to the right reviewer. Currency conflicts, uncertain identity and disputed contractual terms should not be hidden behind a broad automatic tolerance. Permissions and approval history matter as much as the matching logic.

Frequently asked questions about EV charging roaming reconciliation

Is a completed Session enough to invoice a roaming partner?

A completed Session is useful operational evidence, but the final CDR is the charging record to reconcile for billing. Your agreement determines invoice eligibility. If the CDR is missing, investigate or use a separately controlled accrual process rather than treating the live record as final.

Does OCPI automatically settle money between CPOs and eMSPs?

An OCPI connection does not, by itself, transfer or settle funds. Charging data supports the financial process, while the commercial agreement, invoicing workflow and payment arrangement determine who pays whom and when.

Should a driver's receipt match the CPO's CDR amount?

Not necessarily. The driver's retail agreement may differ from the CPO–eMSP pricing agreement. Reconcile each amount against its own pricing basis, then investigate unexplained differences within that layer.

What is the best way to prevent duplicate CDR billing?

Use a stable key based on the record owner and CDR ID, retain delivery history and process repeated records idempotently. Investigate conflicting payloads and preserve credit chains. Similar timestamps or energy totals alone are insufficient for safe deduplication.

What reconciliation tolerance should operators use?

There is no single tolerance suitable for every partner. Agree on the calculation precision and rounding treatment first, then set controls appropriate to that rule and currency. Track repeated small differences rather than automatically dismissing them.

How often should roaming records be reconciled?

Run operational checks frequently enough to resolve missing data and pricing exceptions before invoicing. Complete invoice and cash reconciliation according to the agreed settlement schedule. The appropriate frequency depends on volume, partner deadlines and the cost of unresolved exceptions.