Oops! Something went wrong while submitting the form.
Schedule a Demo
See your data in HubiFi < 2 days
See your data in HubiFi < 2 days
This blog addresses the basics of ASC 606, how to overcome its challenges, and what questions to ask to find the right revenue recognition software and partner.
ASC 606 exists to make revenue recognition more uniform across different industries and business models. However, its requirements and the insane pace at which companies have developed has created many challenges for correctly implementing it. This article addresses the basics of ASC 606, how to overcome its challenges, and what questions to ask to find the right revenue recognition software and partner.
ASC (Accounting Standards Codification) 606 is the latest revenue recognition standard that impacts all businesses involved in the transfer of goods or services to their customers.
Released in May 2014 by the Financial Accounting Standards Board (FASB) and International Accounting Standards Board (IASB), it provides a universal framework for recognizing revenue from customer sales.
ASC 606 illustrates the timing of when a company is truly fulfilling an obligation based on one of its contracts. That revenue is going to be tied to a certain period. That's the good news and makes things much more transparent.
The bad news is that the entire process is significantly more complex and rigorous than the prior standards. In addition, the data itself and how it’s being captured has changed. In most operational data sources, data is mutable but gets overwritten or deleted when that should not be the case. Business models, too, have changed, with subscriptions over time complicating things and throwing things like upgrades, downgrades, additions and deductions, discounts, bundles, etc. into the mix.
There just hasn’t been a lot of thought put into this until recently when ASC 606 was implemented from a GAAP perspective. A lot of the financials in the past were based on billing a customer , cash basis, % completion, point of sale, completed contract or proportional performance. There were a lot of different implementations for when revenue was actually recognized.
The whole purpose of GAAP accounting and accrual accounting is to make financials more meaningful and insightful. In other words, to provide a better reflection of how a company is actually performing.
Imagine some companies that really rigorously bill customers and some other companies that aren’t so great at it and there's a timing difference. Their revenue might look wildly different, even though those two companies could be pretty similar in performance. ASC 606 aims to eliminate this. However, we’re still at a point where technology is lagging behind and can’t keep up with the nuances of today’s business models.
Revenue recognition can get complicated depending on different business models. Despite that, it can be explained using the four W’s: who, what, when, and why.
ASC 606 revenue recognition is important for all types of organizations and business entities: public, private, or non-profit. It is used for contracts involving the exchange of goods, services, or specific nonfinancial assets with customers.
ASC 606 provides a universal framework used for recognizing revenue from the sale of goods and services. It focuses on the obligations expressed in the contract and ensures that revenue is only recognized when these obligations have been met. To help organizations follow these principles, the standard provides a five-step process for revenue recognition we’ll cover a couple of sections below.
In May 2014, the FASB and IASB published the Accounting Standards Update (ASU) 2014-09, introducing ASC 606. It highlights how revenue received from contracts is treated and provides a standardized framework for recognizing revenue.
ASC 606 revenue recognition was developed for a variety of reasons, including:
This step details the criteria an entity or a business must meet when it enters into a contract with a customer to deliver goods or services. The components of the contract are:
Performance obligation simply means the transfer of goods or services to the customer. During this step, businesses should define each distinct performance obligation. A good or service is considered distinct when it has value for the customer and can be transferred independently of other goods or services in the contract.
This step is about calculating the transaction price. The transaction price can include cash and non-cash compensation received from the customer, as defined in the contract. An important thing to note is that businesses need to factor in any discounts, upgrades or custom pricing arrangements into the calculation.
This is where businesses distribute the total transaction price across the unique performance obligations in the contract. For subscription-based transactions with recurring payments, the performance obligation is continuous. This is a scenario that makes deferring and allocation complex.
This step specifies that revenue should be recognised as each performance obligation is met, and not when the contract is initiated or when the funds associated with the contract are received.
Here are a couple of examples:
If a customer purchases a made-to-order sofa that will take 12 weeks to build and ship, the revenue from that contract should be recognised in the accounting period when the order is fulfilled, not when the order was originally placed.
If a customer signs a contract committing to a year of subscription software service at a rate of $12 per month, then the business needs to attribute each monthly payment to its respective accounting period. The business should not treat the entire year’s worth of fees as a lump sum that’s recognized in the period during when the contract was signed.
The industries that were highly impacted by ASC 606 are those who either have a lot of transactions or they have revenue/performance obligations that happen over time or their business model (and contracts) are flexible and can change at any time.
The hardest ones are when you have both. It’s industries where there's some sort of a service over time and you have a ton of transactions from customers. Insurance and subscription services over time are a good example.This is a scenario where you’re selling a lot of policies and a lot of subscriptions. And that revenue is being earned over time, but what if there’s a change to the services or subscription? What if the customer decides to add or deduct someone from their policy of their subscription or add some sort of different technology to the contract?
Now you have two performance obligations on a contract that's happening over many months, sometimes years. That complexity from a data perspective is tough. That’s not only because you have to identify the contract, but also because you have to manage the contract life cycle with all the changes included. Then you have to track the performance of those individual obligations across those two timeframes. That ends up being a ton of data. Unfortunately, you really have to capture every lifecycle change of a contract that affects either the price or how you allocate or the performance obligation. And that happens to be virtually any contract change.
That's going to have a huge impact on your rev rec schedules. Historically, companies that had all their data in an ERP like Netsuite were able to automate revenue recognition over a period of time on a basic level. The challenge comes in more complex scenarios, for example if someone modifies the contract during the revenue recognition period or after.
Now you're tracking data changes over time and ERP and existing rev rec solutions start to fall short. Someone ends up hacking together an analysis to tell them the right answer. That analysis comes from the heroics of a single person, not a systemic solution.
You end up the risk of one person who’s processing a giant revenue schedule, but is also responsible for calculating what is arguably the most important number in your business. That’s where the situation becomes untenable.
There’s a ton of challenges with ASC 606 and applying it to your business, and some of the most common ones include:
Finding the right revenue recognition software means looking at the five step process. You have to be able to understand the core requirements of recognizing revenue and where your customer contracts are. A lot of companies have contracts in their online selling marketplace, CRM, ERP, or even on their website because that’s where their orders are coming from.
So the first thing to think about is do you have a solution that gets all your contracts into one place. Once you answer that, the next question is: what are your performance obligations?
If you go to your source systems and can identify what the right data & metadata is - that’s already half the battle. The other part that gets tricky is the transaction price. For a lot of companies, the transaction price for revenue is the same as the customer price. That's fairly simple. You have a contract, your performance obligation, and how you know how much of that revenue was done. Then the performance obligations are completed and it’s relatively easy to capture, even in the most basic of revenue recognition tools.
However, what happens when the transaction price and the customer price are different? What if there’s a discount involved in the process? All of a sudden, a relatively straightforward process becomes much more complex.
For example, say there’s a 50% discount on a couple of items. That type of bundle discount means you really have to look at that discount as a percentage of the list price of those two items. And then you have to allocate the discount, which means that your net transaction selling price needs to be allocated and apportioned appropriately.
That prompts key questions from a system perspective. Can you get all the data in one place from all your different contracts systems? Can you integrate and understand multiple types of performance obligations, which could be performance obligations over time, like a pro rata or is it going to be an immediate performance obligation? And then do you have any complexities in the transaction price or is it the same as the customer price?
One concept of ASC 606 is especially important for high transaction business, like e-commerce or subscription services, and that’s event-based revenue recognition.
Say for example you fulfilled an item from an online store or physical store. In those cases, there's concepts like a right of return. You give your customers a 30 day window to return a product. From historical data, you know a certain percentage of those folks are actually going to return some of those items.
So when you book the revenue, you also need to figure out what is the probability someone's going to return it. And you need to back that out of your revenue calculation. It used to be that accounting was just historical cash. Well, now proper accounting is needed with many complexities and probabilities involved you need to account for.
You need to look at probabilities and probabilistic outcomes of things returning. You have to true those up against your forecast. That's a lot of complexity and many managers are aware they aren’t ready for it today.
Understanding these questions is the prerequisite to selecting the partner that you need to automate revenue recognition. If you know your use cases and rev rec requirements, you’ll be able to understand what the solution needs to be able to do from a data point of view.
Finding the right revenue recognition technology starts with looking at your own data first and asking the right questions. Take the first step to analyzing your revenue recognition practices and schedule a free conversation with the founder of HubiFi here.
Former Root, EVP of Finance/Data at multiple FinTech startups
Jason Kyle Berwanger: An accomplished two-time entrepreneur, polyglot in finance, data & tech with 15 years of expertise. Builder, practitioner, leader—pioneering multiple ERP implementations and data solutions. Catalyst behind a 6% gross margin improvement with a sub-90-day IPO at Root insurance, powered by his vision & platform. Having held virtually every role from accountant to finance systems to finance exec, he brings a rare and noteworthy perspective in rethinking the finance tooling landscape.
Copyright © 2024 HubiFi | Powered by HubiFi
