Convergent Billing

Last updated 12 Oct 2026

At a glance

Convergent billing has two meanings. One is running prepaid and postpaid on one platform, with one catalog, one rating engine, one balance model and one account, so payment type becomes a product attribute. The other is bringing different services (mobile, broadband, TV, IoT) onto one account and one invoice. Both depend on the Install Base being right for every product involved.

The picture

Two stacks that each hold part of the customer, against one platform that holds all of it

1 · Dual stack

Prepaid

Catalog copy (prepaid)
OCS: real-time rating
Prepaid balance
Prepaid account

Postpaid

Catalog copy (postpaid)
Batch rating at bill run
Postpaid invoice
Postpaid account

Every product defined twice; one customer appears as two accounts; moving between them is a migration

2 · Converged

One product catalog
payment type is a product attribute
Unified rating
real-time and batch, same tariffs
Single balance management
deduct now, defer, or mix
One account hierarchy
sub-accounts, shared pools (TMF666)
One invoice
sections per service (TMF678)

Mobile, broadband, TV and IoT resolve onto the same account; cross-product discounts read the Install Base

Two stacks, each with its own catalog copy, rating, balance and account, against one platform with one catalog, unified rating, single balance management, one account hierarchy and one invoice.

How it works

Two stacks

Historically, prepaid ran on a real-time Online Charging System that deducted from a balance on every event, and postpaid ran on batch billing that rated usage at bill run and produced a monthly invoice. The two had different databases, rating engines, product catalogs and often vendors. That split compounds over time:

Duplicate catalogs: every product defined twice with different pricing rules, so inconsistency and slower launches.
No single customer view: prepaid mobile and postpaid broadband appear as two unrelated accounts; cross-sell and loyalty cannot span both.
Migration friction: moving a customer between prepaid and postpaid is an account migration between systems, often with interruption and re-keying.
Double operational cost: two platforms, two sets of mediation interfaces, two rating configurations, two support processes.

Three pillars

Pillar	What it unifies	What it enables
Unified rating engine	Real-time and batch rating from the same catalog and tariffs	One tariff definition for every payment type
Single balance management	Immediate deductions, deferred charges and mixed models	A postpaid plan with a prepaid top-up for extras
Unified customer and account model	One customer record and account hierarchy regardless of payment method	Payment type as a product attribute, not a system boundary

Convergence is a spectrum

Most operators converge in steps: a shared catalog with separate rating engines, or converged rating with separate balance management. Each step reduces operational cost, but the full benefit arrives only with full convergence. The risk is stopping part-way, in a state with the complexity of both models.

Across services: one account, one invoice

A household with mobile, broadband and TV, or an enterprise with voice, data, connectivity and IoT, expects one relationship and one bill. Each service is often fulfilled by a different OSS stack and rated from a different usage source. Convergent billing rates each under its own model, applies cross-service discounts and bundle rules, and resolves everything onto one account hierarchy (TMF666) and one invoice (TMF678), or several invoices from one account where the customer needs them, for example per cost centre.

Element	Example	Why it is hard
Multiple products	Mobile, broadband, TV on one account	Each may come from a different catalog lineage and order flow
Multiple charging models	Prepaid data top-up beside a postpaid broadband contract	Online and offline charging must share balances and customer context
Recurring + usage	Monthly fees plus out-of-bundle calls, roaming, pay-per-view	Recurring from the Install Base, usage from mediation: two feeds, two timings
Discounts	10% off broadband while a mobile plan is active	Depends on another product's state; if either is wrong, the discount is wrong
Bundles	Mobile + broadband + TV at one price	The price must be split back to services for revenue recognition and tax
Shared accounts	Family data pool; 500 enterprise SIMs on one pool with cost-centre invoices	Real-time balance sharing; hierarchies need roll-up and split billing

Standards alignment

