Ask five SaaS vendors what “per user” pricing means and you’ll likely get five different answers. Some charge per named seat regardless of activity, others only for users who log in during a billing period, and others blend the two with usage charges layered on top.
On its face it seems like such a simple term. But there’s no uniform definition, and the same words get used loosely and often interchangeably even though they sometimes describe genuinely different commercial arrangements.
These opaque definitions tend to work in the vendor’s favour. Especially once a sales quote starts mixing models without labelling them clearly.
So, let’s untangle it* and make a few things clear. In this article, we’ll explain each of the main SaaS pricing models plainly, lift the lid on why the terminology gets muddled in the first place, and give you a practical way to spot exactly which model you’re actually being quoted for, before you commit to anything.
*The below is true in general, though don’t be surprised if a vendor finds a new way to redefine the same term!
Why SaaS pricing terminology is confusing
Vendors don’t use pricing language consistently. And the reason isn’t nefarious. In fact, the reason is fairly mundane: it’s just a thing people do. Much in the same way a bread roll is called a ‘roll’ in the South, a ‘cob’ in the Midlands, a ‘barm cake’ in the North-West. Language is diffuse.
In SaaS, for example, “seat” can mean a named individual with login credentials, or it can mean an active user counted only when they take an action in a billing period. Two platforms can use the identical word to describe opposite billing logic.
So, yes, not necessarily deceptive, but certainly not helpful for you, the buyer. And it means the burden falls on you to ask the right questions.
The main SaaS pricing models
Per-seat pricing
You pay a flat fee for every named user with access to the platform, whether they use it or not. This is common in tools where access itself carries value, such as document collaboration software.
- Pro: highly predictable. You know your monthly cost the moment you know your headcount, which makes budgeting and forecasting straightforward.
- Con: you pay for dormant or rarely used accounts. As teams grow or restructure, the gap between licensed seats and those actually using the tool tends to widen, quietly inflating your effective cost per active user over time.
Per-active-user pricing
You’re charged only for users who take a defined action (which can include simply logging in) within a given billing period. Inactive accounts don’t count towards the bill.
- Pro: cost tracks actual use more closely than a per-seat model, which is particularly useful for tools with seasonal or uneven adoption across a team.
- Con: “active” doesn’t always mean fully elastic. Many active-user models still sit on top of a contracted baseline agreed at the start of the contract, meaning there’s a floor cost regardless of how few users are active in a quiet month.
Then there’s also what’s called ‘overage’. Which isn’t a straight ‘con’ per se but something to be aware of. The term simply refers to usage above that baseline, typically billed at a separate per-unit rate. It’s worth checking this detail specifically, since it’s easy to assume active-user pricing means paying purely for what you use when that isn’t always the case.
It’s also not unique to this model; overage can apply wherever a contract sets a baseline, so it’s worth checking regardless of which model a vendor quotes you (see the comparison table below).
Usage-based (consumption) pricing
You pay by volume: transactions processed, claims submitted, reports created and so on. This model is common in infrastructure and payments platforms where cost naturally scales with throughput.
- Pro: cost scales directly with the value you’re extracting from the platform, so a quiet month costs less and a busy month reflects genuine growth.
- Con: spend is harder to predict. A single unexpectedly busy period can produce a bill that catches finance off guard, which makes usage-based pricing a poor fit for organisations that need tight budget certainty.
Tiered or flat-rate pricing
Fixed packages, each bundling a set of features and usage limits at a set price point.
- Pro: simple to understand and compare, since each tier is a single number with a defined feature list attached.
- Con: awkward at the edges. Outgrowing a tier by a small margin, say a handful of extra users or a slightly higher transaction volume, often forces an upgrade to a much more expensive tier with far more capacity than you actually need.
Feature-gated pricing
A common model in our specific SaaS niche (spend management, that is). A base price covers core functionality, with specific capabilities available as paid add-ons layered on top.
- Pro: you only pay for the functionality you actually use, which can make this a genuinely cost-effective structure for teams with narrow requirements.
- Con: total cost is opaque until you’ve mapped your full requirements against the add-on list. Two organisations with similar-looking needs can end up with very different final bills depending on which add-ons turn out to be necessary in practice.
Different price models, in summary
| Model | How it’s charged | Pro | Con | Overage possible? |
| Per-seat | Flat fee per named user | Predictable | Pay for inactive accounts | No |
| Per-active-user | Only users that make an action | Tracks real usage | Often sits on a contracted baseline | Yes |
| Usage-based | By volume, e.g. transactions or calls | Scales with value | Unpredictable spend | N/A – the whole model is usage |
| Tiered / flat-rate | Fixed packages with limits | Simple to compare | Awkward between tiers | No |
| Feature-gated | Base price plus paid add-ons | Pay only for what you use | Total cost opaque until mapped | Sometimes |
A quick note on the “overage” column
Something to remember is that ‘no overage’ doesn’t necessarily mean ‘cheaper’. It means the cost shows up in a different place:
- Per-seat pricing bakes its inefficiency into the base price, since you’re paying full rate for every licensed user whether they log in or not.
- Active-user and usage-based models push their inefficiency into occasional spikes instead, charging more only when usage genuinely exceeds what you agreed.
This distinction matters more in expense management than in a lot of other SaaS categories, because expense activity is naturally uneven across a workforce. Finance and admin teams are in our platform constantly, but most employees only submit an expense when they’ve spent something.
With per-seat pricing, every one of those people needs their own named licence regardless of how rarely they use it.
With active-user pricing, you’re still contracting for a baseline that covers your core, regular users, but occasional or infrequent submitters don’t each need a dedicated seat set aside for them.
Instead, when needed those infrequent users draw against the baseline in the periods they’re actually active (rather than requiring individual licence allocation year-round).
What to check before comparing quotes
Before you put two vendor proposals side by side, get clear answers to the following:
- Does “per user” mean named or active? This single distinction can significantly change your effective cost.
- Is there a minimum commitment or contracted baseline? A low headline rate means little if it sits on top of a high floor cost.
- Are overages charged, and at what rate? Ask for the exact figure in writing rather than a general assurance.
- What counts as an “action”, a “transaction” or billable unit? Definitions vary between vendors even when the language sounds identical.
- Is support or onboarding included in the price, or billed separately? This is one of the most common sources of budget surprises after signing.
- Are there one-off setup costs? Implementation, configuration, data migration, and change management support are often billed separately from the recurring fee.
Get straight answers to these six questions from every vendor on your shortlist and you can compare quotes on genuinely equal terms.
How we price our platform
At this point, you might be wondering, ‘well, how do you price your product?’ A fair question. And one we’re pleased to answer. I’ll hit you with the jargon first (but I will explain):
We use active-user pricing with a contracted baseline, one-off implementation fee, and overage charges.
In practice, that means you agree a baseline number of active users upfront, which sets a predictable floor cost you can budget against from day one. If usage exceeds that baseline in each period, overage charges apply at an agreed rate.
This isn’t a fully elastic, pay-for-exactly-what-you-use pricing model (and we don’t present it as one). It’s designed to give you cost certainty at the outset, since you know your minimum spend before you commit, while still accommodating growth in your active user base without requiring a full contract renegotiation.
For finance teams that value knowing their floor cost in advance, this structure offers a middle ground between the unpredictability of pure usage-based pricing and the potential waste of paying for every named seat regardless of use.
Want to see not just what you’d pay, but what you’d get back? Try the Webexpenses ROI calculator and see your likely savings before you commit to any pricing model.
