Receiving a payment from a client doesn’t mean that you have earned it. If you are the manager of a fast-growing software company that is using accrual-based accounting, that money will probably be a liability on your Balance Sheet, as Deferred Revenue, until you have earned the right to it by actually performing the obligation. At the point of payment, not only have you not earned the revenue, but there is a chance that you’ll be unable to satisfy the obligation and need to return it - therefore the revenue cannot be recognized right then.

Depending on the good / service you are selling as well as your clients’ needs, it may be a few days, weeks, or months until the good / service is delivered / performed and the money is earned, allowing it to be recognized as Revenue on your Income Statement. Bottom line, you want to make sure that you recognize revenue correctly and in a consistent manner. This will make it easier for your team, investors, and auditors to review your financial statements and compare them over time as well as with other companies.

Revenue recognition is a generally accepted accounting principle (GAAP) that outlines the conditions in which a business can recognize revenue. ASC 606 (Accounting Standards Codification) provides a uniform framework by the Financial Accounting Standards Board (FASB) for recognizing revenue from contracts with customers.

There are five steps needed to satisfy the most recent revenue recognition principle:

1. Identify the contract with the customer
2. Identify the contractual performance obligations
3. Determine the amount of consideration/price for the transaction
4. Allocate the determined amount of consideration/price to the contractual performance obligations
5. Recognize revenue when the performing party satisfies the performance obligation

Tracking deferred revenue tends to be a time-consuming and error-prone process. Therefore, you must be very careful.

Why is it important?

There are many reasons why this is important:

1. Stay Compliant: The most critical reason is that you want to be compliant with the accounting standards.
2. Easy to Read: You want it to be easy for anyone (a new employee, investor, or auditor) to read, understand, and analyze your financial statements. ‍
3. Match Revenue with Costs: Not only is this a basic accounting principle (the “Matching Principle”), but it helps you to show an accurate and normalized Income Statement. If revenue and associated expenses incurred to deliver the performance obligation to earn the revenue, are not recognized in the same time period, then your financial statements and margins will be inconsistent and misleading. However, many companies can’t do this correctly because they are not accurately recording the data or don’t have the data readily accessible to them.

Different Pricing Models, Different Ways to Recognize Revenue

Revenue recognition needs to keep in mind the nuances of the price plan. Therefore, there should be close coordination between the Sales, Product, and Finance / Accounting teams.

We will go over a few examples of common price plans and how revenue should be recognized in each scenario.

Traditional License Model

The traditional software price plan model is time-based (or access-based), not usage-based. The percent of the contract that is recognized is directly proportional to the percent of time that has passed in the contract term. Actual usage is not a consideration.

In this model, the seller will, for example, offer a $12,000 annual contract and using the straight-line method will recognize it equally over the 12-month period. If it’s paid all up-front, the money will be put into deferred revenue, then $1,000 will be recognized at the end of each month. It wouldn’t matter if the client used the service or not. The performance obligation is not based on the usage of the particular product, but access to the particular product. Therefore, just giving the client access to the product is enough to satisfy the performance obligations each month.

Pay As You Go Model

In a pure usage-based model, such as a Pay As You Go, the revenue should be recognized at the end of the billing period. Since everything that was used in that month is reflected in the invoice, all of the revenue on that invoice can be recognized that month. Therefore, if I were to send 100,000 text messages with Twilio for $0.01 per message, my bill would be $1,000. Twilio would then recognize all $1,000 immediately (i.e., in the month that I sent the text messages).

Mixed Plans: Monthly Base Fee + Usage

A common model in the usage-based world is a combination of a flat-fee and usage. For example, an annual contract with a $1,000 monthly fee and incremental fees on different meters ($10 per active user, $1 per GB storage hour, $0.05 per API call, $0.01 per text message, etc.) both charged at the end of the month. In this case, there is the committed Monthly Recurring Revenue (MRR) of $1,000 for access to the software for that month as well as the same month’s usage component (say $11.06, if just one of each of the above incremental meters is used). All $1,011.06 would be invoiced and recognized together for that month.

Mixed Plans: Annual Base Fee + Usage

