Telecom Mediation and Rating: When a Customer Disputes One Line and Nobody Can Find the Record Behind It

Why this is a data engineering problem that finance owns

Mediation and rating sit in an awkward place organisationally. The work is high-volume stream processing, which is engineering. The output is every invoice the business sends, which is finance. When something goes wrong, it is discovered by a customer, escalated by an account manager, and diagnosed by a data engineer who has to explain to a controller why one line on a bill says four hundred dollars.

The failure mode that defines this category is not an outage. It is quiet incorrectness. Records that arrived and were silently dropped because a file had an unexpected trailer. Duplicate records that were counted twice because the dedup window was an hour and the switch retransmitted after ninety minutes. A tariff change applied from the wrong effective date so three weeks of traffic rated at the old price. None of these page anyone. All of them appear on invoices, and the ones that undercharge are never reported by the customer at all.

So the requirement is not throughput, although throughput is table stakes. The requirement is that for any number on any invoice, you can produce the raw records behind it, the rate that was applied, why that rate applied, and proof that nothing else was dropped along the way. Everything else in the architecture follows from that one sentence.

Problem 1: a dozen formats, none of them documented the way they behave

Usage arrives from softswitches, session border controllers, packet gateways, application platforms and partners. Some of it is ASN.1 encoded binary. Some is fixed-width text a vendor described in a PDF from 2014. Some is JSON from your own API platform, which changes when a developer adds a field. Roaming settlement arrives as TAP files with their own specification and their own rejection procedure. A CPaaS provider gets event logs from message and voice APIs that look nothing like a call detail record and have to be rated like one.

The stated format and the actual behaviour diverge everywhere. A field documented as mandatory is empty on twelve percent of records from one node. A duration field is in seconds on one switch and milliseconds on another that runs the same software at a different release. A partner starts sending a new record type without telling anyone. Each of these is discovered in production, usually at month end.

What a custom build does: parsers are declarative and versioned per source, with a schema contract that is validated on every file rather than assumed. When a source deviates, the records go to suspense with the specific violation attached, and the pipeline keeps running for everything else. That last property is what separates a real mediation system from a script: a partial failure must never become a total one, and it must never silently become a success with missing data.

Problem 2: deduplication is not the same thing as removing duplicates

Every source retransmits. A switch buffers during a link failure and resends a file. A collection job runs twice because someone restarted it. A partner sends a corrected file that overlaps the original by two days. Naively deduplicating on a hash of the record works until you meet two genuinely distinct calls with identical fields, which happens more than intuition suggests on high-volume routes with short durations.

The correct approach uses the source's own unique identifier where one exists, plus a composite key where it does not, and it retains the dedup index for long enough to catch a late retransmission rather than for a convenient window. That retention is the expensive part, and it is exactly where cheap implementations cut, which is why they double-bill occasionally and cannot explain why.

What a custom build does: an explicit, persisted dedup index with a retention period you set based on how badly your worst source behaves, not on what is easy. Every rejected duplicate is logged with the reason and both record identifiers, so that when a customer says they were billed twice you can show them the record you suppressed and the one you kept. Correction files are handled as a first-class case with a defined supersede rule rather than as an operational emergency.

Problem 3: rating is where the money is decided, and the rules live in people

The tariff is never as simple as a rate table. Voice carries billing increments, and whether a route bills in one second or six second increments with a thirty second minimum changes the revenue on the same traffic materially. Jurisdiction matters, so the same call rates differently depending on origin and destination determination that has to be resolved against routing data. There are contracted floors, committed volume tiers with true-up, grandfathered plans that must never be touched, promotional rates with end dates that everyone forgot, and partner-specific rounding.

DigitalRoute MediationZone is the strongest dedicated product in this space and it handles enormous complexity, with the trade-off that configuration happens in its own toolkit, which means you either build vendor-specific expertise in house or you buy it perpetually. Oracle Communications Billing and Revenue Management is deeply capable and correspondingly heavy: an upgrade is a program with a plan and a steering committee. MATRIXX and Optiva are built for real-time converged charging, which is the right answer if you need online charging control for prepaid mobile and considerable overkill if you are a wholesale voice carrier rating files after the fact. JeraSoft is far more accessible and is aimed squarely at wholesale voice and VoIP, and it is a sensible answer at moderate complexity. Hansen and Comarch bring rating inside a broader BSS suite, which is attractive if you are replacing the suite and awkward if you are not.

What a custom build does: express the tariff as versioned data with effective dating on every element, so that any period can be rated or re-rated under the rules that were actually in force. Make the rating decision explainable: for each rated record, store which rate, which tier, which jurisdiction determination and which rule matched. That explanation field is the difference between a five minute dispute and a five week one, and it costs almost nothing if it is designed in from the start.

Problem 4: back-dated reprocessing, the requirement that defeats generic tooling

Here is the requirement that rules out most generic data platforms, and the reason people end up here in the first place. A partner rate was loaded incorrectly on the fourth. It is now the nineteenth. You need to re-rate everything between those dates for that partner, produce the delta against what was already invoiced, and issue an adjustment, without touching anything else and without losing the record of what was originally billed.

