Custom Software for Telecom Operators
Secure, flexible, and compliant architecture tailored for the unique challenges of the Telecom Operators sector.
Vivek Mishra — Founder & Lead Architect, ERPStack
Quick Answer
In short: a telecom ERP is OSS and BSS with the seams removed. ERPStack builds custom telecom software on TM Forum Open APIs — TMF620 catalogue, TMF622 ordering, TMF678 billing — mediates 3GPP call detail records into a rated PostgreSQL ledger, and keeps FCC CPNI records and broadband-label data auditable.
Why Custom ERP for Telecom Operators?
Operating in the Telecom Operators sector requires a systems architecture designed for high scalability, operational flexibility, and strict regulatory compliance. Standard off-the-shelf software forces your teams to reshape their workflows to fit rigid software packages. A custom ERP for the Telecom Operators industry maps directly to your exact business logic. Deployed to your secure cloud infrastructure (AWS or Azure), the system isolates database schemas, automates redundant reporting tasks, and scales without user seat licensing fees. This ensures your corporate data remains under your absolute control, eliminates vendor lock-in, and lowers long-term operational technology costs by up to 70% over a 3-year period.
Industry Pain Points
- The product catalogue sits inside the billing system, so TMF620 offerings, TMF637 product inventory and the FCC broadband label drift apart
- A telecom product order has no decomposition, so TMF622 fallout is worked by hand in email instead of held as state in PostgreSQL
- 3GPP TS 32.298 call detail records are rated inside the transactional PostgreSQL ledger, so usage and month-end close contend for the same rows
- Revenue assurance is a monthly spreadsheet, so leakage between TMF640 activation, TMF635 usage and TMF678 invoicing surfaces a quarter late
- CPNI approval status and marketing-campaign records are not queryable, so the 1 March officer certification in EB Docket 06-36 is assembled by hand
- MVNO and device-financing lines are bolted on as discounts, so multi-tenant settlement and IFRS 15 handset allocation cannot be produced
Engineering Blueprint
Telecom IT has a published vocabulary that almost nobody outside the industry uses. eTOM is ITU-T Recommendation M.3050.1, the TM Forum Information Framework names the entities, and the Open Digital Architecture and TM Forum Open APIs make them addressable. ERPStack builds telecom systems to those shapes.
An order is four objects, not one
A generic ERP has one order table. A telecom operator does not: TMF622 carries the product order, TMF641 the service order it decomposes into, TMF652 the resource order beneath that, and TMF640 the activation that touches the network. Fallout — the half-provisioned order — is where telecom revenue leaks, and it only becomes fixable when every hop is a row with a state. ERPStack models that decomposition in PostgreSQL with Drizzle ORM, so a stuck order is a query.
// Drizzle ORM on PostgreSQL — TMF622 decomposes, it does not flatten
export const serviceOrders = pgTable('service_orders', {
productOrderId: text('product_order_id').notNull(), // TMF622
serviceSpecId: text('service_spec_id').notNull(), // TMF633
resourceOrderId: text('resource_order_id'), // TMF652
state: text('state').notNull(), // acknowledged|inProgress|failed|completed
falloutCode: text('fallout_code'),
activatedAt: timestamp('activated_at'), // TMF640
});Mediation and rating are a volume problem
Usage does not arrive as invoices. 3GPP TS 32.297 defines the CDR file format and transfer, TS 32.298 the CDR parameters, TS 32.290 and TS 32.291 the 5G converged charging services over the Service Based Interface. At half a billion records a month, rating cannot run inside the transactional ledger. ERPStack mediates through an Event-Driven Architecture on Apache Kafka, Zod-validated and deduplicated by charging id — idempotency in API design, applied to telecom mediation. Rated usage lands in a ClickHouse analytics database or TimescaleDB; balances stay in PostgreSQL, where a prepaid decrement needs ACID compliance and a Redis reservation.
The catalogue is the system of record
Every telecom price a customer can be charged should come from one TMF620 product catalogue: the storefront, TMF648 quoting, TMF637 product inventory and — since 47 CFR 8.1 — the FCC broadband consumer label, published machine-readable at a dedicated URL and archived two years after a plan closes to new subscribers. When the catalogue lives inside the billing system those four drift apart and every tariff change accrues Technical Debt. ERPStack makes it a versioned, effective-dated catalogue in PostgreSQL behind a REST and GraphQL API, TMF688 events replacing nightly extracts.
What ERPStack does not replace
Not the network. MEF service definitions — MEF became the Mplify Alliance in June 2025 — and ETSI GS NFV-MAN 001 orchestration stay where they are. ERPStack integrates through TMF638 service inventory and TMF639 resource inventory, applies the Strangler Fig Migration Pattern to the telecom BSS side only, and ships to AWS or Microsoft Azure defined in Terraform.
Our Solutions
- TM Forum Open API surface in TypeScript and Next.js: TMF620 catalogue, TMF622 product order, TMF641 service order, TMF637 inventory, TMF666 account
- Order decomposition as an explicit saga — product order to service order to TMF652 resource order to TMF640 activation, with fallout stored as state
- Mediation on Apache Kafka: 3GPP CDRs deduplicated by charging id and landed in a ClickHouse analytics database or TimescaleDB, never in the ERP ledger
- TMF678 customer bill and TMF654 prepay balance against one PostgreSQL account, with Redis reservations so prepaid and postpaid telecom share a ledger
- FCC broadband labels generated from the catalogue, published machine-readable at a dedicated URL and archived two years per 47 CFR 8.1
- CPNI records, PCI DSS card-on-file scope and 24-hour traceback responses as Immutable Audit Trail rows on AWS, auditable against SOC 2 and ISO 27001
Compliance & Security
Telecom compliance is recordkeeping with a clock attached. Every rule below becomes a retention period, an access rule or a generated filing — which is why it belongs in the schema.
CPNI is a retention schedule and an access model
47 CFR 64.2009 makes a telecom carrier keep a record of every marketing campaign that used CPNI — the description, the CPNI used, the products offered — for a minimum of one year, plus outbound supervisory records. An officer files a signed certificate with the Enforcement Bureau on or before 1 March each year in EB Docket No. 06-36, and 64.2010 requires authentication before call detail is disclosed. CALEA, at 47 CFR 1.20000, allows interception only with legal authorisation and the affirmative intervention of a named carrier employee. ERPStack keeps approval, campaign membership and disclosure events as immutable rows behind RBAC and Zero-Trust Security.The breach clock, stated correctly
Under 47 CFR 64.2011 as it currently stands, a telecom carrier notifies the Secret Service and the FBI through the central reporting facility no later than seven business days after reasonable determination, and may not notify customers until seven full business days have elapsed — the investigating agency can bar disclosure a further 30 days. The FCC’s 2024 rewrite at 89 FR 9968 took effect 13 March 2024 except its 64.2011 amendment, which is delayed indefinitely. Build to the rule in force; version the workflow.Robocall and 911 duties are SLAs in disguise
47 CFR 64.6305 requires a telecom voice provider’s robocall mitigation programme to answer traceback requests from the Commission, law enforcement and the industry traceback consortium within 24 hours, and to certify in the Robocall Mitigation Database. The FCC’s NG911 rules (FCC 26-39, 91 FR 42794) take effect 10 August 2026 and require a certifying official to attest under penalty of perjury. Both are ticket workflows — timers, owners and OpenTelemetry observability, not policies.Where the money rules bite the rating engine
Universal service contributions are computed on projected collected interstate and international end-user revenues at a factor the FCC sets quarterly under 47 CFR 54.709, reported on Forms 499-A and 499-Q. 47 CFR 54.712 caps the line item on a telecom customer’s bill at the interstate portion times that factor — a hard constraint on the rating engine, not a footnote — and late contributions accrue interest at the US prime rate plus 3.5 percent. IFRS 15 forces handset-versus-service allocation across an instalment contract, and card-on-file autopay drags PCI DSS and, for EU subscribers, GDPR into the same schema.
Standards we engineer to
- FCC CPNI 47 CFR 64.2009
- FCC 47 CFR 8.1 Broadband Labels
- STIR/SHAKEN 47 CFR 64.6305
- CALEA 47 CFR 1.20000
- TM Forum ODA
- 3GPP TS 32.290
- SOC 2 Type II
Get the Blueprint
Download our comprehensive Systems Architecture Blueprint to see how we architect compliant solutions.
Download BlueprintMetrics & Integrations
Illustrative engineering targets for this sector — the SLAs and capacities we design and build toward, not a live service dashboard.
Rated CDR throughput target
Order-to-activate design target
Broadband label archive
Traceback response window
Integration: TMF620 Product Catalog API
Integration: TMF622 Product Ordering API
Integration: 3GPP CDR mediation
Integration: Apache Kafka
Integration: ClickHouse
Integration: Robocall Mitigation Database
Implementation Process
Catalogue first
One TMF620 product catalogue in PostgreSQL that the storefront, CPQ and the FCC label all read.
Order decomposition
TMF622 product orders split into TMF641 service and TMF652 resource orders with explicit fallout states.
Mediation and rating
3GPP CDRs normalised on Apache Kafka, deduplicated by charging id, rated against the telecom catalogue.
Billing and balances
TMF678 customer bills and Redis-backed TMF654 prepay balances against one TMF666 PostgreSQL account.
Regulatory surfaces
Broadband labels, CPNI campaign records and Robocall Mitigation Database evidence generated from the same data.
Assurance and settlement
Revenue assurance reconciliation and TMF736 partner settlement wired to TMF635 usage on AWS.
Proven in Telecom Operators
Real-Time Fraud Detection Platform
Real-time fraud detection and risk scoring platform
Read Case StudyFrequently Asked Questions
A published data model. eTOM is ITU-T Recommendation M.3050.1, and the TM Forum Open APIs name the objects: TMF620 product catalogue, TMF622 product order, TMF637 product inventory, TMF641 service order, TMF666 account. A generic ERP has one order table; a telecom operator needs a product order that decomposes into service and resource orders. ERPStack builds those shapes directly in PostgreSQL.
No. At half a billion CDRs a month, rating cannot run inside the transactional PostgreSQL instance that also closes the books. ERPStack mediates over Apache Kafka, deduplicating on the charging id defined in 3GPP TS 32.298, and lands rated telecom usage in a ClickHouse analytics database or TimescaleDB — leaving only invoice lines, adjustments and balances in the ledger.
It is the BSS half plus the ledger. BSS covers product catalogue, CPQ, ordering, rating and charging, invoicing, collections and partner settlement; OSS covers service and resource inventory, activation and assurance. ERPStack builds the BSS side against TM Forum Open APIs and integrates the telecom OSS through TMF638 service inventory and TMF639 resource inventory rather than replacing the network stack.
More than a PDF. A telecom provider must display a broadband consumer label at every point of sale, publish the same content machine-readable as a spreadsheet at a dedicated URL, and archive each label at least two years after the plan closes to new subscribers, producing any archived label within 30 days. Compliance began 10 April 2024 for larger providers and 10 October 2024 for those with 100,000 or fewer subscriber lines.
Under 47 CFR 64.2011 as currently in force, a telecom carrier notifies the Secret Service and FBI through the central reporting facility as soon as practicable and no later than seven business days after reasonable determination, and may not tell customers until seven full business days have passed. The FCC's 2024 rewrite at 89 FR 9968 took effect 13 March 2024 except its 64.2011 amendment, which is delayed indefinitely.
Keep Salesforce for sales and case management if it is already embedded; the churn conversation lives there and moving it buys little. What Salesforce cannot be is the telecom system of record for subscriptions, balances and rated usage. ERPStack builds that as a TMF666 account carrying TMF678 bills and TMF654 prepay balances in PostgreSQL, and syncs the customer view back over a REST API.
By separating balance from invoice. A postpaid telecom subscriber accrues rated usage against a bill cycle; a prepaid subscriber decrements a balance in real time, which 3GPP models as converged charging over the Service Based Interface in TS 32.290 and TS 32.291. ERPStack holds both against one TMF666 account in PostgreSQL, so a hybrid plan becomes a policy rather than a second system.
In the seams. Between TMF640 activation and the TMF620 catalogue price, between mediation and rating, and between a partner settlement file and an interconnect invoice. ERPStack instruments each hop of the telecom order-to-cash path as an event on Apache Kafka carrying a reconciliation key, so a service active without a rated subscription becomes a daily query in PostgreSQL instead of a quarterly audit finding.
It makes the operator a lender. An equipment instalment plan is a receivable with a term, an implied rate and default risk, and IFRS 15 requires the transaction price to be allocated between handset and service across the contract. ERPStack models the instalment schedule and the telecom subscription as separate performance obligations on one PostgreSQL contract, so the allocation is computed rather than estimated.
Response times and attestations. 47 CFR 64.6305 requires a telecom voice provider's robocall mitigation programme to commit to answering traceback requests from the Commission, law enforcement and the industry traceback consortium within 24 hours, and to certify in the Robocall Mitigation Database. The FCC's NG911 reliability rules, adopted as FCC 26-39 at 91 FR 42794, take effect 10 August 2026 and add an attestation under penalty of perjury.
As a tenant, not a copy. An MVNO buys capacity wholesale and resells it under its own TMF620 catalogue, pricing and bills while sharing mediation and rating with the host telecom network. ERPStack builds that as Multi-tenant Architecture in PostgreSQL — tenant-scoped catalogues, rated usage partitioned by brand, and settlement through the TMF736 to TMF738 revenue-sharing APIs.