CloudBilling vs Exivity Core

At a glance

Where CloudBilling is the better choice

Your revenue is Microsoft CSP and you resell licences. CloudBilling’s CSP connector was built for the Partner Center: it retrieves Azure consumption and licence subscription counts every day, prices NCE seat-based offers at Microsoft’s expected retail price, takes partner earned credit into account, and has a written answer for why its invoice differs from the one Microsoft sends you. If most of what you invoice is Microsoft 365 seats, Azure Plan consumption, reserved instances and marketplace, that is exactly the shape CloudBilling is made for. Exivity Core applies CSP and NCE terms too, but it is a general engine that meters Azure rather than a product built around the Partner Center.

You buy through a distributor. Copaco, Arrow, Pax8 and TD Synnex each have a named connector in CloudBilling, so the purchase side of your margin arrives without modelling. Exivity Core reads a distributor feed through its universal extractor, which is a configuration task rather than a switch.

You want the system that sends the invoice. CloudBilling runs the order-to-cash step end to end: invoices are calculated continuously as purchases arrive, locked in an approval workflow, numbered by your own scheme, corrected with credit invoices, transformed to PDF or a file for your accounting package, and mailed in a message run. Exivity Core produces the invoice-ready charges and the billing run and hands them to the system that sends them. If you do not have that system, or do not want one, CloudBilling is the shorter path.

You want a partner, in Dutch, who does the setup with you. CloudBilling is a team of around twenty-five people in Naarden, with a Dutch-language site and support, managed services that will run your billing scenarios for you, and case studies with Dutch and UK providers. For a provider in the Netherlands or Belgium that wants a consultative vendor within driving distance, that counts, and we would not argue otherwise.

You want white-labelled customer reporting out of the box. Customer Portals with standardised Power BI reports are a packaged add-on. Exivity Core scopes each customer’s view to its own data; the richer per-customer analytics sit in Hypermeter.

Where Exivity Core is the better choice

Part of what you bill has no billing export. A VMware cluster, a Nutanix environment, an OpenStack region, a Kubernetes platform, a bare-metal fleet, a licence pool or a managed service does not arrive as a purchase with a price on it. CloudBilling’s private-cloud coverage is a VMware agent and a vCloud Director connector, and everything else is an Excel upload or an API call you write. Exivity Core, built by Exivity, meters those platforms at the source with thirty-plus extractor templates and a universal extractor for the rest, so the revenue from your own infrastructure is measured rather than estimated.

The rate has to be derived, not marked up. Resold cloud comes with a buy price and CloudBilling’s pricing rules adjust it. Your own datacentre does not come with a price at all. Exivity Core derives it: the cost base, the measured driver it is divided by, the rule that allocated indirect cost, and the resulting unit rate, all held in a versioned rate card. When a customer asks why the GB-hour costs what it does, the derivation is the answer.

There is a distributor, a reseller and an end customer. Exivity Core models the hierarchy as one structure with a rate card at each level and a view scoped to that level: the distributor sees every reseller, the reseller sees only its own customers, and nobody sees the level above. CloudBilling groups customers into clusters with parent tags and connects to distributors on the buy side; a rate card and a scoped view per hierarchy level is not a stated capability.

The invoice will be disputed line by line. Every charge Exivity Core produces carries the measurement, the rate-card version, the bracket that selected the rate, and any uplift or credit applied, and re-running a closed period produces the figure it produced the first time. CloudBilling documents reconciliation as a manual comparison of the vendor’s reconciliation files against its invoice, and explains the differences that will always exist. Both are honest; one is a property of the engine.

The data has to stay in the building. Exivity Core deploys as a virtual machine or on Kubernetes in your own environment, authenticates over SAML2, applies your role model through RBAC, and runs air-gapped. CloudBilling is a SaaS platform at its own address with OpenID Connect single sign-on. For a sovereign, regulated or public-sector hoster that cannot send usage data out, that decides it.

You bill internally like a provider. Summary billing for chargeback is the same rated output without an external invoice attached. CloudBilling is built for invoicing a paying customer; showback to an internal department is not what it is for.

The differences that decide it

Where the usage comes from

CloudBilling has a connector catalogue: the public clouds, the distributors, VMware, and an Excel editor and API for the rest. Exivity Core has an ingestion and mediation layer that treats any API, database, object store or file drop as a source and collects it on a schedule. If everything you bill is on CloudBilling’s list, the catalogue is faster. If one thing is not, the engine is the only one of the two that measures it.

What a rate is

In CloudBilling a rate is a pricing rule applied to a purchase price. In Exivity Core a rate is an entry in a versioned rate card that may have been derived from a cost base. The first is the right abstraction for resale margin. The second is the one you need for infrastructure you own.

Who sends the invoice

CloudBilling is the invoicing environment: status, approval, numbering, correction, PDF, message run. Exivity Core stops at invoice-ready charge records and hands them to the accounting or billing system you already run. Providers with an ERP prefer the second; providers without one prefer the first.

Real time versus closed periods

CloudBilling recalculates invoices continuously as purchases arrive and locks them at approval. Exivity Core runs a billing cycle over a closed period and produces the same figure every time it is re-run. Continuous is more convenient during the month; repeatable is what an auditor asks for.

Where it runs

CloudBilling is SaaS. Exivity Core is self-hosted, hosted or air-gapped. This is not a feature difference; for some buyers it is the whole comparison.

Migration and coexistence

Running both is a real pattern for a provider that resells Microsoft through a distributor and also runs its own platform: CloudBilling keeps the CSP and licence billing and sends the invoice, and Exivity Core meters the private infrastructure and passes rated charges into CloudBilling as purchases through its API. Both products document the interfaces that make this work; it is an integration you configure, not a connector either vendor ships. Moving from CloudBilling to Exivity Core means re-expressing customers, product categories and pricing rules as a model with rate cards and a hierarchy, and moving invoice sending to your accounting system. The usual path is to meter one platform first, run a billing cycle in parallel with the existing process, and cut over when the figures agree. Moving the other way gives up metering at the source, derived rates and self-hosting.