Metering and billing

The SaaS model has shifted software pricing from one-off purchases to recurring plans, giving businesses more predictable revenue and closer relationships with their customers. To make the most of this, the application's architecture also needs to be built around the recurring model, letting product teams experiment with different pricing. When metering and billing are flexible enough, businesses can test new pricing strategies, respond to market signals quickly, and unlock revenue opportunities that would otherwise require painful rewrites.

Metering is the raw data collection layer. It’s all about tracking product usage, sometimes in real time. Think of it as the "utility meter" for your SaaS API calls, storage consumed, active users, compute time, transactions and so on. This data forms the backbone for billing and product insights. If metering is inaccurate you risk losing customer trust and can’t even accurately recognise your own revenue.

You might think that metering is just another type of metrics, but this is actually not exactly right. Unlike metric aggregators, the metering system must have two critical features: guaranteed delivery and deduplication. Guaranteed delivery ensures you capture every usage event, so you don't lose revenue. Deduplication, on the other hand, ensures that you don't charge the customer multiple times for the same consumption unit, which could quickly damage your reputation and customer relationships.

Billing sits on top of the metering system. It translates consumption units into invoices, applying your pricing model. The billing system should (1) apply the right price to each consumption unit, (2) generate accurate invoices, and (3) collect payments through the channels your customers prefer. All of this should be compliant with regulatory requirements.

Most SaaS companies don't build billing systems from scratch. Instead, they rely on proven, widely available billing platforms that already handle the heavy lifting. This approach saves engineering time, reduces compliance headaches, and lets you focus on your core product.

A SaaS pricing model is a combination of price metrics and a packaging model. Choosing the right pricing model for your business is beyond the scope of this article, but we will explore the main types to demonstrate how the pricing model influences software architecture.

Price metrics specify the units you charge your customers for. The main types of price metrics include flat-rate, user-based, usage-based, capacity-based and outcome-based.

Flat-rate pricing is a simple model where you offer your service for one fixed price. Customers pay the same monthly or annual fee for unlimited access to all features, regardless of how intensively they use your product. This model is very straightforward and makes financial forecasting easy for both the software provider and the customer, as there are no variable costs.

For flat-rate pricing, the architectural requirements are simpler. Since every customer pays the same fixed amount, you don't need to build a complex system to track usage. Your billing system only needs to handle basic functions like subscriptions, renewals, and payments.

The main challenge, however, shifts from usage tracking to cost management. You need to ensure the total cost per customer is less than the flat rate they pay. This is where tenant cost allocation and rate limiting become critical. Cost allocation allows you to understand profitability on a per-customer basis, enabling you to adjust pricing or optimise infrastructure as needed, while rate limiting ensures customers don't abuse your service.

The user-based pricing, often seen in B2B, counts the number of active users your customers enable in their accounts. It's intuitive, scales naturally as your customers grow, and is widely accepted across different industries. When user count strongly correlates with value, this model remains a good choice.

Identity and Access Management (IAM) is crucial for managing seat-based pricing. Your architecture needs to track how many active users each customer has, manage their roles, and ensure licenses are enforced in real time. For B2B customers, it's vital to have integration with their corporate identity providers.

Usage-based pricing, also known as pay-as-you-go, ties service charges to consumption levels. The more your customers use your service, the more they pay for it. Common examples include the number of API calls, or GB of storage consumed. It's widely used across industries thanks to its flexibility, as it lowers the entry barrier for new customers.

Architecturally, this is one of the most complex price metric types, as it depends on accurate metering pipelines. You need to capture raw usage events, such as API calls, and store them reliably for billing purposes. This requires low-latency data ingestion, durable event storage, and aggregation jobs that convert usage into billable units. Transparency is key here, as customers often expect real-time dashboards and consumption alerts to prevent unexpected charges.

Capacity-based pricing limits how much of a resource your customers can use under their plan. For example, a virtual machine might come with a fixed number of CPU cores and amount of RAM, or a file hosting plan might include a specific number of gigabytes.

Capacity-based pricing only works if usage limits are properly enforced, otherwise customers can easily exceed their allocations. Strong enforcement techniques are therefore essential to make this pricing model work.

Outcome-based pricing aligns directly with the value your service generates for customers, so they only pay when they see real results. This builds trust and makes the commercial relationship feel like a genuine partnership.

From an architectural perspective, outcome-based pricing is similar to usage-based pricing, as both rely on a metering system to capture activity. The key difference lies in what gets measured. Usage-based pricing tracks consumption, such as API calls or gigabytes transferred, whereas outcome-based pricing meters the business results your service delivers.