This can be further complicated if the annual committed base fee (say $12,000) is expected upfront. Then there is a mismatch between the first invoice sent to the client before the contract begins (say in December), the cash received from the client (maybe in December, maybe in January), and the recognized revenue for the first month (say in January).

1. First Invoice: The December invoice would be $12,000, but none of it would be recognized yet as it has not been earned yet.
2. Second Invoice: If the usage and prices are the same as in the example above (“Monthly Base Fee + Usage”), then the January invoice would only be $11.06. The access fee, $1,000 for the month, was already considered in the December invoice for the $12,000 base fee. The revenue recognition for that month would be $1,011.06, for performing the obligation of access and usage. Meanwhile, the cash you receive from the client for that month will be $11.06.

The accounting team needs to keep track of the revenue recognition of the deferred revenue using the straight-line method as well as the (not deferred) revenue from month-to-month usage spend. Typically these teams are managing a growing number of distinct contracts, each with different rates, lengths, and terms.

Mixed Plans: Base Fee With Included Usage + Overages

Additionally, it is common in this model that the committed base fee (whether annual or monthly) includes some usage and then an overage fee on incremental usage above that. In this case, for example, the $1,000 monthly fee may give the client free access to up to 10 active users, 10 GB storage hours, 10 API calls, and 10 text messages. So, if the client uses 1 of each meter, then there would be no usage fee. The revenue amount recognized that month would be just on the committed base fee of $1,000, for giving access to the product.

However, if in the next month the client uses 11 of each meter, then the incremental overage fee on usage applies and there would be a cost of $11.06. The amount recognized that month would be $1,011.06, representing access to the product, the included usage, and the incremental usage.

Mixed Plans: Pre-paid Credit Model

This is where things get interesting. In this example, if a client buys 12,000 pre-paid credits for $12,000 in December for future use, and uses none of the credits in January, no revenue should be recognized because the company hasn’t earned any of it yet. However, if the client then uses 5,000 credits in February, $5,000 should be recognized for that month. Similarly, if 1,000 credits are used in March, then $1,000 should be recognized for that month. It is possible that the client will use all 12,000 credits before the year ends (say by July) and the company will be able to recognize all of the $12,000 in revenue, perhaps faster than anticipated!

One typical challenge here is that clients may be sold credits at different rates. So, although credits are advertised at $1 per credit, if bought at volume there may be discounts to encourage client commitment. Therefore, 100,000 credits may only cost $80,000 - a 20% discount. This needs to be considered in the revenue recognition. In this case, if 1,000 credits are used in March, then only $800 should be recognized for that month.

In many cases, companies are managing client credit balances with multiple credit valuations. A particular client may have a balance of 121,000 credits, where 1,000 of the credits have a 1 credit to $1 valuation, 100,000 credits with a 1 credit to $0.80 valuation, and 20,000 credits that were given for free due to a missed SLA.

Once again as the number of clients proliferates and the different credit allocations / rates are made, revenue recognition becomes increasingly complex. Keeping track of the different prices of each of these credit allocations and knowing which are being used can be challenging for the Accounting and Product teams. However, the credit-based model is becoming increasingly preferred by sellers (like Snowflake) and purchasers of software.

How Does Octane Solve This Problem?

Octane assists Accounting departments with all 5 steps of ASC 606 to recognize revenue. Since Octane calculates your client’s usage in real-time and has their price plans as well as the price for each credit, it is uniquely able to determine how much revenue needs to be recognized each month. Also, it can easily distinguish and separate the base fee from the usage component. Furthermore, its end-to-end integrations with CRMs, usage-metrics, payment gateways, and accounting software packages allow it to automate much of this flow - from contract-signing to actual usage tabulated to invoice sent to payment received to revenue recognized.

Conclusion

It is critical to ensure that your business is recognizing revenue on a timely basis and correctly. Having a process that is too manual or complicated is a serious risk, especially as your company scales. The Sales, Product, and Finance / Accounting teams must coordinate on the pricing structures that they are offering and ensure that there is an efficient and reliable process on the back-end to recognize revenue. This will position your company to scale its sales, operations, and future financing.