The engineering behind Snowflake’s FY24Q2 earnings report

At the end of August, Snowflake released their 2nd quarter financial report for the 2024 financial year. They reported product revenue of $640.2 million (37% year-over-year growth), a net revenue retention rate of 142%, and remaining performance obligations of $3.5 billion.

These numbers matter hugely to public companies. They influence investor confidence, stock prices, and strategic decisions moving forward. But how do companies compute them? How does a company like Snowflake go from your payment for a 2.5-hour batch-loading task every night to reporting quarterly revenue of half a billion dollars and an RPO of $3.5 billion?

This happens through an intricate revenue recognition process. “Rev rec” is the core mechanism finance teams use to understand a company's financial health. You might be far from releasing your own earnings reports, but the concepts that come together to create Snowflake’s report are exactly the same that any company using a usage-based pricing model faces.

Let’s pick one of these metrics—remaining performance obligations (RPO)—and work through how a company like Snowflake computes this number.

Computing RPO

Remaining Performance Obligations (RPO) are the contracted revenue that a company expects to recognize from existing contracts in future periods. In other words, it captures how much revenue the company should expect to collect from the customer – if Snowflake has signed a 3 year-commit, the RPO will factor in all 3 years of committed revenue. RPOs are an essential metric for understanding future revenue streams.

When a company uses usage-based billing, the process for calculating RPO can be more intricate than traditional subscription models. Here's how a company might use information from usage-based billing to compute that RPO number:

1. Data Collection

Firstly, the company needs to track and collect detailed usage data for each customer. This data can include metrics such as data volume processed, API calls made, or any other relevant usage metrics that determine the billing. There are two attributes that make data collection best-in-class: the data is fresh (e.g. you can compute the usage data for each customer on a daily basis) and you’re able to slice it by the relevant dimensions (individual contract or SKU).

2. Contractual commitments

Not all usage-based contracts are the same. Some might have minimum usage commitments (i.e., a customer commits to using at least a certain volume or number, even if their actual usage is below this threshold). Any such commitments should be included in the RPO.

3. Discounts and incentives

Consider any volume-based discounts or incentives that might reduce the actual billed amount. If a customer gets a discount after hitting a specific usage threshold, this needs to be factored into the RPO calculation.

4. Contract duration

RPO should consider the length of the contract. For example, if a customer has a three-year agreement with the company, the RPO should reflect revenue expectations for the entire duration, even if the billing is monthly or based on actual usage.

5. Churn and renewal rates

Historical churn and renewal rates provide insight into how long customers are likely to stay and if they're likely to expand their usage. Incorporating these rates will offer a more holistic view of expected revenues.

6. Aggregation

Once the above factors have been considered for each customer, the RPO is aggregated to get a total value for all customers.

Intricacy over complexity

Usage-based accounting isn’t complex. Every individual component is an understandable part of the business—how much storage is customer A using, and how long is customer B’s contract?

But it is intricate. Part of that intricacy comes from the data silos of these different components. Engineering can quite easily know the storage usage of customer A, but how do they get that information to the finance team? The finance team might know the length of customer B’s contract, but how do they align that with the compute they’ve used within that timeframe?

This is where having a clear data pipeline purely for revenue data is critical, whether you are a Snowflake or not. By leveraging information from usage-based billing in conjunction with other financial and contractual data, companies can calculate an RPO, or an NRR, or topline revenue, that reflects a more accurate and comprehensive view of their future revenue expectations and allows them to achieve that growth.

Where Orb can help

Orb is a billing system that’s natively built for usage-based models. The core billing engine helps customers track consumption on a daily basis over potentially millions of events a second and translates that to invoices you issue to customers.

In order to calculate a metric like RPO, Orb keeps a continuously accruing revenue ledger that’s built on top of usage data, subscription terms, and contractual commitments. Each day, whether or not an invoice has been issued, the revenue ledger tracks and aggregates the usage that’s occurred. Orb’s revenue waterfall and recognition reports can automatically capture accounting inputs that would normally require the very large data science team embedded in Snowflake or Google Cloud’s finance organization. This includes unbilled revenue in the middle of a subscription term and the precise burndown of a customer’s commitment to date. Since Orb combines this ledger with revenue recognition schedules and contract information, Orb’s accounting module provides the information you need to directly create your accounting journal entries. 

Orb’s responsibility doesn’t just end with invoices and data exports; instead, it acts as a bridge between the engineering teams and finance teams by natively producing revenue recognition reports that align with ASC606 guidelines, which specify concepts like an RPO. Unlike accounting systems that act purely on issued invoices and leave you to calculate unbilled revenue or credit drawdowns in a mess of spreadsheets, Orb tackles the modern challenge of revenue recognition in consumption based models as a data engineering exercise head-on.