Having worked at a usage-based billing company for a little over a year, I’ve seen more billing implementations than the average engineer will see in a lifetime. I've also experienced the complexities of pricing and billing during my time as a tech lead at Plaid and Pinterest. At both companies, I worked closely with the sales teams and navigated several different B2B sales motions. Both experiences helped me develop a good understanding of how go-to-market and billing operations intersect.
While I am by no means the foremost expert in pricing, packaging, metering, rating, dunning, etc., etc., I have seen enough to begin unraveling the gordian knot that is usage-based billing and share my learnings.
This is the first of a series of blog posts I’ll be writing on what I’ve learned while building scalable billing infrastructure for some of the fastest-growing companies, including OpenAI, Starburst, and Cockroach Labs.
First things first, why does billing matter?
Every company needs billing and I might go so far as to say that numerically, billing might have the most direct stakeholders across a company.
Here are some of the stakeholders that have billing requirements and what they expect from an ideal billing system:
- Customers need a flexible, transparent, and reliable way to purchase.
- Sales teams need a system with enough optionality to deliver varied pricing and packaging.
- Finance teams need a system reliable enough to accurately invoice, track sales, and recognize revenue. For public companies in particular, there’s an increased emphasis on compliance and ensuring financial calculations are accurate and audit-ready.
- Marketing teams need a system that can handle discounts, coupons, and promotions.
- Analytics teams need a system that makes real-time usage, costs, and revenue easily available. They are also responsible for making sure the right cross-functional teams have the reporting they need.
- Security teams must have a system that is protected against internal and external threats.
- Engineering teams need to implement all these requirements with strong constraints of correctness, reliability, and scalability.
- Product teams need to be able to launch new products, change pricing, and understand the impact of new billing models on adoption and churn.
Billing is a critical piece of infrastructure that every company needs, which makes it not only important but also pretty interesting (at least us billing nerds think so 🙂).
There are two prominent business models for SaaS: subscription and usage-based pricing. In subscription pricing models, customers subscribe to services or purchase products at a fixed recurring fee over a specific period of time. In usage-based pricing, also known as consumption pricing, customers are charged based on how much they use your product. Companies choose a usage metric to price on that maps to the value a customer is getting from the product. This post will be diving deeper into usage-based pricing.
Usage-based billing foundations
For folks newer to billing and usage-based pricing, I’ll cover a common set of definitions when discussing pricing and packaging. If you are a pricing or billing expert, you can use this section as a refresher or skip it since you already know your way around an invoice.
Pricing and packaging
This section refers to how you encode your products into contracts, invoices, and quotes. A good reference to look at is a company’s pricing page.
A common model for SaaS companies is having two or three plans that are free, paid, or custom quoted. Each plan includes products with associated prices. These products with prices translate into line items on an invoice. Depending on the company, there could be 10, 100, or 1,000s of products (aka SKUs) that can be grouped into different plans that show up on an invoice.
Metering
Metering refers to how a company keeps track of how much a product is being used and by whom. Metering is typically only needed for usage-based billing models, and is less common in subscription models. However, it can come up in entitlement use cases regardless of pricing model (e.g. this package only allows for 10 free workspaces).
A simple example of metering is how power companies track kilowatt hours for every address. Each address will have one or multiple meters that look like this:
Power companies will then collect the data from a meter to determine how much electricity was used per customer and charge accordingly.
Rating
The act of rating refers to applying pricing to usage. Rating combines your pricing and packaging with metered usage of your product. The complexity of rating is mostly determined by how complex a company’s pricing and packaging model is. The more sophisticated the pricing and packaging, the more business logic is required for an accurate rating.
Invoices and usage statements
An invoice is a document that contains a collection of costs. Each record will usually detail which service or product was delivered and the price.
Invoices serve as an input for payments, revenue recognition, customer transparency and more. It can be found in some form within all billing systems and is the culmination of the entire billing system working in concert.
Usage statements have the same structure as an invoice (line items with usage amounts and costs), but aren’t directly used for payments. They are typically used in pre-paid cases (e.g. upfront credit purchases) to give your customer transparency around how their usage was spent.
Integrations
This is a catch-all bucket for all of the downstream applications that rely on a billing system:
- Accounting software
- Payment processors
- Data warehouses
- Dunning (process of collecting on accounts receivable)
- CRMs
- Other (each company has their tech stack that billing data needs to connect with)
A robust billing system needs to seamlessly communicate with these applications, so relevant stakeholders can access the information they need.
Why is usage-based billing so hard?
The simple answer:
- Each part of the billing stack is interconnected
- There are many stakeholders, which means there are many requirements
Billing is interconnected
A billing system could be compared to a table where the legs are different parts of the billing stack. One leg of the table is for pricing and packaging, another for metering and rating, etc. If you want to introduce a new pricing model, that is sort of like increasing the height of the table. Every leg’s length must be increased somehow so the table can still function. You can prop up one leg as a temporary solve, but this could compromise the structure of the table. The prop might not hold as much weight or be slightly off in sizing—causing future issues down the road and result in revenue "sliding off the table" if you'll indulge the metaphor.
The table analogy highlights one of the main challenges with usage-based billing. Adding requirements after the system is built can require updating the entire system. This is mainly due to each part of the system depending on the other. Let’s go through an example to illustrate how usage-based billing is interconnected.
Let’s take a company that builds fintech APIs and starts with a pricing model where they charge per API call. The billing team builds a usage-based billing system from scratch to handle this use case. 6 months down the road, the company launches a new product that pulls bank account information. The GTM team would like to bill on the unique number of bank accounts associated with the customer on a monthly basis. The customer (e.g. Venmo, Braintree) could potentially have millions of bank accounts and the math would look roughly like this:
(X number of unique bank accounts processed) * Y pricing = Z totals
Month 1: X = 100, Y = $1, Z = $100
Month 2: X = 150, Y = $1, Z = $150...
To implement this new model many questions come to mind:
1. Pricing and packaging
- Who gets access to this product? Will this product be self-serve, sales-assisted, or both?
- Will the pricing be different based on the size of company (e.g. SMB vs. Enterprise)?
- How will this product be bundled with other products that we sell?
- Do we want to introduce trials or promotions?
- Can our system handle different rate cards (or custom pricing) per customer in this new pricing model?
- Is the number of monthly bank accounts a maximum or an average number of accounts? Do we want to support both?
2. Metering and rating
- What kind of scale do we need to support metering the unique number of bank accounts?
- Does our current storage solution support approximate distinct calculations?
- What level of accuracy do we need to support the unique aggregations?
- How fast do we need to turn around aggregates for this use case?
- What is the time frame we are collecting usage for and rating it? Monthly? Quarterly? Annually?
- Is the time frame different than the billing period (time between invoices)?
- Is the metering fast enough to allow for customers to see estimated costs before the billing period ends?
- Do we need real-time, on-demand metrics or only after an invoice is finalized?
3. Invoices
- How should we display this on the invoice?
- How do we give customers transparency into which unique IDs were counted?
- How frequently should we be sending invoices to customers?
- Should customers have access to draft invoices throughout the billing period so they can track spend?
4. Integrations
- Do the current integrations need to be updated for the additional invoice line item?
- Will it be easy to update integrations as pricing and packaging changes over time?
- Is the new pricing model revenue recognized the same way?
- Does the CPQ (Configure, Price, Quote system) handle this new product line?
- Have we updated the data warehouse schema to handle a new data type?
While this is an example, the amount of work necessary to bring online a new pricing model or product is substantial. Companies often times staff an entire team of engineers to work on billing complexity. If this was a once or twice in-a-company event it might be acceptable to pay the cost of updating the entire system, but this isn’t usually the case.
Engineering and product want to launch new features with different billing models, go-to-market teams want to offer customized contracts, and finance wants to be able to dial pricing according to costs. With all of these different needs, how could changes be infrequent?
More stakeholders, more problems
As discussed earlier, billing has at least 7 departmental stakeholders at a company. Having to meet the needs of too many stakeholders is a real challenge and billing certainly experiences its fair share of misalignment across functions.
The primary driver of these misalignments is due to competing priorities for each group. For example, an engineering and product team might be more focused on delivering a solid user experience for the majority of customers. On the other hand, a sales team could be totally focused on delivering an excellent buying experience for enterprise accounts. If there are a fixed set of resources, something might get dropped or development velocity slows to a crawl. Slows and stoppages in billing almost always result in a direct drop in billed revenue.
Can usage-based billing ever be simple?
Yes, for a single pricing model
To implement a single pricing model (e.g. number of API calls) with a couple integrations is actually pretty straightforward. The technical solution designed can ignore future pricing scenarios and focus on scaling, accuracy, and reliability. Since the requirements are lower, there is potential for one or two focused team(s) making this happen in some factor of quarters (depending on company scale).
With this said, this scenario feels unrealistic in the long term for certain types of companies due to pull from the market. For example, most B2B companies serving enterprise clients will almost certainly need custom pricing and packaging per account. B2B companies may also offer self-serve plans to fuel product-led growth and turn a small user footprint into a large enterprise account.
No, for complex pricing and packaging
But it doesn't have to be so painful! For complex pricing models, there are a few approaches to solving this problem (we’ll be covering these options more deeply in the future):
- Put more resourcing behind your billing team to deal with the complexity.
- Use a billing provider like Metronome that specializes in usage-based billing. We’re built to handle many different pricing and packaging scenarios out-of-the-box, so when a new use case comes up, Metronome already has it covered.
I’ll be continuing to share my thoughts and learnings on pricing and packaging on the Metronome blog. If there are specific topics you’re interested in learning about, reach out to me at allan@metronome.com.
