Why SaaS Pricing Is Getting Harder to Compare in 2026: Seats, Credits, Usage and AI Add-Ons

SaaS pricing is getting harder to compare because the bill increasingly depends on more than one unit. A subscription can cover access, seats can determine who uses the product, credits can meter AI features, usage charges can track activity, and separate add-ons can sit on top of all three.

The result is a normalization problem. A $20-per-user product and a $30-per-user product are not directly comparable if the first also charges for AI actions, workflows or overages while the second includes them.

The question buyers need to answer in 2026 is no longer simply, "What does this plan cost?"

It is:

"What will this software cost at our actual level of use?"

Current pricing research supports the shift toward mixed models, although no single dataset represents the entire SaaS market. A September 2026 review of 107 AI software pricing pages by Maxio found that many products combine two or three pricing mechanics and that no single category accounted for more than 28% of the sample. Vertice's Q2 2026 pricing data reported another fragmented split: 36.5% per-usage pricing, 32.4% per-user pricing and 31.1% hybrid pricing in its dataset.

Those figures should be treated as directional rather than a census of SaaS. The stronger evidence sits on the pricing pages themselves. HubSpot combines seats with credits. Intercom combines seats with usage and outcome charges. Notion keeps seat pricing while metering some autonomous agents with credits. Twilio can meter messages, active users, storage and other components depending on the product.

The difficult part is no longer finding a price. It is converting different pricing architectures into the same economic unit.

SaaS buyers increasingly have to compare different billing units

A traditional software comparison could be straightforward:

50 users × $25 per user per month = $1,250 per month.

That calculation still applies to many products. But products that compete for the same budget can now measure consumption in completely different ways.

One vendor may bill every provisioned user. Another may bill active users. Another may charge a platform subscription plus AI credits. Another may charge for messages or workflow executions. Another may charge when an AI agent resolves a conversation.

These units are often called value metrics: the units a company uses to connect price with how customers use or receive value from the product.

A value metric can be a user, contact, transaction, API request, gigabyte, token, workflow run, credit, generated output or resolved conversation.

Stripe's 2026 guide to AI SaaS pricing describes the value metric as the unit that tracks customer benefit and argues that AI creates tension when usage and underlying computing costs grow independently of employee count.

That distinction changes how software should be compared.

The same headline monthly price can therefore sit on top of very different cost structures.

A "seat" can mean more than one thing

Per-seat pricing remains useful when the number of users reasonably tracks the amount of value a customer receives.

That applies naturally to many collaboration, productivity, CRM and administrative products.

The problem is that vendors do not always define a billable user the same way.

Slack's Fair Billing Policy provides a clear example. Slack bills paid workspaces for active members rather than every account indefinitely. A paid member who has not used Slack for more than 28 days becomes inactive for billing purposes, and Slack applies a prorated account credit for unused time. Full members and multi-channel guests are billable, while single-channel guests and bots are not.

Slack also prorates newly added members. For some annually invoiced customers, increases beyond the member count already paid for are settled quarterly.

So even before AI enters the calculation, "50 users" can mean several things:

A product could charge for 50 named accounts. Another could effectively charge for 43 active users. Another could require a contractual seat minimum regardless of actual adoption.

A procurement model that simply multiplies employee count by public seat price can therefore produce the wrong number.

AI adds another weakness to seat-only comparisons. Two employees can hold identical licenses while generating dramatically different AI workloads. One might use a few summaries per week. Another might run autonomous processes throughout the day.

The seats are identical. The workload is not.

That does not mean per-seat SaaS pricing is disappearing. Maxio's pricing-page review found a platform or seat fee somewhere in the pricing structure of 39% of the products it examined. Its interpretation was that seats often remain as a base layer while vendors add consumption or outcome charges above them.

That conclusion fits several current product structures better than the claim that AI will simply eliminate seats.

Usage-based SaaS pricing shifts the comparison toward workload

Usage-based pricing charges according to consumption rather than, or in addition to, access.

The meter can be an API call, message, transaction, compute unit, gigabyte of storage, workflow execution, record processed, token or another measurable event.

The FinOps Foundation's SaaS guidance defines consumption-based SaaS as software where the customer is charged based on actual usage rather than only a fixed license or subscription.

The advantage is straightforward: spending can follow activity more closely.

The forecasting problem is equally straightforward: activity changes.

Twilio provides a useful real-world example because the underlying units are visible. Its current US SMS pricing documentation starts SMS at $0.0083 per inbound or outbound message for common US number types, but that figure does not describe the whole messaging bill. Carrier fees can apply, messages can be charged by segment, and phone numbers have their own monthly fees.

