When software companies are interested in Tensoft's Revenue Cycle Management (RCM) product, we first try to determine a fit for their requirements, so that no one's time is wasted.  Even if they have not yet created a requirements document, we find that a lot can come out of considering these three variables:

1) Billing. How does your company go to market (eCommerce, enterprise agreement, channel model, etc.)?  You'll want to look for a billing system or a billing support system that matches your go-to-market model.

2) Revenue Recognition. The rules for software industry revenue recognition are complex and changing. For the basics, you'll need a sub-ledger for deferred and recognized revenue analysis and appropriate methods and models to support your revenue recognition models.

3) Revenue Compliance. Could be part of the above, but is often a sub-set of that, and one that not every company needs.  There is no easy way to describe this, but if you have a sales process with multiple related elements in it (like software plus maintenance), and there are different recognition periods for the elements, you are most likely subject to more complex accounting guidelines.

Tensoft Revenue Cycle Management (RCM) supports billing requirements as well as complex software revenue recognition and contract management.

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

 Thanks to everyone who attended "EITF 08-1 and the Relative Selling Price Method for Multiple Element Arrangements," another very informative webcast presentation by Silicon Valley revenue recognition expert, Jeffrey Werner.  Tensoft was pleased to host this event, and is looking forward to Jeffrey's upcoming revenue recognition online classes that we'll hosting in November - check Tensoft's website next week for more information about that. 

Meanwhile, here are the answers to attendees' questions from last week's webcast:

Q: How does this apply to Web Based Application Services, if at all?

JW: If the web-based application service includes multiple elements, we would use ESP to allocate revenue to each stand alone element and then generally recognize revenue when that element is delivered. There may be other considerations such as the requirement to recognize set up fees over the longer of the contract period and the expected customer relationship period.

Q: If a company sells software using an on premise subscription model and SAAS-on demand, how can you justify using different revenue recognition models for which is essentially the same business model. The primary difference is on is a time based license that is on premise at the customer's location and the other is time based whereby the customer's software is located at a data center? This is more a request, but it would be helpful to see similar examples where the multiple elements include services, on demand services that include support. Is there anywhere I can obtain this info

JW: If the on-premise subscription model meets the requirements for software revenue (customer has the right and ability to take possession without significant cost) it would be recognized under software revenue recognition (residual method using VSOE).

The SaaS on demand sales would be allocated and recognized under EITF 08-1.

If a transaction had both on premise subscription and SaaS, the allocation would be done using EITF 08-1 and then on premise recognized using residual method and VSOE and the SaaS recognized as a service under 08-1.

Q: is EITF 03-5 no longer relevant?

JW: EITF 03-5 is superseded by EITFs 08-1 and 09-3.

Q: is ASU 2009-14 only used for tangible items w/ software?  What is used to determine how to account for a hosting engagement where software is sold? 

JW: If the hosting engagement meets the requirements for software revenue recognition because the customer has the right and ability to take possession and self-host without significant cost, then software revenue recognition would continue to be applied. If not, the multiple elements in the arrangement would be allocated revenue according to EITF 08-1.

Q: Would you use residual method for delivered software other than ESP?

JW: The residual method would only be used for the initial revenue allocation for software sales without other non-software elements. Software would use ESP and the relative selling price method for the allocation if the multiple element arrangement included non-software element.

Q: While I understand that contract terms and conditions affect the decision, I am wondering about his opinion on a particular transaction set.  If a company responds to an RFP which requires HW, SW & ongoing services (PCS & BPO, for example).

JW: This would appear to be a transaction that requires allocation of revenue to the separate elements using the relative selling price method. If some of the elements are determined to be software elements under the guidance of EITF 09-3, then the residual method would be applied to the allocated amount and VSOE would be required for any undelivered elements.

Q: Assume vendor responds to RFP requiring HW, SW and ongoing services (PCS & Business Process Outsourcing) and also assume that the vendor usually uses contract accounting & guidance of 97-2, an old fashion "Build & Run" scenario.  What's your opinion about using ASU 2009-14 to take the transaction outside of 97-2 guidance?

JW: If the hardware and software meet the requirements of EITF 09-3 to determine that the hardware and software work together to provide the functionality of the combined hardware and software product, then the transaction would be accounted for under EITF 08-1 for both the allocation and revenue recognition. If it is determined that there are both software and non-software elements, then revenue would be allocated using ESP and the relative selling price method and the software recognized under software revenue recognition and the non-software elements recognized under EITF 08-1.

