How to Reconcile CDR Records Without Lost Revenue

A two-minute difference between an IVR platform and a carrier report can look harmless until it is repeated across thousands of answered calls. Small mismatches affect billable minutes, payout forecasts and the confidence partners place in a traffic route. Knowing how to reconcile CDR records gives operators a repeatable way to identify those differences before they become disputed revenue.

For international premium-rate and revenue-share traffic, reconciliation is not simply matching two spreadsheets. It is the process of proving that each billable call was recorded consistently across the traffic source, routing platform, carrier and payout report. The goal is not always a perfect line-by-line match on the first pass. The goal is to explain every material variance with evidence.

What CDR reconciliation is designed to prove

A call detail record, or CDR, documents an individual call event. Depending on the system, it may include a call reference, originating country, dialled number, start and answer time, release time, duration, disposition, trunk or route, and rated amount. Each party in the delivery chain can generate its own version of that record.

Reconciliation compares those versions against a shared reporting period and a defined commercial rule. For a traffic monetisation partner, the core questions are straightforward: how many calls reached the destination, how many were answered, how many minutes were billable, and which rate applies to those minutes?

The answer can differ between datasets for valid operational reasons. A platform may measure connected duration from answer to hang-up, while a carrier rounds each call to a billing increment. One report may use UTC and another local destination time. A call transferred within an IVR may create multiple legs. These are not necessarily errors, but they must be understood before revenue is calculated.

Start with a clean reporting baseline

Before comparing records, agree the scope. Use the same start and end time, time zone, destination, number range and traffic type in every extract. A reconciliation performed with one report ending at 23:59 local time and another ending at 23:59 UTC will produce artificial variances around the reporting boundary.

Confirm the reporting period in writing, particularly where month-end traffic is involved. It is sensible to retain the source files exactly as exported, then perform normalisation in a separate working file or database table. This preserves an audit trail if a variance later needs to be reviewed.

Next, establish a data dictionary. Labels vary widely between switches and portals. “Duration” might mean total call duration, ringing time, answered seconds or billable seconds. “Completed” may include calls that connected but did not meet a minimum-duration rule. Map each field before calculating anything.

At minimum, identify:

• the unique call identifier or reference available in each source;
• start, answer and release timestamps, including their time zone;
• final disposition or disconnect cause;
• raw duration and billable duration;
• dialled number, destination and route; and
• rating fields, including currency, rate and rounding rule.

Where there is no common unique ID, build a matching key from several reliable fields, such as dialled number, start time, originating number where permitted, and duration. This is less precise than a shared call ID, so use a reasonable time tolerance and flag uncertain matches rather than forcing them into the result.

How to reconcile CDR records step by step

1. Normalise the source data

Export CDRs in a structured format such as CSV where possible. Standardise timestamp formats, convert all records to one agreed time zone, and ensure durations use the same unit. Remove formatting characters from numbers only where this does not alter destination identification.

Normalisation also means treating empty fields consistently. A blank answer timestamp, for example, should not be converted automatically into a zero-duration answered call. Keep the original value and classify it according to the business rule.

2. Match calls before comparing totals

A top-level comparison of total calls and total minutes is useful, but it cannot explain why a variance exists. Match individual records first. Classify each record as matched, unmatched on your side, unmatched on the counterparty side, or matched with a variance.

For matched calls, compare answer time, release time, raw duration and rated duration. Use tolerances that reflect the infrastructure. A one- or two-second difference may arise from signalling or timestamp precision. A 60-second difference may point to a rounding policy, delayed answer event or an incorrect call leg.

Avoid applying a broad tolerance simply to make the figures align. That hides patterns that could affect commercial reporting.

3. Separate call-count variance from minute variance

A reconciliation can show a close call count while still exposing a significant difference in billable minutes. Analyse both measures independently. Start with offered calls, then answered calls, then billable calls, followed by raw connected seconds and rated minutes.

