Billing Systems Are Where Telecom Software Projects Go to Die 

Ask anyone who's spent a career in telecom software where the bodies are buried and you'll get one answer: billing. Not the network side, not the app, not the CRM. Billing. Industry post-mortems of billing transformations put failure and serious-overrun rates above half, and having been inside a few of these projects, we believe it. A regional ISP we worked with was on their second failed billing replacement when we met them, with the original 18-month project entering year four. The pattern behind these failures is remarkably consistent, and if you're scoping telecom billing system development, seeing the pattern in advance is worth more than any vendor comparison matrix.

The Complexity Is Real, and It Compounds

Billing looks like arithmetic from a distance: usage times rate, minus discounts, plus tax. Up close, it's a rating engine that has to price events against tariffs with time-of-day rules, bundles, fair-usage thresholds, and promotions that interact with each other in ways nobody documented. Then the genuinely hard part: change over time. A subscriber upgrades mid-cycle, so the month is prorated across two plans. A payment bounces after the invoice was issued. A retroactive credit lands on a period that's already been taxed and reported. Each rule is manageable alone. The compounding is what kills: that ISP had 30,000 subscribers spread across 340 active tariff configurations, most of them grandfathered plans no one sold anymore but contracts still honored. Any replacement had to reproduce all of it, to the fils, or the finance team would refuse cutover. Rightly.

Why the Rewrite Keeps Failing

The classic death spiral goes like this. The old system is genuinely bad, so leadership approves a full replacement. The team specs the new system against the documented tariffs, which turn out to be maybe 70 percent of the real ones, because the rest live as patches, spreadsheet adjustments, and one engineer's memory. Migration testing reveals the gap invoice by invoice, the timeline slips, and meanwhile the business keeps launching promotions into the old system, so the target keeps moving. After two years of parity-chasing, the project is cancelled or relaunched, and the old system gains another layer of scar tissue. The root mistake is treating parity as a specification problem when it's an archaeology problem. Nobody knows what the old system does. The old system is the only complete description of itself.

What the Survivors Do Differently

The billing replacements that actually land share a few habits. They run shadow billing early: the new engine rates the same event stream as production and every invoice diff gets investigated, which turns unknown rules into a to-do list instead of a launch-day surprise. On the ISP project, the first shadow run matched only 71 percent of invoices exactly; five months of diff-driven fixes later it held above 99.9 percent for three consecutive cycles, and that number, not a date, was the cutover criterion. They migrate cohorts, not everything: new customers on the new engine first, then simple grandfathered plans, then the long tail, with the strangler-style gateway keeping both systems live. And they use the migration to retire complexity, getting business sign-off to sunset dozens of near-identical legacy tariffs by moving those subscribers to equal-or-better current plans, which shrank the parity problem itself.

The Invoice Is a Product Surface Too

One underrated payoff of getting billing right: the invoice itself stops generating support load. On the old system, billing questions were the ISP's single largest call-center category, about 40 percent of contacts, because the invoice was a two-line total no customer could interrogate and no agent could explain without a ticket to engineering. The new engine kept rated events queryable, so the self-service portal could answer the only question customers actually ask: why is this month different from last month? A subscriber taps the invoice and sees the prorated upgrade, the roaming bundle, the one-off installation fee, itemized against their plan. Billing-related calls dropped by roughly a third within two quarters, which the support team noticed before anyone showed them a chart. If you're building the business case for a billing replacement, put this in it. The engineering argument is about risk, but the support-cost argument is the one finance can see in a monthly report.

Rules for Anyone Attempting This

• Assume documented tariffs cover 70 percent of reality, and budget archaeology for the rest
• Build shadow billing before building features, and treat invoice-match percentage as the only honest progress metric
• Cut over by cohort with a rollback path, never by calendar date
• Freeze new tariff launches into the legacy system, or accept that parity is a moving target you're funding twice
• Use the migration to retire grandfathered plans, with commercial sign-off, so the new system starts simpler than the old one
• Keep finance in the loop weekly; they're the ones who accept or veto the cutover

The Takeaway

Billing projects don't die because engineers can't do arithmetic. They die because a billing system is a decade of commercial history compiled into software, and replacements get scoped as if it were a calculator. Respect the archaeology, measure progress in matched invoices, and move in cohorts you can reverse. That ISP completed cutover about 14 months after the shadow engine first ran, ended a four-year saga, and, the part their CFO quotes, closed their first billing cycle in years with zero manual adjustment journals. Boring, in billing, is the whole prize.