Telecom Revenue Assurance: How to Find the Services That Are Lit but Never Invoiced

Why revenue assurance is a reconciliation problem and not a report

A wholesale fiber operator finds a 10 gigabit wave that has been carrying customer traffic for fourteen months and has never appeared on an invoice. Nobody found it in billing. It was found because the account manager pulled the contract file ahead of a renewal conversation and noticed the customer was paying for two waves while the network showed three. The order had been worked out of sequence: engineering lit the circuit early because the customer was waiting on a data centre migration, the order was closed manually to clear the queue, and the billing start step, which in that operator is a person clicking a button, never happened.

That is the shape of the problem. Revenue assurance is not a dashboard and it is not a monthly report. It is a set of reconciliations between systems that were never designed to agree with each other, run continuously, with a case workflow attached so that a discrepancy becomes somebody's job instead of a line in a spreadsheet. Leakage runs in three directions and most operators only look at one of them.

• Revenue never billed: the service exists in the network, the customer is using it, and there is no subscription behind it.
• Revenue billed wrong: rating errors, a promotional price coded as a permanent adjustment, contract pricing that should have stepped up at renewal and did not.
• Cost overpaid: a disconnected service whose underlying off-net circuit, cross connect or port is still being invoiced to you by the supplier every month.

You will see leakage percentages quoted in vendor material. Ignore them, including any a developer quotes at you. The only number that matters is the one you measure in your own estate, and the first job of any build is to produce that number honestly rather than to assume it.

Problem 1: nobody owns the gap between switched on and billed

In a carrier the provisioning path and the billing path diverge at the moment the circuit goes live. Provisioning cares that the service works. Billing cares that a subscription exists with a start date. The link between them is usually a status transition that a human is supposed to trigger, and in every operator we have worked with there is a category of order that skips it: expedites, trial circuits that quietly became production, capacity upgrades on an existing service, and anything worked during an outage.

Fixing this requires a genuine three way join, not a two way one. The logical service in your inventory has to be matched against what the network actually reports through discovery, and both have to be matched against the active subscription in billing, then against the contract record that says what the customer agreed to pay. Two way reconciliation between inventory and billing misses the worst case, which is a service that exists in the network but appears in neither system, because after three acquisitions your inventory is not a reliable record of what is lit. That is exactly why the reconciliation logic has to be written against your specific schemas and your specific naming conventions rather than configured in a product that assumes clean data.

Problem 2: discounts and contract pricing that never expire

A promotion is granted for twelve months and is entered into billing as a recurring credit with no end date, because the billing system makes it easy to enter and difficult to schedule. A large enterprise negotiates price protection through a contract term and the account team applies it as a manual override. Then the contract renews, the price should step, and nothing changes because the override has no relationship to the contract record.

Nobody re-reads nine hundred contract records once a quarter, and asking sales to do it is how you get a spreadsheet that is right once. The reconciliation that works is contract to billing: parse the commercial terms out of the contract record, including term dates, committed volume and any price schedule, then compare the rate actually being applied on the invoice line each cycle. Where the two disagree, open a case with the evidence attached. This one is unglamorous and it is usually the fastest to build, because the data is small compared with usage.

Problem 3: the cost side, where the largest money usually sits

Most revenue assurance programmes are aimed at revenue and quietly ignore the supplier ledger, which is a mistake for any operator with off-net footprint. You buy tail circuits from other carriers, cross connects in colocation facilities, IP transit ports, dark fibre with maintenance charges and wavelength capacity on someone else's system. Your customer churns. You disconnect the service on your side. The access service request to disconnect the underlying tail either never goes out, or goes out and the supplier keeps invoicing anyway, and the invoice is paid because accounts payable has no way to test whether a circuit identifier on a supplier bill corresponds to anything you still sell.

The reconciliation here joins the supplier invoice line, matched on their circuit identifier, to your own record of active off-net components. Anything on their invoice with no live component behind it is a claim, and the claim usually has a window in the interconnection or master services agreement, which is the reason speed matters. Anything in your inventory with no supplier invoice behind it is also worth a look, because it usually means the cost is landing under a different identifier and your margin per service is wrong.

Problem 4: usage feeds that quietly stop arriving

A mediation feed from one switch or one probe stops delivering. Volume dips. Nobody notices, because volume dips for ordinary reasons and nobody has a per source baseline. Two months later a customer disputes an invoice and you discover that a portion of their usage was never rated at all.

Completeness control is boring and it is the highest value control you will build. Expected file arrival per source per interval, sequence number continuity so a gap is detectable rather than invisible, record counts compared against the same weekday in prior weeks, and a rated to raw ratio per source. When any of those breaks, an alarm fires with the source named. This is not analytics. It is plumbing with alarms on it, and it prevents the class of loss that is impossible to recover once the reprocessing window has closed.

What Subex, Mobileum, TEOCO and Araxxe actually do, and where they stop

