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

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.