Know the rules to get revenue results
Revenue recognition for software companies is complicated and often misunderstood. Emerging integration of intangible software and tangible hardware from companies like Apple, Microsoft and others require new thinking.
Accounting leaders have struggled to establish rules to best reflect the nature of today's software market. A Wall Street Journal article recently noted that "revenue recognition is already one of the top issues cited by companies in financial restatements…” The rules are intricate, unforgiving and frustrating.
Even finance professionals and independent auditors can trip up. Consider the Hewlett-Packard acquisition debacle of Autonomy. The Wall Street Journal recently published that “Questionable revenue recognition practices may be at the heart of H.P.’s messy $11 billion acquisition of UK software company Autonomy."
So how can company leadership best understand software revenue recognition during these changing times? First, accept this statement: The rules are what they are. They can't be changed.
They're like tax regulations: They don't have to makes sense – they just are. Software companies have perpetually struggled with revenue recognition rules because of the inherent intangible nature of their product. It’s about the intellectual property, the code, the creativity. So let’s accept this and move on.
Generally, the four criteria that must be met to recognize revenue:
- Persuasive evidence that an agreement exists – (signed contract, PO, etc)
- Delivery has occurred or services have been rendered (shipping document, etc)
- The seller’s price is fixed and determinable (excludes guarantees or allowances for discounts)
- Collectability is reasonably assured – (the customer must have ability to pay)
When the above criteria are met, you can recognize revenue. However, if you add additional elements to the agreement such as implementation services, ongoing support services or tangible products, these transactions are now considered to be “multiple element arrangements," or “bundled arrangements." Software companies are required to separate each element and determine the fair value based upon stringent rules discussed below.
Unfortunately, it is not possible to fully articulate all the nuances within a concise article. However, I can briefly touch on two common revenue recognition rules software companies must acknowledge and apply, while including some insight.
- ASU 2009 13/14 – Issued by the FASB (Financial Accounting Standards Board). The rule applies to certain software companies beginning in 2011 which includes, but is not limited to: 1) companies that embed software into hardware (servers, computers, tangible machines, etc.); and 2) certain subscription based transactions, otherwise known as Software-as-a-Service. The key update to this rule is it modifies a strict legacy concept of fair value (otherwise known as “VSOE” – vendor specific objective evidence of fair value) historically dominated by SOP 97-2 and discussed further below.
A discussion on VSOE deservingly requires its own chapter in a book, so let’s keep it simple.Under ASU 2009 13/14, the VSOE concept is expanded by introducing “estimated selling prices."Estimated selling prices require the company to use its “best estimate” if it cannot prove VSOE, or third party evidence to support fair value.Keep in mind support renewals originally recognized under this guidance falls under SOP 97-2.Stay with me here.
- SOP 97-2 – Issued by the AICPA. This rule generally applies to software transactions that do not include hardware products. The key is to establish VSOE of fair value for each type of revenue stream. These revenue streams typically include software, post implementation support and maintenance, and professional services. The company needs to accurately determine the fair value of each distinct revenue stream using the VSOE concept. Your finance team is critical in helping determine this.
Under SOP 97-2, if you don’t establish VSOE you are most likely deferring more revenue than anticipated.An additional frustration is that you can have a very clean contract with distinct pricing, and you are still limited.Stated contractual prices are not allowable as fair value from an accounting perspective.If you haven’t established VSOE, the amount of revenue initially recorded can be disappointing.
So what does all this mean? Get your finance group involved in the sales cycles early, ideally before pricing is presented to a client. Add dedicated resources with a strong revenue recognition background to lean on for guidance.
Yes, this resource costs money, but is worth it. Why? It takes money to make money. Your finance team is a vital resource to setting accurate revenue expectations. Give your company the advantage of setting and achieving your revenue goals, properly setting expectations and playing to win.