The category stopped at showback
A cost dashboard tells you what happened. If your job is to bill customers, the deliverable is the document — and it has to withstand scrutiny.
The source nobody has a connector for
What you bill for includes a private cloud, a bespoke managed service, a licence pool and telemetry from a platform you built yourself. A connector catalogue covers the vendors on its list and nothing else, so that revenue is estimated, absorbed, or left off the bill.
The rate card the tool cannot express
Graduated bands. A minimum commitment with overage above it. An uplift on one region and not the others. A credit agreed in March. Most tools model a rate per unit and stop there, so everything else becomes a manual spreadsheet process in every billing cycle.
The hierarchy with a margin at every level
Distributor to reseller to end customer: one measurement rated three times, each level seeing its own commercial reality and none of the others. A tool built for one vendor and one account never has to model settlement between levels, so it does not.
All three are routine for anyone who invoices for infrastructure.
Mediation: the part between the usage and the bill
Mediation is the step that turns whatever a system happens to record into a billable record — collected, normalised, deduplicated, correlated to a customer and aggregated to the grain you charge at. It is the reason a source you have never seen before is a configuration task rather than a roadmap item.
If a person can retrieve the data, Exivity Core can retrieve it repeatedly without them.
This is a general-purpose ingestion and transformation engine, not a catalogue of pre-built connectors with a request form attached. A REST endpoint, a database, a CSV drop, an object store, a vendor portal with an export button: nothing is left off a customer’s bill for lack of a connector, and nothing waits on vendor development.
- Any HTTP or REST API
- Authenticated with Basic, OAuth2, JWT, or the native credentials of AWS, Google Cloud and Azure.
- Databases, queried directly
- PostgreSQL, MySQL, MariaDB, SQL Server and Oracle.
- Object storage
- Amazon S3, Google Cloud Storage and Azure Blob Storage, including scheduled drops.
- Document formats
- JSON, JSON Lines, XML, CSV and Parquet, whatever shape the source emits them in.
- On a schedule you set
- Cron expressions with IANA timezones, so a collection runs when the source is ready, in the source’s own time.
What happens to a record once it is in
- Normalise
- Units, timestamps and identifiers put into one shape, so bytes from one system and gigabytes from another become the same quantity.
- Deduplicate
- Overlapping collection windows and re-runs resolve to one record per event, not two.
- Correlate
- A virtual machine, a namespace, a licence seat and a subscription identifier resolved to the customer who should be charged for them.
- Aggregate
- Summed to the grain you bill at: per customer, per service, per day, closed into a period.
Collection is scheduled rather than streamed, by design. A billing period is a closed set of records, and closing it is the whole point.
One usage record, all the way to an invoice-ready charge
Everyone in this market will show you a chart. Here are the rated lines at the end of the month — ten of them, off hybrid infrastructure — and the full trail behind one. Whether these lines are sent as the bill or handed to the system that issues it, they are the same lines.
- Number
- 2026-08-114
- Period
- 1–31 August 2026
- Currency
- EUR
| Description | Quantity | Unit | Rate | Amount |
|---|---|---|---|---|
| 1Virtual compute — vCPUVMware, production clusters | 42,048 | vCPU-hours | €0.0180 | €756.86 |
| 2Virtual memory — vRAMVMware, production clusters | 161,220 | GB-hours | €0.0320 | €5,159.04 |
| ↳Managed service uplift on line 2Rate card rule: percentage uplift, managed tier | — | — | 4.0% | €206.36 |
| ↳Service credit on line 2SLA breach, agreed 3 August | — | — | — | −€180.00 |
| 5Block storage, performance tierStorage array, provisioned capacity | 24,600 | GB-months | €0.0900 | €2,214.00 |
| 6SQL Server licences, per coreLicence pool, active cores in period | 24 | cores | €58.0000 | €1,392.00 |
| 7Azure consumption, resold at costPass-through of the metered Azure bill | — | — | At cost | €3,120.75 |
| ↳Resale margin on line 7Rate card rule: percentage markup, cloud resale | — | — | 12.0% | €374.49 |
| 9Kubernetes, shared platform namespacesAllocated by namespace label to this customer | 18,600 | vCPU-hours | €0.0240 | €446.40 |
| 10Platform feeFixed monthly charge, not driven by consumption | — | — | — | €1,250.00 |
| Subtotal | €14,739.90 | |||
| VAT, 21% | €3,095.38 | |||
| Total due | €17,835.28 | |||
How line 2 was produced
Six stages, each one naming the rule that did the work. When a customer queries this line, this is the answer — not a reconstruction of it.
- CollectedTwo vCenter instances polled hourly for the memory configured to each virtual machine, for all 31 days of the period.source: vcenter-prod-a, vcenter-prod-b · hourly
- MediatedSamples normalised to GB-hours, overlapping windows deduplicated, and each machine resolved to a customer by folder and tag.transform: vram-to-gb-hours · dedupe key: vm.uuid + timestamp
- Aggregated to a billable grainOne quantity per customer, per service, per day, summed across the period: 161,220 GB-hours.grain: customer × service × day
- RatedThe tariff selects a bracket by the customer’s total volume. 161,220 falls in the third bracket, so the whole volume is charged at €0.0320.rate card: northwind-2026 · first-match bracket 3 of 4 (120,000–200,000 GB-hours) · effective 1 Jan 2026
- Charged161,220 GB-hours × €0.0320 = €5,159.04, written as invoice line 2.charge record: 2026-08 · NWR · svc.vmware.vram
- AdjustedThe managed-service uplift and the agreed SLA credit attach to the line rather than disappearing into the total, so both are visible on the document.lines 3 and 4 · both reference line 2
Illustrative figures throughout. Names, rates and volumes are examples, not a price list. The formal invoice document, including tax handling, is typically issued by your billing or ERP system from these rated lines.
Six systems, one document
The hypervisor, the storage array, the licence pool, the Azure bill, the Kubernetes cluster and the contract. None of them has ever spoken to the others.
Every line carries its trail
Line 2 is shown because something has to be. The same six stages exist behind every other line, and behind every line of every period already billed.
A closed period stays closed
Once billed, the figures do not change. A re-run of August returns August, at the rate card that was in force in August.
Invoice-ready, and what comes out of it
Invoice-ready means charges you can put in front of someone who will pay them, and defend line by line when they are queried.
Every charge traces to the quantity that was measured, the rate that applied, and the contract rule that selected that rate. The period closes, and a closed period does not change after it is billed.
Plenty of tools produce a report of what cloud resources cost. A report is an opinion about the past; an invoice is a commercial instrument, and the difference shows up the first time a customer disagrees with one.
Billing runs and invoice-ready charges
A closed period, per customer, per service, at the rates their contract says. Ready to send onward, or to hand to the system that issues the invoice.
ERP and finance export
Rated charge records exported to the general ledger, so revenue lands in accounting the way finance already books it.
Per-customer breakdowns
The same figures split the way the customer thinks about them: by department, by project, by environment, by service.
Summary billing for chargeback
Internal recipients get the same rated output without an external invoice attached to it.
What it costs you and what you charge are two different numbers
Most cost tools hold one figure and call it cost. Anything that produces an invoice needs two — a cost object and a price object, carried by the same measured quantity — because the distance between them is your margin.
| The same measured quantity, two objects | Cost object | Price object |
|---|---|---|
| What it represents | What the infrastructure costs you to run | What this customer has agreed to pay |
| Where the figure comes from | Depreciation, support contracts, facilities and power, licences, operational effort | A rate card: a rate, the bracket that selected it, uplifts, discounts, credits |
| Who it belongs to | The platform or service that incurs it | The contract it is billed under |
| When it changes | When the infrastructure or the cost base changes | When the contract changes |
| What it is used for | Cost-to-serve, internal chargeback, margin analysis | The invoice, the resale margin, settlement between channel levels |
Margin becomes a report, not an exercise
Because both objects hang off the same measurement, margin per customer, per service, per platform or per channel level is something you read rather than something you assemble. Change a rate on the rate card and every figure downstream of it moves at once: the invoice, the export, the breakdown you send the customer, and the margin report you keep for yourself.
Three reports cannot disagree about what a customer owes, because there is only one rate.
Where the unit rate comes from, and why finance accepts it
Public cloud hands you a price. A cluster you bought four years ago does not, and the rate you charge for it has to be derived. That derivation is the thing a CFO actually questions, so it is the thing worth building properly.
- 01Start from what the infrastructure costs
Capital assets on their depreciation schedule, support and maintenance contracts, facilities and power, licences, and the operational effort that keeps the platform running.
- 02Pick drivers you can measure
vCPU-hours, GB-hours, provisioned IOPS, port-hours, cores, seats. A driver the engine meters, not a utilisation assumption somebody made once in a spreadsheet.
- 03Allocate the indirect cost by a stated rule
Shared and indirect cost attaches to those drivers by a rule that is written down, so the split can be argued with on its merits instead of defended as a judgement call.
- 04Divide, and you have a rate
The cost base over the measured driver volume: a unit rate per service, expressed in the unit that service is metered in.
- 05Version the rate card rather than overwriting it
A rate card records what the rate was, from when, and what it replaced — so re-running a closed period returns the figure that period was billed at.
Meter more than just AWS, Azure and Google Cloud
Exivity Core meters whatever you run, wherever it runs: in the public cloud, in your own datacentre, or behind an air gap.
Public cloud
Billed usage, private rates, reservations and commitments
Hybrid and private platforms
vCPU, vRAM, storage and IOPS allocations per cluster and tenant
Bare metal and hardware
Redfish hardware inventory and telemetry, mapped to billable usage by your rules
Operations and automation
Managed services, tickets and provisioned resources as billable events
AI tokens and model calls
Token and model-call consumption metered per provider, per model and per consumer, so it can be rated and billed like anything else you sell.
A provider running VMware and Nutanix and Kubernetes and three public clouds and a storage array is not an edge case; it is the normal shape of hybrid infrastructure. Most tools in this market meter one silo well and describe the result as hybrid, which leaves the customer’s bill assembled from several of them by hand. See every integration.
Your commercial terms, applied once
Rating is the step that turns a measured quantity into money; the tariff is the rule that decides which rate applies. Both live in one rate card per customer, in the currency their contract is written in — instead of a spreadsheet somebody re-applies by hand every month.
- Consumption rates
- A rate per unit of whatever you measured: GB-hours, vCPU-hours, seats, cores, tokens, tickets.
- First-match brackets
- The whole volume is charged at the rate of the bracket it lands in.
- Graduated and prorated tiers
- Each band of volume is charged at its own rate, and the bands add up. Prorated where a customer arrives mid-period.
- Minimum commitments
- A floor the customer pays whether or not they consume it, with overage rated above it.
- Discounts
- Per customer, per service or per period, applied before or after other terms as contracted.
- Uplifts and markups
- Margin on a resold service, expressed as a percentage or a fixed amount.
- Credits
- One-off or recurring adjustments: SLA breaches, goodwill, migration allowances.
- Fixed amounts and flat offsets
- Subscriptions, platform fees and support charges that are not driven by consumption.
- Conditional and aggregated rules
- A rate that depends on another value, or on a total across the whole period rather than a single record.
One rate card per customer
The rate card is the single place a price is stated. Everything you negotiated is expressed there as a rule the engine applies — which means a term you agreed in a contract and a term the system charges cannot drift apart, because they are the same object.
Distributor, reseller, end customer
Multi-level channels — n-tier, B2B2X, whatever your paperwork calls them — are not a special case to be worked around at invoice time. Each level holds its own rate card, its own margin and its own view of the same measured consumption.
- 01Distributor
Buys at wholesale rates. Sees every reseller beneath them, the settlement owed to each, and the margin on all of it.
- 02Reseller
Applies their own uplift and their own contract terms. Sees their customers, and not the distributor’s others.
- 03End customer
Receives an invoice at the rates they signed, and a breakdown they can check line by line.
One measurement, rated three times, with each level seeing only its own commercial reality.
The cost-management tools this engine is usually compared against do not address this ground: multi-tenant billing, reselling, margin management and customer invoicing are absent from them, because the only relationship those products model is one vendor and one account. FinOps and billing for service providers.
Deploy where the data has to stay
Some organisations cannot send cost and usage data to somebody else’s cloud. That is not a preference to be talked out of. It is a regulator, a contract, or a physical air gap.
Self-hosted VM or Kubernetes
Run it in your own datacentre or your own cloud account, on a virtual machine or on Kubernetes, under your own change control.
Air-gapped
Deployable into an environment with no outbound connectivity. No cost or usage data leaves it.
Cloud
Run it as a hosted deployment when there is no requirement to keep it in the building, and move later if that changes.
SAML2, RBAC, API-first
Your identity provider, your role model, and an API that can do everything the interface can, so it fits the environment you already run.
Who this is for
- Sovereign and national-cloud requirements
- Defence and public sector
- Regulated finance and healthcare
- Any organisation under a data-residency clause
Your existing BI keeps working
You are not being asked to replace the reporting stack your business already reads.
REST API
Every measurement, rate and rated charge is addressable. The API does what the interface does, which is what makes automating a billing run possible at all.
BI connectors
Power BI, Tableau and SAP BI read rated charge data directly, so the numbers in the dashboard and the numbers on the invoice come from the same place.
Warehouse and export
Scheduled exports into the warehouse or the general ledger, in the shape the receiving system expects.
Where Hypermeter fits
Exivity Core answers what to bill. When the question becomes who caused the cost and whether it was worth it across sources Core does not meter, that is Hypermeter, built by Exivity: SaaS for cross-source cost allocation, FinOps analysis and unit economics.
Hypermeter attributes cost to whoever drove it — including the shared platforms nobody owns — from whatever sources you point it at: cloud exports, databases, licence registers, and the rated charge records this engine produces if you happen to run it. Neither product needs the other to be useful.
Exivity Core is actively developed and fully supported. It prepares invoice-ready output and runs self-hosted, including air-gapped. Hypermeter does not replace it, and existing deployments are unaffected.
When we began our partnership with Exivity, we immediately felt like we were in good hands. Their expertise in hybrid-cloud billing gave us the confidence to start from scratch, knowing that we would have a functional solution in no time.
Common questions
Pricing is scoped to your organisation and deployment. How pricing works.
Ask us the restWe have a source nobody supports. What happens to it?
It becomes a source. Point the engine at the API, the database, the object store or the file drop, describe the shape of what comes back, and it is collected on a schedule like everything else. There is no queue for a connector to be written, because the ingestion and mediation layer is the product rather than a catalogue sitting in front of one.
Where does the rate for our own datacentre come from?
You derive it, and the engine holds the derivation rather than just the answer: the cost base, the measured driver it is divided by, the rule that allocated indirect cost to that driver, and the resulting unit rate. Rate cards are versioned, so re-running a closed period produces the figure it produced the first time. Nothing here depends on a number somebody typed into a settings field and then forgot.
How long until a first invoice?
The engine deploys as a virtual machine or on Kubernetes, and the usual path is to meter one platform first, run a billing cycle in parallel with your existing process, and cut over when the figures agree. A scoped 30-minute demo against your own platforms is the fastest way to size that path for your organisation.
Can it feed our existing billing or ERP system?
Yes. Exivity Core produces rated charge records, and sending them onwards is a supported output rather than a workaround: exports to the general ledger, scheduled exports to a warehouse, and a REST API that exposes every measurement, rate and charge. You can keep the system that sends the invoice and replace only the part that assembles it.
What does it need to run?
A virtual machine or a Kubernetes cluster in your own environment, or a hosted deployment if nothing requires it to stay in the building. It authenticates against your identity provider over SAML2, applies your role model through RBAC, and runs air-gapped where outbound connectivity is not allowed.
How does pricing work?
Licensing is scoped to your organisation and your deployment requirements. There is no public price list because no two organisations meter the same things. The pricing page explains what a quote needs.
See it meter your infrastructure
A scoped 30-minute session against the platforms you actually run, ending with a rated line off one of them.