Modelled exposure
6,550 KESmodelled amount
Across 9 services, period 2026-08
Modelled by heuritel.ledger-reconciliation.engine v1 · rules RA-M1, RA-M2, RA-M3, RA-M4, RA-M5 · on the sample. 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, with every financial action a person's.
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 sample of your market, today.
Runs on the sample; exposure is modelled, and recovery is the finance team's, in a pilot, through the billing, charging or finance system that owns it.
The journey runs on a 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.
- Buyer
- CFO, Revenue Assurance Director and Risk / Fraud Director
- Operated by
- Revenue assurance, finance and fraud analysts
Run the Revenue Assurance demonstration Open the sample-data studio Download the populated sample 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 left unbilled is revenue earned and lost; one billed and left unprovisioned 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; correcting a bill stays with finance.
What it computes
On the 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
- Source evidence12 rowsledger id and record key behind every exception
Sample dataset RA-SYNTH-EA v1, period 2026-08, KES. Exposure is modelled; recovery is finance’s, in a pilot.
The exceptions by category, and the recommendation
Explained by known differences
300 KESexplained amount
Across 1 of 6 differences, period 2026-08
Counted apart from exposure; a suppression with no reason or past its date counts for nothing.
Exceptions standing
5exceptions
Across 9 services, period 2026-08
2 charged, not billed · 1 billed, not provisioned · 1 value mismatch · 1 duplicate charge.
Matched across all three ledgers
44%of services
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 |
| Standing, unexplained | 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. Approval below records a decision about the proposal; the case, the bill correction and the system call are finance’s, in a pilot.
Not implemented
Outside this product's contract
- Live connectors The billing, charging and provisioning systems are read in a pilot; every run computes from the sample.
- 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
The four questions, field by field
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
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; every amount stays visible.
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
- Every run computes from the sample dataset, a generated sample or a returned workbook, and is written with its connection state.
Not implemented
- Live connectors — The billing, charging and provisioning systems are read in a pilot; every run computes from the sample.
- 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.
Runs on the sample; an operator system is connected in a pilot, under the operator's authorisation. Where the contract uses its own engineering term for the 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 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
The four steps, in three states each
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; the workbook is the source.
- Configured during a pilot
- Indicative extracts of the three ledgers for a period, through the same validation.
- Required for production
- Live connectors, agreed and connected in the pilot.
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.
The result, the evidence, the gaps and the sources
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 - The public sample can be downloaded, edited and reviewed without a session, and the review keeps nothing.
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: the billing, charging and provisioning systems are read in a pilot; every run computes from the 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
Sold, catalogued, opened
The propositions, the streams and the workspace
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.
Streams beneath this product
- Revenue Assurance & Reconciliation
- Fraud, Identity & Customer Protection
- Mobile Money, Credit & Financial Services
- Operations, Finance & Back Office
The workspace for this product
One workspace screen belongs to this product. It opens for a member of an organisation whose subscription includes it.
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
Next steps