Billing & Revenue Simulation Lab
Run a customer through product, order, fulfilment, install base, usage, mediation, rating, billing and payment; inject failures and find the leakage; then investigate fraud alerts and decide what to do.
Two simulations of the chain taught in 8.1–8.9. Each follows the same loop: learn the flow, understand each system's role, simulate a normal run, introduce a failure, investigate the evidence and understand the root cause — which system failed, which control should have caught it and what it cost.
Revenue Management & Assurance Simulation
Follow one customer — a 10 GB plan at €30 a month — from catalog and order to activation, usage, rating, billing and payment, then break a hand-off and see which reconciliation control catches it. All amounts are Illustrative — simulation assumption.
Revenue management & assurance simulation
Fictional customer · money beyond Alex’s invoice is illustrative
Order → activate
Usage leaves the network for mediation; the lifecycle update reaches billing by an integration pattern that varies.
Usage → cash
Transaction not started.
Three states
- Commercial · what was sold
- PENDING
- Service · what is live
- NOT ACTIVE
- Billing · what is charged
- NOT ACTIVE
Event log
- Waiting for the order…
Alex orders the 10 GB Mobile Plan
€30 a month, 10 GB included. Alex then uses 500 MB. Press Play to follow the order to activation and the usage to cash — and watch revenue assurance reconcile the chain.
Select any system for its role, where the Academy teaches it and the products that sell it.
Fraud Management Simulation
Follow suspicious activity through data collection, detection, risk scoring and automated controls, then investigate the alert and choose what to do.
Fraud management simulation
Fraud asks whether someone is deliberately abusing the service, account, network or payment system. Revenue assurance asks a different question — whether our own systems lost legitimate revenue.
An attacker moves the victim’s number to a SIM they control, then uses it to pass one-time-code checks elsewhere.
Detect
Decide
Respond
Twenty minutes after a SIM replacement, the same account sees a password reset, a login from a new device in an unfamiliar city and a high-value handset order on account credit. Each event alone is ordinary; together they are the classic takeover sequence.
Alert not yet raised.
Signals vs baseline
Signals appear when the detection engine evaluates the alert.
Investigate the alert
The alert pauses at Decision management. You take the decision.
Four Functions, Four Questions
Four functions, four questions
| Revenue Management | Revenue Assurance | Fraud Management | Dunning & Collections | |
|---|---|---|---|---|
| Objective | Create and collect revenue | Protect revenue integrity | Detect and prevent abuse | Collect billed revenue |
| Core question | What should we charge? | Did we capture what we should? | Is this activity legitimate? | Has what we billed been paid? |
| Main flow | Product → usage → charge → bill → payment | Reconcile the entire chain | Activity → detection → decision → action | Invoice → due → remind → restrict → collect |
| Primary risk | Incorrect charging or billing | Revenue leakage (and overcharging) | Fraud loss | Bad debt |
| Typical response | Charge, bill, collect | Investigate, reconcile, recover | Allow, challenge, restrict, block | Remind, restrict, suspend, collect |
Where Each System Is Taught
- Catalog, order, service and Install Base — 8.1 Overview
- Mediation — 8.2 Mediation
- Rating, charging and OCS — 8.3 Rating & Charging
- Billing subscriptions, proration and the bill run — 8.4 Subscription Billing
- One account, one invoice — 8.5 Convergent Billing
- Partners and settlement — 8.6 Interconnect & Roaming
- Reconciliation controls — 8.7 Revenue Assurance
- Detection, scoring and decisions — 8.8 Fraud Management
- Payment, dunning and collections — 8.9 Dunning & Collections