Twilio's broader Messaging pricing documentation describes pricing as a combination of monthly volume, API, sender and channel fees.

Another Twilio product shows how even one vendor can use several meters. The Conversations API currently charges by monthly active user and separately meters media storage, with standard messaging rates applying where relevant.

"Usage-based pricing" is therefore a category, not a standardized billing method.

The comparison needs to move one level deeper:

What activity creates a billable event, how often will we create that event, and what else gets charged alongside it?

Credits make SaaS pricing harder because they introduce a conversion layer

Credit-based SaaS pricing takes usage and translates it into a vendor-specific internal unit.

The important point is that a credit is not a standardized economic unit.

One credit from Vendor A has no necessary relationship to one credit from Vendor B.

HubSpot demonstrates the problem clearly. Its current HubSpot Credits documentation lists a standard rate of $0.010 per credit and $10 for a 1,000-credit capacity pack. The company also offers pay-as-you-go overages beyond a customer's monthly allowance.

But buyers still cannot estimate AI cost from the credit price alone.

HubSpot's own product documentation says its Customer Agent consumes 50 credits for a resolved text conversation. Its broader rate sheet contains other features with different credit requirements.

HubSpot also states that included credits refresh each month and unused credits do not carry over.

Now compare that with Notion.

Starting in May 2026, Notion Custom Agents began using Notion credits. Monthly credits cost $10 per 1,000, are shared across the workspace and reset monthly. Unused monthly credits do not roll over. Other Notion AI features such as Notion Agent, AI Meeting Notes and Enterprise Search remain included in Business and Enterprise plans.

The numbers look similar at first glance: 1,000 credits for $10.

The units are not comparable.

Notion's credit documentation explains that Custom Agent consumption depends on the work performed. Reading more content, taking more actions, using more tool calls and running more frequently can increase credit use.

So comparing "10,000 HubSpot Credits" with "10,000 Notion credits" tells you almost nothing by itself.

The useful conversion is:

Dollar price of credits × credits required per business task × expected number of tasks

Then check what happens to unused capacity, overages and high-consumption tasks.

Credits can make complicated compute or AI activity easier to package commercially. They can also make cost comparison harder because the buyer has to translate an abstract balance back into actual work.

Credit economics depend on rules beyond the sticker rate

The conversion rate is only one part of credit-based pricing.

You also need to know whether credits are pooled across an account or attached to individual users, whether they expire, whether they roll over, what happens when the pool reaches zero, whether administrators can set limits and whether different actions consume different quantities.

Notion, for example, shares Custom Agent credits across the workspace. Its documentation says agents automatically pause when the workspace lacks sufficient credits, and administrators receive notifications at specified consumption thresholds.

HubSpot uses a different overage design. Its current credits page says pay-as-you-go is the default overage setting for customers and charges for credits used beyond the monthly limit, with the account returning to its original limit on the next reset date.

Those policies change the financial risk.

A hard stop can interrupt workflows but restrict unexpected spend.

Automatic overage preserves service but can create a larger invoice.

Neither structure is inherently better. Buyers need to know which risk they are accepting.

"AI included" can describe very different offers

The phrase "AI included" has become too broad to use as a purchasing criterion.

AI can be packaged several ways inside SaaS pricing: included in a normal subscription, limited to certain tiers, sold as a per-user add-on, metered through credits, charged according to raw usage, or priced separately when an autonomous agent performs work.

Google provides one version of inclusion. Its Workspace documentation says Gemini AI features began moving into Business and Enterprise Workspace subscriptions in January 2025, replacing several previous Gemini add-ons. The exact AI capabilities available still depend on the Workspace edition.

Microsoft provides another structure. The current US Microsoft 365 Copilot pricing page offers Copilot Business on a per-user basis and also bundles Copilot into some Microsoft 365 Business subscriptions. Microsoft's documentation notes that the Copilot Business add-on requires an eligible Microsoft 365 subscription.

Notion combines the two ideas. Core AI capabilities remain included in Business and Enterprise plans, while Custom Agents consume separately purchased credits.

Intercom goes further by combining several pricing meters in one product family.

Its current pricing page describes the main Intercom platform in terms of seats while charging separately for usage such as Fin outcomes and certain messaging channels. It also sells optional add-ons.

This means the procurement question should not be:

"Does AI come with the plan?"

It should be:

"Which AI functions are included, which are capped, which create variable charges, and what happens when usage grows?"

