Subscription Billing & SLM
Last updated 12 Oct 2026
At a glance
Most telco revenue is recurring: plan fees, add-ons, rentals. Subscription billing turns each active product into a recurring charge every cycle, using SLM as its source of truth for what the customer has, from when, and in what state. If SLM is wrong, every recurring invoice is wrong. The bill run combines those charges with usage, one-time charges, discounts and tax.
The picture
Two records of one product instance, kept in step, become one line on each cycle’s invoice
1 · Install Base
- Product
- Mobile 10 GB
- Status
- ACTIVE
- Active from
- day 11
Product Inventory (TMF637) or subscription management
2 · Billing subscription
- Price
- €30 / month
- Charge start
- day 11
- Bill cycle
- 1st of month
Separate in most estates: reconcile 1 against 2
3 · Recurring charge
€20
€30 × 20/30, first cycle
full, prorated, suspended or zero, by state
4 · Invoice
- Recurring (20 of 30 days)
- €20.00
- Usage (rated)
- from rating
- One-time
- from the order
- Discounts / adjustments
- from catalog / agents
- Tax
- by jurisdiction
Customer Bill, TMF678
How it works
From product to invoice line
Product / subscription
COM / Subscription MgmtThe customer holds an instance of a product offering ("Mobile 10 GB, €30 a month") with a start date and contract terms.
Install Base
Product Inventory (TMF637) / SLMThe instance is recorded as ACTIVE: the answer to "what does this customer have?"
Billing subscription
BillingBilling's own record of the chargeable item on a billing account: price, charge start date, bill cycle, discounts.
Recurring charge
Billing / ratingEach cycle, a charge: full, prorated, suspended or zero, according to state and catalog rules.
Invoice
Billing (TMF678)Recurring charges combined with usage, one-time charges, discounts, adjustments and tax.
Steps 2 and 3 are two records of the same product instance, usually in different systems. Some suites share one record; most estates do not. Where they are separate, every lifecycle event must reach both, and Install Base to Billing reconciliation (6.9) is the only reliable way to know they still agree.
Lifecycle events and their billing impact
| Event | SLM state change | Billing impact | Common error |
|---|---|---|---|
| Activation | Subscription created, active | First charge, prorated from activation to next bill date | Billing starts before the service is live |
| Upgrade / downgrade | Plan changed, effective date recorded | Credit for the old plan, charge for the new, for the remaining days | No proration: full month on both plans |
| Suspension | Suspended, with date and reason | Charges paused, reduced or continued, depending on suspension type | Charges continue when they should pause; disputes on reactivation |
| Cancellation | Pending termination, end date set | Final prorated charge; early termination fee if applicable | Charges continue after the end date; refunds |
| Add-on change | Component added or removed | Prorated charge or credit from the effective date | Charge starts but SLM not updated: the two out of sync |
Getting these wrong is the leading cause of billing disputes. The worked figures are in 6.6.
The bill run
A bill run generates the invoices for a billing cycle. For large operators it processes millions of accounts and must finish inside a defined window, typically overnight.
- Bill cycle assignment: accounts spread across cycles (1st, 15th of the month) to spread load. Enterprise accounts may have bill dates aligned to contract terms.
- Charge aggregation: recurring charges and rated usage combined per account; discounts, promotions and loyalty credits applied.
- Tax calculation: by service type, customer location and tax jurisdiction. Multi-country operators face very different rules.
- Invoice generation: rendered (PDF, electronic or both) and delivered on the customer's preferred channel.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Product instance and its state | Product Inventory / Subscription Management (SLM) | COM, CRM, self-care | Billing | TMF637. Active, suspended, pending termination, terminated, with effective dates. |
| Billing subscription | Billing | — | Product Inventory | Price, charge start date, bill cycle and discounts for the chargeable item. |
| Billing account and bill cycle | Billing | CRM / self-care | — | TMF666. Includes account hierarchy and payment method. |
| Invoice | Billing | Self-care, CRM | ERP | TMF678. Finance takes receivables and revenue from it. |
| Proration and suspension charging rules | Product Catalog | — | Billing, CPQ, Rating | Product decisions; billing applies them. |
In practice
Every lifecycle event (activation, change, suspension, cancellation) must update SLM and billing atomically or through guaranteed eventual consistency. Most estates rely on order integration and a scheduled reconciliation to catch what the integration misses.
Bill-run windows constrain change. A new rule that adds processing per account has to fit inside the overnight window for the largest cycle, so changes to charging logic are often scheduled around cycles.
The trade-off
What it solves
Driving recurring charges from SLM means the invoice follows what the customer holds, including every mid-cycle change, without manual intervention.
What it does not solve
- A wrong SLM record, which billing will charge faithfully every cycle.
- Lifecycle events that reach SLM and not billing, or the other way round.
- Disagreement about proration and suspension rules between billing, CPQ and self-care.
What it adds
- Two records of each product instance (Install Base and billing subscription) must be kept in step.
- Bill runs must finish inside fixed windows as account volumes and rules grow.
- Effective dates must be carried precisely through every system, or proration is wrong.
Architecture decision
Should billing hold its own subscription record, or read the Install Base directly?
Shared record
Choose when a suite holds product inventory and billing together, and the operator accepts that dependency.
Separate billing subscription, event-fed
Choose when SLM and billing are different products, and every lifecycle event can be delivered to both with guaranteed delivery and a reconciliation behind it.
Billing reads the Install Base at bill run
Choose when SLM is fast and complete enough to be queried for every account inside the bill-run window.
Breaks if one system can be updated without the other and no reconciliation runs. Billing disputes then become inevitable and grow with every cycle.
Takeaways
Key Takeaways
- Recurring billing depends on SLM as its source of truth for what each customer has and in what state
- The chain is product, Install Base, billing subscription, recurring charge, invoice; the middle two are usually separate records
- Every lifecycle event has a billing consequence: proration, credits, fees or a stop
- SLM and billing divergence is systematic, so it is the most dangerous billing failure
- Bill runs combine recurring charges with usage, one-time charges, discounts and tax inside a fixed window
Check yourself
Customers on one add-on are charged for it, but self-care does not show it on their accounts. Which records disagree?Show answerHide
The billing subscription and the Install Base. The add-on charge started in billing but SLM was not updated, so reconciliation between the two should flag every affected account.
A customer suspended for non-payment is still charged the monthly fee. Is that a defect?Show answerHide
Not necessarily. For involuntary suspension the contract often continues, so the recurring charge may too. Billing must know why the service is suspended, and the rule must come from the contract and catalog.