Telecom ERP Implementation: BSS, OSS, and Billing Integration

Telecom ERP implementation sits at the intersection of business process management and technical telecommunications infrastructure. Unlike most industries where ERP implementation involves primarily business process change, telecom ERP implementation requires integration with specialized telecommunications systems — provisioning platforms, mediation systems, billing engines, and interconnect settlement systems — that have their own technical standards, data models, and real-time performance requirements.

This guide provides a practitioner-level framework for telecom ERP implementation, with specific attention to the BSS/OSS integration architecture, billing system migration, and subscriber data migration challenges that distinguish telecom implementations from commercial ones.

Key Takeaways

• BSS/OSS integration architecture must be designed before implementation begins — API capability assessment of legacy systems determines the integration approach
• Billing migration is the highest-risk component — a billing system error affects all subscribers simultaneously
• Subscriber data migration requires extensive deduplication and account balance reconciliation before cutover
• Number inventory migration must include full porting history for number portability compliance
• Real-time provisioning integration must be tested at production scale before go-live
• Revenue assurance controls must be validated with a full usage-to-bill comparison before legacy billing decommission
• Regulatory reporting (FCC Form 477, CPNI) must be validated in the new system before the first regulatory deadline
• Telecom tax engine integration must be tested for all service types, jurisdictions, and customer types

---

Pre-Implementation: BSS/OSS Architecture Assessment

Before planning the ERP implementation, conduct a comprehensive assessment of the existing BSS/OSS architecture. This assessment determines which systems will be replaced by ERP functionality, which will be integrated with the ERP, and which will remain as separate systems.

System Inventory

A typical regional telecom BSS/OSS stack includes:

API Capability Assessment

The most important technical assessment is the API capability of each legacy system. Systems with well-documented REST APIs support real-time integration. Systems with older web services or proprietary APIs require middleware. Systems with no API capability require batch file integration — introducing latency and complexity.

For provisioning systems (which must activate service in near-real-time), API integration quality is critical. A provisioning system that requires batch file integration cannot support same-day service activation — a significant customer experience disadvantage.

---

Phase 1: Finance and HR Foundation (Months 1-4)

The finance and HR implementation proceeds similarly to other industry implementations, with telecom-specific chart of accounts configuration.

Telecom Chart of Accounts

Telecom chart of accounts must support revenue recognition by service type (voice, data, video, enterprise), by customer segment (residential, SMB, enterprise, wholesale), and by geography. Interconnect revenue and expense must be tracked separately from retail revenue. Regulatory fees and taxes must be tracked by type for FCC and state reporting.

Regulatory Reporting Framework

FCC reporting requirements — including the annual Form 477 broadband deployment census and the quarterly Form 499 universal service fund contributor data — require specific data from the billing and customer management systems. The finance module must be configured to capture the necessary data elements from day one, so that regulatory reports can be generated from the ERP from the first reporting period.

---

Phase 2: Product Catalog and Service Plan Management (Months 3-7)

The product catalog is the central configuration element that drives both billing and provisioning. Every service that can be ordered — every plan, every add-on, every device installment option — must be defined in the product catalog before billing or provisioning can function correctly.

Product Catalog Configuration

Telecom product catalog configuration is more complex than most industries because of the relationship between product definitions and network provisioning parameters:

• Each service plan has a set of network parameters: data speed tier, voice minutes allocation, SMS allowance, roaming permissions
• When a customer activates a plan, those parameters must be transmitted to the provisioning system
• When a customer upgrades or downgrades their plan, the provisioning change must be transmitted in real time

The ERP product catalog must be designed with these provisioning attributes embedded in each product definition. When the billing system generates a plan change, the associated provisioning parameters are automatically included in the change order transmitted to the provisioning system.

Promotion and Bundle Management

Telecom promotions — discounts, bundle pricing, loyalty offers — are frequent and complex. A mobile carrier may run 20+ concurrent promotional offers at any given time, each with specific eligibility criteria, duration, and value. The product catalog must support all of these promotions without requiring separate billing system configuration for each one.

---

Phase 3: Billing System Migration or Integration (Months 5-12)

Billing migration is the most technically complex and operationally risky component of telecom ERP implementation. A billing error that affects all subscribers simultaneously generates customer service volume spikes, regulatory complaints, and revenue impact.

