Volume vs. Graduated Tiers: SaaS Tiered Pricing, Worked Through

A three-tier price table looks unambiguous. Yet two billing systems can take the same table and the same quantity and produce two different invoice totals, and both will claim they followed "the tiers". The difference sits in a detail that rarely makes it into the order form: is the table applied as volume tiers or as graduated tiers? This article works through both models with one example and shows the three places where tiered pricing in SaaS tends to get billed wrong: the tier boundary, the counting scope and the rounding.

Running tiers over time (mid-month upgrades, late events, credit notes) is covered in billing tiered pricing in SaaS without Excel. This one is about the arithmetic.

One word, two contracts: volume tiers and graduated tiers

With volume tiers, the total quantity reached selects a single unit price, and that price applies to every unit. With graduated tiers, each tier is priced separately: the first units cost the first tier's price, the next ones the second tier's, and so on.

There's also package pricing. Up to 5,000 calls the month costs a flat €1,500, up to 20,000 calls €4,000. The quantity only decides which flat fee applies.

All three models need the same fields in the product catalogue. A definition might look like this:

metric: api_calls
aggregation: sum per calendar month and contract account
mode: graduated          # or: volume | package
tiers:
  - up_to: 1000   unit_price: 0.50
  - up_to: 5000   unit_price: 0.40
  - up_to: null   unit_price: 0.30
rounding: per invoice line, half-up to the cent

Two details here save arguments later. First, tiers are defined only by an inclusive upper bound. If two adjacent rows say "up to 1,000" and "from 1,000", nobody knows which tier the thousandth unit belongs to. Second, the mode is its own field. It belongs in the contract and the catalogue, not only in the sales team's heads.

Same table, six quantities, two totals

Using the example tiers (€0.50 up to 1,000 calls, €0.40 up to 5,000, €0.30 beyond), these are the monthly net amounts:

The graduated amount for 6,000 calls breaks down as 1,000 × €0.50 = €500, plus 4,000 × €0.40 = €1,600, plus 1,000 × €0.30 = €300. That's €2,400, or €0.40 per call on average.

If sales sold it as "only €0.30 per call once you pass 5,000", the customer expects €1,800, which is the volume price. The €600 gap comes back as a dispute, even though the system billed exactly what the contract says. If you sell tiers, put one worked example amount in the quote.

Volume tiers are quicker to explain: 6,000 × €0.30 = €1,800. They do have one property you should understand before offering them.

The cliff at the tier boundary

Compare 5,000 and 5,001 calls in the table. One extra call drops the volume-tier invoice from €2,000.00 to €1,500.30. Work backwards: €1,500.30 at the second tier's price is about 3,750 calls. So every customer using between 3,751 and 5,000 calls pays more than a customer using 5,001.

Procurement teams notice. They generate load to get over the line, or negotiate a 5,001-call minimum before signing. Either way your usage data gets distorted and you lose revenue.

Three common fixes:

• Use graduated tiers instead. The total then rises with every unit and never jumps.
• Keep volume tiers but add a floor per tier: a tier's total never drops below the maximum of the tier before it. In the example, any quantity from 5,001 to 6,666 calls then costs €2,000.
• Choose boundaries and prices so the drop stays small, for example by narrowing the price gap between tiers.

You can automate the check. A test computes the total at every boundary g and at g + 1 units. If the total falls, the table has a cliff. Run that test on every new price version before you publish it.

Where you count: account, workspace or contract year

The second source of errors is the counting scope. Say a customer has two workspaces with 3,000 calls each. If graduated tiers apply per workspace, they pay 2 × €1,300 = €2,600. If usage is summed across the contract account, the 6,000 calls cost €2,400. That €200 depends on one line that many quotes leave out. With group customers there's a further question: do several subsidiaries share one tier table even though each receives its own invoice?

The time window works the same way. A monthly tier resets to zero each month. An annual tier accumulates over the contract year, and combined with volume tiers that has an awkward consequence: if the customer reaches the cheaper tier in month nine, the lower price applies retroactively to every unit of the year. The invoices for months one to eight were too high, and depending on the contract wording you owe a credit note.

The close feels it too. Step three of the five steps in IFRS 15 is determining the transaction price. If it's foreseeable that the customer will reach the cheaper tier, invoicing at the higher early-month price can overstate revenue for those months. Agree with your auditors how the expected price is estimated before you sell the first annual tier.

Fix the rounding rule and the invoice lines

Unit prices with three or four decimal places are normal for usage products. For example, 333,333 calls at €0.0025 come to €833.3325. Rounding each tier to the cent and then summing, or summing first and rounding once, usually differs by a few cents per invoice at most. It has to happen the same way every time, though. Otherwise a recalculation for a customer query won't match the invoice that went out, and nobody can say which number is right. Write the rule into the catalogue and calculate with decimal types, not floating point.

The invoice should let the customer recompute the tiers. For graduated tiers that means one line per tier with quantity, unit price and net amount. For volume tiers one line with the total quantity and the price of the tier reached is enough, plus a note saying which tier that is. A customer who only sees "API usage March: €2,400.00" can't check anything and will email support.

Tiers don't change the tax treatment. Every tier line on an invoice carries the same VAT treatment. For a cross-border B2B service within the EU, the invoice needs the reverse charge note required under the EU VAT Directive, whether it has one tier line or three.

Five checks before a tier table goes live

1. Is the mode (volume, graduated, package) its own field in the catalogue and spelled out in the contract?
2. Are tiers defined only by inclusive upper bounds, with an open last tier?
3. Does the total fall anywhere between g and g + 1? If so, is that intended?
4. Are the counting scope (account, workspace, legal entity) and window (month, contract year) fixed, and has finance worked through the effect of a retroactive annual tier?
5. Is the rounding rule fixed, and does the invoice show quantity, unit price and amount for each tier?

All five can run as automated tests against each new price version. An included quota with overage follows the same rules plus a few of its own, worked through in automating overage billing. In Kontier, tiers are versioned price rules in the product catalogue, applied to usage events.