This sequence makes the issue easier to isolate. If answered-call totals differ, investigate call setup, routing and final disposition. If answered calls match but rated minutes do not, focus on duration measurement, minimum charges and rounding increments. If minutes agree but revenue differs, the likely cause is rate application, currency treatment or a commercial exception.

4. Apply the agreed rating logic

Raw duration is not necessarily the duration used for payout. Some destinations bill per second after an initial minimum; others round to 30 or 60-second increments. Certain services may exclude calls below a defined duration threshold. Re-rate a controlled sample using the exact rule agreed for the destination.

Document whether rounding occurs per call or on the aggregate. Per-call rounding can produce a meaningful difference over high-volume traffic, even when the total raw seconds look similar. The same is true of partial-minute treatment.

Use the effective date of each rate. A rate change introduced mid-cycle should not be applied across the entire month. Split the report at the change point and retain evidence of the applicable rate table.

5. Investigate exceptions by pattern

Once records are categorised, group exceptions by destination, number, route, hour, disposition and duration band. Patterns reveal more than isolated call reviews. For example, unmatched calls concentrated in a short time window may indicate an ingestion delay. Variances only on one number range may point to a configuration issue. A recurring difference on calls lasting just over one minute often indicates rounding logic.

Prioritise material exceptions. Review the largest monetary differences first, then investigate recurring smaller discrepancies. A small variance repeated daily across a high-volume route may be commercially more important than one unusually long call.

Common causes of CDR mismatches

Time-zone misalignment is among the most frequent causes, especially for traffic spanning Europe, MENA, Asia and Africa. Daylight saving changes add another layer of risk. Store timestamps in UTC where possible, then display local time only for operational analysis.

Duplicate records can appear when a call is retried, when a platform reprocesses an event, or when records are joined incorrectly after an export. Conversely, missing records may result from delayed mediation, incomplete file delivery or filters that omit short calls.

Call-leg handling deserves particular attention. A single inbound call can create several records when it is transferred, bridged or routed through multiple systems. Decide which leg represents the commercial event. Counting every leg as a separate billable call will overstate traffic; selecting the wrong leg may understate connected duration.

Finally, distinguish technical completion from commercial eligibility. A call may connect technically but fail the billing rule because it ended before the minimum duration. This should be visible in the reconciliation rather than treated as a missing payment without evidence.

Build a control process, not a month-end rescue

The strongest reconciliation process runs frequently. Daily checks identify issues while switch logs, route settings and support evidence are still accessible. Weekly reviews show whether an exception is growing. Month-end reporting should validate a controlled process, not be the first time two datasets are compared.

Set practical thresholds for review, such as variance by answered calls, rated minutes and expected payout per destination. Thresholds should reflect traffic volume. A fixed percentage alone can be misleading on low-volume routes, while a fixed monetary threshold may miss a rate issue on a strategically important destination.

Maintain a variance register with the reporting period, route, issue type, financial impact, owner, evidence and resolution date. This creates accountability and helps identify repeat causes. It also gives finance and operations a shared record of why a payout figure changed.

A platform with live statistics and exportable CDR reporting, such as TrustCaller, can shorten this cycle by giving partners timely visibility of call activity and rated performance. Even so, portal data should be checked against the agreed rating rules and the relevant carrier-side evidence when a material discrepancy appears.

Make disputes evidence-led

When raising a discrepancy, send a concise exception file rather than a general statement that totals do not match. Include the call identifiers, timestamps in the agreed time zone, raw and rated durations, expected rate, reported rate and the calculated variance. State the matching and rounding assumptions used.

This approach reduces back-and-forth and protects both parties from subjective interpretations. It also makes it easier to distinguish a reporting delay from a genuine rating issue.

Accurate reconciliation is a commercial discipline: the closer it sits to daily traffic operations, the easier it is to protect valid minutes, correct errors early and maintain confidence in every payout cycle.