Pricing a SaaS product affects billing architecture, customer expectations, support effort, revenue reporting and the ease of changing plans later. This section helps teams compare models by operational consequences rather than by headline price alone.
| Start here | What the section helps you decide | Practical outcome |
|---|---|---|
| How Subscription Billing Works | Subscription billing is the mechanism that turns a SaaS product into a recurring business. | Rather than charging a one-off licence fee, the customer pays at regular intervals — typically monthly or annually — for continued access to the software. |
| Choosing a Subscription Billing Provider | The billing provider sits between your application and the payment gateway. | It manages subscriptions, invoices, proration and customer portal functions, while the payment gateway handles the actual card processing. |
| Pricing Strategies for SaaS Products | Pricing a SaaS product is not a one-time decision made before launch. | It is an ongoing process that should be revisited as you learn how different customer segments value different features. |
| Free Trial vs Freemium vs Paid-Only SaaS Models | The entry model you choose affects your conversion funnel, your support costs and the type of customer you attract. | Each approach has a specific set of conditions under which it works well. |
How Subscription Billing Works
Subscription billing is the mechanism that turns a SaaS product into a recurring business. Rather than charging a one-off licence fee, the customer pays at regular intervals — typically monthly or annually — for continued access to the software. The billing system handles several tasks that are easy to underestimate at the planning stage.
At its core, the process follows a cycle: a customer subscribes, the system creates a billing schedule, a payment is collected on each renewal date, and the subscription remains active until it is cancelled or payment fails. Where SaaS billing diverges from a simple recurring card charge is in the handling of edge cases that arise in real operations.
When a customer changes plan partway through a cycle, the system must calculate proration — the proportional charge or credit for the unused portion of the old plan. When a payment fails, the system needs a retry schedule and a dunning process: automated reminders that escalate in urgency before the subscription is suspended or cancelled. When a customer is billed in a different currency, the system must handle exchange rates and, for UK businesses selling into the EU, the correct VAT treatment on each transaction.
These are not features you want to build from scratch in an early-stage product. The logic around date boundaries, timezone handling, failed-payment recovery and tax calculation is substantial, and errors in any of these areas create direct revenue loss or compliance risk. The practical decision for most SaaS founders is to integrate a specialist billing provider rather than developing custom billing logic.
Choosing a Subscription Billing Provider
The billing provider sits between your application and the payment gateway. It manages subscriptions, invoices, proration and customer portal functions, while the payment gateway handles the actual card processing. Some providers bundle both functions; others integrate with a gateway you choose separately.
Evaluating a billing provider means checking several dimensions that matter differently depending on your market and scale:
- Supported payment methods and currencies. If you plan to sell internationally, check which currencies and local payment methods the provider supports and whether it handles automatic currency conversion.
- VAT and tax calculation. For UK businesses, the provider should be able to apply the correct VAT rate based on the customer's location, handle the reverse charge for B2B EU sales, and produce VAT-compliant invoices. Confirm whether tax calculation is included or requires an additional integration.
- Proration and plan-change logic. Understand exactly how the provider calculates mid-cycle upgrades and downgrades. Different providers use different default approaches, and customising this behaviour can be limited or costly.
- Dunning and failed-payment handling. Check what retry logic is configurable, what customer communications are built in, and at what point a subscription is automatically cancelled.
- API quality and webhooks. Your application needs to react to billing events — payment succeeded, subscription cancelled, invoice generated. Assess the API documentation and the reliability of webhook delivery, including retry behaviour and signature verification.
- Customer self-service. Most SaaS customers expect to view invoices, update card details and cancel their own subscription without contacting support. Check what self-service portal the provider offers and how much it can be branded or embedded.
- Pricing model of the provider itself. Some charge a percentage of transaction volume, others a flat monthly fee, and many use a combination. Model the total cost at your expected revenue levels, not just at launch.
A common mistake is choosing a provider based solely on its free tier or lowest-cost plan without checking whether it supports the billing behaviour your pricing model actually requires. Map your planned pricing tiers, upgrade paths and tax scenarios first, then evaluate providers against those requirements.
Pricing Strategies for SaaS Products
Pricing a SaaS product is not a one-time decision made before launch. It is an ongoing process that should be revisited as you learn how different customer segments value different features. There are three broad starting points, each with distinct trade-offs.
Cost-plus pricing calculates the cost of delivering the service — infrastructure, support, development — and adds a margin. This approach is straightforward but fundamentally misaligned with how SaaS customers buy. A customer does not care about your server costs; they care about the value the product delivers to their business. Cost-plus pricing also makes it difficult to capture additional value as your product improves.
Competitor-based pricing sets your price relative to existing alternatives. This is useful as a sanity check — if your price is an order of magnitude above or below comparable products, you need a clear explanation for why. The limitation is that it assumes competitors have priced correctly, and it encourages a race to the middle rather than differentiation based on your product's specific strengths.
Value-based pricing anchors the price to the measurable outcome the customer achieves. If your product saves a operations manager ten hours per week, the price should be a fraction of the cost of those hours. This approach typically yields the highest sustainable prices, but it requires genuine understanding of your target customer's economics — which is why it works best after you have initial customers to learn from, not before.
In practice, most SaaS founders use a blend: value-based as the primary logic, competitor pricing as a reference frame, and cost-plus as a floor to ensure the unit economics remain viable. The structural decision that matters more than the exact price point is how you segment your offering into tiers.
Free Trial vs Freemium vs Paid-Only SaaS Models
The entry model you choose affects your conversion funnel, your support costs and the type of customer you attract. Each approach has a specific set of conditions under which it works well.
Free trial gives full or near-full access for a limited period — typically seven to fourteen days. The advantage is that every sign-up has explicitly opted into evaluating a paid product, which tends to produce higher conversion rates from trial to paid. The risk is that if the product requires significant setup or configuration, the trial period may expire before the customer experiences enough value to justify paying. Free trials work best when the core value can be demonstrated quickly and the product does not require extensive data input or team coordination to become useful.
Freemium offers a permanently free tier with limited features, capacity or usage, alongside paid tiers that remove those limits. This model lowers the barrier to entry further than a free trial and can drive substantial user volume, which is valuable if network effects or user-generated data are part of your product's value. The downside is that free users consume support and infrastructure resources without contributing revenue, and conversion rates from free to paid are typically much lower than trial-to-paid rates — often in the low single digits. Freemium is most effective when the free tier naturally creates a need for the paid features, rather than simply being a crippled version of the same product.
Paid-only requires payment from the first day. This is uncommon in consumer-facing SaaS but more viable in vertical B2B markets where the product addresses a regulated or mission-critical need, the buyer is already committed to solving the problem, and there are few free alternatives. Paid-only eliminates the support cost of non-paying users and ensures every customer has buying intent, but it requires strong brand credibility or a sales process to overcome the initial friction.
A frequent mistake is choosing freemium because it feels modern, without modelling whether the expected conversion rate and average revenue per paid user can cover the cost of serving the free user base. The right model depends on your product's time-to-value, your support capacity and whether free users generate indirect value for paid users.
How to Handle Subscription Upgrades and Downgrades
Plan changes are a routine part of SaaS operations, but the billing logic behind them needs to be defined clearly before development begins. The two key questions are: when does the change take effect, and how is the charge calculated?
Timing. Some products apply plan changes immediately; others queue the change for the next renewal date. Immediate changes provide a better customer experience — the user gets access to new features straight away — but they require proration calculation on every change. Next-renewal changes are simpler to implement but can frustrate customers who upgrade because they need a feature now.
Proration method. When a customer upgrades mid-cycle, the standard approach is to charge the difference between the old and new plan for the remaining days in the cycle. When a customer downgrades, the typical approach is to apply a credit that reduces the next invoice. However, there are variations: some providers charge the full new-plan price immediately and issue a credit for the unused portion of the old plan. The exact method affects your cash flow and the customer's invoice, so it should be specified in your requirements and tested explicitly.
Feature access. When a customer downgrades, decide what happens to data or configurations that are only available on the higher tier. If a user on a premium tier creates fifty custom workflows and then downgrades to a plan that allows ten, you need a defined policy: are the excess workflows archived, hidden or deleted? This is a product decision with billing implications, and it should be documented before build, not improvised after launch.
When specifying upgrade and downgrade behaviour for a development team, include the exact proration formula, the timing rules, the feature-granularity of each tier and the data-handling policy for downgrades. Ambiguity in any of these areas leads to either over-engineering or customer-facing bugs.
Managing SaaS Revenue Recognition
Revenue recognition in a SaaS business is counterintuitive for founders who come from non-subscription backgrounds. When a customer pays £1,200 for an annual subscription, you do not recognise £1,200 of revenue on the day the payment arrives. Under standard accounting practice, you recognise £100 of revenue each month as the service is delivered.
This distinction matters for several practical reasons. If you are raising finance or seeking investment, potential backers will scrutinise your revenue recognition policy. If you are reporting to shareholders or a board, the gap between cash received and revenue recognised can cause confusion if it is not clearly explained. And if your business grows quickly, the deferred revenue liability on your balance sheet can become significant.
The complexity increases with certain pricing structures. If you sell an annual plan with a discount compared to monthly billing, the revenue recognition schedule still follows the delivery period, not the payment pattern. If you charge a one-time setup fee alongside a subscription, the treatment of that fee depends on whether it is considered a separate deliverable or part of the overall arrangement — a judgement that requires accounting input.
This is an area where general guidance has limits. The specific rules that apply depend on your company's legal structure, jurisdiction and reporting requirements. The practical step is to engage a qualified accountant with SaaS experience early — ideally before you sign your first annual contract — and ensure your billing system produces reports that align with the recognition policy you have agreed.
Usage-Based Pricing vs Flat-Rate SaaS Pricing
Flat-rate pricing charges a fixed amount per period regardless of how much the customer uses the product. Usage-based pricing — sometimes called metered or consumption pricing — charges according to volume: number of API calls, gigabytes of storage, transactions processed, seats added or some other measurable unit.
Flat-rate pricing is simpler to implement, easier for customers to predict and cheaper to operate because it does not require metering infrastructure. It works well when the cost of serving an additional user or transaction is negligible and when customers value predictability. The limitation is that you cannot capture additional revenue from high-usage customers, and light users may perceive the flat rate as poor value relative to their actual usage.
Usage-based pricing aligns your revenue with the value the customer extracts. A customer who processes ten thousand transactions per month pays more than one who processes a hundred, which feels fair to both parties. It also lowers the barrier to entry — a new customer can start with minimal usage and grow into higher spend. The trade-offs are increased technical complexity, less predictable revenue for your business and the risk that customers become cautious about using the product because they are watching a meter.
Hybrid models are increasingly common: a flat base tier that includes a defined usage allowance, with overage charges above that threshold. This combines the predictability of flat-rate pricing with the revenue capture of usage-based pricing. If you are considering a hybrid model, the key specification decisions are the allowance threshold, the overage unit price and whether the customer receives usage alerts before incurring additional charges.
From a technical standpoint, usage-based pricing requires a metering system that reliably records each billable event, handles edge cases such as retries and failed operations, and reconciles metered totals with the billing provider's invoices. This is non-trivial at scale and should be factored into your architecture planning.
How to Present Pricing on a SaaS Website
The way you display pricing affects both conversion and the volume of sales conversations you receive. There is no single correct approach, but there are structural decisions that should be made deliberately rather than by default.
Show prices or hide them. Displaying prices openly filters out prospects who cannot afford your product before they contact your team, which saves sales effort. Hiding prices — replacing them with "Contact us" — is common in enterprise SaaS where deals are negotiated individually, but it also deters buyers who prefer to self-educate before speaking to a salesperson. A useful heuristic: if your price is within a range that a typical buyer could approve without multiple sign-offs, show it. If every deal requires a custom proposal, hiding prices is reasonable.
Number of tiers. Three tiers is a common pattern because it gives the buyer a clear middle option — the psychological "safe choice" — while anchoring the top tier as premium and the bottom tier as entry-level. Fewer than three can feel limited; more than four tends to cause decision paralysis. Each tier should differ on at least two meaningful dimensions — not just a marginal increase in a single metric.
What to emphasise in each tier. The most effective pricing pages lead with the outcome or capability the customer gets, not the technical feature list. "Unlimited projects" is more compelling than "No project-limit configuration field." The feature comparison table should focus on the differences between tiers, not repeat the same features across every column.
Handling annual vs monthly pricing. Most SaaS products offer a discount for annual payment — typically presented as "pay monthly" and "pay annually" toggles. If you offer both, show the annual price as the total per year and the monthly equivalent, so the customer can compare directly against the monthly plan without mental arithmetic. Be explicit about whether annual billing is a single upfront payment or twelve equal instalments.
Addressing common objections inline. Including brief answers to the questions that arise during pricing evaluation — cancellation policy, data export on exit, whether prices include VAT — reduces friction and prevents these questions from blocking the sign-up flow. These do not need to be lengthy; a single sentence next to the pricing table is often sufficient.
The pricing page is not a marketing brochure. It is a decision-making tool. Its job is to give the reader enough information to choose a tier and proceed, or to decide that your product is not the right fit — both of which are useful outcomes.