Metered billing vs. usage-based billing

When it comes to pricing, SaaS companies have shifted the way they charge for their offerings to reflect the evolution of their products and customer demands. Slack, pursuing a fairer billing practice, charges only for active users each month. Snowflake charges by storage and compute separately, mirroring the product’s key technical innovation. SendGrid uses a hybrid model underscoring its dual value, charging by volume of emails sent and features activated. With increased nuance and complexity in pricing comes a need for billing that can keep pace with the market. This is why efficient and rapidly scaling SaaS companies often partner with a billing vendor, rather than spinning up an internal billing team.

But evaluation of billing vendors is tricky. Not all providers take the same approach to supporting usage-based businesses, which can lead to challenges to the core of your business—how your measure and charge for your product.

Billing solutions originally built for subscription pricing, like Stripe Billing, take a “metered billing” approach, while Orb takes a “usage-based billing” approach. While some platforms may use these terms interchangeably, they are not the same. In fact, the seemingly-minor differences between the two can have a big impact on your business: from engineering time, to customer trust and account retention, to product velocity.

Defining metered and usage-based billing

Metered billing is a method of calculating an invoice that involves sending the billing system a value that represents the quantity you want to charge for. The billing system simply takes the last reported quantity and multiplies it by a unit price in order to generate the charge. Metered billing is most commonly found in subscription-native solutions because it’s the closest analog to a static license-based model, where the quantity is easily derived, and doesn’t change often.

To support Slack’s active user model, the billing platform would directly take the total number of active users and multiply that number with a per-user price to create the final invoice.

Usage-based billing, by contrast, is a method of calculating an invoice that uses raw, underlying events to produce a final value, encoding the quantity calculation in the billing platform itself. For Slack’s model, instead of providing the billing solution with the total number of active users, the billing platform might ingest every user activity event or a record of logins to calculate a distinct set of users over the course of the month. 

The paradigm of billing based on the underlying events rather than a final tally becomes crucial to how you grow and iterate a usage-based business. 

The limitations of metered billing

Let’s take as an example a cloud infrastructure business like Snowflake looking to charge for cluster compute costs, and dig into what limitations a metered approach would incur.

Loss of transparency

To charge for cluster compute in a metered approach, we’d send periodic reports reflecting the total or incremental number of compute hours to charge the customer, and leave it to the billing system to multiply this by the price per compute hour. 

In practice, by sending the billing system a single aggregate rather than individual events tagged with compute-specific metadata, you lose the ability to unpack the data to provide transparency to your internal team and customers. If you want to break apart the compute costs by cluster name, cluster size, or infrastructure region on your invoice, that data isn’t available. This leads to a poorer end-user experience, or an inability for your users to understand the source of their charges. Similarly, internal teams may not be able to understand the source of an anomaly or trend; they can see changes in the total, but not what is potentially driving them.

Increased engineering time and effort

With metered billing, your engineering team needs to think not only about measuring what’s happening in your product, but also how that will translate to a final quantity for billing. For example, suppose that we want to filter out development clusters from compute charges, or we need to aggregate data from different internal reporters before we can calculate the total hourly compute. These filters and data aggregations would need to be built in-house with a costly data infrastructure setup that can scale to your event volume.

To make matters more complicated, suppose that one of your enterprise clients is charged for compute differently than others; they have their own dedicated infrastructure which reports events in a way that’s different from the rest of your architecture. This logical difference will need to be encoded within your reporting data pipeline, creating work for your engineering team to maintain different infrastructure and business logic for each edge case in your system. Each nuance means a new data integration, meaning that your billing provider is no longer the single source of truth for billing logic and an increased risk of errors. 

Reduced agility and ability to scale 

Suppose that you’re running a strategic price change, where you’re charging for cluster compute in TB/mo instead of Gb/hr, or you’re increasing the granularity with which you measure your compute per instance. Instead of this being a change in your metric definition over existing events, metered billing requires you to re-integrate with your billing system to send the new quantity. 

A metered billing setup ties your business teams (sales, revenue, finance, etc.) to your engineering team, preventing them from operating independently. Every custom contract means relying on available eng time and resourcing, slowing down your sales cycle and adding friction to every deal close.

Why usage-based billing is different

Unlike metered billing, usage-based billing relies on events to determine costs. This is the fundamental reframe: an event is a record of activity in your application, not directly how you intend to charge. You already have these events instrumented; they’re core to your product analytics. Since they’re representative of the performance obligations of your product, they usually don’t vary much from customer to customer.

A truly usage-based billing system should be able to:

1. Ingest raw events in real time, not just aggregates in batches.
2. Build multiple metrics on top of the same event. For example, an event that reports each transaction with its amount allows you to charge by number of transactions and by transaction volume/size.
3. Consolidate billing logic into a single system. Everything needed to adjust pricing or determine usage is in the same location. 
4. Prevent repeated integration cycles. No need to bring in engineering for every change in business requirements. 

Because the input to a dedicated usage-based billing system is events rather than aggregates, the system needs to be built differently. It has to support a real time high throughput API, which means an architecture built for scaling. It needs to support workflows and triggers that act in real time, and must have a powerful, flexible, and expressive way to construct metrics from your events. 

What usage-based billing can do for you

Usage-based billing ensures that you have real-time data telemetry for the present, with fewer abstractions. The low level nature of the architecture opens up flexibility for easier maintenance, and lower-friction pricing updates or customization in the future, not to mention greater accuracy.

To learn more about Orb’s approach to usage-based billing, schedule a custom demo.