How reconciliation is handled at scale In large telecom environments, reconciliation is treated as a control framework that sits across the whole revenue chain, not as a single “billing feature”. The usual pattern is to reconcile at multiple points (network element → mediation → rating/billing → invoicing/GL),with clear ownership, evidence, and time-bound exception handling. The aim is to prove
completeness (nothing missing),
uniqueness (no duplicates),and
accuracy (correct mapping and charging),rather than hoping rating logic catches issues downstream.
A common approach is layered reconciliation:
- Volume and control totals: per switch/MSC/PGW/SBC, per trunk, per IMSI/MSISDN range, per time window. Control totals include record counts, summed durations/bytes, and key event counts (starts/ends).
- Sequence and gap checks: where network elements provide sequence numbers, file IDs, or batch IDs, gaps are flagged quickly (often within minutes for near-real-time feeds).
- Session stitching rules: partial sessions are normal (roaming, handovers, interim updates). Mediation/rating applies correlation keys (session ID, charging ID, GTP/IMS identifiers) and rules for late-arriving legs, with tolerances and reprocessing windows.
- Duplicate detection: fingerprinting (hash of key fields),idempotency keys, and “seen before” stores stop replays and resend storms becoming revenue.
Operationally, exceptions are managed like incidents: dashboards, thresholds, and a ticket workflow with SLAs. Good setups keep raw CDRs immutable, store each processing stage, and support controlled re-rating/re-billing. Finance-facing reconciliation then ties billed usage to invoices and the general ledger, so leakage isn’t just a technical metric but a provable £ impact.
Tooling varies (vendor RA platforms, bespoke data lakes, streaming pipelines),but the winning factor is governance: defined controls, audit trails, and someone accountable for clearing breaks rather than accepting them as “noise”.
