Telecom Mediation and Rating Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does traceability get underscoped so often?

Mediation projects are scoped as data engineering, because that is what they look like: collect files, parse, normalise, deduplicate, enrich, rate, output. Written that way, the requirement is throughput, and throughput is the one thing that is rarely the problem. The result is a pipeline that runs beautifully and cannot answer a question from a controller.

The requirement that should drive the whole architecture is one sentence. For any number on any invoice, you must be able to produce the raw records behind it, the rate that was applied, why that rate applied, and evidence that nothing else was dropped along the way. Everything follows from that. Raw records are retained immutably. Rating is a pure function of raw records plus a versioned rule set. Every rating run is identified, so any output traces back to the run and the rule version that produced it. Re-rating creates a new run rather than mutating the old one, and adjustments are computed as the difference between runs.

Scoped as a pipeline, none of that appears, and it cannot be retrofitted. A system that stores rated output and discards the source has thrown away the only material an adjustment could be built from. Teams discover this the first time a rate is loaded with the wrong effective date, which is usually within the first year.

So put it in the first design session, ahead of volume. Ask the supplier to describe re-rating three weeks of one partner's traffic after a rate correction. If the proposal involves updating rated records in place, stop there. The correct answer preserves the original run, produces a new one, and computes the delta so finance can reconcile it without taking anyone's word for it.

What goes wrong when historic usage and tariff history are migrated?

Migration here is not moving records. It is recovering what the rules were, and that turns out to be the hard part.

Three problems recur. First, tariff history exists in the current system as current state. Rate tables were edited in place over the years, so the platform can tell you what a route costs today and cannot tell you what it cost in March two years ago, which is exactly what you need to re-rate a disputed period. Reconstruction means reading change tickets, contract amendments and emails, and it is genuinely slow work.

Second, effective dating is often approximate. A rate was intended to apply from the first of the month and was actually loaded on the third, so the records in between were rated under the old price and the invoice was issued anyway. Migrating that as though the intended date applied creates a discrepancy against invoices you have already sent.

Third, archived raw records are frequently incomplete or in a format nobody can still read, because a decommissioned switch wrote a proprietary encoding and the tooling left with the vendor.

Handle it by scoping how far back you genuinely need. Full re-ratability for the period your contracts and dispute windows require, and a searchable archive of rated output for everything older. Reconstruct tariff history as versioned data with explicit effective dates, and where the actual loading date differed from the intended one, record both. That distinction sounds pedantic and it is the difference between an adjustment that reconciles and one that does not.

Why do the switch, gateway and partner feeds break after launch?

Source diversity, not volume, is what makes this category hard, and every source will eventually diverge from its documentation.

The specifics are familiar to anyone who has run one of these. A field documented as mandatory is empty on a share of records from one node. A duration field is in seconds on one switch and milliseconds on another running the same software at a different release. A partner starts sending a new record type without telling anyone. A file arrives with a malformed trailer at two in the morning. A collection job runs twice after an operator restart. A softswitch buffers during a link failure and resends a file ninety minutes later, which is outside a one hour deduplication window.

What matters is the failure behaviour rather than the failure itself. A partial failure must never become a total failure, and it must never silently become a success with missing data. A job that aborts on a bad trailer means manual recovery at month end. A parser that skips unreadable records without recording them means revenue that simply evaporates.

Build declarative, versioned parsers per source with a schema contract validated on every file, so deviations send the specific offending records to suspense with the violation attached while everything else keeps processing. Alarm on absence as well as on error, because a source that stops sending looks identical to a quiet period. And make the deduplication index persistent, keyed on the source's own unique identifier where one exists plus a composite key where it does not, with a retention period set by how badly your worst source misbehaves rather than by what is convenient. Cheap implementations cut exactly there, which is why they double-bill occasionally and cannot explain why.

What happens when suspense, rejects and revenue assurance are not covered?

These get deferred because they are not features anyone demonstrates, and their absence is what turns a working system into a quietly incorrect one.