Replace vs. Integrate Decision

For MVNOs and small operators (under 100,000 subscribers), replacing the legacy billing system with ERP native billing or a cloud billing platform integrated with the ERP is typically the right decision. The legacy billing system in small operators is often an expensive licensed platform with high support costs; replacing it with a modern alternative generates both cost savings and improved capability.

For large operators (over 500,000 subscribers), the legacy billing system typically has complex rating logic that has been customized over years to handle the operator's specific products and promotions. Replacing this system requires recreating all of this logic in the new platform — a high-risk undertaking. Integration — maintaining the legacy billing system for rating and using the ERP for financial reporting and customer management — is the lower-risk approach.

Billing Data Migration

The billing data migration for subscriber cutover requires:

1. Account balance migration: Every subscriber's current balance (charges accrued but not yet billed, credits applied, payments received) must migrate exactly. A $1 balance error on a subscriber's account generates a customer service contact.

2. Bill cycle assignment: Each subscriber has a monthly bill cycle — the calendar day on which their invoice is generated. The migration must preserve the existing bill cycle assignment to avoid generating two bills in one month or skipping a bill for some subscribers.

3. Payment method migration: Autopay subscribers have payment methods (credit card, bank account) on file. These payment tokens must be migrated to the new billing system, typically through a tokenization transfer with the payment processor.

4. Billing history migration: 24 months of billing history provides sufficient support for billing disputes; longer histories may be archived rather than migrated.

Billing Parallel Operation

The billing parallel operation period should cover at least one complete billing cycle for every bill cycle date (typically requiring one full calendar month). During parallel operation, both the legacy billing system and the new ERP billing system generate invoices independently. Results are compared subscriber by subscriber to identify discrepancies.

Acceptable tolerance thresholds must be defined before parallel operation begins. A $0.01 difference due to rounding is acceptable; a $10.00 difference requires investigation before go-live.

---

Phase 4: Provisioning Integration (Months 6-10)

Provisioning integration is a real-time, mission-critical integration that must function correctly before the ERP can manage subscriber lifecycle events.

Provisioning API Integration

The provisioning integration must handle every subscriber lifecycle event:

• New subscriber activation: Service plan parameters, phone number assignment, SIM registration
• Plan change: Updated data and voice parameters in real time
• Add-on activation: Additional features (international roaming, premium data) added to the subscriber's profile
• Suspension: Temporary suspension for non-payment — voice and data services should be suspended with emergency calling preserved
• Reactivation: Reinstatement of full service when payment is received
• Termination: Full deactivation of all services, number return to inventory

Each of these events must be tested in the provisioning system's test environment before production deployment.

Provisioning Error Handling

Provisioning failures — situations where the provisioning command is sent to the network but fails to execute — are a normal occurrence in telecom operations. The ERP must handle provisioning failures gracefully:

• Log the failure with the error code from the provisioning system
• Generate an alert for the operations team
• Retry the provisioning command automatically for transient failures
• Escalate to manual intervention for persistent failures

Without proper error handling, provisioning failures result in subscribers who are being billed for services they cannot access — a quick path to customer escalations and regulatory complaints.

---

Phase 5: Number Inventory Migration (Months 4-8)

Telephone number inventory management — tracking which numbers are assigned, which are available, and the porting history of each number — is a unique telecom requirement.

Number Inventory Data

The ERP number inventory module must maintain:

• All numbers in the operator's inventory, with current status (available, assigned, porting-in, porting-out, reserved, aging)
• The subscriber assignment history for each number
• Porting transaction history — every time a number was ported in or out, the date, gaining carrier, and transaction ID
• Geographic designation (the rate center and state associated with each number)

LNP Compliance

Local number portability compliance requires that the operator process porting requests within FCC-mandated timeframes. The ERP porting workflow must:

• Accept porting requests from gaining carriers within minutes of submission
• Validate that the number and account information match the operator's records
• Submit valid porting requests to the NPAC within the required timeframe
• Reject invalid requests with specific rejection codes

Number Recycling Controls

Numbers that have been ported out or surrendered must be "aged" before being reassigned to a new subscriber. Industry practice is to age a released number for 90-180 days before reassignment, to reduce the probability of calls intended for the previous subscriber reaching the new subscriber.

