BSS/OSS Academy
πŸ’°
Section 5.6

Convergent Billing

Prepaid/postpaid convergence, the dual-stack problem, single balance architecture, unified rating, and the OCS role.

The Convergence Problem

Historically, telcos ran separate billing stacks for prepaid and postpaid customers. Prepaid used a real-time Online Charging System (OCS) that deducted from a balance on every event. Postpaid used a batch billing system that rated usage at bill run and generated monthly invoices. These two stacks had different databases, different rating engines, different product catalogs, and often different vendors. Convergent billing is the architectural goal of running both prepaid and postpaid on a single platform with a unified customer view.

Convergent Billing
A billing architecture that supports both prepaid (real-time balance management) and postpaid (invoice-based) customers on a single platform, with a unified product catalog, single customer view, and shared rating engine. Convergent billing eliminates the dual-stack complexity and enables hybrid payment models (e.g., postpaid plan with prepaid data top-up) that are impossible with separate systems.

Why Dual-Stack Billing Breaks

Running separate prepaid and postpaid stacks creates operational and commercial problems that compound over time.

  • Duplicate product catalogs β€” Every product must be defined twice (once for prepaid, once for postpaid) with different pricing rules, leading to inconsistency and slower time-to-market
  • No single customer view β€” A customer who is prepaid for mobile and postpaid for broadband appears as two unrelated accounts. Cross-sell, upsell, and loyalty programmes cannot operate across both.
  • Migration friction β€” Converting a customer from prepaid to postpaid (or vice versa) requires account migration between systems, often with service interruption and manual data re-entry.
  • Double operational cost β€” Two platforms to maintain, upgrade, and staff. Two sets of mediation interfaces, two rating configurations, two support processes.

Convergent Architecture: Single Balance, Single View

A convergent billing platform unifies the prepaid and postpaid models through three key architectural elements:

  • Unified rating engine β€” A single engine that can rate in real-time (for prepaid/hybrid) and batch (for postpaid), driven by the same product catalog and tariff plans.
  • Single balance management β€” One balance architecture that supports immediate deductions (prepaid), deferred charges (postpaid), and mixed models (postpaid plan with prepaid top-up for extras).
  • Unified customer/account model β€” One customer record, one account hierarchy, regardless of payment method. The payment type becomes a product attribute, not a system boundary.
Convergence Is a Spectrum
Full convergence β€” a single platform for all customers β€” is the target state, but most operators achieve partial convergence first. Common intermediate steps: shared product catalog with separate rating engines, or converged rating with separate balance management. Each step reduces operational cost but full benefits only materialise with full convergence. The risk is getting stuck in a permanent "partially converged" state that has the complexity of both models.
Standards Alignment
The Online Charging System (OCS) is defined by 3GPP TS 32.296 (OCS architecture) and TS 32.299 (Diameter-based charging). Convergent billing aligns with TMF Open APIs TMF678 (Customer Bill Management), TMF654 (Prepay Balance Management), and TMF666 (Account Management). The ODA functional block for billing is expected to support convergent prepaid/postpaid as a single component rather than separate functions.

Key Takeaways

  • Convergent billing unifies prepaid (real-time OCS) and postpaid (batch billing) on a single platform
  • Dual-stack billing creates duplicate catalogs, no single customer view, migration friction, and double operational cost
  • Three architectural pillars: unified rating engine, single balance management, and unified customer/account model
  • Most operators achieve convergence incrementally β€” the risk is getting permanently stuck in a partially converged state