Modelled exposuremodelled amount
6,550 KESAcross 9 services, period 2026-08
Modelled by heuritel.ledger-reconciliation.engine v1 · rules RA-M1, RA-M2, RA-M3, RA-M4, RA-M5 · disconnected. Not recovered, not prevented, not realised.
Revenue, Risk and Assurance
Reconcile what was provisioned, charged and billed, classify every difference as an exception or a known difference, quantify the modelled exposure, and propose who should investigate first — never automatic financial action.
Runnable demonstrationintegrated workflow — The stages are joined by persistence, identity and authorisation inside the platform. This does not mean integrated with an operator system.
A journey you can run end to end on a synthetic dataset for your market, today.
Internal, simulated and disconnected. Exposure is modelled, never recovered; no correction, case or request has been sent to a billing, charging or finance system.
The journey runs on a synthetic three-ledger sample dataset — or on a generated sample for a visitor's market, or on a ledger workbook an operator returns. Every figure is labelled with the dataset it came from.
Run the Revenue Assurance demonstration Open the sample-data studioDownload the populated synthetic workbook
The demonstration needs a verified work email; the studio and the workbook need nothing. Demonstration ledgers; no billing, charging or finance system is connected.
The problem
Three ledgers that should agree, and do not
- Provisioningsays a service is live
- Chargingsays it was charged
- Billingsays what reached the bill
At month end each system is right about itself and they disagree with each other. A service charged and never billed is revenue earned and lost; one billed and never provisioned is a customer paying for nothing; a value that differs, or a charge raised twice, is a dispute waiting to happen. Some differences are known and accepted by finance already — and a known difference with no valid reason is an exception, not an explanation. The product reconciles the three, classifies every difference, values it, and proposes who should investigate first. It never corrects a bill.
What it computes
On the canonical synthetic sample, today
- Matched services4 of 9agree across provisioning, charging and billing
- Classified exceptions5Duplicate charge · Charged, not billed · Value mismatch · Billed, not provisioned
- Known differences1suppressed with a valid reason, 300 KES counted apart
- Modelled exposure6,550 KESCharged, not billed 3,700 KES · Billed, not provisioned 1,200 KES · Value mismatch 450 KES · Duplicate charge 1,200 KES · Known difference (suppressed) 300 KES
- Proposed ownerBilling operationsinvestigate first; a proposal to a person, never an action
- Source evidence12 rowsledger id and record key behind every exception
Sample dataset RA-SYNTH-EA v1, period 2026-08, KES. Modelled exposure is modelled: nothing has been recovered, prevented or realised.
Explained by known differencesexplained amount
300 KESAcross 1 of 6 differences, period 2026-08
Counted apart from exposure; a suppression with no reason or past its date counts for nothing.
Exceptions standingexceptions
5Across 9 services, period 2026-08
2 charged, not billed · 1 billed, not provisioned · 1 value mismatch · 1 duplicate charge.
Matched across all three ledgersof services
44%Matched 4 of 9 services, period 2026-08
1 matched with a timing note; 0 checks refused.
| Category | Count |
|---|---|
| Charged, not billed | 2 |
| Billed, not provisioned | 1 |
| Value mismatch | 1 |
| Duplicate charge | 1 |
| Known difference (suppressed) | 1 |
| Category | KES |
|---|---|
| Charged, not billed | 3,700 KES |
| Billed, not provisioned | 1,200 KES |
| Value mismatch | 450 KES |
| Duplicate charge | 1,200 KES |
| Category | Services |
|---|---|
| Matched across all three | 4 |
| Exception standing | 5 |
| Explained and suppressed | 1 |
| Category | Exceptions |
|---|---|
| Known difference applied | 1 |
| Known difference refused | 2 |
| No known difference | 3 |
Recommendation · investigate
Investigate first: charged, not billed
Proposed owner Billing operations
5 exceptions stand, worth 6550 KES of modelled exposure, led by unbilled charge on SVC-1008 (2500). Proposed first owner: Billing operations. Modelled, not recovered.
- 1EX-005 · SVC-1008 · Charged, not billed · 2,500 KES · rule RA-M1
- 2EX-001 · SVC-1005 · Duplicate charge · 1,200 KES · rule RA-M5
- 3EX-002 · SVC-1002 · Charged, not billed · 1,200 KES · rule RA-M1
- 4EX-006 · SVC-1009 · Billed, not provisioned · 1,200 KES · rule RA-M2
- 5EX-003 · SVC-1004 · Value mismatch · 450 KES · rule RA-M3
A proposal for a person to take up. Nothing here raises a case, corrects a bill or calls a system; approval below records a decision about the proposal and changes no ledger.
Not implemented
Outside this product's contract
- Live connectors No billing, charging or provisioning system is read; provenance.connection is always disconnected.
- value.recovered Revenue recovered or prevented as a result of the exceptions found.
- execution.request A request to a billing or charging system to correct what the exceptions found.
- execution.receipt A receipt from a billing or finance system confirming a correction or a case.
- outcome.observed Revenue actually recovered, prevented or written off after investigation.
- attribution Attribution of a recovery to this run's exceptions.
- reconciliation Completion of the reconciliation against the operator's own ledgers — corrections made and the difference closed.
Technical detail
Inputs, decision logic, systems touched, records kept
What do the three ledgers carry?
The canonical sample dataset RA-SYNTH-EA v1
- 9 services across provisioning, charging and billing, period 2026-08
- Amounts in KES, whole units; the sample's own currency, not a market's
- Known differences carried as their own sheet, each with a reason code and a validity date
Workbook
- Schema heuritel.ledger-reconciliation.dataset v1 · template v1
- Provisioning, charging, billing and known-differences sheets carry data; the manifest, guide, dictionary, scenario and expected-outputs sheets do not
- A public copy is issued to the public sample tenant and is refused by the private review; an organisation's workbook is refused by the public one
Synthetic, authored by HeuriTel. A generated sample for a visitor's market prices from that market's researched packs and converts nothing.
How is a difference classified, and when is one suppressed?
Matching rules and suppression policy, version 1
- RA-M1 · Provisioned and charged, absent from billing: A service with a provisioning row and a charge, and no billing line, is an unbilled charge worth the charged amount.
- RA-M2 · Billed without provisioning: A billing line whose service has no provisioning row is unprovisioned billing worth the billed amount.
- RA-M3 · Value mismatch: A charge and a billing line for the same service whose amounts differ by more than the value tolerance are a value mismatch worth the difference.
- RA-M4 · Timing: A billing line later than the timing window after its charge is noted beside the match. It is not an exception on its own.
- RA-M5 · Duplicate charge: Two charges for one service, product and date are a duplicate worth the repeated amount.
- RA-S1 · Suppression: A known difference suppresses an exception only when it names the service, carries a non-blank reason, and its until date is on or after the evaluation date.
- RA-S2 · Suppression: A suppressed exception is still listed, with its reason, and its amount is reported apart from the modelled exposure. Nothing disappears.
Checks, with the result on the sample dataset
- Source completeness — pass. All three ledgers carry rows for 2026-08: 8 provisioned, 9 charged, 6 billed.
- Matching-key quality — pass. Every row carries a service key.
- Known-difference suppression — pass. 2 known differences did not apply — no reason, or past its date — and the exceptions stand.
- Ownership — pass. Every standing exception maps to an owner: Charging platform owner, Billing operations, Rating and tariff owner, Provisioning operations.
Scenario profile heuritel.ledger-reconciliation.scenario v1: the tolerances and the timing window the run was decided under. Deterministic: the same ledgers give the same exceptions.
What would an operator connect, and what is connected today?
Sources a pilot would extract
- Provisioning: the services that are live
- Charging: the charges raised against them
- Billing: the invoice lines that reached a bill
- Known differences: the reasons finance already accepts
Connected today
- None. provenance.connection is written as disconnected on every run; every run computes from the synthetic sample dataset, a generated sample or a returned workbook.
Not implemented
- Live connectors — No billing, charging or provisioning system is read; provenance.connection is always disconnected.
- value.recovered — Revenue recovered or prevented as a result of the exceptions found.
- execution.request — A request to a billing or charging system to correct what the exceptions found.
- execution.receipt — A receipt from a billing or finance system confirming a correction or a case.
- outcome.observed — Revenue actually recovered, prevented or written off after investigation.
- attribution — Attribution of a recovery to this run's exceptions.
- reconciliation — Completion of the reconciliation against the operator's own ledgers — corrections made and the difference closed.
Internal, simulated and disconnected. Nothing has been sent to or executed in an operator system. Where the contract uses its own engineering term for the synthetic sample dataset, it is shown here as “sample dataset”, and the key that names it as provenance.sampleDatasetId.
What does a run record, and what does it not?
Computed on every run
- recommendation.owner — The investigation owner proposed for the exceptions found, by role. A proposal to a person.
- recommendation.kind — investigate, or no-action when every difference is matched or explained. No action is a complete answer.
- recommendation.explanation — Why, in the rules' own words. Deterministic rule reasoning, not a model's.
- exceptions[].classification — Each difference the rules found, classified: unbilled_charge, unprovisioned_billing, value_mismatch, duplicate_charge, or suppressed_known_difference.
- exceptions[].matchQuality — How the records were matched: exact, tolerance, or unmatched — the rule's own confidence, stated as its method.
- exceptions[].evidence — The source rows behind each exception: ledger id and record key for every record it was built from.
- exceptions[].suppression — Where a known difference explained the exception: the reason code, the reason, and the row that carried it. Absent otherwise.
- checks[].state — Source completeness, key quality, suppression validity and ownership: pass or refuse, for this pack.
- checks[].detail — Why the check passed or refused, for this pack. Deterministic rule reasoning.
- exposure.modelled — The sum of the unbilled, mismatched and duplicated amounts across the standing exceptions, in the market currency's whole units.
- exposure.suppressed — The amount carried by exceptions a valid known difference explained. Reported apart so a suppression cannot quietly lower the exposure.
- exposure.byClassification — The modelled exposure split by exception class.
- provenance.matchingRulesVersion — The version of the matching rules and suppression policy the run applied, carried as the engine version.
- provenance.scenarioProfileId — The reconciliation policy — tolerances and timing window — the run was decided under, and its version.
- provenance.configurationHash — A digest of the effective tolerance values the run was decided under.
- provenance.sampleDatasetId — The synthetic ledger sample dataset the run was composed against, and its version.
- provenance.connection — Always "disconnected". No billing, charging or finance system is connected.
- run.reference — A short reference a person can quote for this run.
- dataset.contentHash — SHA-256 of the normalised ledgers the run computed from.
Persisted with the run
- run.executionMode — Always "simulated".
- approval.state — proposed until an authorised second person decides; then approved, rejected or revision_requested.
- approval.actorRole — The role that carried the authority at the moment of the decision.
- approval.reason — The decider's own words, never interpreted.
Not implemented
- value.recovered — Revenue recovered or prevented as a result of the exceptions found.
- execution.request — A request to a billing or charging system to correct what the exceptions found.
- execution.receipt — A receipt from a billing or finance system confirming a correction or a case.
- outcome.observed — Revenue actually recovered, prevented or written off after investigation.
- attribution — Attribution of a recovery to this run's exceptions.
- reconciliation — Completion of the reconciliation against the operator's own ledgers — corrections made and the difference closed.
The output contract is the seventh workbook role; a contract cannot claim a recovery or an observed outcome by editing a row. Where the contract uses its own engineering term for the synthetic sample dataset, it is shown here as “sample dataset”, and the key that names it as provenance.sampleDatasetId.
Delivery
Four steps, and what is true of each one today
01 Scope
- Demonstrated now
- Three ledgers, five matching rules and a suppression policy, versioned; a scenario profile with tolerances and a timing window.
- Configured during a pilot
- The operator's own tolerances, timing window and known-difference reasons agreed and versioned.
- Required for production
- A scope with an accountable revenue-assurance owner.
02 Connect
- Demonstrated now
- A workbook: the populated sample downloads, an edited copy is validated, accepted as a version and run. No system is read.
- Configured during a pilot
- Indicative extracts of the three ledgers for a period, through the same validation.
- Required for production
- Live connectors. Not built.
03 Validate
- Demonstrated now
- Source completeness, key quality, suppression validity and ownership, on every pack; a run replays from its snapshot.
- Configured during a pilot
- The operator's completeness and key-quality thresholds, enforced the same way.
- Required for production
- Reconciliation completed against the operator's own ledgers. Not built.
04 Operate
- Demonstrated now
- A proposed owner and a recommendation, decided by a second person on the journey; the ledgers unchanged by it.
- Configured during a pilot
- Exceptions reviewed against the operator's policy; still nothing corrected.
- Required for production
- Correction requests, finance cases, recovered value, observed outcome, attribution. Not implemented, by contract.
Who it is for
Buyer and operator
- Buyer
- CFO, Revenue Assurance Director and Risk / Fraud Director
- Operated by
- Revenue assurance, finance and fraud analysts
Intended outcomes
The result this product produces
- Every difference between the three ledgers classified, valued and traced to the source rows it was built from
- Known differences suppressed only with a valid reason, and reported apart so a suppression cannot lower the exposure quietly
- A proposed investigation owner and a recommendation a second person decides, with the ledgers unchanged by the decision
Evidence
Built today
- Three ledgers are reconciled by versioned matching rules and a suppression policy, deterministically.
app/_lib/demo/reconciliation.ts - A second registered product contract, with its own schema, scenario profile and output contract.
app/_lib/contracts/revenue-risk-and-assurance-outputs.ts - A returned ledger workbook is validated, accepted as an immutable version, and a run is stored from it.
app/_lib/demo/ledger-pack.ts - A public synthetic sample can be downloaded, edited and reviewed without a session, and nothing is kept.
app/_lib/demo/sample-endpoint.ts - The journey: overview, charts, exception workbench, drill-down to source rows, and the decision on a saved run.
app/_components/demo/ReconciliationJourney.tsx - The Revenue Assurance and Anomaly Operations offer runs end to end on /operator/trust/reconciliation: its workbook is registered with schema heuritel.ledger-reconciliation.dataset v1 and engine v1.
app/_lib/demo/reconciliation.ts
Not built
Still to build
- Live connectors: no billing, charging or provisioning system is read; every run computes from a synthetic sample, a generated sample or a returned workbook
- Billing correction and finance-case creation: the recommendation proposes; nothing is requested of or received from an operator system
- Recovered value, observed outcomes and attribution: exposure is modelled, and no recovery is recorded against a run
Where it is sold
Propositions that include this product
- Operator-branded Consumer AI PacksSell subscribers an AI allowance the way you sell a data bundle — your brand, your currency, your payment methods, your safety policy.
- OTT, Content, Sports and Gaming BundlesSell partner content as operator bundles, with rights, entitlement, cancellation and partner margin handled.
- Customer-care AI Resolution AssistantResolve more contacts at first touch, with the agent in control and every action evidenced.
- Revenue Assurance and Anomaly OperationsFind revenue leaking between systems, and evidence the recovery.
- Network Intelligence and Open Gateway ServicesTurn network capability into services enterprises can buy, with operator policy and commercial control intact.
Catalogue
Streams beneath this product
Workspace
The workspace for this product
One workspace screen belongs to this product. It opens for a member of an organisation whose subscription includes it.
Provenance
Sources of this description
PRODUCT_06_REVENUE_RISK_AND_ASSURANCE.md§1 Paid product proposition, §6 Reconciliation rulesapp/_lib/contracts/revenue-risk-and-assurance-outputs.ts— the output contract that names what is computed, persisted and not implemented