AI creates a legitimate reason for vendors to meter activity separately

The added complexity is not necessarily arbitrary.

Generative AI can create variable costs whenever a model processes input, generates output, searches data, invokes tools or completes a multi-step task.

Raw AI APIs make that structure easy to see. Anthropic's current Claude Sonnet 5 pricing is based on separate input and output token rates rather than the number of people using the model.

A SaaS company building on AI infrastructure does not have to pass raw token pricing through to customers. Many deliberately avoid doing so because tokens are difficult for nontechnical buyers to forecast.

Instead, the vendor can translate underlying compute into a more understandable commercial unit: a credit, an agent run, a document, a resolution or another unit of work.

Stripe describes the same economic pressure in its 2026 AI SaaS pricing analysis. Usage can increase provider cost independently of seat count, while pure usage pricing can expose customers to less predictable invoices. That tension helps explain the attraction of hybrid pricing.

This is a more useful explanation than claiming that AI has made per-seat pricing obsolete.

AI has created more situations where the seat is an incomplete measure of both customer activity and vendor cost.

Hybrid pricing is where the normalization problem becomes obvious

Hybrid SaaS pricing combines fixed and variable charges.

A buyer might pay:

base subscription + seats + usage + credits + add-ons + overages

The exact combination depends on the product.

Intercom is a clear current example. Its pricing page explicitly says that pricing has two broad components: seats and usage. Fin AI Agent can be charged by outcome while messaging channels can introduce other usage charges.

HubSpot explicitly described its move toward seats plus credits as a form of hybrid pricing for AI products.

Notion keeps the workspace seat price intact while separating Custom Agent activity into a credit-based add-on through its Custom Agents model.

These models can give the vendor predictable recurring revenue while attaching variable charges to costly or high-volume activity.

They can also give the customer a predictable base cost.

But they weaken the usefulness of headline-price comparisons.

A $20 seat price is not necessarily cheaper than a $30 seat price if the $20 product requires additional AI credits, add-ons and overage capacity for the workload you intend to run.

Outcome pricing still needs a billing definition

AI agents have also renewed interest in outcome-based pricing.

But "outcome" needs careful treatment.

A generated document is an output.

An invoice processed is a unit of work.

A support conversation completed without a person may be an operational outcome.

Revenue generated from that interaction is a broader business outcome.

Those units should not be treated as interchangeable simply because a vendor uses the word "outcome."

Intercom provides a useful concrete example. Its Fin outcome documentation currently charges $0.99 for several service outcomes, including a resolution or successful procedure handoff, and $9.99 for a defined sales qualification. Intercom says customers are charged at most once per conversation and are not billed when the specified outcome does not occur.

That is materially different from charging for every AI token or every message.

It still requires the buyer to understand the operational definition.

For example, Intercom defines a resolution according to how the conversation ends after Fin's response, including confirmed and assumed resolutions.

The buyer should therefore compare the billing trigger, not the marketing label.

SaaS comparison now resembles a normalization exercise

The normalization issue extends well beyond individual vendors.

The FinOps Open Cost and Usage Specification, or FOCUS, was created partly because providers use inconsistent billing schemas and terminology. The specification describes that inconsistency as an obstacle to cost allocation, budgeting and forecasting across providers.

FOCUS covers cloud and increasingly SaaS-style cost data. Its SaaS examples distinguish concepts such as consumed quantity, pricing units, recurring charges and usage-based charges.

That provides a useful principle for SaaS procurement even when a vendor does not expose FOCUS-formatted data:

Separate the price from the unit that generates the price.

For every vendor under consideration, normalize at least these fields:

This moves the comparison away from pricing-page layout and toward actual economics.

The useful comparison is cost per realistic workload

Start by defining what you expect the software to do.

For collaboration software, that might be 50 employees, 35 regular users, 10 occasional users and five guests.

For an AI support system, it might be 20 service agents, 30,000 monthly customer conversations and an expected 40% AI handling rate.

For an automation platform, it might be 100,000 workflow runs, 500,000 processed records, 15,000 AI actions and a defined amount of storage.

Only after defining the workload should you translate each vendor's pricing structure into dollars.

A useful vendor-cost model is:

Estimated annual SaaS cost = base/platform charges + seat charges + required add-ons + expected usage or credit charges + expected overages + mandatory implementation or onboarding + required support or service fees

Not every vendor includes every component.

This is narrower than full total cost of ownership. A broader SaaS TCO calculation can then add internal administration, migration effort, integration work and other costs created by adopting and operating the tool.

Keeping the two calculations separate is useful. It tells you whether a cost difference comes from the software contract or from the work required to implement it.

A hypothetical 50-person comparison shows why the workload matters

Consider a fictional 50-person US company comparing three AI-enabled tools.

The numbers below are hypothetical. They do not represent any real vendor.

Apply the same workload to all three.

At low usage, Tool C costs least.

At 10,000 monthly actions, Tool B costs least.

At 25,000 actions, Tool A costs least because the workload remains inside its included allowance.

None of those relationships can be discovered by comparing seat prices alone.

Tool B also demonstrates the credit problem. Twenty thousand included credits sound generous until the buyer knows that each modeled action consumes two credits. The useful capacity is therefore 10,000 actions.

That conversion should happen before procurement compares the products.

The public price can be correct and still be incomplete

Not every additional cost is a hidden fee.

Often, the pricing page publishes the rule. Buyers simply miss it when they copy the largest displayed number into a spreadsheet.

A seat price might assume annual billing.

A credit pool might reset monthly.

Unused credits might expire.

A feature might require a higher base plan before you can buy the add-on.

Usage might trigger automatic overage billing.

A product might require additional spending for API capacity, storage, implementation, premium support or advanced controls.

Even pricing cadence can change the effective unit cost.

HubSpot provides a current example. Its main HubSpot Credits documentation lists a standard price of $0.010 per credit, while some annual pricing structures can change the effective economics of purchased capacity.

That is not contradictory pricing. It is contract context.

Microsoft provides another example. Its US Copilot Business pricing page can show different rates depending on the purchasing and commitment structure.

A pricing comparison therefore needs to normalize billing frequency as well as the usage metric.

Variable SaaS costs should be modeled in scenarios, not one forecast

The FinOps Foundation's forecasting guidance offers a useful approach for consumption-based software.

Its forecasting guidance recommends combining historical cost and usage data with planned changes in demand and technology.

You can apply the same principle to SaaS.

For variable software, model three practical states in your purchasing spreadsheet: current or low usage, expected adoption, and a credible high-use case.

The low case establishes the spending floor.

The expected case should reflect the level of adoption you realistically expect after rollout, not pilot usage alone.

The high-use case should test what happens if AI activity, automation volume, transactions or user adoption rises materially.

For a multi-year agreement, repeat that model across the contract period.

This method matters because automation changes usage differently from traditional seat growth. A company does not need to double its employee count to double the number of API calls, agent runs or AI-generated outputs.

The questions procurement asks should follow the billing model

A procurement team does not need a 50-question pricing checklist.

It needs to resolve the variables that could materially change the invoice.

For seats, establish who counts as billable, whether inactive users remain billable, how guests work, whether minimum seats apply and when true-ups occur.

For usage, establish exactly what event is metered, what volume is included, the overage rate and whether administrators can set hard caps or alerts.

For credits, determine what the major business actions consume, whether credits are pooled, whether they expire, whether unused capacity rolls over and what happens when the balance reaches zero.

For AI, identify which capabilities come with the base plan and which require a separate add-on, credit pool, higher tier or usage charge.

For the contract, normalize monthly and annual pricing, minimum commitments, promotional terms and renewal pricing.

Then ask one final question:

What would this product cost if our usage doubled?

That single stress test often exposes the difference between an attractive starting price and a sustainable software budget.

SaaS pricing transparency is now about reconstructing the invoice

A SaaS company can publish every individual rate and still leave buyers with significant work to estimate the final bill.

Credit pricing is useful only when customers can connect credits to real tasks.

Usage pricing becomes predictable only when the metered event and likely volume are understood.

Outcome pricing becomes comparable only when the billing definition is clear.

Per-seat pricing becomes meaningful only when the buyer knows who counts as a seat.

Hybrid pricing requires all of those calculations at once.

This suggests a practical test for SaaS pricing transparency in 2026:

Can your finance or procurement team take a realistic workload, apply the vendor's published or contracted rules, and reproduce an expected invoice?

If it cannot, the pricing comparison is not finished.

The most reliable purchasing method is therefore to compare identical workloads rather than identical pricing-page labels.

Define the users, activity, AI work and capacity your company expects to consume. Convert each vendor's pricing architecture into annual dollars. Run a high-consumption scenario. Add required contract costs. Then compare the totals.

A lower seat price can produce a higher annual bill.

A larger credit allocation can represent less usable work.

An AI feature can be "included" while autonomous agent activity is charged separately.

The unit that makes SaaS pricing comparable is not the seat, credit or token.

It is the same workload, priced through each vendor's model.