Dan King //January 7, 2013//
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:
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.
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.
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.