Suspense is not a bin. A record in suspense needs a specific violation attached, an owner, an age and a route back into rating once corrected, because a suspense queue nobody works is functionally identical to dropping the records. The measure that matters is how many records are in suspense today, how old the oldest one is, and what they are worth. If nobody can answer, the queue is a hiding place.

Rejects on partner and settlement files are the second gap. Roaming settlement files arrive with their own specification and their own rejection procedure, and a rejected file that nobody resubmits inside the window is revenue you have forfeited rather than merely delayed.

Revenue assurance is the third and it is the one that pays for itself. Reconciliation counts at every stage, records collected against records parsed against records rated against records invoiced, with differences explained rather than tolerated. Undercharging is never reported by the customer, so the only way you find it is by counting. Build the counts into release one, because a system without them cannot tell the difference between a quiet month and a broken collector.

Should you build custom or configure what you already own?

There is a genuine case for buying, and it is not a small one.

If you are a wholesale voice or internet telephony operator with conventional rating needs at moderate volume, JeraSoft is built for exactly that and will cost a fraction of a build. If you need real-time online charging with credit control for prepaid subscribers, buy MATRIXX or Optiva, because that is a hard problem with real safety requirements and it should not be scoped as an extension of file-based mediation. If Oracle Communications Billing and Revenue Management is already in place and working, replacing a functioning billing platform is one of the higher-risk projects a telecom operator can undertake, and the trigger for it should be a business change rather than dissatisfaction with a screen.

DigitalRoute MediationZone handles enormous complexity and is the strongest dedicated product in the category. The trade-off is that configuration happens in its own toolkit, so you either build that expertise in house or buy it perpetually, and that trade-off is the actual decision rather than a feature comparison.

Build when your rating logic is a commercial differentiator rather than a standard construct, when back-dated reprocessing is routine rather than exceptional, when source diversity means configuration effort approaches engineering effort, or when every tariff change requires a consultant and your commercial agility now runs on someone else's calendar. Before deciding either way, take one month of real production traffic and rate it in parallel against your current system. The differences will define the scope better than any workshop.

How do hidden costs get into the quote?

Five items sit outside most quotes. Source diversity, which drives cost far more than record volume does, since every format is a parser, a set of undocumented quirks and a discovery period. Get the sources named and counted before pricing, and expect the list to grow once someone checks what is actually sending.

Second, tariff reconstruction, described above, which is frequently priced as data migration and is closer to forensic work. Third, roaming settlement, which brings its own specification, its own reject handling and its own deadlines. Fourth, real-time charging, which is a different system and should be quoted as one rather than as a phase. Fifth, the number of distinct tariff constructs your commercial team has sold over the years, which is reliably more than the commercial team believes.

Attach a written exclusion list to a fixed first release naming the sources, the usage types and the settlement scope included. Then rate one usage type completely, end to end and reconciled, before adding the next.

What separates a build that works from one that fails here?

The builds that work make traceability a product feature rather than a capability an engineer could theoretically exercise. An account manager drills from an invoice line to the rated records to the raw records with no query language involved, and the same path serves revenue assurance, settlement disputes and internal reconciliation. When only engineers can trace a charge, disputes take weeks, credits get issued because nobody could prove the charge in time, and within a year your commercial posture is to concede. That behavioural change costs more than the credits, and it is why we push for this in release one rather than as an enhancement.

The second differentiator is the parallel run. One month of real production traffic rated alongside the existing system, with every difference investigated rather than explained away. That exercise surfaces the undocumented source behaviour, the tariff constructs nobody remembered and the records your current pipeline has been silently dropping, and it gives you a defensible baseline to measure against once the new system is live.

The third is control. The code, the repository and the infrastructure should be yours from the first commit, agreed before kickoff. This system decides every number on every invoice you send, and the ability to hire a different team to work on it is not a procurement preference. It is the only thing standing between you and a rating engine you cannot change without permission.