These are real products with real capability and for a large operator with a dedicated revenue assurance function they are a legitimate answer. Subex and TEOCO are the enterprise suites of the category, built around tier one operator scale, and they carry deep control libraries. The practical constraint for a regional carrier, a wholesale fibre operator or a utility telecom arm is that onboarding is itself a data integration project of considerable length, the commercial model is sized for subscriber and volume counts you may not have, and adding a control against a schema quirk unique to your estate tends to become a change request in a queue rather than something your team does on a Tuesday.

Mobileum's strength is in roaming and fraud management, with revenue assurance alongside it. If your leakage profile is retail mobile and roaming, that heritage helps you. If your leakage is enterprise circuits, off-net supplier cost and contract pricing drift, it is aimed somewhere other than your problem. Araxxe takes a genuinely different angle, generating real test transactions and verifying that they appear correctly on the bill, which is a strong independent check for retail voice and data products. It does not tell you about a lit wave with no subscription behind it, because there is no test call that reveals a missing contract.

The common gap is the same one across the category: every meaningful control has to be expressed against your inventory, provisioning, mediation and general ledger schemas, and every leakage rule encodes your product catalogue and your history of acquisitions. A product gives you a control framework. You still have to write the joins, and the question is only whether you write them inside someone's licensed platform or inside your own.

What a custom build has to include

• Connectors that read rather than disturb: replicas or change data capture from inventory, provisioning, mediation, billing and the ledger, so no control ever writes to a production operational system.
• An entity resolution layer that reconciles identifiers across systems, because the same circuit is known by a different string in each one and the mapping is the actual asset you are building.
• Switch to bill reconciliation as a scheduled control, joining network discovered state, inventory, active subscription and contract.
• Contract to billing reconciliation covering term dates, price schedules and committed volume.
• Supplier invoice to inventory reconciliation on the cost side, with claim tracking against the supplier's dispute window.
• Usage completeness controls per source with sequence and volume baselines and alarms that name the feed.
• Case management, because a finding with no owner and no due date is not a finding. Each case carries the evidence query that produced it, so it can be re-run rather than screenshotted.
• A recovered value ledger that ties confirmed recoveries back to the general ledger, which is the only way the programme keeps its funding at the next budget round.

What it costs and how long it takes

A first release covering switch to bill reconciliation on your largest product family, supplier cost reconciliation and case management runs $80,000 to $180,000 and ships in 12 to 18 weeks. A full platform covering every product family, usage completeness controls, contract to billing, dispute tracking and ledger tie out runs $200,000 to $500,000 phased over 8 to 14 months.

What moves the number: the count of distinct source systems, because each one is its own extraction and its own set of data quirks. Whether you have been through acquisitions, since a merged estate means two or three naming conventions and a period where nobody enforced either. Usage volume, because completeness controls on billions of records per month are an engineering problem rather than a query. And access, which sounds trivial and is not: if getting a read replica of the billing database requires a vendor change request with a lead time, that lead time is your project timeline.

Build versus buy, and what to do before either

Before you spend anything, do this yourself in a week. Export active services from inventory, export active subscriptions from billing, and join them on whatever identifier you have. The unmatched rows on both sides are your first estimate of leakage, and it will be wrong in detail but right in order of magnitude. If that exercise produces a number that does not justify a project, you have saved yourself a project. If it produces a number with a comma in it, you now have a business case built on your own data rather than someone's benchmark.

Buy a suite if you are a large operator with a formal revenue assurance function, tier one usage volumes and the appetite to run a long onboarding. Build if you are a regional carrier, a wholesale or fibre operator, an MVNO or a utility telecom arm, where the estate is idiosyncratic, the controls that matter are specific to your product catalogue, and the licensing model of the suites is priced for a business several times your size. Our position is that in this category the reconciliation logic is the product, the surrounding platform is commodity, and paying enterprise licensing for a case management workflow while still writing all your own joins is the worst of both options.

How to choose a developer for a revenue assurance build

Ask how they will resolve the same circuit across four systems that name it differently. If the answer is a join on a common key, they have not seen a real carrier estate. The correct answer involves a resolution layer with confidence scoring and a human review queue for the ambiguous cases.

Ask what they will do to guarantee the controls never write to production operational systems, and how they will handle a source system that is only reachable through a vendor. Ask how a control will be tested before it is trusted, because a false positive rate above a few percent trains your team to ignore the tool within a month, and a revenue assurance system that is ignored is worse than none because it provides false comfort.

Ask for the recovered value ledger by name. A developer who has done this before will bring it up unprompted, because they know the programme gets cancelled at the second budget cycle unless it can prove what it returned.

Ask who owns the code, and get repository and infrastructure ownership written into the agreement before kickoff. At Digital Heroes the client owns the code from the first commit. Start with the one week export and join described above, bring us the unmatched row counts, and we will scope against your number rather than an industry average.