How to Bill Tiered Pricing in SaaS Without Excel
On the 28th of the month, a customer crosses the 100-seat threshold. The price drops retroactively for all seats, the invoice is not due to be created until the end of the month, and reverse charge applies at the same time. A tier table in the frontend cannot handle this. To bill tiered pricing in SaaS, you need billing logic that brings together the price rule, the current quantity, tax, payment status and revenue data in a traceable way.
In the product catalog, tiered pricing looks simple. In operations it runs into upgrades, downgrades, proration, corrections, multiple currencies and country-specific invoicing requirements. If these cases are only interpreted during the billing run or the month-end close, you get exactly the manual work a SaaS billing system is supposed to prevent.
Billing tiered pricing in SaaS starts with pricing semantics
The term "tiered pricing" covers at least two different models, and they must not be handled with the same calculation.
With volume pricing, the quantity reached sets the price for all units. If a product costs €10 per seat up to 100 seats and €8 per seat from 101 seats, a customer with 120 seats pays €960. Crossing the threshold also changes the price of the first 100 seats.
With graduated pricing, each tier is priced separately. The first 100 seats cost €10 each and the next 20 seats €8 each, so the invoice comes to €1,160. The two calculations reflect different commercial agreements, so the choice is more than a display setting.
Usage-based products add a third dimension: the measurement period. An API request can be counted when it arrives but only become billable at the end of the calendar month, at the end of a customer-specific contract month or once a free allowance has run out. The product catalog therefore has to define explicitly whether quantities are accumulated, reset, aggregated across several meters or rated separately per workspace.
The rule should be machine-readable: metric, aggregation window, tier boundaries, calculation method, currency, billing interval, tax classification of the product and effective date. Free text in CRM notes does not count as pricing logic.
An example with seats and usage
A vendor charges a €49 platform base fee, €12 per active seat up to and including 50 seats, and €9 from the 51st seat. The plan also includes 100,000 API calls. Above that, graduated tiers apply: €0.004 for the next 400,000 calls and €0.0025 for every request after that.
For 70 active seats and 650,000 API calls, the monthly charge comes from three separate calculations: base fee, seat component and usage component. The 550,000 additional requests are split along the defined tier boundaries instead of all being priced at the rate of the last tier. These individual values have to stay consistent across the invoice line, the tax base, the revenue schedule and the general ledger account.
Usage events are the evidence behind the price calculation
For seat models, a daily quantity snapshot is often enough. For usage-based SaaS, the event model is central. Every billable event needs a stable external event ID, a reference to the customer or account, a metric, a quantity, a timestamp and ideally dimensions such as region, feature, workspace or environment.
Events sent twice are a common error, so ingestion has to be idempotent: resending the same event ID must not increase the billed quantity. Late events cause just as much trouble. If a request from January 31 only arrives on February 2, the policy has to be clear. Is it assigned to the January period and corrected with an additional charge, or deliberately billed in February?
Both approaches can make sense. For API products close to individual transactions, assigning usage to its actual period is often more accurate in economic terms. For high-volume telemetry, a clear cutoff can simplify operations. What matters is that product, finance and engineering implement the same rule and that the audit trail shows the decision.
Reliable billing stores more than the final result of 650,000 calls. It keeps the plan version used, the quantity per tier, the source data and the time of calculation. With that, you can answer customer questions, create correct credit notes and reproduce historical invoices even though the current product catalog changed long ago.
Price changes need versioned price plans
Price changes without a deploy stay under control only if price plans are versioned and have effective dates. A new price must not silently overwrite periods that are already running. Otherwise you can later neither explain why an invoice was created nor produce a correct revenue deferral.
For existing customers there are typically three strategies: grandfathering at the unchanged old price, migration on a cutover date, or individual contract terms. That decision belongs to the subscription or contract, and it should not live as an exception in the application code.
Mid-cycle changes also have to be modeled explicitly. If a customer upgrades from 40 to 60 seats on the 16th of a 30-day month, the additional seats can be prorated. With volume pricing there is a further question: does the new price apply retroactively to the whole period or only from the time of the change? Either is possible, but the contract language and the billing engine have to match.
A clean architecture separates the catalog price, customer-specific terms and calculations that have already been invoiced. Later changes go through a credit note, an additional charge or a defined adjustment line. A posted invoice is never rewritten.
Invoice, tax and payment are part of the same chain
For European B2B SaaS, getting the net amounts per tier right is only part of the job. The invoice has to reflect the tax context at the time of supply correctly. Cross-border B2B services within the EU may require a validated VAT ID (USt-IdNr.), reverse charge and the correct invoice wording. In other cases, local VAT, the EU VAT One-Stop Shop (OSS) or different place-of-supply rules apply.
The tax decision therefore cannot be added as a flat percentage after the price has been calculated. It needs the customer's location, tax status, the VAT ID check, the product classification, the service period and the invoice date. For recurring services, it matters in particular whether the invoice shows the service period in a traceable way.
Public-sector buyers and regulated procurement processes add format requirements, and a PDF invoice alone is not always enough. XRechnung and ZUGFeRD under EN 16931 require structured fields that must match the calculated lines, tax categories and payment data. A tier calculation that shows up on the invoice only as a total nobody can check leads to questions you could have avoided.
Collection follows invoice finalization. With SEPA Direct Debit, the mandate reference, due date, pre-notification and returned direct debits belong in the same operational process. A failed collection must not lead to an invoice with changed content. It triggers a receivable status, dunning rules and, where needed, SEPA R-transaction routing.
Month-end close without Excel requires ledger-ready data
In many billing stacks, the first invoice works and the close is the weakest point. Billing produces a PDF, payments manages transactions, and finance exports totals and then tries to explain the differences between credit notes, taxes, incoming payments and revenue recognition.
With tiered pricing, ledger data has to be created at the line level. Every invoice line needs traceable net and tax amounts, a revenue account, a service period, a contract reference and references to any corrections. For IFRS 15 or ASC 606, you also have to distinguish whether a service is fulfilled immediately or recognized over time. A platform fee billed monthly in advance and API usage invoiced in arrears can have different revenue schedules.
The DATEV export should not need a data cleanup afterward. It is the output of one end-to-end model: the price rule creates the line, the line creates tax and ledger information, the payment settles the receivable, and a correction references the original document. That keeps accounts receivable, VAT and revenue reconcilable.
Kontier implements this chain with a versioned product catalog, usage events, tax logic, invoice formats, SEPA and ledger data in one European billing infrastructure. Besides automated invoices, the operational gain is billing whose numbers can still be explained after a price change, a returned direct debit or an audit.
Before you build another price calculator in the frontend, take a real customer account and check whether every billed tier line can be traced back to the plan version, quantity source, tax decision, payment and revenue account. With that chain in place, growth does not turn into a manual reconciliation project.