This question was posed by an anonymous Controller yesterday on Proformative: "Is there a revenue recognition software that is ideal for SMB's?"   As one of their Topic Experts, I provided a brief answer there, and wanted to expand on that further here.

While there are a number of industries with complex revenue recognition requirements, I think it’s safe to say that, in general, technology and software companies are the largest affected segment, as well as the most affected.  For these companies, the ability to scale quickly is often a critical business need.  Given that, a better way to state the question might be: “Is there a revenue recognition solution that will scale with our business, supporting the pricing and performance our company needs now and as our organization grows?”

One challenge for people in technology-related companies is that their expected capabilities are often set by expectations of upper mid-market or enterprise sized businesses in their industry.  These expectations can be a serious mismatch when the company’s current budget and/or transaction volumes fit what you would expect in the SMB market.  One of the main reasons to consider a revenue management solution is to meet the increased challenges and expectations that result from growth.  In this environment, what was easy to manage in a spreadsheet yesterday may quickly become unstable and unscalable.

My company has been offering revenue recognition applications for nearly five years.  Our customers span businesses from “early ramp” to large midsized organizations ($500M+). To the question’s point – yes, solutions are readily available which may be ideal for SMB’s.

 I had the opportunity to weigh in on another great question on Proformative this week, this one from a finance executive who's interviewing with a SaaS company and wanted a quick update.  His question was: "With all of the pronouncements coming out on software recognition, has there been any substantial changes to the basics, i.e. we would have a monthly subscription fee revenue (take full revenue in month they were charged and used the product) and any support and maintenance would be amortized over the contract period?"

Here's the brief answer that I provided there:

"Yes - most definitely.

EITF 08-1 impacts SaaS companies because it changes the prior guidance of EITF 00-21 from the Residual Method to the Relative Selling Price Method. The criteria for separating contracts into separate elements is also different under 08-1.

SaaS companies may find there are more elements to account for in transactions and they are required to have values for all elements, not just the undelivered elements. Because 08-1 is a recent accounting change, best practices are still evolving.

Companies may find that their current accounting system may not adequately address issues under the new guidance and may need to consider manual workarounds or changes to their accounting system and polices.

Good luck with your interview!"

 This will be the first in an on-going series on this topic, authored by several of us here at Tensoft.   I’ll start at the beginning of the process – selecting an accounting and/or ERP system. 

The first myth that I’d like to discuss is: “To make a good decision about which ERP system to choose, you’ll need a detailed RFP (Request for Proposal) to send to each vendor that you want to consider.”   Ostensibly, the purpose of an RFP is to gather detailed information about your selection criteria, make an “apples to apples” comparison of the vendors, and evaluate them based on scoring a weighted analysis of their answers.   In reality, RFPs often simply amount to a waste of everyone’s time.   (A significant waste, since completed RFPs can be hundreds of pages.)

Here's why.  Years ago, the RFP process sometimes uncovered glaring deficiencies and red flags.  Today, however, the General Ledger modules of the top ten accounting systems just aren’t functionally that much different from each other.   In many ways, the functionality differences between the most popular systems are insignificant enough that they’ve practically become a commodity.   Because of this, the analysis provided by an RFP process today is more likely to turn up red herrings than anything truly problematic or outstanding.

What’s the alternative?   Instead of creating and evaluating massive RFPs, invest time into drilling into the exact nature of the business problems that you’d like your new system to solve.  For example, many of our customers have very complex revenue, billing and/or contract management scenarios that they previously developed massive spreadsheets to handle, because their system of record’s core functionality didn’t handle their needs efficiently and effectively.   Once you’ve identified the specific areas that are particularly painful  to try to address with your current systems and processes, you can then look for systems –and vendors - that are differentiated by their ability to solve those particular issues.

The result?  A streamlined selection process that skips rather pointless comparisons of ubiquitous features, and dives straight into the issues, allowing you to quickly identify who and what can solve them. 

 Exposed, then re-exposed - when will it end...?!  The joint revenue recognition project for FASB and the IASB will be hitting a significant milestone on 3/13/12 - the deadline for comments.  Coincidentally, Tensoft will be hosting a webcast on this topic that day, early enough for you to still get in your comments on the draft! 

Silicon Valley revenue recognition expert Jeffrey Werner will break down this topic, presenting practical, actionable information for attendees.  You may think that you'll have plenty of time to make the appropriate changes - or you may still think that these changes don't apply to your company.  Just in case, you may want to sit in on this timely and important webcast. 

Here's a quick preview of the agenda:

• Overview
• Scope, Timing and Status
• Five New Principles of Revenue Recognition
• Differences from Current US GAAP
• Implementation Guidance
• Effects of the Changes on Technology Companies 

For more information, and to register, just go to http://bit.ly/yBATpi, or contact me directly to register you.

And, if you're wondering how Tensoft's solution for complex revenue, billing and contract management can help you company make the required changes, please contact me, or Michael Chadwick. 

 Revenue management functionality is available either as part of a few financial and accounting software solutions, or as an independent solution that provide some level of integration to your system of record.  Vendors on both sides can be glib about their product’s ability to handle anything that you can think of.  If your company is in either the technology or software industries, you’re probably well aware that your needs in this area are beyond what most solutions are designed to handle.  When in doubt, be sure that the vendors that you’re considering can demonstrate - not just talk about or give a slick slide presentation on - the following capabilities:

