QUESTION: I am looking for a software service that allows me to track customer and product profitability.  I work for a SaaS company and we are trying to track engineering and marketing time along with any direct expenses attributed to a particular customer or product.  Since labor is the biggest cost, we are looking to track employee time at a very detailed layer.

What I am looking for is a system that does the tracking and then feeds into the overall system, so I can measure profitability against a specific customer or product.  Ideally, I just want the "one-press-of-the-button" concept.  I know there is stuff for manufacturing, but see no solution that handles more SaaS service-oriented (non-consulting) companies.  Any advice?

ANSWER: In my experience, some challenges require business trade-offs, especially given the reality of available solutions.  While anything is possible, the benefit you receive from tracking this information needs to be business-reasonable to collect, and it also needs to fit with your company’s culture and realities.

Take product cost for example.  The challenges of tracking engineering time to a specific end-customer and product line is monumental -- unless your company does only very large sales to a very few customers.  Obstacles include: accurate time-capture for employees’ timing differences (the time lag between events and labor cost and the revenue to be recognized) and matching challenges.  Some of the expenses will be cost-of-goods-sold (COGS), which is matched by definition to revenue.  Some of them will not be tracked as COGS – and would be challenging to track as COGS (both from a GAAP and a management perspective).

A solution that provides value while considering some of these challenges is a product line P&L.  Revenue, COGS, engineering time and marketing time are all tracked to a P&L by way of an account code or other financial designation.  The period of time considered is usually 3-5 years for analysis – allowing for R&D or other engineering and marketing costs to be captured along with the overall revenue and margin created.

- Bob Scarborough, President and CEO, Tensoft

 Accounting for multi-element sales has quickly become one of the most complex areas of revenue recognition, a topic that affects most technology companies.  A multi-element sale occurs when two or more related product components are sold together at the same time.

The classic example of the multi-element sale is software plus maintenance. These are normally sold as two separate line items, but are inextricably related to each other, so they constitute a multi-element sale.  Beyond this relatively simple example of a multi-element sale, think of all of the everyday consumer products that we use where software is embedded, such as a mobile device.  Or think of an online subscription that includes setup as well as ongoing service.  In accounting terms, a mobile device is hardware, software and service. These multiple elements need to be treated separately in order to properly determine revenue.

The other day I saw an advertisement that said: “60% of the new products introduced in North America this year are ‘smart’ products – products with some sort of ‘smart’ or intelligent feature associated with them.”  As technology becomes more pervasive, more products become subject to the rules governing multi-element sales.  At what point do technology revenue recognition rules become the norm instead of the exception? 

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.

Last week, Tensoft announced a strategic partnership with BroadPoint Technologies, a Washington, D.C.-based business consulting firm. Under this agreement, BroadPoint will promote and deliver the Tensoft RCM Suite to its customers and prospective customers. BroadPoint has a proven record of success serving the software industry, and they already understand the issues that these customers face.

I was able to meet with some of the BroadPoint team in person in DC in July, while our President and CEO Bob Scarborough and sales director Mike Chadwick met with them in March in Atlanta. I’m personally excited to be working with this DC area firm, since this is where I grew up!  

We felt that BroadPoint was a good fit for Tensoft, because we’re seeking partners committed to a vertical strategy  and BroadPoint’s CEO Lee Raesly feels much the same. He recently said: “Our charter is to help our customers surmount industry challenges and improve their bottom line with bright ideas for better performance. Tensoft RCM is truly one of those ‘bright ideas.’ Tensoft’s solution will help us address the increasing complexity of revenue recognition for our clients.”