SmartLink
Telecommunications

Telecom billing software in Pakistan: cost, timelines and revenue assurance

Telecom billing software in Pakistan is rarely a purchase and almost always a piece of engineering around something already running, because no operator replaces a billing platform for fun. SmartLink Services works from Karachi on usage feed reconciliation, revenue assurance controls, provisioning workflow, network asset data and the database tuning that keeps a billing run inside its window. What follows covers the commercial questions that come before any of that: what this work costs at market rates, how long it runs when the billing cycle cannot be interrupted, and which controls the sector expects an operator to run. All figures here are published market ranges rather than a SmartLink quotation.

Discuss your systems
Volume
High, always on
Critical
Billing accuracy
Tracked
Network assets
Watched
Revenue assurance
Overview

At telecom volume, a small billing error is a large number

Telecom systems fail differently from other sectors. Nothing collapses dramatically. Instead a rating rule drifts, a usage feed drops a small percentage of records, and revenue leaks steadily in a way that no single report is looking for.

That makes revenue assurance a design requirement rather than a monthly exercise. Feeds are reconciled record by record between the network, the mediation layer and billing, with alerting on volume anomalies rather than a review after the invoices have gone out.

Around that sit the other constants: provisioning that keeps service, billing and inventory in step, network asset records that reflect what is actually deployed, and database performance work so month end billing runs finish inside their window as volume grows.

The work

Where telecom systems break

Drawn from the problems that come up repeatedly in this sector rather than from a generic capability list.

Where it usually hurts

  • Usage records lost between network, mediation and billing
  • Rating and discount rules that nobody can fully explain
  • Provisioning out of step with billing, so service and invoice disagree
  • Network asset records that no longer match what is deployed
  • Billing runs taking longer each month as volume grows
  • Churn and usage analysis done on extracts rather than live data

What the work covers

  • Usage feed reconciliation and revenue assurance controls
  • Billing and rating system integration and support
  • Provisioning workflow keeping service, billing and inventory in step
  • Network asset and inventory data management
  • Database performance tuning so billing runs stay inside the window
  • Subscriber, usage and churn reporting

Typically involves

ETL pipelines REST APIs Message queues
Discuss your systems
01

Where usage records actually go missing

Record loss is rarely one visible failure. A network element rotates a file and the collector never notices that a sequence number was skipped. A mediation node rejects records it cannot parse into a suspense directory that nobody has opened in months. A duplicate check keyed on a field that is not genuinely unique discards good traffic along with the repeats. Each of these is small, none of them raises an alarm, and together they explain most of what an operator eventually finds during a revenue assurance review.

Time is the other reliable source of loss. Elements stamp records in local time, in network time or in a mix of both, and a record that crosses midnight can be assigned to the wrong day and then to the wrong bill cycle. Roaming adds its own layer, because records exchanged under the GSMA TAP 3 specification arrive on a partner clock with their own rejection route through returned account files. Records that arrive after a rating cut off need a defined home rather than a decision made by whoever notices them.

The remedy starts with file level accounting rather than with analysis. Every file that should exist is expected, received, parsed and counted, and the counts are carried forward at each hop so a gap has a location rather than a suspicion. Suspense stops being a directory and becomes an ageing work queue with an owner, a target and a visible backlog. It is unexciting engineering, and it finds more money than most reporting projects do.

  • File sequence continuity checked per network element rather than per feed
  • Suspense treated as an ageing work queue with a named owner
  • Duplicate detection keyed on a genuinely unique record identifier
  • Time zone and boundary handling resolved once, at ingestion
  • Late arriving and roaming records given a defined home instead of being dropped
02

Revenue assurance designed as a control rather than a monthly exercise

Assurance fails when it depends on one analyst with an extract and a deadline. The person is usually good, the coverage is usually narrow, and the finding usually arrives after the invoices have gone out. Controls belong inside the pipeline instead, running with the data rather than after it, so that a deviation is a notification on the day it happens rather than a discovery at quarter end. That is a design decision, and it is much cheaper to make at the start than to retrofit.

Two directions matter and most programmes only cover one. Completeness runs forward from the network element to the invoice, reconciling counts and values at every hop. Correctness runs backward from the invoice to the published tariff, independently rerating a sample of accounts to confirm that what was charged is what the commercial terms say should have been charged. An operator with strong completeness controls and no correctness testing will find dropped records and miss a misconfigured discount.

