Billing Overview
Last updated 12 Oct 2026
At a glance
Billing & Revenue Management is the Order-to-Cash part of Lead-to-Cash. It turns what the customer has and what they used into invoices, collects payment and passes revenue to finance. It is a domain of several capabilities, often from different vendors, and it depends on upstream systems for almost every figure it produces.
The picture
How it works
Where billing sits
Billing sits downstream of fulfilment. COM captures the order, SOM and ROM make the service live, and the active product is recorded in the Install Base. From then on two feeds run in parallel: the Install Base says what the customer has, and the network produces usage events that mediation prepares and rating values. Both meet in billing, which produces the invoice that payment settles.
Revenue Assurance and Fraud Management are not stages after billing. They sit beside the chain and watch every hand-off.
Several capabilities
Billing is several capabilities. In large operators they may be separate systems from different vendors; modern suites increasingly combine them. Each answers one question:
| Function | Question it answers | Section |
|---|---|---|
| Mediation | What usage happened, in a form rating can use? | 6.3 |
| Rating | What is this usage or subscription worth? | 6.4 |
| OCS / real-time charging | May this session continue, and what is deducted now? | 6.4 |
| Billing | What does this account owe, and on which invoice? | 6.5 |
| Revenue Assurance | Did we capture all the revenue we should have, and only that? | 6.9 |
| Fraud Management | Is this activity legitimate? | 6.10 |
| Payment, dunning & collections | Has what we billed been paid? | 6.12 |
Key interfaces
Billing executes rules and records it receives. Most billing errors start upstream, so the interfaces explain more failures than the billing engine does.
| Interface | Direction | What flows | If broken |
|---|---|---|---|
| SLM / Product Inventory | Inbound | Active subscriptions, product structure, pricing tier, contract terms | Charges for products the customer no longer has, or none for new ones |
| Product Catalog | Inbound | Pricing rules, charge types (recurring, one-time, usage), discounts | Rating cannot calculate charges; prices default or error |
| Mediation | Inbound | Prepared usage records (CDRs, event records) | Usage charges missing or late; leakage |
| COM / order management | Inbound | Order completion events, activation dates, contract start | Billing starts before the service is live |
| Payment gateway | Outbound | Payment requests, direct debit instructions | Payments not collected; cash flow impact |
| ERP / general ledger | Outbound | Revenue recognition, accounts receivable, tax records | Financial reporting wrong; audit risk |
Three states, one Install Base
Every product a customer holds exists in a commercial, a service and a billing state, usually in different systems. Service without billing is leakage; billing without service is overcharging. 6.2 covers how the three are kept in step.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Pricing rules and charge types | Product Catalog | — | Rating / Billing | TMF620. Rating executes these rules; it should not hold its own copy of prices. |
| Active product holdings (Install Base) | Product Inventory / Subscription Management | — | Billing, Rating / OCS | TMF637. Billing is driven from, or reconciled against, this record. |
| Normalised usage records | Mediation | — | Rating, Revenue Assurance, Fraud Management | TMF635 describes usage records. Raw records originate in the network. |
| Billing account | Billing | CRM / self-care | — | TMF666. The account hierarchy, bill cycle and payment method. |
| Customer bill (invoice) | Billing | Self-care, CRM | — | TMF678. |
| Revenue recognition and general ledger | ERP | — | Billing | Billing feeds receivables and revenue; finance owns the ledger. |
In practice
Billing is often the oldest and most embedded BSS system in a telco. Many operators run platforms that are 15 to 25 years old, carrying decades of business rules, custom rating logic and regulatory patches. Some estates split mediation, rating, billing and collections across vendors; others run them in one suite. The capability map is the same either way; the hand-offs move inside or outside a product.
That has a consequence for the rest of the stack. A new catalog, COM or Install Base usually has to feed an old billing model, so product structures are often bent to fit what billing can charge. The constraint runs upstream.
The trade-off
What it solves
Treating billing as a set of capabilities with defined interfaces makes it clear which system answers which revenue question, and where an error must have started.
What it does not solve
- Wrong data upstream. Billing charges correctly against a wrong subscription or a wrong price.
- The age of the billing platform. A clean capability map does not make a 20-year-old system easier to replace.
- Disagreement between what was sold, what is live and what is charged, which needs reconciliation.
What it adds
- Every capability boundary is an interface that can lose, duplicate or delay data.
- Several vendors across the domain means several data models for the same customer and product.
- Finance, network and commercial teams each own part of the chain, and none owns all of it.
Architecture decision
How should the billing domain be sourced in a transformation?
One convergent suite for mediation, rating, billing and collections
Choose when the estate is being replaced end to end, product structures can be remodelled to the suite, and the operator accepts a deep dependency on one vendor model.
Separate products per capability
Choose when one capability (often real-time charging) has needs the others do not, and the operator can own the integration and the reconciliation between them.
Keep legacy billing and modernise around it
Choose when billing replacement risk is too high for now, and there is a dated exit plan for the legacy platform rather than an open-ended wrap.
Breaks if the new catalog and order stack launch products the existing billing system cannot charge. The products are then rebuilt to fit billing, or charged by manual workarounds.
Takeaways
Key Takeaways
- Billing is the Order-to-Cash part of Lead-to-Cash: it turns what the customer has and what they used into revenue
- It is a domain of capabilities (mediation, rating, charging, billing, collections) that may sit in one product or several
- Most billing errors start upstream, in the catalog, the Install Base, mediation or order completion
- Revenue Assurance and Fraud Management run beside the whole chain, not after billing
- Billing is usually the oldest BSS system and the hardest to replace, and that constrains every system upstream of it
Check yourself
Customers are charged the old price for a plan whose price changed last month. Which interface do you check first?Show answerHide
The Product Catalog interface. Rating executes the pricing rules it is given; if it still charges the old price, either the catalog change did not reach it or rating holds its own copy of prices.
A programme proposes to replace the catalog and COM, and leave billing for phase three. What should the architect ask?Show answerHide
Whether the existing billing system can charge every product the new catalog will launch, and when billing is actually replaced. Without both answers, products will be shaped to fit legacy billing indefinitely.