Find revenue leaking between systems, and evidence the recovery.
Revenue leaks between charging, rating, provisioning and settlement, and is found late or never.
Demonstration availableLevel 2 of 5 — A journey runs end to end on sample data, including its refusal and failure states. Bought by Finance and Revenue Assurance. Nothing here has run against an operator system.
Open the demonstrationTwo colleagues reviewing records. The ledgers here are the sample's; nothing has been reconciled against an operator's systems.
Public nowAnyone can do this from this page, without signing in, and the page keeps no record of it. This page, its sample workbook and the sample's review need no sign-in; the steps below say which need more.
44 of 60 services agree across the three ledgers; 13 exceptions stand, worth 5,860 KES of modelled exposure.
HeuriTel default synthetic sample — Kenya, in KES, Kiswahili; sample RA-SAMPLE v1. Three generated ledgers (seed heuritel-1, scale ×1) in KES; invented rows, not an operator's. Configure a market to see the same ledgers recomputed for it. Configure a market and this page, the workbook and the review recompute for it.
investigate, owned by Charging platform owner. If nobody acts: The exceptions stay open and the modelled exposure is neither confirmed nor recovered; Finance has confirmed nothing. Work the ledgers in the studio.
10 steps: 4 public now, 3 in an entitled workspace, 1 a request form, 1 needing an authorised sandbox, 1 not implemented.
Each step says who can take it today. A route existing is not the same as an action being available: the state beside each step is decided by the same rules that refuse a request.
- 01 · What you can buyPublic nowFind revenue leaking between systems, and evidence the recovery.All ten offers
- 02 · A working demonstrationPublic nowThe offer's journey on sample data.Open the demonstration
- 03 · The sample, as a workbookPublic nowthree ledgers and the known differences, with a manifest and the guide — downloadable without signing in, in the sample's market and currency.Download the sample workbook
- 04 · Validation, on the samplePublic nowthree ledgers and the known differences: every row carries a service key, every amount is whole units of the market currency, every known difference names a reason and a date, the manifest binds the pack to this organisation and market. The public review checks a returned workbook against the sample it was issued from, answers with the result before and after, and stores nothing.
POST /api/sample/three-ledgers-reconciliation/review - 05 · Acceptance and the stored simulationEntitled workspaceYour organisation's own workbook, reviewed, accepted as an immutable version with its original retained, and the engine's result stored whole — never recomputed on reopening.Open the workbench
- 06 · Decision and approvalEntitled workspaceA second person decides the recommendation; the maker cannot. Approval applies to a simulated recommendation.The approvals queue
- 07 · EvidenceEntitled workspacereconciliation with exceptions and owners; maker-checker decision; evidence record with fingerprint and rules applied; register export and retained original. The register export, the retained original, the run history, the dry-run plan and the pilot package are downloadable from the workbench.Evidence on the workbench
- 08 · A controlled pilotPilot request availableThe request form is available here; the pilot is scoped in writing before anything runs on your systems: a reconciliation run against two real operator sources with Finance confirming at least one finding. No pilot has been requested or agreed, and none is demonstrated.Request a controlled pilot
- 09 · Execution against your sandboxRequires an authorised sandboxThe dry-run plan names every connector call an approved decision would make across provisioning, charging, billing, general ledger; nothing is called and no receipt exists, because no authorised sandbox is registered.
- 10 · Live operationNot implementedUnder a separate production authorisation, with outcomes reconciled against your own records: recovered value confirmed by Finance; exceptions closed in the operator's own systems. Not built; no connector exists.
- Public now
- Anyone can do this from this page, without signing in, and the page keeps no record of it.
- Available after sign-in
- A verified sign-in sees it on sample data; it reads nothing private and stores nothing.
- Entitled workspace
- A member of an organisation that holds the owning product and has the journey configured; the role decides which actions.
- Pilot request available
- The request form is available. A pilot is scoped in writing afterwards; the pilot itself is not demonstrated.
- Requires an authorised sandbox
- Needs an authorised operator sandbox, which no organisation has registered. The permission that would reach one is refused to everyone.
- Requires production authorisation
- Needs a production authorisation from the operator and a connected operator system. No such authorisation exists.
- Not implemented
- No code performs this.
The contract, the data, the pilot and the products beneath.
Four things a technical or commercial evaluation asks for, each in the same terms as the other nine offers.
The offer in twelve lines
The offer in the same terms as the other nine.
Read from the offer contract and the engine's own run; the same twelve fields on every offer page.
- Commercial offer
- Revenue Assurance and Anomaly Operations
- Buyer
- Finance and Revenue Assurance
- Problem
- Revenue leaks between charging, rating, provisioning and settlement, and is found late or never.
- Outcome a pilot would count
- Leakage identified and confirmed by Finance.
- Current availability
- Demonstration available — level 2 of 5: A journey runs end to end on sample data, including its refusal and failure states. Of 10 steps, 4 are public now, 3 need an entitled workspace, 2 need what does not exist yet. Public now Entitled workspace Not implemented
- Public sample
- HeuriTel default synthetic sample: Kenya, in KES and Kiswahili (sample RA-SAMPLE v1). Download the workbook. Three generated ledgers (seed heuritel-1, scale ×1) in KES; invented rows, not an operator's. Configure a market to see the same ledgers recomputed for it.
- Data requirements
- Provisioning, charging and billing ledgers and the known differences. three ledgers and the known differences: every row carries a service key, every amount is whole units of the market currency, every known difference names a reason and a date, the manifest binds the pack to this organisation and market. Service keys are your own references; no subscriber identifier is accepted.
- Executable result
- Engine ledger-reconciliation v1, on the public sample: 44 of 60 services agree across the three ledgers; 13 exceptions stand, worth 5,860 KES of modelled exposure. 5 measures with their basis, 3 sections, 13 exceptions with owners. Recommendation: investigate, owned by Charging platform owner. If nobody acts: The exceptions stay open and the modelled exposure is neither confirmed nor recovered; Finance has confirmed nothing. Simulated; nothing ran against an operator system.
- Approval model
- Maker-checker: the person who accepted the data or requested the run cannot decide its recommendation; a client administrator does. Approval applies to a simulated recommendation.
- Evidence
- reconciliation with exceptions and owners; maker-checker decision; evidence record with fingerprint and rules applied; register export and retained original; the retained original with its inspection verdict; the run history; the per-record dry-run plan; the pilot package.
- Pilot requirements
- a reconciliation run against two real operator sources with Finance confirming at least one finding. None is evidenced; no pilot is requested or agreed.
- Live requirements
- Connected under a separate authorisation: provisioning, charging, billing, general ledger — none connected; reconciled before any outcome is claimed: recovered value confirmed by Finance; exceptions closed in the operator's own systems. Not built.
Beneath the offer: Revenue, Risk and Assurance, Customer Intelligence, Excel-to-Simulation Product Studio, AI Assurance, Governance and Handover, Revenue Assurance & Reconciliation.
Your data — three ledgers and the known differences, checked before anything is read
Three ledgers and the known differences, checked before anything is read from them.
three ledgers and the known differences: every row carries a service key, every amount is whole units of the market currency, every known difference names a reason and a date, the manifest binds the pack to this organisation and market. A subject column holds your own pseudonymous reference; a phone number, IMSI, IMEI or account number in it is refused and never echoed back.
A pilot’s measure and prerequisites — 5 things that would have to be true
Leakage identified and confirmed by Finance.
Nothing is counted until it is reconciled against your own records: recovered value confirmed by Finance; exceptions closed in the operator's own systems.
- a reconciliation run against two real operator sources with Finance confirming at least one finding
- Connected under authorisation: provisioning. Not connected today.
- Connected under authorisation: charging. Not connected today.
- Connected under authorisation: billing. Not connected today.
- Connected under authorisation: general ledger. Not connected today.
Built on 4 governed products and 2 catalogue streams
4 governed products and 2 catalogue streams.
The offer is a commercial view onto the same platform every other offer runs on. Its workbench opens with Revenue, Risk and Assurance.
- Customer IntelligenceCanonical product 1.
- Revenue, Risk and AssuranceCanonical product 6 — the entitlement that opens the workbench.
- Excel-to-Simulation Product StudioCanonical product 11.
- AI Assurance, Governance and HandoverCanonical product 15.
- Revenue Assurance & ReconciliationCatalogue stream.
- Fraud, Identity & Customer ProtectionCatalogue stream.