Governance is what keeps it alive. Every finding is logged with a root cause and closed by adding or repairing a control, not by correcting the affected accounts and moving on. A coverage map showing which feeds, products and partner arrangements have no control at all is more useful than any dashboard, because it names the risk that is currently invisible. The reference material published by the TM Forum is a reasonable starting frame, provided it is adapted to the estate rather than adopted wholesale.

  • Counts and values reconciled at every hop from network element to invoice
  • Alert thresholds set from each feed's own normal profile rather than a fixed limit
  • Independent rerating of sampled accounts against the published tariff
  • A leakage register where every finding ends in a new or repaired control
  • A coverage map that names the feeds and products with no control at all
03

Rating and discount rules that someone can still explain in two years

Rule sets accumulate. A launch promotion, a retention offer, a grandfathered plan from a migration, a bundle built for one enterprise customer, a rounding change nobody documented. Very little is ever removed, because removing something requires knowing who is still on it. After a few years the rating configuration is archaeology, and the honest answer to why a particular customer was charged a particular amount takes a specialist a day to establish. That is uncomfortable when the question comes from a regulator or from a corporate customer with a legal team.

Treating rules as governed data changes that. Each rule carries an effective date, a named commercial owner and a reference to the approval that created it. Rounding and proration are stated once, including the level at which rounding applies, because rounding per event and rounding per invoice produce different totals at volume and the difference is entirely predictable. Retired plans get a retirement path with a date instead of surviving indefinitely because migrating the last few subscribers was awkward.

Testing is the part that makes changes safe to release. A regression pack of representative subscriber profiles with realistic usage is rated before and after every configuration change, and any difference has to be explained before the change goes anywhere near a live cycle. Differences that are expected get signed off, differences that are not get investigated. That single habit prevents most of the billing incidents that otherwise end up being found by customers, and it takes far less effort than the credit notes and the goodwill adjustments that follow one of them.

  • Every rating and discount rule effective dated with a named commercial owner
  • Rounding and proration rules stated once and applied consistently across products
  • A regression pack of representative subscribers rated before and after each change
  • Grandfathered plans given an explicit retirement path and date
  • Unexplained differences investigated before release rather than after invoicing
01

What telecom billing and data work costs in Pakistan

Telecom work is priced differently from the rest of this site, because it is usually integration and data engineering rather than a module purchase. Published market rates for development in Pakistan put full stack work at PKR 3,500 to 8,000 an hour and senior specialist work at the upper end of that range, which is the shape most billing and mediation engagements take. A custom application, which is what a reconciliation or assurance layer amounts to, is quoted in the market at PKR 200,000 to 1,000,000 and upwards depending on the number of feeds and the volume behind them.

Where a full enterprise platform is in scope, the ordinary bands apply: PKR 800,000 to 1,500,000 for a focused implementation, PKR 1,500,000 to 3,000,000 for five to seven modules with a mobile application, and PKR 3,000,000 upwards for multi entity work with real integration. Operators land in the top band whenever the subscriber base is genuinely in scope, because volume changes the engineering rather than only the hardware.

Feed count is the honest driver. Each usage source, each mediation output and each interconnect or roaming file is a separate reconciliation with its own format, its own late arrival behaviour and its own way of failing silently. Ten feeds is not twice the work of five. Volume is the second driver and it decides architecture rather than effort: a query that returns in four seconds on a month of data may not return at all on three years of it, and finding that out in production is expensive. For context, published rates in Pakistan sit roughly sixty to eighty percent below Western equivalents, and international billing for comparable work runs USD 15 to 50 an hour. All of that is market pricing. A real figure follows discovery, once feed count, retention period and volume are on paper.

  • Feeds counted individually, since each reconciliation has its own failure mode
  • Market hourly rates for full stack and specialist work at PKR 3,500 to 8,000
  • Assurance and reconciliation layers priced as custom applications
  • Volume and retention period settling architecture before effort is estimated
  • Database tuning scoped against the billing window rather than a benchmark
02

How long telecom billing work takes

Reported timelines put a focused piece of work at six to twelve weeks and a larger programme at nine to twelve months. Telecom engagements often start in the first range and then meet a constraint that no other sector has in quite the same form.

The billing cycle owns the calendar. A rating change, a mediation adjustment or a new reconciliation cannot be proved in a week, because proving it means running a full cycle in parallel and comparing the output line by line against the live run. That is one month per attempt, and if the comparison shows a difference nobody can explain, it is two. Operators who try to compress this by testing on a sample find the discrepancy afterwards, in a month when the invoices have already gone out.

