Insights
- Telecom operators are missing out on an estimated $24 billion a year in business-to-business (B2B) revenue, and much of it traces back to billing systems that catch mistakes only after the damage is done.
- Five separate problems — messy contracts, reactive billing, tangled partner settlements, cautious leadership, and regulatory risk — all point to the same root cause. No single system sees the whole picture.
- Machine learning (ML), generative AI, and agentic AI are already proven elsewhere in telecoms. Billing is the last place leadership has let them in.
- Ontology is the missing piece that ties contracts, billing, and network data together, so problems get caught in real time instead of during next quarter's audit.
Telecom companies are struggling to keep an accurate picture of their own revenue trajectory. And for a tier 1 operator, for whom the B2B segment can account for up to a third of total revenue, the picture gets blurriest. B2B deals are large, complex, and slow to close, so errors have more time and more room to pile up before anyone notices, making revenue forecasts harder to trust.
Research by Omdia and Amdocs in 2025 found communications service providers are missing out on $24 billion of B2B revenue every year, due to process inefficiencies, fragmented systems, and skill gaps. That is roughly 7% of global telecom enterprise revenue. The same study found $170 billion is at risk annually during renewals and new-business deals, for similar reasons.
When revenue isn’t accurately tracked, the numbers used for planning become less reliable, which, in turn, affects decisions about network investment, expansion, and growth.
Barriers to predicting telecom revenue
Five challenges stand in the way of having a trustworthy revenue number.
B2B contracts are complex and ever-changing
Enterprise telecom deals rarely follow one pricing model. A single account can combine usage-based charges, flat subscriptions, and service level agreement (SLA)-linked penalties across connectivity, cloud, internet of things (IoT), and managed services. Any of those terms can be renegotiated mid-contract as a customer's needs change. That constant change is where errors get introduced. This matters more than it would elsewhere because a minority of large accounts typically generate a disproportionate share of B2B revenue. A single misconfigured contract on one of those accounts can mean millions in overbilling that has to be repaid, or revenue that's lost because it was never billed at all.
Picture a large enterprise customer that connects hundreds of office locations to one telecom network. As part of the contract, the customer negotiates a discount: once their monthly usage crosses a certain level, they get 10% off. The sales team records this in the customer relationship management (CRM) system that tracks the deal. But CRM and billing aren't the same system, and don't automatically talk to each other. Someone has to manually configure the discount into the billing system's pricing rules for it to apply. That step gets missed. The customer keeps getting billed at the original, undiscounted rate. By the time anyone notices, the customer has been overbilled by millions of dollars. They dispute it, and the operator ends up repaying the difference, plus credits, as an apology for the error.
According to Infosys’ experience, a typical B2B enterprise sales cycle spans six to nine months, enough time for a contract to be amended more than once and for a missed update to go unnoticed for months after.
Legacy billing systems are reactive
Most billing systems still work like an assembly line: Network usage gets measured, translated into a standard format, priced according to the contract, and only then turned into an invoice. That means an error introduced early in the process — a wrong rate, a missed discount, or a misclassified charge — isn't caught until later as part of a revenue assurance reporting review, or, worse, a customer noticing it on their bill and disputing it, by which point the money has already been counted as earned.
Partner ecosystems lock up billable revenue
Modern telecom services rarely come from one company alone. Wholesale carriers, cloud providers, and resellers each generate their own usage and billing records, on their own formats and cycles, and traditional systems reconcile them manually, at month end. When the numbers don’t add up, the money involved is frozen until someone chases it down. According to Infosys’ experience, that ties up an estimated 5% to 10% of billable revenue, money that's technically owed, but remains unreconciled until disputes are resolved. An analysis by AMI Strategies of more than 67,000 telecom vendor billing disputes found the median case took 62 days to resolve, with only 37% closed within 30 days and some that ran past a year.
Leadership hesitates to modernize billing
Even when AI is working elsewhere in business, many telecom leaders are cautious about bringing AI near the system that calculates the company's revenue, and the data suggests that caution runs deeper here than in other parts of the business. According to a recent survey of telecom operator leaders, conducted by IBM Institute for Business Value and TM Forum, billing and revenue assurance ranks lowest among eight operational domains for AI deployed in production or at scale. Of the telecom operators surveyed that are already running AI in production, or, at scale, only 47% say they have deployed AI in billing and revenue assurance.
Regulatory compliance adds financial risk
Telecom billing errors are also an accounting problem. Under IFRS 15, the revenue recognition standard used in roughly 140 jurisdictions worldwide, and its nearly identical US counterpart, ASC 606, revenue must be recognized when a performance obligation is satisfied, not when an invoice goes out. Getting that timing wrong has real consequences. In the US, Cornerstone Research found that improper revenue recognition was the single most-cited violation in accounting-related securities class actions every year from 2019 through 2023. For a telecom operator managing thousands of B2B contracts with rebates, amendments, and bundled obligations, that's a direct constraint on the confidence with which a board can commit capital to 5G, fiber, or IoT investment, since a billing error made today can resurface years later as a compliance finding.
Telecom companies have tried to address these problems through initiatives such as automated data-cleaning programs, billing systems preconfigured with pricing and discount rules for each product, high-value accounts flagged in the CRM for closer oversight, finance teams manually linking contract obligations to revenue schedules, and dedicated settlement teams reconciling partner records at month-end. All of it worked, but within a slower, more standardized version of B2B telecom.
An AI-driven path to predictable revenue
These five challenges require one connected architecture that consists of three AI capabilities — ML, generative AI, and agentic AI — unified by a fourth, connective layer called ontology (Figure 1). Ontology is a shared rulebook that defines how the building blocks of a telecom deal relate to each other: A contract promises certain terms; those terms define a product the customer is buying; using that product generates a charge; and charges get bundled into an invoice.
Today, those four things often live in four different systems that don't talk to each other. Ontology gives every AI capability in this architecture the same map of those relationships, so a contract clause, a usage anomaly, and an invoice line item can all be checked against one another automatically, instead of being reconciled by hand, weeks later, after a customer complains.
Applied across the revenue chain, each capability does a distinct job, and together they enable continuous monitoring of billing.
Figure 1. How AI, generative AI, agentic AI, and ontology relate in the telecom B2B billing topology
Source: Infosys
How it plays out across the revenue chain
Applied end to end, this architecture is designed to reach nearly every stage of how a telecom operator manages revenue, from contract management to detecting billing anomalies, all the way to settlement (Figure 2). Intelligence would sit inside each stage, with ontology as the connective thread running through all of them.
Figure 2. The AI spectrum in the telecom revenue system
Source: Infosys
What are the benefits of this approach?
Revenue recovered at the source: Continuous monitoring catches leakage as it happens, instead of waiting for an audit cycle to find it. According to Infosys’ experience with telecom clients, shifting from a periodic sampling approach to continuous monitoring could recover between 40% and 60% of the current revenue leakage.
Fewer disputes on the accounts that matter most: Because high-value accounts are watched continuously rather than sampled occasionally, errors get caught before they reach the customer's invoice. Based on patterns Infosys has observed at early-adopter operators, this shift could reduce disputes on high-value accounts by 50% to 70%.
Faster billing cycles: When contract terms, usage data, and billing logic stay synchronized instead of drifting apart, invoices go out faster and with fewer manual checks. Infosys experience suggests billing cycle times could compress by 40% to 60%.
Put together, these shifts turn billing from a once-a-cycle audit into something monitored continuously, so a board isn't discovering months later that the number it built its strategy on wasn't the real one.
How to turn AI architecture into a rollout
The four AI capabilities described in Figure 1 should not be scheduled as four separate projects. They need to land as one coordinated program, with the right governance. Here's what that requires in practice.
1. Start where the losses are greatest
Resist the instinct to pilot AI on a low-risk, low-visibility process first. The strongest business case comes from targeting the highest-leakage, highest-dispute process. For most operators, that's B2B contract billing or partner settlement, the two areas already shown to carry the most concentrated risk. A visible win here does two things a safe pilot won't: it generates the internal proof needed to justify scaling, and it directly targets the revenue leadership is most anxious about, which starts to shift the hesitation identified earlier in this piece.
2. Build ontology first
It is tempting to sequence this as "get the AI models working, then worry about how they connect." That's backwards. Ontology is the layer that lets every function refer to the same underlying reality. Without it, each capability becomes another isolated point solution, generating disconnected data with more tools instead of fewer. Building the ontology first and maintaining it as a live document that is constantly updated by an owner gives every subsequent AI capability something coherent to connect to.
3. Make trust and governance part of the rollout
The rollout plan needs to visibly address leadership hesitation: audit trails on every AI-driven billing decision, clear escalation paths when the system flags something, and staged autonomy that expands only as trust is earned. Skipping this step could result in AI that stays stuck in pilot rather than reaching production.
4. Measure it the way the board will ask about it
Track recovered leakage, dispute volume, and billing cycle time from day one of the pilot. These are the terms a board uses to evaluate the investment and hence can help against the hesitation.
The five gaps in this piece aren't new. Telecom operators have lived with versions of these challenges for decades, patched over with more process, more reconciliation, and more sampling. What's changed is the pace of B2B telecom market itself: Pricing, partners, and contracts now move faster than manual patches can track.
ML, generative AI, and agentic AI are already being put to work across the business in network optimization, customer interactions, and security operations. Billing is the domain still catching up, because a mistake there is hardest to walk back. A staged approach, with trust and governance built in from the start, gives the board a revenue number it can plan around, cycle after cycle.