Revenue Assurance
Last updated 12 Oct 2026
At a glance
Revenue Assurance (RA) checks that every chargeable event was captured, rated, billed and collected, and that customers were charged only for what they received. It processes no transactions. It compares the records each system keeps at every hand-off, from catalog to bank, and investigates where they disagree.
The picture
RA processes no transactions. It compares the records each system keeps at every hand-off.
1 · The chain
- Product Catalog
- Install Base
- Network
- Mediation
- Rating
- Billing
- Payment
Each system keeps its own record
2 · Six controls
Product config ↔ Billing
Do prices and discounts align?
Install Base ↔ Billing
Are all active services billed?
Network ↔ Mediation
Did all usage arrive?
Mediation ↔ Rating
Was all usage processed?
Rating ↔ Billing
Were all charges transferred?
Billing ↔ Payment
Was billed revenue collected?
3 · Both directions
A · Under-billing
100,000 active · 98,500 billed
1,500 live, not billed: leakage
B · Over-billing
98,500 active · 100,000 billed
1,500 billed without service: refunds owed
4 · Investigation
- Which 1,500 services?
- Why: failed event, manual fix, migration defect?
- Which control would have stopped it?
A count mismatch is where the work starts
How it works
An end-to-end control, not a stage
Revenue leakage happens when a chargeable service is delivered but not billed, billed wrongly, or billed and not collected. RA is often drawn as a box after billing. It is better pictured running alongside the whole chain, asking one question at every hand-off:
Did the operator capture all legitimate revenue it should have captured, and charge only for what it delivered?
Six reconciliation controls
| Control | Question | Typical evidence |
|---|---|---|
| Product configuration → Billing | Do product, pricing and discount rules align? | Catalog price and discount definitions vs billing configuration; test-rating samples |
| Install Base → Billing | Are all active services billed? | Active product instances vs billing subscriptions, by product and account |
| Network usage → Mediation | Did all usage arrive? | Record counts and volumes per network node vs records collected |
| Mediation → Rating | Was all usage processed? | Records delivered vs records rated; reject and suspense queues |
| Rating → Billing | Were all charges transferred? | Rated value vs value posted to accounts and invoices |
| Billing → Payment | Was expected revenue collected? | Invoiced vs paid, by age; unapplied payments |
Both directions
Take Install Base against Billing. If 100,000 services are active and 98,500 are billed, 1,500 live services are not billed: leakage. At €30 a month that is €45,000 a month until found (illustrative). Reverse the numbers and 1,500 services may be billed without service. That is not extra revenue. It is refunds owed, complaints and, in many markets, a regulatory breach.
A count mismatch is only the start. The investigation must say which services, why (failed event, manual fix, migration defect) and which control would have stopped it.
Where revenue leaks
| Hand-off | Leakage | Typical cause | Detection |
|---|---|---|---|
| Network → Mediation | Lost records | Collection failure, file corruption, an element not feeding mediation | Expected vs actual record counts per node |
| Mediation → Rating | Unrated events | Format errors, unknown tariff codes, missing subscriber mapping | Reject queue rates, categorised by reason |
| Rating → Billing | Wrong charges | Wrong tariff, discount miscalculated, proration error | Re-rate a statistical sample and compare |
| SLM → Billing | Subscription leakage | Active service missing from SLM, or wrong plan or price there | Inventory-to-billing reconciliation |
| Billing → Collections | Uncollected revenue | Failed payments not escalated, dunning gaps, write-offs too aggressive | Ageing analysis and dunning effectiveness |
Reconciliation and margin analysis
The two core techniques are record reconciliation, comparing counts and values at each hand-off, and margin analysis, comparing expected revenue (from subscriber base, plan mix and average usage) with billed revenue. A drop at a hand-off points to a specific leak; a systematic gap in margin points to a structural one.
- Switch-to-bill: records at the network element against records that reach billing.
- Revenue per subscriber trending: an unexpected drop for one segment often means a rating or catalog error across a whole product.
- Interconnect reconciliation: outbound records against partner settlement statements, which finds overpayment as well as leakage.
- Activation-to-billing lag: time from SOM/ROM completion to the first billing event. A long lag is a customer using the service free.
RA, fraud and dunning are different jobs
RA looks for our failures: a lost record, a missed event, a wrong price. Fraud Management (6.10) looks for someone else’s abuse. Dunning (6.12) chases revenue that was billed correctly and not yet paid.
Four functions, four questions
| Revenue Management | Revenue Assurance | Fraud Management | Dunning & Collections | |
|---|---|---|---|---|
| Objective | Create and collect revenue | Protect revenue integrity | Detect and prevent abuse | Collect billed revenue |
| Core question | What should we charge? | Did we capture what we should? | Is this activity legitimate? | Has what we billed been paid? |
| Main flow | Product → usage → charge → bill → payment | Reconcile the entire chain | Activity → detection → decision → action | Invoice → due → remind → restrict → collect |
| Primary risk | Incorrect charging or billing | Revenue leakage (and overcharging) | Fraud loss | Bad debt |
| Typical response | Charge, bill, collect | Investigate, reconcile, recover | Allow, challenge, restrict, block | Remind, restrict, suspend, collect |
There is no TM Forum Open API for RA. RA systems consume usage (TMF635), product inventory (TMF637) and customer bill (TMF678) data. TM Forum’s Revenue Assurance Guidebook (GB941) covers RA processes, KPIs and maturity.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Reconciliation result and leakage case | Revenue Assurance platform | RA analyst workbench | Finance | RA owns the finding, not the records it compares. |
| Active product instance (install base) | Product Inventory / SLM | — | Revenue Assurance, Billing | TMF637. The reference RA checks billing against. |
| Usage record | Mediation | — | Revenue Assurance | TMF635. Counts per node are the evidence for network-to-mediation control. |
| Rated charge and invoice | Billing | Self-care / contact centre | Revenue Assurance | TMF678 for the customer bill. |
| Price and discount configuration | Product Catalog | — | Billing, Revenue Assurance | Billing holds its own copy; the control checks the two agree. |
In practice
Industry benchmarks put unmanaged leakage at 1–5% of gross revenue. In brownfield estates much of it sits at Install Base → Billing: services provisioned by older stacks, manual fixes and migration defects that left the product inventory and billing disagreeing. Billing truth, service truth and network truth diverge, and RA is often the first function to measure by how much.
Operators that report only “leakage recovered” tend to find overcharging late, through complaints, ombudsman cases or regulators, at a higher cost than the leakage they recovered. RA functions that report to the CFO rather than the CTO usually have more authority to investigate across commercial and technical domains.
The trade-off
What it solves
RA makes revenue integrity measurable across systems that each believe their own records, and finds both lost revenue and overcharging.
What it does not solve
- The root causes: catalog design, broken integrations and migration defects must be fixed by their owners.
- Deliberate abuse, which is fraud management’s job.
- Revenue that was billed correctly and not paid, which is dunning’s.
What it adds
- Read access to every system in the chain, with data extracts that must themselves be trusted.
- Findings that cross organisational lines, so someone must have authority to act on them.
- Overcharging findings that create refund liabilities and possible regulatory reporting.
Architecture decision
Where should RA start in a brownfield estate?
Install Base → Billing
Choose when recent migrations or manual fixes make inventory and billing disagreement likely; it finds both leakage and overcharging per service.
Network → Mediation → Rating
Choose when usage revenue dominates and reject or suspense queues are growing without explanation.
Product configuration → Billing
Choose when catalog and billing are configured separately and new offers launch often.
Breaks if RA measures only under-billing. Overcharging surfaces through regulators instead, and the function is seen as revenue recovery rather than integrity.
Takeaways
Key Takeaways
- RA is an end-to-end control beside the chain, not a stage after billing
- Six controls: product configuration, install base, network, mediation, rating and payment, each against its neighbour
- Reconciliation runs both ways: under-billing is leakage, over-billing is refunds owed
- A count mismatch must become which services, why, and which control would have stopped it
- RA needs cross-system access and the authority to act on what it finds
- RA finds our failures; fraud finds someone else’s abuse; dunning collects what was correctly billed
Check yourself
Billing shows 1,500 more billed services than product inventory shows active. Is this good news for revenue?Show answerHide
No. It is potential overcharging: customers billed for services they do not have. It means refunds, complaints and possibly a regulatory breach. Investigate which services, and why inventory and billing diverged.
Mediation reject queues are growing month on month. Which control is this, and what do you look at?Show answerHide
Mediation → Rating. Categorise rejects by reason (format, unknown tariff code, missing subscriber mapping) and check they are recycled or explained, not left in suspense.
An account was opened with a stolen identity and never paid. Is that an RA finding?Show answerHide
No. It is fraud: someone else’s deliberate abuse. It will appear in dunning, but treating it as bad debt or leakage misses the pattern that created it.