What Telecom Billing Taught Me About Data Quality

From 2007 to 2010 I worked at Xalted in Bengaluru as an Implementation Engineer on operations and business support systems (OSS/BSS) for MTNL. The work covered process mediation, interconnect billing, fraud management and reconciliation.

Those words do not sound exciting, and to most people outside telecom they mean little. But few environments teach the value of accurate data as directly as a telecom back office. Years later, when organisations ask me why their analytics or AI projects disappoint, I often find myself explaining lessons I learned there.

A quick picture of the back office

Every call, message and data session on a telecom network generates records. These records come from many types of network equipment, in different formats, at very high volume.

• Mediation collects those raw records, validates them, removes duplicates, corrects or rejects malformed entries, and converts everything into a consistent format.
• Rating and billing apply tariffs to the usage and produce charges for customers.
• Interconnect billing calculates what operators owe each other when traffic crosses from one network to another.
• Fraud management looks for patterns that suggest misuse.
• Reconciliation compares figures across systems and between operators, and investigates when they disagree.

Each function depends on the one before it. A small error in mediation becomes a wrong charge in billing, a dispute in interconnect settlement, and a false alarm or a missed signal in fraud detection.

Lesson one: garbage in is not a slogan, it is an invoice

In many businesses, poor data quality is an inconvenience. In telecom billing it has a direct financial value. A fraction of a percent of records dropped or duplicated at mediation, across enormous volumes, becomes real revenue lost or real customers overcharged.

That made data quality something everyone could see and measure. It also made one principle obvious: fix problems as close to the source as possible. Cleaning data at the reporting stage is expensive and incomplete. Validating it at the point of entry is cheap and thorough.

Lesson two: reconciliation is a habit, not a report

Reconciliation means comparing figures from systems that should agree and investigating every meaningful difference. In interconnect billing, two operators compare their records of the traffic that passed between them. They rarely match perfectly, and the differences have to be explained.

The lesson I took from it is that no single system should be trusted without a check against another. In later work on business software, this became a standard practice: stock in the inventory system against physical counts, fees recorded against bank deposits, appointments booked against visits billed.

Organisations that reconcile regularly discover problems while they are small. Organisations that do not discover them during an audit, or when a customer complains.

Lesson three: the exception is where the system is really tested

Most records are routine. The difficult ones are the calls that span midnight, the roaming session that crosses a tariff boundary, the record with a missing field from an older piece of equipment. Systems are designed around the routine case and tested, in real life, by the exceptions.

This is equally true in software for restaurants, schools and clinics, and it is especially true for AI. A model that handles the common case well can still fail on the unusual inputs that matter most. Designing and testing deliberately for exceptions is one of the most valuable disciplines an engineering team can adopt.

Lesson four: traceability builds trust

When a customer disputed a bill, the question was simple: where did this charge come from? Answering it required tracing a figure on an invoice back through rating and mediation to the original network record.

Systems that make this tracing easy earn the trust of finance teams, auditors and customers. Systems that cannot explain their own numbers lose it, however accurate they may be.

The same principle now guides how I think about AI. An output that can be traced to its sources, whether a document retrieved, a rule applied or a record read, is far more useful than one that simply appears. That is why the ability to show sources and log actions features prominently in my approach to AI agents and to AI in healthcare.

Lesson five: fraud looks like normal until it does not

Fraud management systems look for unusual patterns: sudden spikes, impossible combinations, behaviour that differs from a customer's history. The challenge is that most unusual activity is innocent, and a system that raises too many alarms is quickly ignored.

That balance between sensitivity and usefulness is a design problem I meet again in many settings, including alerts in clinical software. An alert that fires constantly teaches people to dismiss alerts. Fewer, better-targeted signals, with the evidence attached, are worth more than exhaustive warnings.

Carrying the lessons forward

The technology of telecom back offices has changed a great deal since then, and my own work has moved into AI and, through medical training, into healthcare. The lessons have travelled with me almost unchanged:

1. Validate data at the source.
2. Reconcile systems against each other, routinely.
3. Design and test for the exceptions.
4. Make every important figure traceable.
5. Tune alerts so that people still pay attention to them.

None of them requires new technology. All of them make new technology work better.

Questions

Frequently asked questions

What are OSS and BSS in telecom?

Operations Support Systems (OSS) help telecom operators manage their networks, including service provisioning and fault management. Business Support Systems (BSS) handle customer-facing and commercial functions such as rating, billing, customer management and revenue assurance.

What is data reconciliation?

Data reconciliation is the process of comparing records from two or more systems or sources that should agree, identifying differences, investigating their causes and correcting errors. It is common in billing, finance, inventory and any setting where accuracy has financial or operational consequences.