B2B SaaS pricing models work best when the billing unit fits how customers receive value, buyers can estimate the bill, and the business can support heavy use. Use per-seat pricing when paid participation reflects value; usage pricing when a measurable activity drives value and cost; or a hybrid when a recurring platform benefit and variable consumption both matter.
This guide compares those choices using one fictional reporting product and three customer profiles. All prices, usage levels, and costs are invented teaching inputs in USD per month, not market averages, supplier quotes, or profitability forecasts. The result is a decision sheet you can adapt before implementing SaaS subscription billing.
Separate the model, package, and price
A pricing model defines how the charge is calculated. Packaging defines features, service levels, and limits. The price is the amount attached to those terms. A “Pro” label can describe many different models; it does not explain what the customer pays for.
Write the billable unit before naming plans. In a reporting product, a seat could mean an assigned editor, an active user, or anyone invited. A report could mean a successful completed report, every attempt, or each scheduled run. Those definitions produce different bills and behaviors.
A feature limit and a billable meter also have different jobs. An account may be allowed to generate a limited number of reports without paying per report. Conversely, metered usage can produce charges beyond an included allowance. Explain the boundary rather than relying on a small “fair use” note.
| Layer | Example decision | Question to settle |
|---|---|---|
| Model | Charge per assigned editor | Who counts and when? |
| Package | Viewer access and scheduled reporting | What is included? |
| Price | $12 per editor per month | Which currency and interval? |
| Guardrail | Preview and approve new charges | How does the buyer retain control? |
Stripe's pricing-model documentation is an implementation reference, not evidence that a supported model is commercially suitable. Start with the buyer and the operating economics, then choose the configuration.
Use the pricing table guide when presenting the final offer; keep this model decision separate from page layout.
Compare three customer shapes using one product
Imagine a tool producing client reports. A solo consultant has one editor and 100 completed reports monthly. An agency has ten editors and 1,000 reports. An automated operation has three editors and 10,000 reports. Assume support and account operations cost $8 per account each month, plus $0.01 per successfully completed report.
The example intentionally leaves out hosting overhead, development, acquisition, tax, payment fees, failed-computation cost, refunds, and many other expenses. “Contribution” below means revenue minus only the stated operating costs; it is not net profit or an accounting gross-margin claim.
| Customer | Editors | Monthly reports | Stated operating cost |
|---|---|---|---|
| Consultant | 1 | 100 | $8 + $1 = $9 |
| Agency | 10 | 1,000 | $8 + $10 = $18 |
| Automated operation | 3 | 10,000 | $8 + $100 = $108 |
Now compare four hypothetical offers: flat rate at $49 per account, per-seat at $12 per editor, pure usage at $0.08 per report, and hybrid at $29 including 500 reports plus $0.04 for each report above 500. The flat and seat examples deliberately have no report cap in this exercise, so the risk is visible.
Keep the product promise constant while examining the arithmetic. If one offer includes dedicated support and another does not, the comparison needs those differences documented. Use your content map to understand which customer jobs the offers are meant to serve.
Flat-rate pricing: simple bills, uneven consumption
Flat rate makes purchasing predictable: one account pays the stated amount for the stated package. It can fit a product with reasonably bounded service costs and limited variation in customer demand. Simplicity becomes a problem when the same price covers radically different workloads.
Under the fictional $49 offer, the consultant contributes $40, the agency $31, and the automated operation negative $59 against the costs included in the exercise. That last result is a signal to revisit the offer, limits, customer segment, or underlying cost. It does not establish what your real business will earn.
Before offering “unlimited,” document what usage is sustainable and how exceptional workloads are handled. If there are meaningful limits, make them visible. If the offer requires negotiation above a threshold, explain the threshold before a customer depends on the service.
An enterprise contract can still use a flat account price, with negotiated scope and service commitments. “Enterprise” describes a selling and purchasing context, not a separate arithmetic model. Procurement, invoicing, security review, and implementation may change the package even when the bill formula remains simple.
For the payment and merchant-responsibility side, use the SaaS payment setup comparison.
Per-seat pricing: define paid participation
At $12 per editor, monthly revenue is $12 for the consultant, $120 for the agency, and $36 for the automated operation. Against the stated costs, contribution becomes $3, $102, and negative $72. Seats align well with a collaborative agency but poorly with a small team running a large automated workload.
Decide who counts: editors, viewers, guests, service accounts, or active users. Define the measurement period, the effect of adding and removing a seat, and who can authorize that change. If an invitation creates a charge, the owner should understand it before sending.
Per-seat pricing can discourage collaboration if every occasional reviewer becomes expensive. You might choose free viewers and paid editors, but that is a packaging decision to validate against both value and cost. Do not promise unlimited guest access if guests drive significant support or infrastructure demand you have not modeled.
Test the invoice consequences of mid-cycle quantity changes and explain the applicable adjustment policy. Provider support for quantities does not decide whether a removed user keeps access or receives a credit. Those are product and commercial rules.
The SaaS onboarding checklist provides a place to test whether role and invitation rules confuse first-time teams.
Usage pricing: make the unit defensible
At $0.08 per completed report, the profiles produce revenue of $8, $80, and $800. Contribution is negative $1, $62, and $692 within the exercise. Heavy activity pays more, but a low-volume account may not cover its fixed support cost.
Choose a unit customers can understand, estimate, and audit. A successful report may be clearer than raw compute time, yet it can hide differences in report size. If a report can contain one row or a million rows, you may need another unit, differentiated limits, or a workload policy.
Define failed jobs, retries, cancellations, duplicates, time boundaries, and late usage. A technical retry should not accidentally charge for the same promised outcome twice. Your recording and correction process must survive delayed or repeated events. Stripe's current usage-based billing guidance provides implementation options; choose the approach appropriate to your actual integration.
Show customers current consumption and an understandable estimate. Set alerts and specify whether a budget limit stops activity, requires approval, or simply sends a notification. An alert is not a hard spending cap unless the product enforces it.
Connect metered charges with the billing lifecycle, so the product can explain a charge and handle disputes without guessing from activity logs.
Hybrid pricing: cover a base and expose overage
The hypothetical hybrid costs $29 with 500 reports included, then $0.04 per additional report. The consultant pays $29. The agency pays $49 because 500 reports exceed the allowance. The automated operation pays $409 because 9,500 reports exceed it.
| Model | Consultant bill / contribution | Agency bill / contribution | Automated bill / contribution |
|---|---|---|---|
| Flat $49 | $49 / $40 | $49 / $31 | $49 / -$59 |
| $12 per editor | $12 / $3 | $120 / $102 | $36 / -$72 |
| $0.08 per report | $8 / -$1 | $80 / $62 | $800 / $692 |
| $29 + overage | $29 / $20 | $49 / $31 | $409 / $301 |
Hybrid can connect recurring platform value with variable costs, but it needs more explanation. Specify when allowances reset, whether unused units roll over, whether accounts share a pool, and how usage is treated when a plan changes. The example assumes no rollover and a simple monthly allowance; those are invented terms, not provider defaults.
The largest number in the table is not automatically the best offer. A buyer may reject an unpredictable bill, choose a competitor, reduce activity, or require a commitment discount. Willingness to pay and retention are missing from this arithmetic. Validate them through customer conversations and observed behavior.
Use freemium versus free trial to decide how a prospect experiences this model before paying.
Keep volume tiers distinct from graduated tiers
Tiered pricing is a calculation method, not just three feature cards. In a hypothetical usage schedule, the first 1,000 units cost $0.10 each and higher units cost $0.08. For 1,200 units, a graduated calculation charges $100 plus $16, totaling $116. A volume calculation applying $0.08 to all 1,200 units totals $96.
Specify which interpretation applies. At a volume threshold, the total bill can decrease when the rate for all units changes; validate that this behavior is intended. Graduated tiers avoid that particular all-units repricing effect, but still require clear boundaries and minimums.
Feature tiers are different again: Basic and Pro may use either graduated usage, flat rates, seats, or a hybrid. Put a worked bill next to the offer when the formula is difficult to infer. Do not expect a visual comparison table alone to explain a nonlinear calculation.
Review provider configuration against the intended formula and test boundary quantities. The pricing table article covers how to present those choices without making the page carry undocumented billing logic.
Use a decision sheet before implementation
Choose a candidate model using customer value, buying predictability, cost variation, measurement reliability, and expansion behavior. Then test the most unfavorable plausible customer profile, not only your average customer. Include acquisition, support, infrastructure, payment, and operational assumptions when evaluating the actual business.
| Decision | Write down | Evidence to gather |
|---|---|---|
| Buyer and value unit | Who approves and what outcome they buy | Customer interviews and purchase objections |
| Bill formula | Base, quantities, tiers, and interval | Worked invoices at boundary values |
| Cost exposure | Fixed and variable cost drivers | Measured workload and support data |
| Change policy | Effective date and adjustments | Upgrade, downgrade, and cancellation tests |
| Customer control | Alerts, estimates, approval, or limits | Buyer can predict and explain a sample bill |
| Transition | Existing terms and migration path | Customer communication and compatible implementation |
Keep the original terms attached to existing subscriptions when required by your policy and agreements. Do not silently change what an existing buyer owes because the public pricing page changed. Version prices and document the transition, with appropriate review for actual contracts.
Implement only after the offer is explainable. Use the subscription billing guide for lifecycle consistency and the website launch checklist to verify that the purchased offer and delivered access match.


