One list, every operating company.
The schema is easy and the data is the product. 5–10% of spend typically surfaces as unjustified services once an inventory exists.
Request a pilot
- What it does
- Holds every billed and delivered service in the group — MPLS ports, dedicated internet access, mobile plans, direct-dial number ranges — on one spine, with entity, currency, cost centre and circuit role as real columns rather than custom fields.
- What it reads
- Invoices first, then carrier portals, contracts, the CMDB, router configs and an engineer's memory, in that order of reliability. Every artifact is kept as raw bytes, forever.
- What stays yours
- Your identifiers, exactly as your carriers wrote them. They stay opaque, one service may carry as many aliases as the sources give it, and a human correction supersedes the earlier claim rather than erasing it.
- Where it shows up
- Every downstream number. A bill line joins to a service, a monitored interface binds to a service, and a finding names one. This is the spine the rest of the platform stands on.
Also inside this capability
Each row opens to what it does and where it stands.
Carrier confirmation
The carrier checks your inventory for you.
- What is sent
- What you hold for that carrier, as CSV or XLSX, by email.
- What comes back
- The carrier's answers, kept as evidence field by field. An answer sits beside the record and overwrites nothing.
- What it shows
- A confirmed share per carrier, so onboarding can see which carriers have checked their part of the estate.
- Status
- Built.
Import cleanup
Opt-in, per import, so the mess in a spreadsheet is handled in the import rather than by hand.
- Placeholder IDs
- Recognised as placeholders rather than read as identifiers.
- Several IDs in one cell
- Split into separate identifiers.
- Bandwidth pairs
- A value written as 100M/20M is read as its two figures.
- Your own role words
- The company's own words for circuit roles are mapped to primary, backup, DR and the rest.
- Status
- Built.
Who uses it
- The reader
- Regional IT, who own the services, and the implementation lead who runs onboarding. Group finance reads the result.
- The question
- What does each operating company actually run, and which of those services is still paid for?
- What they get
- One list with every field's source beside it, a review queue for every unresolved claim, and an undo for every import, so a mistake found in week six costs an hour rather than a weekend.
- Where it starts
- Three invoices from one operating company. The services on them are the first rows, and every later source is reconciled against those.
How it is built
Opaque identifiers
Circuit reference formats share no grammar across regions, so we store the raw value beside a normalised copy with case and separators stripped, and match on that. A service can carry as many aliases as the sources give it.
Two status axes
Operational status and billing status are separate fields. Keeping them apart is what makes a service that is disconnected and still billed representable at all. Every move is recorded with the actor, the source and the evidence.
Imports with an undo
Every import runs as a dry run first, reports per-row errors, and can be undone in one move back to the pre-batch state. A bad mapping found in week six is rolled back, not hand-cleaned.
Provenance as a row
Each asserted value is stored with its source, its confidence and a pointer into the artifact it came from. A CMDB that says 100M against an invoice that says 50M is a visible conflict, not a silent overwrite.
What you get
A service you can point at
Every service has one row, one set of identifiers as the carriers wrote them, and a completeness record that says which of its facts are still missing. Partial data renders behind a badge rather than as an empty screen.
Ghost circuits made visible
Operational status and billing status are separate columns, so a service that was ceased at the site and is still on the invoice is a row you can filter for, with the evidence on both sides attached.
Onboarding that compounds
Mappings, synonyms and ranked candidates are kept, so the second import of a format costs a fraction of the first. Month two is cheaper than month one, and the machinery that makes it so is part of the product.
How it works
- IngestInvoices, exports and contract documents land as immutable artifacts, deduplicated by content hash per operating company. Portals keep bills for a limited window, so we ingest early and retain indefinitely.
- MapA mapping is keyed to the fingerprint of the header row, together with the carrier and the entity, and holds its own transforms: trimming, Arabic-Indic digit folding, separator normalisation, date and currency handling.
- ReconcileAnything the mapping cannot settle opens a work item with ranked candidates, so the person doing onboarding picks rather than types. Every correction is an auditable diff.
- ScoreEach service carries a completeness record: role, contract, bandwidth, site, carrier account, identifier, monitoring binding, at least one invoice. Partial data renders a number behind a completeness badge instead of an empty state.
One service, end to end
A 100 Mbps MPLS port in one operating company, followed from the first invoice to the settled row.
- The invoice arrives
- A PDF from the carrier lands as raw bytes. Extraction reads a circuit reference, a site address and a recurring charge, each with a confidence and a pointer to its place on the page.
- The candidate
- The reference matches nothing on the spine exactly, so a candidate row opens in the review queue with the two closest existing services ranked beside it.
- The decision
- The implementation lead confirms it as a new service. The row records who decided, when, and which invoice the claim came from.
- The CMDB disagrees
- Three weeks later the CMDB import says 50 Mbps against the invoice's 100. Both claims stay on the row, the conflict is flagged, and the bandwidth capability settles it from what the port delivers.
- The settled row
- Entity, currency, cost centre, circuit role, contract and identifier are filled; the monitoring binding is pending. The completeness badge says so, and the service already counts in the group total.
Questions about the inventory
We already have a CMDB. Why another list?
The CMDB is one of the sources, and it is read rather than replaced. What it lacks is the invoice's view of the same service, and the join between the two is where a ceased service still being billed shows up.
How much of the inventory is built by hand?
Less each month. Invoices, portal exports and contracts are parsed, mappings are saved against the shape of the header row, and the review queue ranks candidates so a person picks rather than types. What stays manual is the decision, and each one is recorded.
What happens when a source is wrong?
The wrong claim stays on the row with its source, and a correction supersedes it rather than erasing it. An import that turns out to be wrong is undone in one move, back to the state before the batch.
Does the inventory cover mobile plans and number ranges?
Yes. Fixed services, mobile plans and direct-dial number ranges sit on the same spine with the same columns, and the mobile numbers themselves are stored hashed with only the last digits in the clear.
Related capabilities