The purpose of packaging is to tailor your offering to different customer segments, offering different prices for different customer types. The main packaging models include monolith, good-better-best, modular, base+modular and custom.

A monolith is the simplest packaging structure. Customers get a single option. It's a popular choice for early-stage companies focused on growth, because while it rarely maximises revenue, it makes the buying decision easier.

It's just as simple technically as it is commercially, making it a good choice for early-stage products. Without the need for any access-restriction mechanisms, implementation becomes far easier.

The tiered model, also known as Good–Better–Best, is one of the most popular packaging approaches, providing a good balance between flexibility and choice. The Good tier sits at the lowest price point and offers only the basics, which is perfect for entry-level customers who want to try your product without much commitment. The Better tier expands on this with additional features and higher limits at a mid-range price. The Best tier typically bundles every feature you offer at the highest price point.

In a tiered model, the application's architecture must enforce entitlements and usage limits. A Good tier might have lower usage limits or hide premium features, while a Best tier might have significantly higher limits and unlock everything. This requires tight integration between the authentication, entitlement, rate-limiting, and billing systems. The main challenge is keeping entitlements consistent across the product and making upgrades and downgrades feel seamless.

Since free and low-paying customers can generate significant load, a multi-tenant architecture for lower tiers is often beneficial. Combined with usage limits, it helps ensure they don't overconsume costly resources. To support this effectively, the architecture should also provide strong isolation mechanisms.

With a modular packaging model, customers simply pick the slice of capabilities they actually need. It's a great fit if you're selling by use case, bundle the features required for a specific scenario into a separate module, and charge accordingly.

The main technical challenge is keeping modules cleanly separated while the underlying system remains coherent. That requires strong entitlement checks and careful handling of shared services and data. On top of that, managing dependencies between modules requires additional attention.

The base + add-ons approach extends the modular concept by providing a standard starter version of the product, with optional add-ons you can bolt on for specific features or use cases. The base gives you everything needed to start, while the modules let you extend and customise it as your needs evolve.

From a technical perspective, this packaging model is similar to the modular one. The underlying mechanics of bundling and distribution are essentially the same. The key difference is that the base is simply the portion of a module that is available to everyone, rather than being gated behind module-specific access.

The custom packaging model sits at the opposite extreme from the monolith approach. Rather than bundling everything together, it lets customers assemble their offering at a very granular level, picking and choosing the specific components they want. They only pay for what they actually use, which gives them maximum flexibility and control over costs.

From a technical perspective, custom packaging is the hardest to implement, as it requires a modular architecture where each feature can be independently provisioned, metered, and billed. You'll need solid entitlement systems, fine-grained usage tracking, and a flexible pricing engine to handle the many permutations. The user experience around configuration and invoicing also becomes more complex, since customers expect clarity on what they're paying for.

In reality, you don't have to limit yourself to a single pricing model. The most successful SaaS products blend several. For example, you may use tiered pricing for different customer segments and add usage-based charges for some features. This flexibility lets you reach a wider range of customers.

The flip side of this flexibility is added complexity. You'd need subscription management and a metering system working seamlessly together, then consolidating both into a single invoice while keeping dashboards accurate. Many SaaS companies turn to third-party billing solutions at this point.

To design metering and billing that fits your business, start with your target pricing model and work backwards. The questions below will help you gather the information needed to design it properly.

What pricing model are you aiming for?
This shapes everything downstream, since the pricing model dictates what you need to measure, store, and bill for. A user-base subscription might only need active-user tracking, whereas usage-based pricing demands fine-grained metering pipelines. Without that clarity upfront, you risk building a billing architecture that doesn't fit your actual needs.

How many billing events do you expect to process each month?
A few hundred? Simpler systems, or even manual invoicing, will likely do the job. But if you're dealing with millions of usage events a day, you'll need a high-throughput metering pipeline and solid event storage to avoid bottlenecks and billing errors.

Will you need to offer trials, discounts, credits, or custom pricing?
Your answer shapes how flexible your billing system has to be. Sticking to fixed subscriptions keeps things simple, but as soon as you want to run free trials, apply discounts, issue credits, or offer bespoke enterprise deals, your architecture needs to be more flexible.

Do you need to handle multiple currencies, regions, or tax rules?
Customers expect billing that's localised to their regional tax laws and preferred payment currencies. Plan for this early, otherwise you'll face significant rework when expanding into new markets, which can really slow down growth.

Billing in SaaS does more than bring in revenue, it builds trust. When invoices are clear and accurate, customers stay happier. Flexible pricing models also unlock new ways to earn, letting you experiment with tiers, usage-based plans, and bundles that suit different segments. And as you scale, automation takes the manual load off your finance team, freeing them up for work that actually moves the needle.