Access is the second constraint and it is procedural. Network teams control the feeds, and getting a test extract with realistic volume and realistic mess, rather than a tidy sample, takes longer than the analysis that follows it. We ask for that early and specifically. Subscriber data in a non production environment then needs masking agreed before anything is copied, which is a policy conversation rather than a technical one, and policy conversations do not run to a sprint boundary.

  • Focused work reported at six to twelve weeks, larger programmes nine to twelve months
  • A full billing cycle run in parallel before any rating change is accepted
  • Realistic test extracts requested early, with the mess left in
  • Masking of subscriber data agreed before any copy is taken
  • Comparison run line by line rather than on a sample
03

Subscriber data, rating changes and control in telecom

Revenue assurance is a control, and controls are judged by what they catch on an ordinary month rather than by what they found once. The useful version is unglamorous: counts and values reconciled between network, mediation and billing on a schedule, with a threshold, an owner and a record of what was investigated. Where reconciliation is a quarterly exercise performed by whoever is free, the gap between the network and the invoice grows quietly, and at telecom volume a small percentage is a large number.

Rating changes need the same discipline as financial configuration, because that is what they are. Every change to a tariff, a discount rule or a bundle should carry who requested it, who approved it, when it took effect and what it replaced. We have opened rating configurations where a discount had been running for two years and nobody in the building could name the customer it was agreed for, or the person who agreed it. That is not a software failure; it is the absence of a change record, and it is straightforward to fix once somebody decides to.

Subscriber data deserves more care than it usually gets in development environments. Production copies taken for testing are the most common route by which real customer records end up somewhere they should not be, so masking is agreed before the first copy and applied by a process rather than by a person remembering.

Two boundaries. What the Pakistan Telecommunication Authority requires of an operator, and how any obligation should be interpreted, comes from your own regulatory affairs and legal advisers rather than from us; we build systems that hold and produce what they specify. On tax, section 3(9A) of the Sales Tax Act requires Tier-1 retailers and other notified persons to integrate with the FBR computerised system for real time reporting, and whether and how that reaches your billing is a question for your own tax adviser.

  • Reconciliation between network, mediation and billing run to a schedule
  • Thresholds, owners and investigation records attached to every control
  • Rating and discount changes carrying requester, approver, date and predecessor
  • Subscriber data masked by process before any non production copy is taken
  • Regulatory interpretation left to your advisers, tax treatment to your tax adviser
How we deliver

Delivering in telecom

The six steps hold, but the calendar does not belong to us. Every date is set against your bill cycle, and nothing is released into a window where a run is due to start.

  1. 01

    Discover

    One usage record, followed all the way. Off the network element, through collection and mediation, into rating, onto an invoice. The hops where the count changes are where the first phase gets scoped.

  2. 02

    Blueprint

    Controls are specified before anything is built: what gets counted at each hop, what a normal profile looks like for each feed, who clears suspense, and where a late record is supposed to go.

  3. 03

    Build

    Reconciliation jobs, suspense queues and alerting go in feed by feed. Each one is proven on live traffic before the next is added, so nobody inherits a wall of alerts on day one.

  4. 04

    Test

    A regression pack of representative subscribers is rated before and after every change, and each difference has to be explained. Volume testing uses production sized data, not an extract that fits on a laptop.

  5. 05

    Go live

    Nothing is released into a live bill cycle. Changes land after a run completes and before the next opens, and where billing itself moves, a full parallel cycle is compared invoice by invoice first.

  6. 06

    Run

    The first month is watched hour by hour through the cycle. After that, support plus a standing review of the coverage map, since the feed nobody has a control on is the one that leaks.

Working together

Instrument before you tune

The temptation on this kind of work is to start with the component everyone complains about. That is usually a mistake. Instrumentation comes first, because until counts exist at every hop, any fix is a guess with a budget attached to it. A first phase that only measures is easy to justify and hard to argue with, and it tends to change the priority order that everyone assumed at the start.

Ownership sits with the operator afterwards and that has to be designed in. Somebody clears the suspense queue daily, somebody owns the rating rule catalogue, somebody signs off the exception queues from the three way reconciliation. Controls without owners decay quietly, and the failure mode is not an alarm but a queue that grows until it is too large to work through, at which point it gets ignored and the leakage returns.

There are limits worth being clear about. Reconciliation finds the records that went missing. It does not make a commercial rule sensible, and it will not settle whether a discount should have been offered in the first place. Performance work can hold a billing window as volume grows, but it cannot compensate indefinitely for a design that assumed a smaller business. Both are worth saying before a project starts rather than during it.

Credentials

Compliance for telecom clients

Operators licensed by the Pakistan Telecommunication Authority audit their vendors properly, so here are the accreditations and the data handling position without decoration.

