There are many scenarios where what you sell does not move directly to revenue. Revenue is deferred largely because it has not been earned yet due to some need to deliver over time or possibly events that have not yet occurred. When you need to defer revenue you need to identify the sale to the customer (the combination of invoices or orders or contracts or terms that define the sale) and assign rules to the various categories of revenue so that they will be recognized correctly in the future.
If your sale includes multiple related elements then you may need an additional step in the revenue deferral process – a step to re-allocate the sales dollars among the various SKUs or activities that make up the sale. These types of transactions have been called multi-element arrangements (MEA). The accounting regulations provide specific guidelines for how you need to review and allocate revenue for each sale. Once you have this level of challenge related to your revenue it can be extremely helpful to have a framework to analyze and organize how your revenue process works.
One such framework organizes the requirements into three distinct categories. These categories are based on an overall revenue process model consisting of: a) determining the revenue model; b) applying the revenue model to sales that occur; and, c) recognizing revenue based on the revenue recognition concepts. These three categories are described in more detail here:
1) Determination. Effective revenue processes begin with identifying the appropriate compliance regulations and the revenue rules for the products sold based on these concepts. For many technology companies, an independent analysis and valuation of the items sold in multi-element models is also required. Determination is generally completed on an annual basis and may also be monitored during the year.
2) Application. While the determination occurs in a static environment, it is useful only if the determined revenue rules and values are applied to real company transactions as they occur. Application considers your sales model (how sales occur), as well as the transactions that are created for which the determined revenue rules are applied, and then automates the consistent processing of the revenue.
3) Recognition. If you apply revenue rules and policy to the appropriate sales transactions as they occur, revenue recognition is much more streamlined. However, it is still a good idea to review the sub-ledger validation, special case or exception rules needed, as well as the general processes around revenue recognition.
A request to understand the fair value of a single element within a multi-element sale thus becomes a Determination need. Likewise, a need to ensure a consistent approach to revenue recognition based upon company policy and compliance requirements is an Application need. Once the proposed framework is applied, addressing the requirements becomes significantly more manageable.
A solid, documented understanding of your company’s go-to-market model(s) is a good starting point. “Go-to-market” means the combination of channels, sales efforts, and customer actions that result in sales. This type of process and analysis is critical when thinking about how to best manage and implement the required revenue recognition processes and systems.
For more information about this topic, you may be interested in Tensoft’s white paper, “Revenue Regulatory Compliance Considerations in Business Software Implementation,” co-authored by Bob Scarborough and Jeffrey Werner.
For more information about Tensoft’s products and services, please contact us. If you’d like to comment on this article, I encourage you to Tweet, post to Facebook or blog about it!