# Choosing a unit for cloud cost per unit

> Which count to divide cloud spend by (subscriptions, orders, transactions, API requests or customers), where to find it, and why it can't change.
>
> Source: https://roiva.ai/docs/choosing-a-unit-for-cloud-cost
> Checked against the product on October 14, 2026

Roiva's cloud cost formula doesn't compare this month's cloud bill with the bill before the initiative. A bill that grew because the business grew isn't waste, and a quiet month isn't a saving. It compares what it cost to serve one unit of demand before and now, and multiplies the fall by this month's units:

(cost per unit before − cost per unit now) × units this month

So beside the spend, the formula needs one count: the demand your cloud bill grows with. Roiva calls it Business Volume, and asks for it on the **Missing Inputs** page.

#### Pick the count your business grows by

You don't need to know how the cloud is built. You need the number your business already watches that rises when the bill does.

| If your business… | Count | Where it usually is |
|---|---|---|
| sells subscriptions | Active subscriptions at the end of the month | Your billing system's list of subscriptions, filtered to active |
| sells online | Orders placed in the month | Your store's orders report |
| processes payments, bookings or claims | Transactions completed in the month | That system's monthly report |
| sells access to an API | API requests in the month | The API's usage dashboard; engineering will know where it is |
| none of these, or you're unsure | Active customers in the month | Your billing system or CRM |

When you're asked for the first figure, Roiva fills in a suggested unit and says why: a count a connected tool already reports (active subscriptions or payments from Stripe), else what companies in your account's industry usually count, else active customers. Change it if another count follows your bill more closely.

#### Counts to avoid

- **Requests your cloud provider meters**, like API gateway requests, serverless invocations or CDN requests. The work being measured often cuts them: caching and batching serve the same customers with fewer requests. Cost per request then holds steady while the bill falls, and the saving disappears.
- **Revenue.** A price rise looks like more demand, and a discount looks like less.
- **Headcount.** The bill doesn't grow with your staff.

#### Keep it the same every month

The first figure you enter, the baseline, names the unit. Every later figure has to count the same thing over the same window: a month of orders against a month of spend. A later figure that names a different unit is flagged wherever it shows, and the value calculated from it waits for a person to review it instead of being approved automatically.

If you change your mind about the unit, change the baseline too, so the before and after figures count the same thing.

#### When Stripe already counts it

If Stripe is connected, Roiva can read the count itself, so there's nothing to type each month. Once Stripe has synced both its subscriptions and its payments, a Cloud Cost Optimization initiative measures the saving:

- **per active subscription**, when you have at least half as many active subscriptions as payment charges, which is typical of a subscription business;
- **per transaction** (each payment charge in the currency your Stripe account settles in), when you have payments and fewer subscriptions than that, as a store or marketplace does.

An initiative that already has one of these formulas moves to the right one by itself after a later sync, as long as it hasn't recorded value and nobody has edited the formula. One that has, **Missing Inputs** offers to switch: the months it booked stay on it, and the new formula books from the month after the last of them. See [How value is calculated](https://roiva.ai/docs/how-value-is-calculated) for how a formula's figures come together.