SaaS Pricing Models: How They Charge and How to Choose

A SaaS pricing model is the rule that converts a customer’s use of a product into a bill. The common models are flat-rate, per-seat, tiered, usage-based, freemium and hybrid, and the right one depends on where the value of the product sits, how predictable customer usage is, and how much billing complexity the business is prepared to engineer and operate. This guide describes each model, the invoicing logic it demands from the software, and the criteria for choosing between them.

TL;DR

• Pricing defines what customers are charged for; billing is the machinery that meters, invoices, collects and recognises it. Every pricing model imposes its own billing requirements.
• Flat-rate and per-seat pricing are the simplest to build and forecast; usage-based pricing aligns cost with value but needs trustworthy metering and makes revenue less predictable.
• Most mature B2B products end up with a hybrid: a subscription base for predictability plus a usage or overage component for expansion.
• Choose the model from customer behaviour and value metrics, then test it against churn, customer lifetime value and average revenue per user.
• Decide the pricing model before the billing architecture is built, because retrofitting metering and proration into a live product is costly.

Table of Contents

• Pricing model and billing model: two different layers
• The main SaaS pricing models at a glance
• Who carries the risk
• What each model demands from the billing system
• How to choose a pricing model
• When to revisit the model
• Perspective
• Building pricing into the product
• FAQ
• Sources

Pricing model and billing model: two different layers

The two terms are often used interchangeably, yet they describe different layers of the same system. A pricing model defines how a software company charges customers for access to its product, while a pricing strategy defines how it decides what to charge, based on customer value, market positioning and growth goals, as Sage’s guidance for SaaS businesses frames it. Billing is the operational consequence: the invoicing methods the company adopts to collect what the pricing model says it is owed.

Solvimon’s glossary describes billing as the end-to-end system covering pricing, subscriptions, entitlements, metering, rating, invoicing, payments, dunning and revenue recognition, which makes pricing one component of billing rather than a synonym for it. The distinction matters in practice because each pricing model creates different engineering obligations. Usage-based pricing requires metering and rating, whereas per-seat pricing requires tracking seat changes and handling proration when a customer adds or removes users mid-cycle.

This is also the reason the second query readers type, how SaaS invoicing models work, cannot be answered without first choosing the pricing model. Invoicing is derived from pricing, not the other way round.

The main SaaS pricing models at a glance

The table summarises how each model charges, where it fits best and what it demands of the billing system. The sections that follow examine each in turn.

Flat-rate pricing

Flat-rate pricing charges a single price for everything, up front. Its attraction is clarity: the customer knows the cost, the vendor knows the revenue, and the invoice never surprises anybody. Stripe’s overview of billing models notes that this inflexibility can carry opportunity costs, since a heavy user and a light user pay the same amount and the vendor leaves expansion revenue untouched.

The model suits a product with a narrow, uniform audience, where the value delivered does not vary much between customers. It is also a reasonable starting point for a first release, because it can be built and explained quickly.

Per-user or per-seat pricing

Per-seat pricing scales with the number of people using the product and is common in B2B software. Revenue grows as the customer organisation adopts the product internally, which makes forecasting straightforward: seats purchased multiplied by the unit price.

The model works when value correlates with the number of users, as in project management, communication or CRM tools. It works less well when a product delivers value to a whole organisation through a few administrators, or when automation reduces the number of humans needing a licence. In those cases the price metric diverges from the value metric, and customers begin to share logins to avoid cost, which is a pricing signal as much as a security problem.

Operationally, per-seat billing must handle additions, removals and role changes during the billing period, and calculate prorated amounts accurately. The logic looks trivial in a specification and is rarely trivial in production.

Tiered pricing

Tiered pricing offers packages with increasing features, capacity or value at different price points. It is the model most visitors recognise from a pricing page: three or four plans, a highlighted middle option and an enterprise tier negotiated individually.

The design work lies in deciding what separates the tiers. Good tier boundaries follow genuine differences in customer segments, such as team size, compliance needs or integration depth, rather than arbitrary feature withholding. From an engineering standpoint, tiering requires an entitlement layer: the application must know, at every request, which capabilities the customer’s plan includes, and the same source of truth must feed the invoice.

Usage-based pricing

Usage-based pricing charges customers according to how much they use the product. According to Microsoft’s guidance on SaaS pricing strategies, it aligns cost with actual value but makes revenue harder to predict. That trade-off is the essence of the model.

It fits products where the vendor’s own costs scale with consumption, such as API calls, storage, messages sent, compute time or AI inference, and where customers range from occasional to very heavy users. A TechTarget overview observes that usage-based pricing can be economical at low volumes, while power-user costs can rise substantially and fluctuating invoices make budgeting difficult. For that reason many vendors add spending caps, committed-use discounts or alerts, so customers are not surprised by an invoice.

