Every Billing Change Waits on a System Nobody Dares Touch. Four Ways Off the Old Applications, Weighed.

The complaint was resolved on Tuesday. A business customer had been charged a full month for a part-month after a plan change, and the service team agreed the charge was wrong.

The rule that made the charge is another matter. It sits in the old charging application, and the one engineer who changes that application has a queue: a new tariff for business customers, two discount corrections, and a report finance asked for in the spring.

The head of billing operations asks whether the rule can simply be changed. The answer has not changed in years: not without checking every other bill, and nobody has a list of what those depend on.

What We Found

For this article we went through the public record on what keeps operators on old billing applications: one news report of a fine after a move to a new billing system, one survey of IT professionals on why old systems stay, and the rules that operators in India now work under on billing complaints.

Two findings stand out. The rules are set out in the next section.

A fault in a billing move can run for many months. In an older case in October 2016 the UK regulator, Ofcom, fined Vodafone £3.7 million, finding that between December 2013 and April 2015 it gave 10,452 pay-as-you-go customers incorrect information that they would receive the services they paid for with top-ups, and that “the account balance information did not accurately reflect the true extent of the credit for which they had paid”. Press reports at the time said the operator linked the failures to a move to a new billing system; Ofcom’s notice gives no cause. Neither says anything about what went wrong inside that system or how the move was checked, and we do not guess. Press reports tied it to a move to a new billing system, a kind of move we do not make. We take one narrow point: a fault at a move can run for months.

The fear is of disruption, and the old system still runs. In one survey of about five hundred IT professionals in the US, across industries and company sizes, run by a firm that sells software services and not about telecom, more than a third named fear of disrupting operations as a reason for not modernising, and half said the current system still works.

Our reading is that the two fears feed each other. A charging application nobody dares change is kept because a move might disrupt billing, and because it is kept, every change to it carries the same fear. So each tariff and each correction waits its turn.

What Waits While Nobody Dares Touch the Charging Rules

In India, TRAI’s Standards of Quality of Service regulations of 2024 have been in force “with effect from 1st October 2024”. Among their customer-service benchmarks are “Resolution of billing/ charging complaints within four weeks” (for 100% of complaints) and adjustment to the customer’s account “within one week from the date of resolution”. The regulations apply to providers of access and broadband services and to internet service providers, but not to “an Internet Service Provider whose total number of subscribers as on last day of the preceding financial year does not exceed ten thousand”. A consultation paper of 5 August 2026 proposes resolving billing complaints “within one week”; that is a proposal, not a rule, and TRAI had not notified it as of 14 October 2026.

These regulations name no application and say nothing about how a charging rule is kept. Our reading is that every tariff or billing change, and every correction, still waits on a system nobody dares touch. An operator that cannot change a charging rule without fear of what else it breaks will find set timelines for complaints and adjustments harder to plan around. Whether and how these rules apply to your firm is a question for your own advisers.

This is our reading of the evidence. It is not a measured market figure, and it is not legal advice.

Four Ways Off the Old Charging Applications, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Stay, and patch around the old applications	Few changes are needed, and the people who understand the charging rules are staying	The queue stays, and every change still risks another bill
Replace everything in one large move, on a single date	The old applications are failing and there is no time to stage the work	Every charging rule is tested at once, on the first bill run, with no old system to fall back on
Replace one module at a time, while the old applications keep running	The applications must go, and the firm wants each change checked before the next	Two systems run side by side for a time, and keeping accounts in step has to be planned
Buy a packaged billing or customer product	The firm wants a maker’s product in place of what it built, and has the specialists to implement it	A move of its own, with its own specialists; we do not implement or move such a product

When old and new disagree. A difference is not always a fault in the new module; the old application may have been charging in a way nobody chose. A written record shows what the old system does, not whether it is right, and no check of ours proves a charge right. Where that happens, your own people rule on whether the new module keeps the old rule. What to do about charges already made is for the operator and its advisers; we give no view on refunds, back-billing or what must be reported.

Where You Are Now, and Where You Should Be

A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own applications, each with a target.

For this issue, the benchmark would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Charging rules written down	Few; most known to one or two people	Every rule the old application applies, in the specification, confirmed by your own experts	The specification
Old functions matched to new ones	Not recorded	Each function of a rebuilt module linked to its replacement	The traceability matrix
Bills and charges from a rebuilt module compared with the old system’s before release	Not compared	Compared, for the accounts your team chooses, before the module is released	Your own team’s comparison, recorded at each review
Differences between old and new	Found on customers’ bills, if at all	Each one ruled on by your own people before the module is accepted	The risk register and your acceptance record
Modules accepted and running beside the old system	None	Each module accepted and running while the old application still runs	Each module’s acceptance record

The starting points above are what the public record suggests and what we expect to find. In an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a telecom operator.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the charging rules nobody dares change. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is the applications your firm built or had built around its billing system, such as charging, care, activation and dealer payments, and the jobs between them; the specification records the charging rules they apply. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means one of your own applications, or one part of it, rebuilt beside the old one and checked, function by function, against the specification. We never do a single cutover. Each module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

This approach has a price. A staged replacement costs more than one more patch, and two systems run side by side for a time. “Billing applications” here means the applications an operator built or had built around its billing system, not a packaged billing product, which we do not convert or move. We do not migrate customer or billing data, work on the network, or keep the old applications running while we work. A specification records the rules the code applies; a rule nobody wrote into the code, kept by hand, is found only by asking your people. Our published terms on access cover code, not customer records. We give no legal advice, and do not say what any rule requires of your firm or that any work makes it compliant. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We have no published case of this work for a telecom operator.

What changes for the business:

Role	What they gain
CEO	A tariff or billing change no longer waits on a system nobody dares touch.
CTO or CIO	A written record of every charging rule the old application applies, each linked to where the new module applies it.
CFO	A charging rule nobody had listed is found when the system is read, and not first as a credit, a refund or a correction to revenue.
COO	The awkward cases agents handle every day are written into the specification, and are not found out on the phones.
Head of regulatory affairs	A record, built as the work goes on, of what each module was checked against before it was accepted.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
In October 2016 Ofcom fined Vodafone £3.7 million over top-ups sold to 10,452 pay-as-you-go customers; press reports linked the failures to a move to a new billing system. An older case.	Our part is far narrower: the reported cause was a move to a new billing system, a kind of move we do not make, and we do not migrate data or say what went wrong. For applications an operator built, we write down the charging rules and replace one module at a time, each checked against that record.
TRAI’s Standards of Quality of Service regulations, 2024, in force from 1 October 2024, set benchmarks for resolving billing complaints and adjusting accounts. A TRAI consultation paper of 5 August 2026 proposes a shorter timeline; it is a proposal, not a rule, and was not notified as of 14 October 2026.	We give no regulatory advice and do not say what they ask of your firm. For applications an operator built, we write down the charging rules, so a change is made knowing what it touches.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We write down the charging rules first, so that the next change to them is an ordinary one.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →