Vertical SaaS · Saas

Licensing Models for Vertical SaaS on Acumatica

A comparison of per-seat, per-transaction, and site-license models for vertical SaaS, and how to pick one that matches how your customers actually derive value from the product.

John Kihiu12 min read

The licensing model is one of the few pricing decisions that's genuinely hard to change once customers have signed on it — moving an installed base from per-seat to usage-based pricing is a renegotiation with every existing customer, not a config change. Getting the model right early matters more in vertical SaaS than in horizontal SaaS, because vertical products often have a much clearer natural unit of value that the pricing model should track.

Per-seat: simple to sell, often the wrong fit

Per-seat pricing is easy to explain and easy for customers to budget for, which is why it's the default most SaaS products start with. It fits well when the product's value scales roughly linearly with the number of people using it — a project management tool, for instance. It fits badly when value comes from a small number of power users driving outsized business impact, or from automation that reduces headcount rather than requiring more of it — a vertical SaaS product that helps a business run with fewer staff is charging the customer more for a smaller team, which is an awkward incentive to build a pricing model around.

Per-transaction pricing aligns with value, at the cost of revenue predictability

Charging per invoice processed, per shipment tracked, or per transaction handled ties price directly to the value the customer is extracting, which is the theoretically cleanest alignment. The tradeoff is revenue volatility on both sides: a customer's slow season means your revenue drops too, and a customer can't budget a fixed line item for your product the way they can for a per-seat subscription. This model works best when the transaction volume itself is what customers already track and forecast internally — logistics, payments, invoicing — so your pricing maps onto a number they already understand.

Hybrid models are common for a reason

A base platform fee plus usage-based overage combines predictable revenue for you and predictable minimum spend for the customer, with upside tied to actual usage growth. Most mature vertical SaaS pricing ends up here rather than at either pure extreme — pure per-seat undercharges high-usage customers, pure usage-based makes revenue forecasting hard for both sides.

Site licenses solve a specific enterprise procurement problem

Large enterprise customers sometimes explicitly prefer a flat site license over per-seat or per-usage pricing, because it simplifies internal cost allocation and procurement approval — one line item instead of a variable cost that finance has to forecast every quarter. Site licenses generally only make sense above a certain deal size, since underpricing a large account into a flat fee to win the deal can quietly erode margin as that customer's actual usage grows past what the flat fee assumed.

The real question: what does the customer already measure as their value driver

The most durable licensing model tracks a metric the customer already cares about and already measures internally, not a metric that's merely convenient for you to bill on. If your customers already report "invoices processed per month" as a KPI to their own leadership, pricing per invoice is intuitive to them. If they think in terms of headcount, per-seat is intuitive. Picking a billing unit the customer has to translate in their head to understand their bill creates friction at renewal time even if the underlying economics are sound.

Wrapping up

There's no universally correct licensing model — the right one depends on whether your product's value scales with headcount, transaction volume, or something else entirely, and whether that unit is something your customers already think in. Most mature vertical SaaS businesses land on a hybrid of a base fee plus usage, but the starting point should always be how the customer already measures the value they're getting, not which model is easiest to implement in your billing system.

John Kihiu
Acumatica ERP Developer · Laravel Engineer

Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.