Test SaaS invoices at a pricing-tier boundary

A rate table showing lower unit prices at higher volumes needs a calculation rule. Under one arrangement, the final quantity selects a rate for all units. Under another, each block of units keeps its own rate. Stripe calls these volume-based and graduated pricing. Confirm which arrangement the customer accepted before comparing the invoice with a spreadsheet.

Record included quantities, flat charges and the boundary values as well as the rates. Check whether the tiers reset monthly, annually or by another contract period. A correct calculation using the wrong measurement period can still create a significant error. Preserve customer-specific schedules separately from the public pricing page.

Test the last quantity in one tier and the first quantity in the next. Include a zero-usage case and the largest expected quantity. Calculate the expected bill independently, then compare invoice lines and totals. The test should prove the method rather than merely verify that the billing platform returns a number.

For a hypothetical graduated schedule, the first 100 units might cost $2 each and later units $1.50. At 101 units, the charge is $201.50. A volume schedule applying $1.50 to all 101 units instead produces $151.50. Both arithmetic results are correct for their stated rules; the contract determines which belongs on the customer's invoice.

Find out whether the agreement combines usage across workspaces, products or subsidiaries. The billing implementation may evaluate each subscription item separately even when sales promised a shared volume tier. Prepare the calculation at the level defined in the contract, then show how the platform's items combine to that result.

Check how a midperiod change affects the tier. Added seats, a product migration or a contract amendment may split the period into more than one calculation. Give the accountant the approved interpretation and service dates. Avoid using the customer's final quantity for the whole period unless that is the agreed pricing rule.

Check whether several workspaces, products or departments share the quantity used to select a tier. Record the agreed pooling rule and the customer identifiers included. A correct calculation for each workspace can still produce the wrong invoice if the contract requires one combined tier calculation, or if unrelated accounts have accidentally been pooled.

For a hypothetical boundary at 1,000 units, two workspaces with 600 units each may need to be tested as 1,200 combined units or as two separate 600-unit amounts, depending on the agreement. Add a workspace transfer during the period to the acceptance set and confirm its treatment. Retain the membership history so a later reviewer can reproduce the quantity that selected the tier.

Ask a prospective billing or accounting provider to walk through the boundary calculation using a redacted contract. Request the expected invoice, correction method and retained evidence. A provider that can reproduce the example and explain its assumptions gives you more useful information than a general assurance that tiered pricing is supported.

After any price configuration change, rerun the boundary set and retain the results with the effective date. Investigate customers whose bills move unexpectedly near a tier before issuing broad credits. If an error affected earlier invoices, identify the full population and document approved corrections; a corrected rate for future billing does not settle the historical difference.