Oracle

Partner

Most of the billing estates we work on sit on Oracle Database. Partitioning to the bill cycle, plan stability and restartable runs are the work that keeps a month end inside its window.

Microsoft

Partner

SQL Server carries the reconciliation and reporting layer at plenty of operators, with Power BI over it. Azure suits the assurance workload, which is spiky and does not need a permanent machine.

Google

Partner

Used more on the analytics side than in the core. Where subscriber and usage analysis has outgrown the reporting database, separating that workload from billing is worth costing properly.

FBR digital invoicing

Compliant integrations

Telecom invoicing carries sales tax on services under the provincial authorities alongside the federal obligation. We build the digital invoicing reporting into the invoice run rather than as a separate nightly file.

HIPAA

Compliant practices

Not a telecom obligation. It applies where an operator carries health data for a customer or runs its own staff clinic, and we handle that under documented controls and a business associate agreement.

Client words

What telecom clients say

Comments from people running telecom systems day to day.

  • Our first concern with FBR integration was simple: what happens to the tills when the line drops. They built the queueing and retry before anything else and demonstrated it by pulling the connection in front of us. Trading carried on, and the invoices went up when the link came back.
    Operations Manager Retail chain, Pakistan
  • Every vendor we spoke to said they could handle style, colour and size. This team asked to see our order book first, then told us which of the shortlisted platforms would need thousands of item codes to do it. That one piece of advice probably saved us a year.
    General Manager Textile exporter
  • The handover was the part I judged them on. Configuration decisions documented with the reasoning, our administrators trained properly, and a checklist we actually worked through. We run it ourselves now, and calling them is a choice rather than a necessity.
    Head of Shared Services Multi site manufacturing group
Questions

Questions about telecom systems

Published market rates put full stack and specialist development at PKR 3,500 to 8,000 an hour, and a custom reconciliation or assurance layer at PKR 200,000 to 1,000,000 and upwards. Where a full platform is in scope, multi entity work starts at PKR 3,000,000. Those are market ranges rather than our price, and our figure follows discovery once the feed count and retention period are known.

Longer than the code suggests, because the billing cycle sets the pace. Proving a rating or mediation change means running a full cycle in parallel and comparing output line by line, which is a month per attempt and two if the comparison shows something nobody can explain. Focused work is reported at six to twelve weeks.

Rarely, and we will say so early. Most of our telecom work sits around the platform already running: reconciliation, assurance controls, provisioning workflow, network asset data and database tuning. Replacing a billing platform is a programme with a different risk profile, and an operator considering one deserves an honest conversation about scale before anyone proposes it.

Usually, and the first step is measurement rather than tuning. We instrument the run to find where the time actually goes, which is often two or three queries and a nightly job nobody has looked at in years. Tuning without that measurement is guesswork, and it tends to move the bottleneck rather than remove it.

Masked by a process before any copy is taken, not by somebody remembering. Production extracts are the most common route by which real customer records reach places they should not be, so the masking rules are agreed in writing first and applied automatically. That conversation is a policy one and it happens before the first extract.

Counts and values reconciled between network, mediation and billing on a schedule, each with a threshold, a named owner and a record of what was investigated. It is judged on what it catches in an ordinary month rather than on a single discovery. At telecom volume, a small percentage of leakage is a large annual number.

Other sectors

The other sectors we work in.

The same practices, applied to the problems each sector actually has.

01 Governmental Departments and authorities that need auditable systems, controlled access and procurement that survives scrutiny. 02 Food Manufacturing Batch traceability, shelf life and yield, joined up from goods in through to the despatch note. 03 Aluminum Alloy, coil and billet traceability with the costing detail that melting, extrusion and finishing actually need. 04 Retail Tills, stock and online joined to one set of numbers, with FBR digital invoicing where it applies. 05 Professional services Time, utilisation and project profitability made visible while a job can still be steered. 06 Wholesale Distribution Stock accuracy, route delivery and true landed cost across warehouses and vans. 07 Oil & Gas Asset heavy operations where maintenance, permits and contractor control carry real consequence. 08 Construction Project cost control, subcontractor certification and valuations that reconcile to the ledger. 09 Automotive Part traceability, supplier schedules and dealer systems joined to the plant. 10 Mining Production, grade, fleet availability and consumables measured where the cost is incurred. 11 Textile Style, colour and size matrices, plus real costing across spinning, weaving, dyeing and stitching.
All industries

Working with telecom systems?

Tell us what you run today and where it breaks. The first conversation is a consultation, not a pitch.

Book a consultation All industries