The billing consequence is significant. Oracle’s NetSuite documentation states that invoices may be raised in advance or in arrears, and that in-arrears billing is required for usage-based subscriptions, because the amount is known only after the usage has been recorded. A usage-based product therefore needs a reliable event pipeline, idempotent metering, a rating engine and an audit trail that can answer a customer’s dispute line by line.

Freemium pricing

Freemium offers a free basic tier with paid upgrades. It is an acquisition mechanism as much as a pricing model: the free tier lowers the barrier to adoption, and a share of users convert when they reach a limit or need a premium capability. Microsoft’s guidance cites HubSpot as an example of a vendor that attracts small businesses with free tools and monetises as they scale.

Freemium only works where the marginal cost of serving a free user is low and where the paid tier offers a clear step in value. Otherwise, the free tier consumes infrastructure and support capacity without producing conversion. The engineering work lies in enforcing limits cleanly and designing upgrade paths that preserve the user’s data and context.

Hybrid pricing

Hybrid pricing combines subscription fees with usage-based components, providing predictable base revenue alongside expansion potential. The m3ter SaaS Pricing Spectrum report describes the three poles: subscription charges a set amount at regular intervals for a defined package, consumption charges according to actual usage, and hybrid combines a subscription package with consumption elements such as overages or usage add-ons.

In practice, this is where many B2B platforms settle. A customer commits to a plan with an included allowance, pays overage beyond it, and may buy add-ons for specific modules. Hybrid pricing gives finance a predictable floor and gives the vendor a path to grow accounts without renegotiating. It also combines the billing demands of every other model, which is why it should be designed deliberately instead of accreting through exceptions.

Microsoft Azure illustrates the combination at scale: customers can start with free services, move to pay-as-you-go, and later adopt higher tiers or enterprise agreements.

Who carries the risk

One useful lens for comparing models is the allocation of risk between vendor and customer. Stripe frames it as a balance: flat fees put the risk on the customer, who pays regardless of use, while usage-based pricing shifts risk to the business because revenue can be unpredictable. Per-seat and tiered models sit between these poles, with the customer committing to a capacity and the vendor accepting that some customers will use less than they pay for.

The consequence for planning is concrete. A vendor with high fixed infrastructure costs and a small cash buffer is poorly placed to absorb the volatility of a purely usage-based model. A customer in a regulated sector with fixed annual budgets will often resist uncapped consumption pricing. The appropriate model is the one under which both parties can tolerate the residual uncertainty.

What each model demands from the billing system

SaaS billing records a customer’s plan, pricing and billing cycle, collects and rates usage, generates invoices with proration for mid-cycle changes, collects payment and supports revenue recognition, as Zuora summarises it. It also manages renewals, upgrades, downgrades and usage charges as discrete events. NetSuite’s 2026 guide characterises SaaS billing as relational rather than transactional, because it must sustain an ongoing relationship that includes recurring revenue, subscription changes, failed-payment recovery and hybrid charges.

Three technical points deserve attention before a model is committed to code.

Proration and plan changes. Any model that allows mid-cycle upgrades, downgrades or seat changes needs a deterministic proration policy. The policy must be agreed between product and finance, stored as configuration rather than hard-coded, and covered by automated tests, since errors here are visible to customers on their next invoice.

Metering integrity. Usage-based and hybrid models depend on events that are counted exactly once. Message queues deliver at least once in many configurations, so metering consumers must be idempotent, and the pipeline needs reconciliation jobs that compare raw events to rated usage. Observability on this pipeline is a commercial requirement, not an optional extra.

Revenue recognition. Under IFRS 15, SaaS revenue is generally recognised over time as the service is delivered, with allocation across the contract period rather than upfront recognition as in traditional software sales. Billing data must therefore carry enough structure, such as contract term, performance obligations and amendments, for finance to produce the schedules without manual rework. The same Zuora summary names ASC 606 as the equivalent standard in the United States.

The Sage guidance also makes an organisational point: pricing decisions should align finance, product and engineering so that billing logic, contract terms and revenue recognition rules remain consistent. When those three functions decide separately, the inconsistency surfaces as invoice disputes and audit adjustments.

How to choose a pricing model

Choosing a model is a sequence of decisions rather than a single judgement. A workable order follows.

The first step is to identify the target market, then match pricing to customers’ needs, buying behaviour and usage patterns, as Microsoft’s guidance recommends. A product sold to finance directors at mid-sized firms is bought differently from a developer tool adopted bottom-up by individual engineers, and the pricing model should reflect that path to purchase.

The second step is to name the value metric: the unit that grows when the customer receives more value. Seats, projects, transactions, documents processed and API calls are all candidates. The best metric is understood by the buyer, measurable by the vendor without dispute, and correlated with the customer’s own growth. Every pricing model embeds assumptions about customers, costs and where value sits in the product, a point the Alguna guide to SaaS pricing makes explicitly.

The third step is to test the cost structure. If each unit of use costs the vendor real money, as with compute-heavy or AI features, a purely flat price exposes the margin to the heaviest customers. If marginal cost is negligible, simpler models are safer.