1)    Ability to handle multi-element arrangements.

2)    Robust support for fair value methodology.

3)    The system can match the transaction flow of your go-to-market model(s), providing, for example, contract administration or integration to your website or CRM system.  

This is just a starting point, of course, but these three points will help narrow the field a bit.

 In case you missed this recent announcement, Tensoft Revenue Cycle Management (RCM) recently passed Microsoft's highest standard for partner-developed software and is now "Certified for Microsoft Dynamics" (CfMD).  This certification consists of a rigorous testing process performed by VeriTest, to demonstrate product development quality and compatibility, as well as at least 10 confirmed references.  (Many thanks to our customers who helped with this requirement - we were done in well under the average time for completion because of your help!)

Those were basically the same requirements for the CfMD that we had the last time that we went through this process, when we certified Tensoft Multi-National Consolidation.  This time there was one key difference though - the addition of a requirement to have a Source Code Escrow Account. 

This new requirement seems to get short shrift in discussions/articles about CfMD, but we see it as one of the key benefit to customers of CfMD products.  Without it, the CfMD benefits have the potential of being short-lived, providing cold comfort to unlucky customers.

A source code escrow account isn't something new for Tensoft - we've had an Iron Mountain account for years.  Having weathered two significant economic downturns since we started business in 1996, we've counted our blessings as we watched much larger companies fail.  While we feel pretty good about surviving, it would be foolishly arrogant to believe that we're now somehow "immune." 

We buy insurance to protect against adversity, and our Iron Mountain account is insurance that we buy for our customers.  We see it as a great investment in customer service!

I wanted to alert the Tensoft blog community that we’re now installing the Advanced Revenue Compliance Module for our Tensoft RCM Suite for customers who are currently running RCM, RDM or RDM-D. This is timely news, because this new module is designed to automate and streamline compliance with new FASB and AICPA rules that went into effect this month (January 2011).

If your company falls under the U.S. Financial Accounting Standards Board (FASB) rules for multi-element sales, known as EITF 08-01 and EITF 09-03, or statutes such as AICPA SOP 97-2 for software companies, the sooner you begin tracking the necessary data, the better. Available immediately as a cloud application or installed in-house, our new RCM Compliance Module plugs into your existing Tensoft software to flawlessly track all necessary data.

Now, of course, new customers are also welcome to add both the Tensoft RCM suite and the Compliance Module from scratch. If you have friends whose businesses fall under these new rules but are still tracking revenue longhand with spreadsheets, be sure to pass this information along to them. Sometimes it takes “one more onerous new regulation” to spur a company into finally automating their revenue compliance process. We’ve seen it time and time again.

Take a look at our recent press release for more details, and contact me at (888) 450-4030 x406 or via email for more information – or to jump-start the process of adding the RCM Compliance Module to your system. 

Happy New Year!

On September 14^th, Tensoft hosted a webcast^* with Silicon Valley software revenue recognition expert Jeffrey Werner entitled: Revenue Recognition Updates - Requirements of New EITFs and Future Changes to the Revenue Recognition Model.

This blog entry details Werner’s responses to audience questions posed after the live webcast.^*

Foreign Currency Issues

Q:  If a company has multiple-element arrangements set in various foreign currencies, is the estimated selling price set for each currency? Will changes in estimated selling prices be accounted for as a change in estimate?

A:  I think you would set the ESP in the currency of the transaction. This could either be an ESP list for each currency or translation on the date of the transaction from US$ ESP.

Typically, once the ESP is set, it would not change for a transaction once the accounting started, but could change for future transactions as the information used to make the estimate changes. So these would not be accounted for as a change is estimate. This is similar to current accounting for VSOE. Vendors use the VSOE on the date of the transaction. VSOE may change over time and a different VSOE can be used for a similar transaction at a later date.

Support allocation and recognition

Q: I think there is an error in the examples. The software items (licenses and support) should receive their allocation as a bundle. Then, the residual method is applied, which will almost always result in PCS being recognized as its VSOE value. Do you agree?

A: I think if you review the cases in EITF 09-3, when there are tangible product elements and software elements, the allocation is done under the relative selling price method and then the revenue is recognized, depending on whether the element is non-software or software. The Case I (page 15) has an example of non-software and software elements and support on both. In this case the support is separated out for each element.

I do not think the software and support is one bundle. I believe they are separate elements and have stand-alone value. In our example in the webcast slides, the support was on both the hardware and software elements. Since we did not have VSOE for support on only the software, the software and the related support were recognized ratably over the support period. Once you have separated the elements into software and non-software, you would recognize the non-software elements under EITF 08-1 and the software elements under SOP 97-2. 

When you separate out the elements into software and non-software, you may have software elements that are considered non-software because the tangible product and the software work as one product. 