3GPP TS 32.296 defines the OCS architecture and TS 32.299 Diameter-based charging. TMF654 (Prepay Balance Management), TMF666 (Account Management) and TMF678 (Customer Bill Management) cover balances, accounts and bills. The ODA billing component is expected to support prepaid and postpaid as one component.

Who owns what

Entity	System of Record	System of Engagement	System of Reference	Notes
Customer account hierarchy	Billing (account management)	CRM / self-care	—	TMF666. One hierarchy regardless of payment type, with sub-accounts and cost centres.
Balances, allowances and shared pools	Balance management (OCS / CHF)	Self-care, top-up channels	Billing	TMF654. Shared between online and offline charging in a converged model.
Payment type (prepaid / postpaid)	Product Catalog (as an attribute of the offering)	—	Billing, OCS	In a dual stack it is a system boundary instead.
Cross-product discount and bundle rules	Product Catalog	—	Billing, Rating	Evaluated against the Install Base at charge time.
Products held across services	Product Inventory / Subscription Management	—	Billing	TMF637. Every cross-product discount depends on it.

In practice

Convergence usually arrives as a programme of steps, product by product or segment by segment, and the intermediate states can persist. New offers are launched on the converged platform while the existing base stays on the old stacks, so the operator runs three models for a time: prepaid, postpaid and converged.

Cross-product discounts are where convergence leaks

A discount that depends on another holding is only as accurate as the Install Base behind it. Mobile plan cancelled, broadband discount continues: leakage. Plan live, discount missing: overcharging and a complaint. Both are found by Product configuration to Billing and Install Base to Billing reconciliation (6.9).

Legacy reality

Existing prepaid customers may have little customer data beyond a number, a balance and whatever registration the market requires. Bringing them into a unified account model means creating customer and account data that never existed, which is a data programme in its own right.

The trade-off

What it solves

One catalog, rating engine, balance model and account removes the duplicate product definitions and split customer view of the dual stack, and makes hybrid prepaid and postpaid offers possible.

What it does not solve

A wrong Install Base, which makes every cross-product discount and bundle wrong.
Different OSS stacks fulfilling each service, which still feed billing at different times.
Existing customers left on the old stacks until they are migrated.

What it adds

The converged platform is in the real-time call path for every customer, including postpaid.
Bundle prices must be split back to services for revenue recognition and tax.
Shared pools and account hierarchies need real-time balance sharing and roll-up billing.
Partial convergence adds a third model beside the two it was meant to replace.

Architecture decision

How should prepaid and postpaid be converged?

Full convergence on one platform
Choose when both stacks are due for replacement, hybrid offers matter commercially, and the operator can migrate the existing base, not only new customers.
Shared catalog first, separate charging
Choose when duplicate product definitions are the main pain and charging replacement is too risky for now, with a dated plan for the next step.
New customers on the converged platform only
Choose when migration risk for the existing base is high, and there is a defined date and method for moving the base or retiring the old stacks.

Breaks if convergence stops part-way with no exit plan. The operator then pays for three models, and every new product must be built for all of them.

Takeaways

Key Takeaways

Convergent billing means one platform for prepaid and postpaid, and one account and invoice across services
The dual stack duplicates catalogs, splits the customer view, makes payment-type changes a migration and doubles cost
Three pillars: unified rating, single balance management and a unified customer and account model
Convergence is usually incremental; the risk is staying partly converged with the complexity of both models
Cross-product discounts and bundles are only as accurate as the Install Base for every product involved

Check yourself

A customer cancels mobile but keeps broadband, and the "10% off broadband with mobile" discount continues for six months. What failed, and what control should have caught it?Show answerHide
The discount rule did not see the mobile cancellation, because the Install Base or billing's view of it was not updated. Install Base to Billing and Product configuration to Billing reconciliation should have flagged it.
Marketing wants a postpaid plan with prepaid top-ups for extra data. What does the platform need?Show answerHide
Single balance management that supports deferred charges and immediate deductions on one account, and unified rating so the same tariff applies to both. A dual stack cannot do it without moving balances between systems.