The 4 key steps in a usage-based billing workflow

The last few years have brought many conversations around the benefits of usage-based pricing (UBP) – easier adoption, increased NRR, support for Product Led Growth (PLG, and logo churn resiliency, to name a few – but not enough practical guidance on how to actually implement and operate this type of SaaS pricing strategy. 

We’ve heard from many Finance and Product professionals about their endless Google searching, trying to find help with questions like:

• What tools and processes are commonly used to capture and manage usage data in SaaS companies?
• What usage data events do my products need to generate and how do I perform the necessary aggregations and calculations?
• How do Finance teams provide visibility for other teams – like Sales, Customer Success, and Product – into billing data for customer accounts?
• How can I use historical customer usage data to experiment with pricing?

If you’re wondering about any of these questions, know that the challenges you face are common among SaaS businesses, especially as usage-based and hybrid pricing gain more of a foothold in the industry. 

Read on for our take on the “ideal” usage-based billing workflow and overcoming the common challenges that accompany consumption elements in pricing.

What is the ideal usage-based billing workflow? 

The core challenge you’ll need to solve for with UBP is this: If your pricing has consumption-based components, you will need to rate – i.e. apply pricing to – the product usage data. This is the big difference between billing workflows for usage-based pricing versus traditional subscriptions.

The workflow for usage-based billing covers four main steps:

1. Source and prepare the necessary data
2. Load data and perform calculations
3. Deliver calculations to billing and other downstream systems
4. Set up continuous bill calculation 

Because every company is different, many of these sections will contain not only guidance, but also questions for you to consider as you build your own ideal usage-based billing workflow.

1) Source and prepare the necessary data 

There are three broad categories of data that will be needed for usage-based billing: account data, pricing and order data, and product usage data. But the sources of truth for these three categories are typically in different places.

Account data

This is the core customer record that the Finance stack refers to when generating bills and collecting payments. 

Data location examples: NetSuite, Salesforce, your CRM, etc.

Pricing and order data

This data is a record of what has been sold to a customer and which prices should apply when calculating their bill. The more variability that exists in pricing, the more complexity there will be, ranging from all customers on exactly the same pricing (easiest) to every customer on customized pricing (hardest).

This can be stored in a Sales CRM, CPQ, a subscription management system, a separate price book, or some combination of these. 

Data location examples: Salesforce CRM, Salesforce CPQ, etc. 

Product usage data

This data is generated from your core production systems, and there are a number of steps in the pipeline:

• Generate usage events by setting up your systems to capture all the necessary usage vectors (i.e. all the things you’ll price against).
• Label the data, ensuring usage events have adequate metadata to be rated against the correct pricing category.
• Aggregate the data to generate the billable metrics, such as unique users or the sum of API calls. 
• Store that data in a repository, like an analytics database, where it can be easily queried.

These product usage data pipelines typically need to be built and managed by people with technical expertise, because 1) the volume of usage events can be massive, and 2) data can be difficult or impossible to rebuild and recategorize if it is incorrect after the events have been generated.

Data location examples: Bespoke analytics database or analytics databases like Oracle DB and AWS.

2) Load data and perform calculations 

Once the three types of data are located and prepared, the next step is extracting and loading the data into a mechanism that performs calculations. You’ll first need to consider how much you want to automate extraction for each type of data. For example:

• Pricing and order data – Automating data extraction from the sources of truth can ensure you have the most up-to-date pricing, regardless of how many variations your pricing has.
• Product usage data – If you go the manual route, a Billing Operations team member might need to ask an Engineer to run a report each time they want to calculate bills. A better alternative would be if that person could do it themselves with direct access to the analytics database. The best version would be if the extract could be automatically delivered on demand.

However the data is extracted, it then needs to be loaded into your chosen system to perform the calculations. Many companies do this in spreadsheets: They load the account, pricing, and product usage data into Excel, then set up formulas to calculate bill amounts. 

The main challenges with this option? Spreadsheets are prone to errors and they don’t cope well with complex calculations. The chances of error increases when the number of accounts is high and/or the pricing is complex, especially when every customer may have custom prices. Billing this way can also take a really long time as it’s so manual, making it difficult to close the books on time each month. The alternative is to use a task-specific tool, either one built in-house or off the shelf from a provider like m3ter. 

