Billing mediation is one of those concepts that’s been standard in telecom for thirty years and almost entirely overlooked in SaaS – until usage-based billing forced the conversation. Now it’s one of the most consequential infrastructure decisions a usage-based SaaS company can make and most teams encounter it for the first time when something breaks.
Here’s the short version: billing mediation is the layer between your raw event sources and your rating engine. Its job is to collect usage data from wherever it lives, normalize it into a consistent format, validate it, deduplicate it and route it to the component that applies pricing rules. Without it, the rating engine receives whatever arrives: inconsistent, possibly duplicated, possibly incomplete.
Where Mediation Comes From
In telecom, mediation is a mature discipline with dedicated infrastructure. A carrier generating millions of Call Detail Records (CDRs) per hour from dozens of switches, routers and network elements needs a system to collect those records, normalize them into a billing-ready format and deliver them to the rating engine. CDR mediation vendors built entire businesses around this problem. The problem was well-understood.
When B2B SaaS companies started adopting usage-based pricing, they inherited the same problem in a different form. Instead of CDRs from network equipment, they have usage events from APIs, microservices, infrastructure logs and third-party platforms. The underlying challenge (collecting event data from disparate sources and making it billing-ready) is identical. Most SaaS companies either don’t recognize it by name or assume their billing platform handles it automatically.
Most billing platforms don’t handle it automatically. Or they handle the simplest case well and then fall apart at scale.
The pattern we see most often: a team implements a basic event pipeline, processes 10,000 events a day without issues and concludes the mediation problem is solved. Then they scale to 10 million events a day and find the deduplication logic was running in memory and doesn’t survive a service restart. Or they discover that retry-generated duplicate events have been producing overcharges for months. Or a field mapping error in one event source has been silently routing charges to the wrong customer account since launch. None of these are rare failure modes. They’re the standard outcomes of billing infrastructure that treats mediation as an afterthought rather than a first-class architectural concern.
What Billing Mediation Actually Does
Collection and Protocol Normalization
Usage events arrive in different formats from different sources. A REST API delivers JSON payloads. A legacy system drops flat files via SFTP. An infrastructure platform sends events over a message queue. IoT devices ping a webhook endpoint. The mediation layer must accept all of these, translate them into a consistent internal event schema and route them correctly regardless of origin.
This sounds straightforward. It isn’t. In practice, “accepts multiple protocols” in a vendor demo often means “has REST and maybe a file importer.” If you have telecom CDRs, IoT streams or legacy flat-file event sources, you want native support for those formats — not a custom integration that someone on your team maintains.
Schema Normalization
Even after handling protocol differences, raw events arrive with different field names, different timestamp formats and different customer identifier structures. Schema normalization transforms them all into a single internal format: customer ID, event timestamp, metric type, quantity and metadata. Bad normalization is where billing errors get baked in, because a normalized event that maps the wrong field to the customer ID will produce charges on the wrong account, and it will look correct until a customer dispute surfaces it.
Deduplication
Network retries produce duplicate events. Application restarts produce duplicate events. Integration bugs produce duplicate events. The mediation layer must identify and suppress duplicates before they reach the rating engine. The standard approach is idempotency key enforcement: every event carries a unique identifier, and the mediation layer maintains a log of processed identifiers. Any event with a previously seen key is discarded.
The failure mode is being too aggressive. An over-tuned deduplication system discards legitimate events that happen to share characteristics with a previous event, which produces under-billing that’s just as hard to detect as the over-billing from duplicates. The right balance is idempotency key enforcement on explicit IDs, not pattern-matching heuristics.
Validation
Before events reach the rating engine, they should be validated against expected schemas. Missing customer IDs, negative quantities, timestamps that are implausibly far in the past or future, metric types that don’t exist in the rate plan. All of these should be flagged and queued for review rather than silently discarded or silently processed.
The word “silently” is doing a lot of work there. A mediation system that silently discards invalid events is not better than no mediation. It’s worse, because it gives you false confidence that your event data is clean.
Routing and Delivery
Normalized, validated, deduplicated events are then routed to the appropriate rating engine component based on the metric type and customer configuration. The delivery must be guaranteed: events are stored durably before processing begins, so a system failure during rating doesn’t result in lost events that have already been acknowledged to the source.
Native Billing Mediation vs. Bolted-On Mediation
When you’re evaluating billing platforms, this is one of the most important questions to ask: is mediation native to the platform, or is it a separate product that was acquired or integrated later?
The difference matters for three reasons.
- Data model continuity. A native mediation layer shares the same data model as the rating engine. Event IDs, customer IDs and metric definitions are consistent across the entire pipeline. An acquired mediation tool has its own data model that must be translated. Translation is where data integrity breaks.
- Support accountability. When something goes wrong in a bolted-on system, you get a conversation between two vendors about whose component failed. With native mediation, there’s one vendor, one support contact and one throat to choke.
- Configurability. A native system allows you to configure mediation rules and rating rules in the same interface, with the same tooling and with immediate visibility into how a mediation configuration change affects downstream billing. A bolted-on system requires changes in two places, coordination between two systems and additional testing surface area.
When You Don’t Have Proper Mediation
If you’re billing on usage and you don’t have a proper mediation layer, or if your “mediation” is a custom integration someone on your engineering team built, here’s what you’re likely dealing with:
- Periodic billing discrepancies you attribute to “data quality issues” without a clear root cause
- Customer disputes you can’t fully resolve because you can’t trace the invoice back to source events
- Engineering time spent maintaining and debugging the custom integration instead of building product
- A hard ceiling on the volume of events you can process before the system starts dropping things
- No audit trail for late events, retroactive corrections or mid-period amendments
None of these are inevitable. They’re the predictable outcome of building on a billing stack that wasn’t designed for the volume and complexity of modern usage-based pricing.
What to Look for in a Mediation Evaluation
- Native vs. acquired billing mediation. Is it part of the core data model, or was it acquired and integrated later? Ask when the mediation capability was built and whether it shares a data model with the rating engine.
- Protocol support. List what you need: REST, webhooks, SFTP, CDRs, streaming. Ask specifically whether each is native or requires a third-party connector. “We support it” often means “we have a connector someone built once.”
- Deduplication specifics. Ask for the actual idempotency mechanism, not a general assurance. What’s the lookback window? What happens to an event that arrives 30 days after the original?
- Late event handling. How long after period close does the system accept events? Is retroactive rating automatic, or does it require manual intervention?
- Error handling. Invalid events should be queued for review, not silently dropped. “We filter out bad data” is not the same as “we surface bad data for resolution.” Those are opposite behaviors.
- Audit trail. Ask them to show you. Pull an invoice line and trace it back to the raw event, live, in the UI. If it requires a log export or a support ticket, it doesn’t count.
For the complete practitioner guide to metering and rating, see billingplatform.com/metering-and-rating.
See also: Event Deduplication in Billing | What Causes Revenue Leakage — and How to Stop It | Mediation Solution Overview
