Every SaaS T&E product I have quoted for a customer in the last five years is priced per employee per month. Five dollars, ten dollars, fifteen dollars, sometimes with tiering. It is such a default that most customers do not even ask whether alternatives exist.
We priced SpendFlow — our T&E, corporate-card, per-diem, mileage, approval and posting suite for Business Central — per tenant. A single monthly price for the tenant, tiered by module and country pack, not by headcount.
This post is why. It is not a pricing tactic. It is a claim about what the product is actually selling.
The per-employee incentive graph
When you price per employee, your incentive is to make sure everyone at the customer uses your product. Every additional user is revenue. Small teams pay less; large teams pay more. The product manager's job becomes an engagement job — activation, adoption, weekly active users, expansion revenue.
That would be fine if the value the product delivers scaled linearly with the number of employees using it. It does not. The value of a T&E product is: fewer expense reports missing receipts, faster reimbursement, cleaner card reconciliation, better spend visibility, correctly-posted GL entries. Each of those is either a per-transaction effect or a per-company effect. None of them are per-employee.
A 50-employee company running SpendFlow gets: correctly-posted GL entries. A 500-employee company running SpendFlow gets: the same, at higher volume. The engineering surface is identical. The support surface scales with transaction count and with company complexity, not headcount. Per-employee pricing charges the 500-employee company 10× more for the same product because it can — not because the product costs 10× more to deliver.
That is a rent, not a fair price.
The per-tenant incentive graph
When you price per tenant, your incentive is to make sure the product is genuinely useful at the tenant level. Every additional customer is revenue; growing existing customers is not. This shapes the product's roadmap: you build features that make one customer more successful, not features that make a customer's rollout to more employees more sticky.
It also collapses the sales conversation. There is no per-user calculator on the pricing page. There is no "estimate your team size." The tier a customer picks is determined by which modules and country packs they need — real product complexity — not by how many people they employ. Enterprise customers who have historically resented paying $15,000/month for a T&E product they could easily replace with a spreadsheet are pleasantly surprised. Small companies who could never justify $500/month for the same are relieved.
The revenue-per-customer distribution flattens. This is fine — it is the correct distribution for a system-of-record extension. The right price for SpendFlow is what SpendFlow is worth as a piece of software installed in a BC tenant, not what it is worth as a subscription paid per person.
What we give up
Real answer: expansion revenue.
The per-employee playbook has a beautiful growth motion — sign a small pilot at five users, expand to twenty, then to a hundred, then to five hundred. Every expansion is easy, because the customer has already committed to the product and the marginal decision is small. Sales teams love this. Investors love it too. It maps neatly to net revenue retention charts.
Per-tenant pricing does not have this motion. A customer pays their tier this year and the same tier next year, unless they add a country pack or upgrade to include the AI matcher. Growth per customer is modest. New revenue has to come from new customers.
We think that is the right trade-off for two reasons.
First, the customers we want are BC customers who need a full T&E suite. They know at signup whether they need Core + Cards + Approvals or the full Core + Cards + Approvals + AI + India Pack. There is no adoption ramp. There is a discovery-configure-cutover project measured in weeks, and then the product is either fully in use or not in use. A five-user pilot does not mean anything for a T&E product because employee expenses are not opt-in — either the company runs expense claims through SpendFlow, or it runs them through the previous system. There is no half-adopted state.
Second, we do not want the perverse incentive to hide value in higher-tier features to force upgrades. Every module in SpendFlow is genuinely useful. If we priced per-employee, we would eventually be tempted to move a legitimately-core feature — say, the corporate card reconciliation — into a higher tier so that customers had to upgrade for it. Per-tenant pricing removes that temptation entirely. The tiering is by module scope, not by artificial gating.
What the customer sees
The quote for SpendFlow is straightforward: a monthly fee that depends on the module set and country packs selected. A 50-employee customer and a 500-employee customer on the same modules pay the same price. A customer that decides to add the GCC pack six months in pays the pack price for the pack. That is all.
There are no per-user calculators. There is no minimum seat count. There is no distinction between "essentials" and "professional" for the same underlying functionality — the modules are the modules, and the customer picks the modules they need.
We have had exactly one enterprise customer object to this. They wanted to negotiate a per-employee price because their procurement process demands a per-employee price. We politely declined and quoted the tier. They signed the tier. The quote-negotiate-close cycle was thirty percent shorter than the per-employee equivalents they had done before, and their finance team was measurably happier.
What we would tell another SaaS founder
If your product delivers value at the company level or at the transaction level — not at the individual-user level — do not price per user. It is default, and defaults are lazy. It punishes larger customers for using your product exactly the way you designed it, and rewards you for building growth mechanics that do not serve the customer.
Per-tenant pricing looks like it leaves money on the table until you count the CAC savings, the closed-won rate improvement, and the reduced quote-to-cash friction. Then it looks like the trade you should have made two years ago.
We made it in SpendFlow. We are making the same call for Planning Studio and Direct Banking. It is not a promotion; it is what we think the price of the product actually is.