It’s also worth noting you need the ability to rerun bill calculations without re-ingesting the usage data, either 1) to reassure auditors and customers that bills are correct, or 2) to correct bills if the wrong pricing was mistakenly used for a customer.

The “ideal” level of automation varies depending on the company: For early-stage companies with relatively simple pricing situations (e.g. few customers, few products, limited custom pricing), spreadsheets are a viable option, though highly limiting to scalability. As companies mature, they will need to introduce a higher degree of automation and move away from spreadsheets to avoid acute operational headaches and significant amounts of revenue leakage.

3) Deliver calculations to billing and other downstream systems

At billing time, these calculated amounts then need to go to the billing systems: the tools that generate invoices, collect payments, calculate revenue recognition, and post to the general ledger. (If you’re performing your calculations in spreadsheets, that adds another step of manual input here.)

But there are other places that you might need to deliver billing and usage data in SaaS companies:

Sales and Customer Success

If your Sales and Customer Success teams need access to that billing data to manage proactive upsells, renewals, or customer billing queries, you'll need to create that workflow, either by asking the BillingOps teams to manually send it through at regular intervals or through enabling self-service. The more efficient workflow is to make billing data self-serve and available in the tools where the teams spend most of their time, like the Sales CRM like Salesforce or a Customer Success Platform.

Customer

If the end-customer needs access to their billing data, you’ll need to decide where they will be able to see their bills and understand their usage, whether on an “account dashboard” or something similar, and if that data will be delivered flexibly via API or in another way.

Financial Planning & Analysis (FP&A)

You’ll also need to consider whether the FP&A team needs access in order to generate key management metrics, and if they will need the ability to ingest that data to their Business Intelligence (BI) stack for deeper analysis.

4) Set up continuous bill calculation 

If you have a monthly billing cycle, then you only need to calculate the bills once per month, right? 

Wrong (unfortunately). Teams and systems around your business will need to know how bills are tracking based on a customer’s usage so far that month. They might need this “running total” weekly, daily, hourly, or even more frequently. 

Teams have various reasons for needing this information:

• Sales and Customer Success teams need to be proactive in response to usage patterns. If a customer’s usage is high and will generate a big bill at the end of the month, it will earn customer trust (and avoid a potential churn risk) if you reach out to that customer to inform them, rather than just presenting them with a large bill at month’s end.
• Product teams want to deliver great UX, and pricing is effectively part of the product when you have UBP. Customers will want the ability to see their usage and understand on an ongoing basis how it converts to spend, so when Product builds billing dashboards, the data presented in them needs to be current.
• Finance teams want the ability to forecast what monthly billing will be. If you only calculate bills once per month, you’re flying blind until the end of the month. Instead, you want to see a running total of revenues as the month progresses.

Having the systems in place to calculate bills at any given moment will help all teams to fully capitalize on the benefits of usage-based pricing by offering great customer experience and having a higher degree of understanding and control.

Constructing a scalable usage-based billing workflow

When the usage-based billing workflow is running smoothly, bills are calculated automatically, with all relevant teams able to access the “running total” of a customer’s bill at any time. 

BillingOps teams don’t have to constantly ask engineers to run a report to calculate bills – the extract is automatically delivered on demand. 

Sales and Customer Success can proactively initiate customer conversations based on usage patterns and offer more flexible pricing variations without creating more manual operations for the finance team. Deal Desk teams will no longer be a blocker to custom sales pricing because monetizing those deals will be easy. 

Product teams can easily launch new features and release pricing and packaging updates and integrate billing dashboards with an exceptional UX into the product, so customers know what their usage will cost them at the end of the month.

To achieve this level of usage-based billing utopia, you’ll need the right tech stack. With m3ter, you don’t have to change any of your other (carefully chosen) tools, as it slots right in, working not only as data infrastructure between these systems but also one detailed source of truth for bill calculations. 

Get in touch to see how m3ter can uplevel your usage-based billing workflow.