---

Phase 6: Revenue Assurance Integration (Months 8-14)

Revenue assurance integration ensures that all services consumed are correctly billed. This integration compares network usage data to billing data and identifies discrepancies.

Usage Data Reconciliation

The revenue assurance integration must reconcile:

• Network usage records (from the mediation system) against billed usage
• Provisioned services (from the provisioning system) against active billing plans
• Applied discounts and credits against their eligibility criteria

Discrepancies are classified by type and routed to the appropriate operations team for investigation. High-value discrepancies (potential leakage exceeding a threshold) are escalated immediately.

---

Change Management for Telecom ERP

Customer Service Representative Training

CSRs are the most important user group for telecom ERP adoption. They handle high volumes of customer contacts — billing inquiries, service changes, complaints — and their efficiency directly affects customer satisfaction and operational cost.

CSR training must be intensive and hands-on: role plays with actual system scenarios, including common complaint types (billing dispute, service issue, upgrade request) and less common but high-impact scenarios (account compromise, deceased subscriber, business account administration).

Training metrics should include: average handle time, first contact resolution rate, and escalation rate. If these metrics worsen after ERP go-live, the training program needs remediation.

Operations Center Preparation

The network operations center (NOC) must be prepared to monitor the ERP-to-provisioning integration alongside their existing network monitoring responsibilities. Integration health dashboards should be visible in the NOC alongside network performance dashboards.

---

Frequently Asked Questions

How do we handle the billing migration for subscribers on legacy plans that no longer exist?

Subscribers on grandfathered plans that are no longer offered present a migration challenge: the new billing system may not have a matching plan definition. The options are: create matching plan definitions in the new system (preserving grandfathered pricing and terms indefinitely), migrate these subscribers to the closest equivalent current plan (with appropriate notification and potential regulatory requirements), or maintain the legacy billing system in read-only mode for these subscribers until natural attrition reduces their numbers. The decision depends on the volume of grandfathered subscribers and the complexity of migrating their specific terms.

What is the regulatory impact of billing system migration errors?

Billing errors that generate customer complaints to state Public Utility Commissions (PUCs) or the FCC are investigated and can result in fines, ordered refunds, and required system remediation. State PUC billing rules vary significantly — some require customer notification before billing system changes, others require error rate reporting. Review the billing regulations in each state where you serve customers before executing the billing migration cutover.

How do we maintain 911 service continuity during provisioning system integration?

E911 service continuity is a regulatory and safety-critical requirement. The provisioning integration must maintain continuous connectivity between the ERP and the E911 provisioning system (or the Automatic Location Information system). Any planned maintenance window that could affect the E911 provisioning path must be scheduled only with advance notification to the appropriate state E911 authority. Test E911 calls (to the test number rather than 911 itself) should be part of the provisioning integration test script.

What is the timeline for CPNI compliance in the new ERP system?

CPNI (Customer Proprietary Network Information) compliance requires that access to customer usage data be restricted to authorized purposes and that customers have the ability to opt out of certain marketing uses. Before the ERP goes live with customer data, the access controls must be configured to comply with CPNI rules, the opt-out preferences from the legacy system must be migrated, and the annual CPNI certification process must be documented for the new system. The FCC annual CPNI certification deadline is March 1 — plan the ERP go-live to allow at least 60 days before the next certification deadline.

How do we manage the provisioning integration latency requirements?

Real-time provisioning changes (plan activations, suspensions, reinstatements) typically must complete within 60-120 seconds to meet customer and regulatory expectations. The provisioning API integration must be designed with this latency requirement in mind: asynchronous processing should be used for bulk operations (batch plan migrations), while synchronous API calls handle individual subscriber events that customers expect to see take effect immediately.

---

Next Steps

Telecommunications companies planning ERP modernization should start with a BSS/OSS architecture assessment and API capability review to determine the integration approach for each existing system. ECOSIRE's implementation practice delivers telecom ERP deployments that integrate with provisioning systems, billing platforms, and regulatory reporting systems.

Explore ECOSIRE's Odoo ERP Implementation services to learn how our structured methodology addresses the unique integration and data migration challenges of telecommunications ERP implementation.