CDRs live in different systems with different field names, different status codes, different time zones. Reconciliation becomes a spreadsheet exercise — and revenue leaks every billing cycle. The ESME CDR Intelligence Suite is the vendor-agnostic correlation layer that consolidates them, matches them intelligently, and produces dispute-ready evidence packages.
Operators and aggregators that run BroadNet as their reconciliation layer
One correlation layer that catches what single-vendor reporting misses — and produces evidence the next team can act on.
SMSC, firewall, billing, partner CSVs — DB, SFTP, API.
Clock-drift safe matching across vendor systems.
Matched · status-mismatch · only-int · only-op · variance.
Millions per day with configurable retention.
The reconciliation view RA and finance teams open each morning — five variance buckets, one match rate, every discrepancy attributable. Below is an illustrative run built from sample data.
A = internal SMSC · B = partner billing
Illustrative example — sample data, not an audited SLA or a live feed.
Collection, normalisation, intelligent matching, reconciliation and reporting — each layer scoped, scalable, and replaceable independently from the others.
Direct DB read, SFTP polling, REST APIs, file-drop monitoring. Scheduled per source — 5 min for real-time, hourly or daily for batch.
Source ID, sender ID, ESME account, status code, timestamps — all mapped to a single canonical model. Time zones standardised to UTC.
Multi-key matching on message-id, MSISDN, sender-ID and timestamp — with a ±2-second fuzzy window for clock drift.
Matched · status-mismatch · only-internal · only-operator · volume-variance. Root-cause flagged per bucket.
Live dashboards for NOC and RA; scheduled reports for finance; CSV / JSON / PDF evidence packs for legal and partner disputes.
Direct DB read, SFTP polling, REST APIs, file-drop monitoring. Scheduled per source — 5 min for real-time, hourly or daily for batch.
Source ID, sender ID, ESME account, status code, timestamps — all mapped to a single canonical model. Time zones standardised to UTC.
Multi-key matching on message-id, MSISDN, sender-ID and timestamp — with a ±2-second fuzzy window for clock drift.
Matched · status-mismatch · only-internal · only-operator · volume-variance. Root-cause flagged per bucket.
Live dashboards for NOC and RA; scheduled reports for finance; CSV / JSON / PDF evidence packs for legal and partner disputes.
Four reasons operators and aggregators choose ESME CDR over relying on the SMSC vendor's own dashboards.
We hold our own SMPP and SS7 binds with destination operators in 86 countries, and every other route is a labelled partner route. No grey routes, no surprise re-routing, no opaque price markups in the middle.
Operating since 2003, headquartered in Dubai. We carry 300M+ application-to-person messages a day for banks, governments, airlines, and the platforms that power the modern internet.
Local presence across the Middle East and North Africa, plus pan-African, South Asian, and South-East Asian operator relationships that make global rollouts feel like a single market.
ISO 27001 / 9001 / 22301, SOC 2 Type II, GSMA Associate Member, HIPAA-aligned, GDPR-aligned. Sender-ID registrations handled by an in-region compliance team in every regulated market.
Multi-source collector
We have integrated with dozens of SMSC platforms across many generations of telecom kit. If a system can export records — via database, file, or API — the collector can read them.
Both MT and MO records. Direct read-only DB access or scheduled CSV export via SFTP.
Allowed, blocked, modified — the firewall view of the same traffic, correlated with what the SMSC saw.
Direct SMPP connections from ESME clients — captured at the gateway for end-to-end attribution.
Rating and invoicing data pulled from the billing platform for cross-validation against routed traffic.
CSV / XLSX from operators and aggregators — pulled via SFTP, dropped to a watched folder, or pushed via API.
Reads from internal pipeline stores when available — used to enrich correlation and confirm routing decisions.
Reconciliation buckets
Discrepancies are categorised so the right team owns the right bucket — RA owns phantom CDRs, ops owns status mismatches, commercial owns volume variance, legal owns dispute escalation.
The healthy case. Records present in internal and partner data with consistent delivery status. The baseline against which the rest are measured.
We say DELIVRD, partner says EXPIRED. Indicates DLR-timing drift, error-code mapping differences, or genuine delivery disputes.
Potential missing billing on the partner side. Cross-check against firewall logs and routing to confirm send-completion.
Phantom-CDR candidate. Possible duplicate count, test-traffic inflation, or data corruption upstream. Strongest revenue-recovery lever.
Aggregate volume matches but the per-status distribution differs. Usually a sign of segment / concatenation handling drift between the two systems.
Teams served
Live traffic dashboards by ESME, operator, and route. Quality KPIs with delivery rates and error distributions. Threshold and anomaly alerts.
Automated reconciliation against partner CDRs. Leakage analysis identifying unbilled traffic and phantom charges. Billing-rule validation.
Volume trends per partner and destination. Campaign and partner behavior patterns across operators. Margin visibility per route.
Evidence-ready CDR exports with full correlation. Forensic drill-down by message-id, MSISDN, or sender. Structured packages for arbitration.
On-premise or private-cloud, audit-ready, regulator-recognised across MENA.
Companion platforms
The companion product. ESME CDR covers A2P SMS records; Signaling CDR adds SS7 / SIGTRAN / SIP capture and court-ready forensic packages.
Learn moreCarrier-grade messaging core. ESME CDR is the natural reconciliation layer on top of SMSC and partner billing.
Learn morePlain-English answer to the most common question for teams new to telecom CDR work.
Learn moreIt gives operators, aggregators and enterprises one trusted view of A2P SMS traffic, independent of any single vendor's reporting. CDRs from SMSC, firewall, billing, and partner sources are consolidated, normalised to a canonical schema, intelligently matched, and categorised into reconciliation buckets — so disputes have attributable evidence and revenue leakage gets caught before it becomes a recurring loss.
Multiple alternatives are supported: CSV / XLSX export to a polled SFTP folder, REST or SOAP API integration, or working with the SMSC vendor to expose a read-only view. We have integrated with dozens of SMSC platforms across many generations of telecom kit. If the system can export records, the collector can read them.
Matching combines multiple keys — message-id, MSISDN, sender-ID, and timestamp — with a fuzzy time window (typically ±2 seconds) to account for clock drift between systems. Concatenated messages are reassembled before matching so that a single logical message is not double-counted across its segments.
A summary report with totals per bucket — matched, status-mismatch, only-internal, only-operator, volume-variance — and detailed exception lists exportable as CSV for analysis, JSON for system integration, or PDF for formal reports and partner disputes. Forensic drill-down is available on every record.
All timestamps are normalised to UTC on ingestion and stored in UTC. When displayed in dashboards or reports, they are converted to the user's preferred timezone (configurable per account). For reconciliation, the fuzzy time window absorbs both clock drift and small timezone-conversion errors. Raw timezone metadata is preserved for forensic work.
It provides strong fraud indicators rather than full fraud management. Volume-based alerts surface traffic spikes from specific ESME accounts, behavioural analysis flags suspicious sender-ID patterns, velocity checks identify repeat-to-same-destination patterns, and integration with firewall data correlates blocked traffic with CDR patterns. Teams who already run a fraud system feed those indicators into it; teams who do not often start there.
On-premise or in private cloud, on Linux or Windows servers. Data residency is fully under your control — nothing is sent to BroadNet or third parties without explicit approval. Retention is configured per table to match internal IT and compliance policy.
A typical engagement runs in phases: discovery workshop, pilot deployment against the first data source (usually SMSC), full integration of remaining sources (firewall, billing, partners), and production rollout with dashboards, alerts, and team training. End-to-end timelines vary by environment complexity — most operators are in production inside a quarter.
Question not here? Ask our engineering team
The same platform that carries 300M+ messages a day, available as building blocks for your stack.
We will run a reconciliation audit against your existing SMSC, firewall, billing and partner data — and show you what an independent correlation layer would have caught in the last billing cycle.
Go deeper on the concepts behind this product.
