Hypothesis
Revenue found at month end is recovered; revenue found by the auditor a year later is a write-off with a footnote.
Desired result: Incremental revenue or retention; lower contact waste; improved conversion with margin guardrails

Revenue assurance, finance control and billing operations teams
Month end. Provisioning says a service is live. Charging says it was charged. The bill says something else, and each system is right about itself.
Verified work email required.
The product that runs it: Revenue, Risk and Assurance Explore the stream: Revenue Assurance & ReconciliationReconciles three synthetic ledgers end to end. Modelled exposure, never recovered revenue.
Seen by the customer · Finance workbench, English
From the record, not a run: what would reach them, on Finance workbench, in English.
What happened
Month end: the provisioning system says a service is live, the charging system says it was charged, and the bill says something else.
Month end. Provisioning says a service is live. Charging says it was charged. The bill says something else, and each system is right about itself.
What it reads
Checks before anything is sent
Source completeness, matching-key quality, known-difference suppression and ownership checks pass.
Every option considered, including doing nothing
No action is a valid outcome, and it is recorded with its reason. Nothing is computed on this page: the options are the record's own, and no run has decided anything.
The shape of the record, with no values. A reference appears only after a run is saved.
Hypothesis
Revenue found at month end is recovered; revenue found by the auditor a year later is a write-off with a footnote.
Desired result: Incremental revenue or retention; lower contact waste; improved conversion with margin guardrails
Modelled not observed
A run on the sample records shows the decision, the checks it passed and the receipt the responsible system would return. No incremental value is modelled on this page.
Ingest → qualify → score → apply limits/consent → assign control → execute approved action → capture delivery and business outcome → monitor/retrain
Observed
Nothing yet. Measurement begins in a pilot’s validate stage, on your systems, against a comparison agreed first.
Randomised holdout where feasible; intent-to-treat primary view; pre-declared denominator; guardrails for complaints, margin and opt-out
Measured on: Eligible population; treatment rate; conversion; incremental revenue; ARPU; churn; contact rate; margin; opt-out; decision latency
The result wanted.
Incremental revenue or retention; lower contact waste; improved conversion with margin guardrails
The mechanism that could produce it.
Ingest → qualify → score → apply limits/consent → assign control → execute approved action → capture delivery and business outcome → monitor/retrain
The records kept to show it.
Decision log; eligibility snapshot; price/order response; delivery receipt; control assignment; revenue/outcome ledger
The cost, and the ways it can go wrong.
Costs: Setup fee + annual product subscription; optional managed execution fee; optional verified-outcome fee with agreed baseline
If it fails: Fail closed on eligibility/consent/price; queue retryable events; do not duplicate orders; route exception to campaign operations
The measure that shows it helped.
Randomised holdout where feasible; intent-to-treat primary view; pre-declared denominator; guardrails for complaints, margin and opt-out
Measured on: Eligible population; treatment rate; conversion; incremental revenue; ARPU; churn; contact rate; margin; opt-out; decision latency
A saved run keeps the decision and its receipt: what was decided, which checks refused, and what the responsible system returned. It does not show incremental value. That needs the comparison above, over an agreed period, against a baseline finance has accepted.
The business side
| Step | What the customer experiences | What the operator does |
|---|---|---|
| The momentThe moment that started it. | Month end: the provisioning system says a service is live, the charging system says it was charged, and the bill says something else. | Reads extracts from provisioning, charging and billing, matching keys and their quality, known differences and their reasons, ownership by exception type. |
| The decisionThe decision to be made. | Nothing reaches the customer yet. | Reconciles expected against actual across the three ledgers, quantifies each difference as an exception and assigns it an owner. |
| The safeguardsThe conditions that stop it. | Still nothing. No action is sent until every check has passed. | Source completeness, matching-key quality, known-difference suppression and ownership checks pass. |
| The actionThe action that reaches the customer. | Route each exception to its owner for correction in the billing or charging system; suppress the known differences with their reason. Reaches them on Finance workbench, in English. | Recommends. The system that holds the right confirms, charges or provisions. |
| When it goes wrongRefusal, failure and recovery. | A matching key changed format in one system and half the month's records fall out as exceptions that are not real. | The matching-key quality check fails the run before the exceptions are assigned, the key mapping is corrected, and the re-run is compared with the first so the false exceptions are shown as such. |
| The resultThe change it made. | What changed for them is what is counted; nothing else is claimed. | Revenue recovered or prevented, against the exceptions written off. |
| The proofThe proof anyone can check. | Can be answered for, later, from the record. | Source extracts, matching rules, exception list with values, owner assignment, correction record and the revenue and outcome ledger. |
Operator systems remain authoritative. HeuriTel reads these to propose an action; it does not decide on their behalf.
What goes wrong
A matching key changed format in one system and half the month's records fall out as exceptions that are not real.
What happens then
The matching-key quality check fails the run before the exceptions are assigned, the key mapping is corrected, and the re-run is compared with the first so the false exceptions are shown as such.
Expected and actual records are reconciled across charging, billing, provisioning, entitlements, wallets, partners, roaming and interconnect; each exception is quantified, given an owner and closed with the value recovered or prevented on record.
the finance forecast that leakage distorts
the partner settlements reconciled on the same footing
The demonstration follows the same journey end to end: what the customer sees, what the operator decided, and the evidence behind it.