The two models
Per seat. You pay for each named user with access. Cost scales with headcount. Familiar, easy to approve, and easy to compare across vendors.
Per environment. You pay per Dataverse environment where the thing runs, and the user count does not enter the invoice. Cost scales with your estate.
Neither is virtuous. They suit different products, and a vendor choosing one over the other is telling you what they believe drives their own cost.
Where the crossover sits
Take a per-environment product at €8,500 per production environment per year — our own DocGen and DMS — against a per-seat product, for one environment:
| Per-seat price | Users where per-seat costs more |
|---|---|
| €3 / user / month | ~236 users |
| €5 / user / month | ~142 users |
| €8 / user / month | ~89 users |
| €12 / user / month | ~59 users |
Two things fall out of that table. Below the crossover, per seat is genuinely cheaper and you should buy it. Above it, per-environment stops moving while per-seat keeps climbing — for the rest of the time you own the product.
The second is the one people miss during procurement: the crossover is not a one-off comparison. A firm that grows past it has bought an increasing bill for the same software.
Which model fits which product
A useful test: does an extra user cost the vendor anything?
For a hosted multi-tenant SaaS, yes — more users means more compute, more storage, more support. Per seat tracks something real.
For an add-on that deploys into your Dataverse and runs on your infrastructure, no. The hundredth user costs the vendor exactly what the first one did, which is nothing. Per-seat pricing there is not recovering a cost — it is capturing value, which vendors are entitled to do but should not describe as a cost model.
There is also a behavioural cost. Per-seat pricing on a document system punishes the thing that makes it work: everyone in the firm filing documents the same way. Charging per head for a convention you want universally adopted is a tax on the outcome you are selling.
The hidden costs of per seat
- Counting. Somebody maintains the user list against the licence count, forever.
- The true-up conversation. A year after the project ends, someone reconciles headcount and finds a variance. This is the conversation implementation partners like least, because it lands on them.
- Audit clauses. Per-seat contracts point at your user list. Read what the vendor is entitled to ask for.
- Adoption friction. "Can we give this to the graduates?" becomes a budget question rather than an obvious yes.
The hidden costs of per environment
It is not free of problems either, and a vendor who tells you it is has not thought about it from your side:
- Small teams overpay. Fifteen users on a per-environment licence are subsidising the model. If that is you, buy per seat.
- "Environment" needs defining, in writing. Ours is "any Dataverse environment where real business records are handled" — in the licence, not in a sales email. Ask for the definition before you sign, not after you spin up a second production environment.
- Multi-entity estates multiply. One licence per legal entity's production environment adds up quickly for a group.
- Dev and test can be charged. Ask. Ours are free, however many you run, because charging for good ALM is charging a firm for doing the right thing.
Questions worth asking, either model
- What exactly counts as a billable unit, in the contract?
- Are development and test environments charged?
- What happens at renewal if the count changed — automatic true-up, or a conversation?
- Is there an audit clause, and what does it entitle you to inspect?
- What happens if the licence lapses — does the software stop?
That last one matters more than it looks. For anything business-critical, hard enforcement means a billing dispute can stop a firm invoicing. Our own answer is that enforcement is deliberately soft: past renewal the software keeps working and the discrepancy is raised with the billing contact, not surfaced to end users. Whatever vendor you are talking to, get their answer in writing.
The short version
Small team, or a product genuinely hosted by the vendor: per seat, and per-environment pricing is probably overcharging you.
Large team, or an add-on running on infrastructure you already pay for: per environment, because the alternative is an invoice indexed to your own growth for software whose cost to supply did not change.
And whichever it is, make the vendor write down what a unit means.