All Blogs
In today's dynamic tech industry, understanding revenue recognition isn't just a skill, it's a necessity.
Picture this - you’re growing and closing more deals than ever, and the fruits of your labor are about to go into your company's revenue stream. But hold on, before you pop the champagne, there's a critical aspect that can't be overlooked - revenue recognition.
We find that Founders are not necessarily familiar with this important topic. Some will often be surprised when VC firms demand a comprehensive audit according to US-GAAP or IFRS accounting standards pretty early on in a startups’ life. Moreover, if not thought through early enough in how processes look like, it can negatively impact a company’s reputation and even M&A prospects.
This blog is a RevRec 101 for all the Founders out there. Breaking down the complexities of revenue recognition into bite-sized pieces that non-finance folks can easily understand.
Revenue Recognition is a widely accepted accounting principle that describes when and how a company's revenue should be recorded. In Accounting, Cash and Revenue events are separate. The cash amount you receive for a transaction does not necessarily represent the amount of revenue you can recognize. They are driven by different logics and events, and the revenue recognition measurement is based on the rules determined in the accounting standards.
In short, revenue recognition is an accounting principle that gives guidelines to when the Seller's obligations to the customer (products and services) have been fulfilled.
%20(2048%20%C3%97%20500%20%D7%A4%D7%99%D7%A7%D7%A1%D7%9C)%20(8).png)
Historically, Software companies struggled to figure out exactly when revenue should be recognized, due to two main Software features: a) Intangible - Software often doesn’t have a clear ‘product delivery’ (think TV delivery vs Salesforce license; b) SaaS model - the industry’s move to Cloud services made it even more complex, since contracts became long-term and automatically renewed.
Over time, FASB and IASB, the accounting standards institutions, initiated a joint project to develop a single revenue standard containing comprehensive principles for recognizing revenue, removing inconsistencies and weaknesses in existing revenue requirements, providing a more robust framework for addressing revenue issues, and improving comparability of revenue recognition practices across entities, industries, jurisdictions, and capital markets.
The new framework definitely poses unique challenges for the technology industry, whose previous guidance on revenue recognition was superseded.
Today, Revenue Recognition for SaaS companies is a world of its own. Tech companies today have mixed revenue streams, complex and more dynamic business models. The revrec process becomes more challenging. Whether it's License, Usage, Subscription or services - recognition logic is often not that simple.
%20(2048%20%C3%97%20500%20%D7%A4%D7%99%D7%A7%D7%A1%D7%9C)%20(9).png)
Any Founder should know the basics, though. Revenue Recognition, at its core, has five basic steps which are similar to IFRS 15 and ASC 606.
.png)
The first step is identifying the contract with a specific customer. Each contract can have its own bespoke terms based on what both parties agree on. This can look like a silly step, but a contract can mean different things, from a verbal contract to a customer self registering on your website.
There are major building blocks of a ‘contract’ are a commitment with commercial substance, clear payment terms, and the ability to collect those payments. A contract contains a promise to transfer products or services to a customer. The company (Seller) should be able to identify the “obligation” or “obligations”. Moreover, a company must assess whether it is probable it will collect the amount it will be entitled to.
Let's say a company hastily approves a contract without thoroughly reviewing the payment terms or ensuring that both parties have a clear understanding of their respective obligations. In this case, disagreements in expectations and obligations can arise, leading to potential disputes or difficulties with revenue recognition.
%20(2048%20%C3%97%20500%20%D7%A4%D7%99%D7%A7%D7%A1%D7%9C)%20(10).png)
The second step is identifying the obligations the Seller is contractually required to provide. These are the Products and Services you need to deliver as a Seller.
A performance obligation is considered distinct when it's valuable to the customer and can stand alone and be sold separately from other products and services.
Each distinct product or service that an entity promises to transfer is a performance obligation. Products and services that are not distinct are bundled with other products or services in the contract until a distinct bundle is created. The bundle of products or services in that case is a single performance obligation.
A general promise to ‘collaborate’ or to ‘partner’, even if it is defined in a signed agreement, cannot constitute a performance obligation for revenue recognition purposes. The Seller needs to specifically identify the products and services in the agreement, such as ’billing software license’ or ‘installation’.
%20(2048%20%C3%97%20500%20%D7%A4%D7%99%D7%A7%D7%A1%D7%9C)%20(11).png)
The third step is calculating the transaction price. Notice this is the transaction price of the entire contract, without separating the different products and services. The transaction price can include cash and non-cash compensation the company will receive from the customer, according to the contract. The important thing is that you’re able to assign a clear monetary value to the products and services being sold.
Say a company miscalculates the transaction price by overlooking certain discounts or misinterpreting contract terms. This oversight could result in inaccurate revenue recognition, potentially impacting financial reporting and misleading stakeholders about the true value of the contract.
%20(2048%20%C3%97%20500%20%D7%A4%D7%99%D7%A7%D7%A1%D7%9C)%20(13).png)
The fourth step is how to allocate the total transaction price to the separate performance obligations in the contract. In other words, you assign a monetary value for the separate products and services (the performance obligations from step 2) that are included in the contract. Each obligation must have its own standalone selling price, meaning a clear monetary value which we can recognize as revenue, when that performance obligation is fulfilled.
If a company incorrectly allocates the transaction price among its performance obligations, it might lead to distorted financial results. For example, if a company bundles a software license with installation, but charges only for the software, it might need to allocate some of the software price to the installation service.
%20(2048%20%C3%97%20500%20%D7%A4%D7%99%D7%A7%D7%A1%D7%9C)%20(14).png)
In the final step, revenue is recognized when or as the performance obligations are satisfied by transferring control of a promised product or service to the customer.
This concept of transferring control of a product or service aligns with authoritative guidance on the definition of an asset. The concept of control might appear to apply only to the transfer of a product, but a service also transfers an asset to the customer, even if that asset is consumed immediately.
This may be over time or at a point in time. The assessment of whether control transfers over time or at a point in time is critical to the timing of revenue recognition.
Think of an installation - it is a process with usually an unknown date of fruition, that might be done when both parties think they’re done. Another example is a software license, where a performance obligation might be giving access to that software over a time period, and then the recognition might be allocated over that time period.
The assessment when to recognize revenue can get complex when the products and services are mixed, or complex. Think of services, license and usage all bundled together. In this bundled contract you need to determine the transaction price, to allocate it between each performance obligation, and to assess when each revenue shall be recognized- over time or at a point in time.
%20(2048%20%C3%97%20500%20%D7%A4%D7%99%D7%A7%D7%A1%D7%9C)%20(15).png)
Received Revenue Recognition was built specifically for B2B software companies and their unique complexities. It is compatible with all pricing models (including subscriptions, usage-based, or hybrid) and can be defined at the product and contract level in order to accommodate bespoke B2B agreements.
*Note: This blog is intended to provide a general 101 explanation for founders. Received is not an accounting firm, and the foregoing should not be construed as accounting advice. You should consult with an accountant before setting up any accounting policies or procedures.