The fourth step is to consider geography. Effective global pricing should account for regional purchasing power, currency differences and local tax and regulatory requirements such as VAT and GST, according to Microsoft’s guidance. A vendor selling across EMEA and North America needs multi-currency price books and tax handling designed in from the outset, since adding them later touches every invoice template.

The fifth step is to decide how the product will be found and sold, because a pricing model also has to be communicated. A pricing page, comparison content and organic discovery all rely on a model that can be explained in a sentence; teams working on SaaS SEO for growth generally find that a clear pricing structure is easier to position than a complex one.

When to revisit the model

No model is permanent. Businesses should assess pricing when customers say it is too expensive or churn to cheaper competitors, at renewals, when entering new markets and when launching new product lines, according to m3ter’s SaaS Pricing Spectrum. The same source suggests that flexing pricing at renewal may help reduce churn and give customers room to grow.

The indicators to monitor are churn, customer lifetime value and average revenue per user, the three metrics Microsoft recommends tracking to assess pricing effectiveness and customer health. Rising churn in a specific segment suggests a mismatch between price metric and value. Flat average revenue per user alongside growing usage suggests that the model captures too little of the expansion.

A change in model is also a change in software. Migrating existing customers from per-seat to hybrid pricing, for instance, requires grandfathering rules, parallel billing runs and clear customer communication. Planning the migration as an engineering project with a rollback path reduces the risk of billing errors on the day of cutover.

Perspective

We approach pricing as an architectural decision as much as a commercial one. The model chosen in a workshop becomes a set of services, data structures and invoice rules, and those are expensive to change once customers depend on them. For that reason we prefer to agree the value metric and the billing rules before the first line of metering code is written, and to record the reasoning in a written recommendation the business can revisit.

Our engineering-first delivery model means that the people who design the entitlement layer, the metering pipeline and the integration with accounting systems are the same engineers who speak with the client. There is no account-manager layer between a pricing hypothesis and the person who knows what it will cost to implement, which shortens the loop between commercial intent and technical feasibility.

In our experience, the most durable approach is to build pricing as configuration: plans, limits, price books and proration rules defined as data, with observability on every billing event, so that the business can adjust its model without a rewrite. We design for that flexibility from the start, using multi-tenant SaaS patterns, message-driven architectures and API-first integration with payment and finance systems.

Pepe F.

Building pricing into the product

Vicedomini Softworks designs and builds SaaS platforms in which pricing, entitlements and billing are engineered as part of the architecture. Where a business is still deciding between models, our CTO Advisory, Fractional CTO and CTO Partner plans provide senior technical guidance on a monthly basis, starting from €1,800 per month for CTO Advisory, and an initial assessment starts from €3,500 as a one-off engagement. For teams ready to build, our custom software development and architecture services cover multi-tenant SaaS, API development, system integration and AI automation.

Examples of delivered work are collected in our case studies.

FAQ

What is the most common SaaS pricing model?

Tiered subscription pricing is the model most buyers encounter, often combined with a per-seat element. Microsoft’s guidance lists subscription, usage-based, freemium and tiered pricing as the four common models. Many mature vendors then add usage components, producing a hybrid.

Is usage-based pricing better than a subscription?

Neither is better in general. Usage-based pricing aligns cost with value but makes revenue harder to predict, while a subscription gives both sides predictability but may not capture expansion. The choice depends on how closely the vendor’s costs and the customer’s value track consumption.

How is SaaS invoicing different from pricing?

Pricing states what the customer pays for and how much. Invoicing is the operational process that records the plan, meters usage, applies proration, issues the invoice, collects payment and supports revenue recognition. Each pricing model dictates which of those steps are complex.

When should a startup change its pricing model?

Review it at renewals, when customers complain about cost or leave for cheaper alternatives, when entering new markets and when launching new product lines. Track churn, customer lifetime value and average revenue per user to judge whether the current model still fits.

Should billing be built in-house or bought?

That depends on how unusual the pricing logic is and how tightly billing must integrate with the product. A technical review of the pricing model, the metering needs and the finance workflow gives a defensible answer before any build decision is made.

Sources

• Sage: SaaS pricing models and strategies
• Solvimon: What is SaaS billing?
• Stripe: Billing models, a guide for businesses
• Microsoft: SaaS pricing strategies
• TechTarget: Basics of SaaS licensing and pricing models
• Oracle NetSuite: Subscription amounts and billing behaviour
• Salesforce: Common pricing models
• m3ter: The SaaS Pricing Spectrum report
• m3ter: SaaS pricing models guide
• Zuora: What is SaaS billing?
• NetSuite: Guide to billing for SaaS companies
• Alguna: SaaS pricing models guide
• BabyLoveGrowth: SaaS SEO for growth

This article was produced with AI assistance and reviewed for accuracy. It is provided for general information only and is not professional advice.