A pipeline that transforms and discards cannot do this. A warehouse that stores only rated output cannot do this. You need the raw records retained, the rating rules versioned, and the rating step re-runnable in isolation for a scoped selection, with the previous result preserved alongside the new one. Design that in at the start and it is straightforward. Retrofit it and you are rebuilding.

What a custom build does: raw retained immutably, rating as a pure function of raw plus a versioned rule set, and every rating run identified so that any output can be traced to the run and the rule version that produced it. Re-rating produces a new run rather than mutating the old one. Adjustments are computed as the difference between runs, which means the adjustment is auditable in both directions and your finance team can reconcile it without taking anyone's word for it.

Problem 5: the path from invoice line to raw record

A customer's controller emails your account manager: our invoice says eleven thousand dollars for international termination in March and we expected eight. Someone now has to answer that. In a healthy system it takes minutes: drill from the invoice line to the rated records, group by destination and route, compare to the prior period, and find the four days of traffic to a high-cost destination that the customer's own system generated.

In an unhealthy system it takes a week, involves a data engineer writing ad hoc queries against archived files, and ends with a credit issued because nobody could prove the charge. That credit is not the real cost. The real cost is that your commercial team learns not to argue, and after a year your dispute resolution posture is to concede.

What a custom build does: make traceability a product feature exposed to the people who need it, not a capability an engineer can theoretically exercise. Account managers get a drill path from any invoice line to the underlying detail with no SQL involved. The same path serves revenue assurance, settlement disputes and internal reconciliation. When we scope these builds, this is the feature we push hardest for in release one, because it is the one that changes behaviour across the commercial organisation rather than just in operations.

What this costs and how long it takes

A first release covering collection from your main sources, declarative parsing with suspense handling, persistent deduplication, and a rating engine with versioned effective-dated tariffs for your primary usage types runs $120,000 to $260,000 and ships in 16 to 24 weeks. A full platform adding enrichment against routing and customer data, back-dated re-rating with adjustment computation, settlement and partner outputs, roaming file handling where relevant, and the traceability interface for commercial users runs $350,000 to $900,000 phased across 10 to 20 months.

What drives cost up here: volume, but less than people expect, because the architectural jump happens at a threshold rather than continuously. Source diversity, which matters far more than volume, since every new format is a parser, a set of quirks and a discovery period. Real-time requirements, because online charging with credit control is a fundamentally different system from file-based mediation and should not be scoped as an extension of it. Roaming settlement, which brings its own specification and reject handling. And the number of distinct tariff constructs your commercial team has sold over the years, which is usually more than the commercial team believes.

What keeps cost down: rating one usage type completely rather than three partially. Voice or data or messaging, end to end, invoiced and reconciled, before adding the next.

Build versus buy, and where the products win outright

Buy JeraSoft if you are a wholesale voice or VoIP operator with conventional rating needs at moderate volume. It is built for exactly that and it will cost you a fraction of a build. Buy MATRIXX or Optiva if you need real-time online charging for prepaid subscribers, because that is a hard problem with genuine safety requirements and you should not build it. Buy or keep Oracle BRM if you already have it and it is working, since 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, not dissatisfaction with a screen.

Build when your rating logic is a commercial differentiator rather than a standard construct, which is common at CPaaS providers and at wholesale operators with unusual settlement arrangements. Build when back-dated reprocessing is a routine operational need rather than an exception, because that requirement shapes the architecture and bolting it onto a configured product is worse than designing for it. Build when your usage sources are so heterogeneous that the configuration effort in a product approaches the engineering effort of a purpose-built pipeline. And build when the vendor skillset requirement is itself the problem: if every tariff change requires a consultant, your commercial agility is now on someone else's calendar.

Our position: mediation and rating is one of the few areas in telecom where a custom build genuinely competes with mature products, precisely because the requirements are unforgiving in ways that are specific to each operator, and because the underlying engineering is well understood. It is also an area where a bad build is very expensive, so the choice of team matters more than in most categories.

How to choose a developer for a mediation and rating platform

Ask what happens when a source sends a file with a malformed trailer at two in the morning. The answer must include suspense, an alert, and continued processing of everything else. If the answer is that the job fails and gets rerun, you will spend your life doing manual recovery at month end.

Ask them to describe re-rating three weeks of one partner's traffic after a rate correction. If they propose updating rated records in place, stop. The correct answer preserves the original run, produces a new one, and computes the adjustment as the difference between them.

Ask how a non-technical account manager will trace an invoice line to raw records. If the answer requires an engineer, the feature does not exist in any way that matters to your business.

Ask about their dedup retention reasoning specifically. A developer who has done this will ask you how badly your worst source misbehaves before answering. One who names a window without asking has not been burned yet and will be, on your data.

Ask who owns the code, the repository and the infrastructure, and put it in the contract before kickoff. At Digital Heroes that is yours from the first commit. Then start by taking one month of real production traffic and rating it in parallel against your current system. The differences you find will define the scope better than any requirements workshop.