Q: Does this mean that the software & PCS are taken outside of 97-2 with the hardware?

JW: It depends on whether the hardware and software meet the requirements of EITF 09-3 for treatment as non-software. If the hardware and software are always sold together and work together to provide the functionality, then the entire transaction would appear to be outside of software accounting. See Case A.

If the hardware is not always sold with the software, the determination might be that the hardware is a non-software element and the software is a software element. See Case B.

It would depend on the facts and circumstances.

Q: If your company has VSOE established for your product, can you choose to use BESP instead to avoid having to keep VSOE data and analysis?

JW: If a product currently has VSOE, the expectation is that the company would continue to use VSOE. The company would continue to use VSOE unless the situation changed and the company was no longer able to establish VSOE because the pattern of stand-alone sales no longer met the requirements of VSOE.

Q: If we have 2 different ways to sell our product - premise (where the customer buys a perpetual license and has it on site) and SaaS, the premise deals would be under SOP 97-2 and the SaaS deals would be under EITF 08-1, correct?

JW: For software only sales, the company would continue to use SOP 97-2 for allocation and revenue recognition.

For SaaS arrangements, the company would use ETIF 08-1 for allocation and revenue recognition.

If a transaction has both software and SaaS included in one sale, the revenue would be allocated to the separate elements using the relative selling price method of EITF 08-1 and ESP.

Then the software would be recognized using the residual method and VSOE and the SaaS would be recognized using EITF 08-1.

Q: In example 1, how is the ratable revenue split up between hardware, software, and support?

JW: Allocation of the ratable revenue should be on a reasonable and consistent manner to the different classes in the statement of operations/income statement. Pro rata allocation to each element based on contractual amount might be one method. The total revenue would be equal to the total ratable revenue for that period. Consideration would be given to each element. For example, the amount of revenue for support would probably be limited to 1/12^th for each month in the recognition period.

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.

Our recent announcement of a strategic partnership with McGladrey, one of the leading providers of assurance, tax and consulting services in the U.S., has a “back story” that is almost as interesting as the news itself. In the Tensoft press release, dated August 24^th, I alluded to what an ideal partner McGladrey is to represent the Tensoft RCM Suite. The company combines both a strong vertical market focus on the technology sector with multi-faceted consulting services.

We felt that McGladrey’s extensive experience providing tax advice and consulting services to technology businesses was a great fit for the Tensoft RCM Suite. The Microsoft Dynamics-based solution brings together the specific revenue, billing and contract management functionality that software and other technology companies require. McGladrey brings both the strength of their Technology Services practice and the depth of their assurance, tax and consulting services expertise.

How did we get together? I’d like to think that two such ideal partners would just normally find each other out there in the world of business. However, in this case, we had some help.  The agreement was facilitated through Microsoft’s Partner Channel Accelerator Program – a unique program that Microsoft has devised to help its Microsoft Dynamics ISVs locate potential partners using a more refined and focused approach. We went into this with some ideas about what our ideal partner should be and what the market would look like. The program facilitator drew out of us how we should define who our partners should be – what’s in it for them and what's in it for us – to make this something truly real and valuable to both sides.

There was a serendipitous component to the match as well. Tensoft has had an excellent, long-term relationship with Caturano & Co., a company that McGladrey recently acquired. We've been working with Caturano for several years now. They've sold and installed Tensoft RDM as well as Tensoft MNC, so we're excited to have the opportunity to work with them to re-sell Tensoft RCM too, now that they’re part of McGladrey.

Stan Mork, Managing Director – Technology Services for McGladrey, highlighted the good fit from his perspective on his company’s website. “At McGladrey, we understand that technology companies face some of the most stringent regulatory requirements of any industry today, and often grow – and change – so quickly that it can be challenging to set up adequate business processes to address these. By partnering with Tensoft, McGladrey can deliver a scalable solution which meets the specific revenue, billing and contract management needs of these businesses, and can then provide the value-added consulting services that will provide significant strategic advantage.”

From my perspective, I’d say this is a story of three excellent companies, working together for the betterment of all. Truly a win-win-win situation.

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.”