Maybe this is where there is confusion:  In Case A from ETIF 09-3, the computer and the operating system are considered non-software because the computer is not sold without the operating system and the computer and the operating system work as one product. Both the computer and the operating system are accounted for under EITF 08-1.

In Case B, the computer is frequently sold without the operating system. In this case the computer is considered non-software and accounted for under EITF 08-1 and the operating system is considered software and accounted for under SOP 9.

VSOE or ESP for Recognition on Software

Q: For the operating system and the support, why can't you use the best estimate for revenue recognition?   

A: EITF 09-3 requires use of the Relative Selling Price Method for the allocation of revenue to each element. Then the next step is to recognize revenue based on the type of revenue – either non-software under EITF 08-1 or software under SOP 97-2. See paragraph 5 on page 10 of ASU 2009-14.

All software and services – use EITF 08-1 or SOP 97-2

Q: If we have multiple deliverables, where all deliverables are software- and/or services-related (i.e. no hardware or tangibles), do we have to comply with EITF 08-1 or with SOP 97-2? 

A: EITF 09-1 provides the accounting for multiple element arrangements with both tangible elements and software elements. Software only arrangements are still covered by SOP 97-2.

If all the elements are software-related, they would be accounted for under SOP 97-2 and EIF 08-1 would not be used.

Separation of Elements – No stand-alone value

Q: If we do not have the stand-alone value for deliverables, then it would be one unit of accounting and we need not proceed with determining the relative selling price; is that right? Also would you discuss a little more on stand-alone determination?  

A: Correct. If there are not stand-alone values for the different items, then the deliverables would be considered one element. With only one element, we do not need to allocate revenue. Revenue would be recognized when all the delivery for all deliverables is complete.

Elements are considered to have stand-alone value if the customer can use an element independently without the other elements. One indication of stand-alone value is resale value. If the customer can resell an item separately, it probably has stand alone-value.

ESP Methods for SaaS

Q: What are the some of the acceptable BESP methods for SaaS clients offering multiple products to customers?

A: Methods to establish the estimated selling prices for SaaS arrangements could include VSOE or VSOE “Light,” cost-plus-margin and what other companies sell an item for.

For VSOE or VSOE “Light,” this would be an analysis of the prices these elements were sold for when sold on a stand-alone basis. For example if a SaaS vendor sells training and often does so in stand-alone transactions, the fees for the training when sold separately could be used to establish the estimated selling price of the training when sold in a multiple element SaaS arrangement.

For the cost-plus-margin method, the cost of providing the training plus a normal margin on the training services could be used to establish the estimated selling price.

If other companies sell one day of training for a similar type of SaaS service, perhaps the price other companies charge could be used to establish the estimated selling price of one day of training.

Differences between current US GAAP and the proposed FASB IASB revenue model

Q: Under the new revenue model, what are the main differences in the allocation criteria between the old and new revenue models?

A: The proposed FASB IASB revenue model will use the relative selling price method for allocation of revenue to the multiple elements. Estimates will be used to establish the relative selling prices for the allocation of revenue. This approach is similar to the relative selling price method of EITF 08-1. There is no requirement of valuation hierarchy such as ETIF 08-1 has with VSOE, TPE and ESP. Estimates will be used for other considerations. The allocation of revenue will include estimates for the time value of money and collectability. Contingent revenue and rights-of-return will be estimated and the net revenue recognized. Under current US GAAP, contingent revenue and return rights generally require deferral. Revenue is generally deferred if not collectible in full and the time value of money is not taken into consideration.

^* Click here to view this on-demand webcast in its entirety.

  Maybe it’s force of habit, since I’m so used to starting every implementation project with a “kick-off meeting” where we set expectations and discuss logistics, but it seems important to do something similar here.   So, I’ll share a little about what you can expect to find here and who’ll be involved.

Starting with who’ll be involved, we plan to include a variety of perspectives from Tensoft ‘s team, including myself and Tensoft’s other co-founder, William White, as well as others.  In addition, we plan to include entries from occasional guest bloggers.

As a company, what we do is business systems for tech companies.  Within that specialization, we focus on execution.  Our focus isn’t on helping our customers build a better product or on building a market. Our focus is on how well our customers do as a company and how well we can enable them to track, manage, bill, and get information to make timely, decisive action possible. 

Our perspective for this blog comes from our experience working with hundreds of tech companies.  What works and what doesn’t?  What are best practices for our customers?  What are the challenges they face?  What are the areas of tech execution – like revenue management, supply chain integration, multi-national operations at an early stage, and the nature of the workforce,  for example – that are important as tech companies grow and re-structure?    

It also comes from our experience and evolution as a tech vendor ourselves – starting as a systems integrator and Value Added Re-seller, transitioning to a software product company, and then adding  hosted ERP to our core offerings.   What industry trends influence us, and how do we stay ahead of them?  How do we innovate and continue to improve on our fabless semiconductor software, our revenue management software, and our ERP solutions?

Finally, I’d like to encourage you to comment on the posts here – we want to hear from you.  And while we’d prefer to have open discussions on the topics here, please contact us directly by clicking on our name at the end of the article, if you’d prefer to send a private email.

-          Bob Scarborough, CEO and Co-founder, Tensoft