Software Revenue Recognition

Software Revenue Recognition A User-Friendly Guide for Navigating through the Many Complexities pwc

ATTENTION Please visit www.pwcrevrec.com to find the latest information on software revenue recognition. The document that follows is a print-out of the www.pwcrevrec.com Web site content as of March 31, 2009. We strongly recommend that you use the Web site as your primary source of revenue recognition information from PricewaterhouseCoopers to ensure you have the most current guidance.

Welcome Welcome to PwC's Software Revenue Recognition Web site. Software revenue recognition has not gotten easier. However, one of the keys to success is having the right tools. With this in mind, we are pleased to present a new, updated, interactive version of our well known user-friendly guide for software revenue recognition. We have updated the instructional content to reflect the latest trends and challenges, including a new chapter dedicated to Software-as-a- Service. And by moving to a web-based format, we've enabled users to more easily navigate the many complexities of software revenue recognition. We've added the following features: Web 2.0 capabilities, Flip-through pages, Make and save notes, Highlight text, In-context search results, easy access to other PwC thought leadership for software companies. While a transition from US GAAP to IFRS appears a fait accompli, when it will happen remains uncertain. So, most of the global software industry will continue under SOP 97-2 until at least 2014. Yet, while US GAAP continues to apply, it will be imperative for software companies to begin soon to address the impending conversion. Look for future guidance on www.pwcrevrec.com regarding software revenue recognition under IFRS and the transition thereto. Also, for those under US GAAP, applicability of SOP 97-2 may be affected upon resolution of EITF Issue No. 09-3. And finally, will the relief around determining fair value being afforded under EITF Issue No. 08-1 to non-software companies be considered for software companies? Again, keep tuned to www.pwcrevrec.com where we will address these issues as they develop. We hope this guide will continue to be your tool of choice to help you address the questions that will arise. PwC distinguishes itself in its practical applications of these complex rules. Please do not hesitate to contact me or the PwC professional nearest to you to discuss this subject and how we can assist you. Sincerely, Dean S. Petracca Global and US Software Leader

Acknowledgements This guide would not be possible without the contribution of the partners and staff of PricewaterhouseCoopers' software industry network. It is their continuous sharing of knowledge and experience that provides the practical industry insight and expertise that makes this thought leadership possible. PwC's User-Friendly Guide was the first comprehensive guidance regarding the challenging subject of software revenue recognition, and continues to be regarded as the best. Many PwC professionals have contributed to it over the years but I would like to specifically acknowledge those software industry experts from around the country who were part of the team responsible for this most recent update - they are listed below. And finally, I want to specifically acknowledge Alan O'Rourke, senior manager in Boston, who led this project to comprehensively update the content and to launch the Guide as a Web-based tool. Alan O'Rourke, Senior Manager, Boston Bobby Bono, Senior Manager, Raleigh Clay Campbell, Partner, San Jose Jim Connor, Partner, Washington DC Rita Dhir, Senior Manager, San Jose Jonathan Gralnick, Senior Manager, New York Brett Harrington, Senior Manager, Florham Park Brian Hough, Senior Manager, Boston Geoff Jacobi, Managing Director, Washington DC Asif Khoja, Manager, Boston Tina Knauss, Senior Manager, San Jose Karen Nakamura, Director, Washington DC Aimee Pace, Senior Manager, Florham Park Josh Paul, Senior Manager, Florham Park Tiffany Perkins, Global Marketing, San Diego Brent Stolle, Senior Manager, Florham Park Mark Stratton, Manager, Minneapolis Jill Walker, Senior Manager, Florham Park Dan Zwarn, Partner, Florham Park

Table of Contents Page(s) 1.0 Scope of statement of position 97-2 1 1.1 Determining whether software is incidental to the product as a whole 1 1.2 Determining when software becomes more than incidental 5 1.3 Determining whether the software is essential to the functionality of non-software deliverables 6 1.4 Determining whether a contract requires significant production, modification, or customization of the software 8 1.5 Determining if a hosting arrangement is a service contract outside the scope of SOP 97-2 9 1.6 Determining if an arrangement includes a lease 10 1.7 Determining whether an arrangement is a contract for funded software development 10 1.8 Determining the applicable guidance 11 2.0 Basic principles of software revenue recognition 12 2.1 Persuasive evidence of an arrangement exists 13 2.1.1 Use of written contracts 2.1.2 Use of master agreements 2.1.3 Varying practices for different customers 2.1.4 Form of license: perpetual versus term 2.2 The software has been delivered 18 2.2.1 Specific terms for delivery 2.2.2 Electronic delivery 2.2.3 Software duplication 2.2.4 Delivery location 2.2.5 Intermediate delivery site 2.3 Fixed or determinable fees and collectibility 26 2.3.1 Extended payment terms 2.3.2 Third-party financing arrangements 2.3.3 Cancellation privileges 2.3.4 Fiscal-funding clauses 2.3.5 Forfeiture or refund clauses 2.3.6 Customer-acceptance clauses

3.0 Arrangements involving multiple elements 48 3.1 Revenue recognition for multiple-element arrangements 49 3.2 Vendor-specific objective evidence 50 3.2.1 Residual method 3.2.2 Establishing VSOE of fair value 3.3 Postcontract customer support 55 3.3.1 General guidelines for recognition of PCS revenue 3.3.2 VSOE of fair value for PCS and other undelivered elements does not exist 3.3.3 PCS revenue is recognized with the initial license fee 3.3.4 Distinguishing between warranty obligations and PCS 3.4 Determining VSOE of fair value for PCS arrangements 60 3.4.1 Fair value of PCS in a short-term time-based license 3.4.2 Fair value of PCS in a multi-year time-based license 3.4.3 Fair value of PCS in perpetual and multi-year time based licenses 3.4.4 Coterminous PCS 3.4.5 Fair value of PCS with a consistent renewal percentage but varying renewal dollar amounts 3.4.6 PCS arrangements involving a maximum charge 3.4.7 PCS renewals based upon users deployed 3.4.8 Fair value of PCS with usage-based fees 3.5 Explicit versus implied PCS arrangements 68 3.6 Services 72 3.6.1 PCS offered in arrangements involving significant customization or modification 3.7 Presentation and disclosure of product and services revenue 74 4.0 Giving end users rights to return or exchange software 75 4.1 Return rights 76 4.1.1 Implicit and explicit 4.1.2 For specified products 4.1.3 For unspecified products 4.1.4 In multiple-element arrangements 4.2 Exchange and platform-transfer rights 80 4.2.1 For specified products currently available 4.2.2 For specified products not currently available 4.2.3 For unspecified products 4.2.4 Sunset clauses 5.0 Postcontract customer support 86 5.1 Specified upgrades and enhancements 86 5.2 Additional products 92 5.3 Specified versus unspecified additional software products 93 5.4 Intellectual property infringement indemnifications 99 5.5 Undelivered elements to be provided by Third-Party Vendor 99

6.0 Impact of Discounts, Marketing Programs, and Barter Transactions 101 6.1 Discounts 103 6.1.1 Multiple-element arrangements in which VSOE exists for all elements 6.1.2 Multiple-element arrangements in which VSOE exists only for undelivered elements 6.1.3 Multiple-element arrangements involving an upgrade right 6.1.4 Coupons for or discounts on future products 6.2 Volume purchase arrangements 110 6.3 Discounts in PCS arrangements 111 6.4 Impact of a vendor's marketing and promotional activities 115 6.4.1 Creating customer expectations of future deliverables and product roadmaps 6.4.2 Undelivered elements to be provided by Third-Party Vendor 6.5 Barter transactions 118 7.0 Issues related specifically to resellers 123 7.1 Persuasive evidence of an arrangement 124 7.2 Delivery 124 7.3 Fixed or determinable fees and collectibility 125 7.4 Rights of return or exchange and price protection 128 7.5 Implied PCS arrangements 131 7.6 Prepaid royalties 133 7.7 Multiple-element arrangements with resellers 134 8.0 Funded software development arrangements 137 9.0 Services and contract accounting 141 9.1 Determining if services can be accounted for separately 142 9.2 Applying contract accounting 147 9.3 Interaction of SOP 97-2, SOP 81-1 and SAB 104 153 9.3.1 Separation and allocation 9.3.2 Evidence of arrangement and collectibility 9.3.3 Impact of customer-acceptance clauses 9.3.4 Impact of PCS and other services 9.3.5 Extended payment terms 9.3.6 NRE arrangements that include subsequent manufacturing 9.4 Accounting for installation services 157

10.0 Hosting Arrangements Including Software-as-a-Service (SaaS) 160 10.1 Applicability of SOP 97-2 to hosting arrangements 161 10.1.1 Significant penalty 10.2 Revenue recognition guidance for hosting arrangements falling outside of SOP 97-2 165 10.2.1 Set-up services 10.3 Hosting arrangements and other considerations 169 10.3.1 Professional services 10.3.2 Specified enhancements and upgrades 10.3.3 Service level agreements 10.3.4 Contingent revenues 10.3.5 Inconsequential or perfunctory deliverables 10.4 Accounts receivable and bad debt considerations 175 10.5 Cost considerations 176 10.5.1 Cost associated with up-front services 10.5.2 Capitalization of development costs 10.5.3 Transition from a hosted to a license model and vice-versa 11.0 Tax Considerations 180 11.1 Federal income tax matters 181 11.1.1 Software revenue recognition for tax purposes 11.1.2 Deferral of revenue 11.1.3 Sale of goods 11.1.4 Sale of services (including PCS) 11.1.5 Other considerations 11.1.6 Common differences in revenue recognition between tax and financial reporting 11.1.7 Changes in accounting method rules 11.2 State income tax matters 185 11.2.1 Income tax considerations 11.2.2 Nexus 11.2.3 Apportionment 11.3 Sales and use tax considerations for software 187 11.3.1 Nexus 11.3.2 Prewritten computer program 11.3.3 Custom computer program 11.3.4 Custom modifications 11.3.5 Customized computer program 11.3.6 Software maintenance agreements 11.3.7 Consulting services 11.3.8 Software training services 11.3.9 Hosting arrangements, including Software-as-a-Service 11.4 International tax matters 191 11.4.1 Cross-border software transactions: characterization and source 11.4.2 Characterization of software transactions 11.4.3 Transfer of a copyright right 11.4.4 Transfer of a copyrighted article 11.4.5 Provision of services 11.4.6 Provision of know-how 11.4.7 Transfer of a copyright right: sale vs. license 11.4.8 Transfer of a copyrighted article: sale vs. lease 11.4.9 Forms and labels 11.4.10 Means of transfer

11.4.11 Hybrid transactions 11.4.12 General sourcing rules 11.4.13 Copyright rights 11.4.14 Copyrighted articles 11.4.15 Services and know-how 11.4.16 Withholding taxes 11.4.17 Extraterritorial income 11.4.18 Domestic manufacturing deduction 11.4.19 Income from foreign corporations Appendices Appendix A: Statement of Position 97-2 A-1 Appendix B: Statement of Position 98-4 B-1 Appendix C: Statement of Position 98-9 C-1 Appendix D: Technical Practice Aids for SOP 97-2 D-1

Chapter 1: Scope of Statement of Position 97-2 1.0 Overview The revenue recognition guidance in SOP 97-2 applies to activities that represent licensing, selling, leasing, or other marketing of computer software. SOP 97-2 does not apply to products or services that contain software incidental to the products or services as a whole. SOP 97-2 applies to arrangements where a vendor hosts its own software for a customer unless the arrangements are service contracts outside the scope of SOP 97-2. Also, SOP 97-2 requires that the guidance in Statement of Position 81-1 (SOP 81-1), Accounting for Performance of Construction-Type and Certain Production-Type Contracts, be applied to contracts in which (1) significant production, modification, or customization of the software is required or (2) the service element in the arrangement does not meet the criteria for separate accounting. The initial determination to be made in establishing the proper revenue recognition should be to decide what relevant accounting guidance is applicable - EITF 00-21, EITF 03-05, EITF 00-03, SOP 97-2, SOP 81-1 or SAB 104. The first question to answer is whether or not the software is more than incidental to the products or services as a whole, or whether the customer can even take possession of the software. To the extent the software is incidental or the customer has no contractual right to the software, the arrangement falls outside the scope of SOP 97-2 and should be accounted for pursuant to SAB 104, EITF 00-21, or other relevant guidance. If the arrangement is in the scope of SOP 97-2, the next question to answer is whether the services in the arrangement involve significant production, modification or customization of the delivered software. Arrangements involving such services should be accounted for in conformity with contract accounting, in accordance with the provisions of SOP 81-1. The flowchart in Appendix C of SOP 97-2 describes this decision process. This chapter provides additional guidance in the following areas: 1.1 Determining whether software is incidental to the product as a whole 1.2 Determining when software becomes more than incidental 1.3 Determining whether the software is essential to the functionality of non-software deliverables 1.4 Determining whether a contract requires significant production, modification, or customization of the software 1.5 Determining if a hosting arrangement is a service contract outside the scope of SOP 97-2 1.6 Determining if an arrangement includes a lease 1.7 Determining whether an arrangement is a contract for funded software development 1.8 Determining the applicable guidance 1.1 Determining whether software is incidental to the product as a whole Many of today's products contain embedded software. The customer, however, does not necessarily consider the software a significant enough attribute of the overall product for it to be evaluated in a purchasing decision. In determining whether software is incidental to the product as a whole, it is important that a distinction be made between (1) products for which software is a key influence in the customer's purchasing decision and (2) products for which the software, although necessary for the product to function, is not a significant factor in a purchasing decision. If the software component of the arrangement is not incidental to the products or services as a whole, or the software is essential to the functionality of non-software deliverables, revenue recognition for the entire arrangement is governed by the provisions of SOP 97-2. All components will be considered elements of the arrangement and should be accounted for subject to the guidance in SOP 97-2. www.pwcrevrec.com 1

For example, the embedded software in many products is there to provide functionality that customers desire (and may require). In most situations, the software is not marketed separately. Rather, the functionality that the software provides is being marketed as part of the overall product. For instance, an automobile manufacturer may advertise that its current model has a new automatic traction-control system to improve the handling of the vehicle. Although computer software is embedded in the car to provide this function, the manufacturer is not advertising the software. Instead, it is the new tractioncontrol system, grouped with many other features that may persuade the customer to purchase one particular model of an automobile over another. The software is improving the features and functionality of the car, but even with the improvements the car is still functioning as a car. In this situation and others similar to it, the software is considered incidental to the product as a whole and revenue recognition is not governed by SOP 97-2. SOP 97-2 applies to arrangements including software products and related services in which software is a primary attribute. Software is likely more than incidental when the vendor's principal marketing efforts provide the customer with extensive information about the software, including, for example, comparative performance specifications that the customer is likely to evaluate when making a purchasing decision. Generally, software embedded in consumer products will be deemed incidental to the product as a whole. However, we expect that the use of embedded software will continue to expand to more and more products and that the definition of incidental will become more blurred. The determination of whether software that is embedded in a product falls within the scope of SOP 97-2 needs to be periodically evaluated based on the facts and circumstances particular to each case. Footnote 2 to paragraph 2 of SOP 97-2 provides the guidance on evaluating whether software is incidental to the product as a whole. It specifies that the following should be determined: Whether the software is a significant focus of the marketing effort or is sold separately; Whether the vendor is providing postcontract customer support; and Whether the vendor incurs significant costs that are within the scope of FASB Statement No. 86 (FAS 86), Accounting for the Costs of Computer Software to Be Sold, Leased, or Otherwise Marketed. These factors are not all-inclusive, and other factors may be relevant based on the individual circumstances of each situation. In the case of the first criterion noted above, the description of a company's business and products in SEC or other public filings, on its website or in other publicly available documents should be considered in evaluating the focus of the marketing efforts. In the case of the second criterion noted above, many hardware vendors offer a maintenance program for hardware devices they sell. We believe that the guidance in SOP 97-2 is focused on whether the vendor offers maintenance specifically for the software, including rights to upgrades and enhancements of the software residing in the product, not on whether maintenance is offered for the device as a whole. Obviously, for maintenance to be specific to the software, any upgrades and enhancements of software provided pursuant to a software maintenance contract would need to be replaced or be inserted in the hardware device. In the example of the automobile manufacturer, the software in the automobile is used solely in connection with the operation of the automobile and is not sold or marketed separately. Once installed, the software would not be updated for new versions that are subsequently developed. While the automobile manufacturer's costs to develop the software will generally be within the scope of FAS 86, such costs are likely to be insignificant relative to the other product development costs of the automobile. 2 PricewaterhouseCoopers LLP

While the above automobile example is relatively simple, it does illustrate many of the basic considerations that go into determining whether software is incidental. For many products, particularly computer hardware with embedded software, significant judgment may be required, including an extensive evaluation of the vendor's marketing efforts (including Web site), in determining whether the embedded software is incidental. Questions and Answers Example of incidental software A Vendor sells a large ejection-molding machine to a Customer. The ejection-molding machine contains proprietary software that provides features and functionality that distinguish the molding machine from the molding machines sold by the Vendor's competitors. The Vendor does not separately market the software, nor does it provide upgrades and enhancements of the software under a maintenance contract. The Vendor does not provide potential customers with specification data for the software element that can be compared to the specifications of other vendors that provide software for the machine manufactured by the Vendor. The Vendor offers a one-year overall maintenance agreement with the purchase of the machine. Question: Is the software incidental to the molding machine? Answer: Yes, the software is incidental to the molding machine; therefore, SOP 97-2 does not apply. The Customer is buying the machine for the features and functionality of the machine as a whole and not for the software. While the Vendor does offer a maintenance agreement, it is for the entire machine and does not specifically focus on the software. Example of software that is not incidental Consider the fact set as described in the above question, however, assume that the Vendor (1) advertises the features and functionality of the software by comparing these with aspects of competitors' products and (2) agrees to provide unspecified upgrades, on a when-and-if-available basis, to the software for one year after the purchase. Question: Would the software still be incidental to the product? Answer: The marketing of the software and the commitment to provide unspecified upgrades for one year might indicate that the software is more than an incidental part of the machine. However, all the facts and circumstances would need to be evaluated to form a definitive conclusion. Factors to consider include the following: What are the ramifications for the contract if software upgrades are not provided? Does the Customer have the ability to renew its right to upgrades? Are the upgrades licensed separately? What is the Vendor's history and expectations of providing upgrades? How do the upgrades impact the Customer's purchasing decision? www.pwcrevrec.com 3

Example of incidental software The Vendor develops, manufactures, and sells a hardware product that includes application-specific integrated circuits and embedded software. The Vendor develops the software internally in conjunction with the development of the related hardware. While the Vendor offers maintenance contracts for the hardware product, these contracts do not include any upgrades or enhancements of the embedded software. The hardware product is marketed based on features such as speed and ease of use, but no mention is made of the software, nor is it licensed separately. Question: Is the software incidental to the Vendor's product? Answer: Yes, the software is incidental to the product, and SOP 97-2 does not apply. The Vendor does not provide upgrades or enhancements. It markets the machine based on features that may be provided by the software, but makes no mention of the software in its marketing materials or on its Web site. Therefore, the embedded software is not a significant consideration in the Customer's purchasing decision. Example of software that is not incidental Consider the fact set as described in the above question. However, assume that, with the hardware product, the Vendor also licensed software that allowed the product to be controlled with a personal computer and provided upgrades and enhancements to this software, as well as upgrades and enhancements of the embedded software, through its maintenance agreements. In addition, assume that the Vendor's marketing literature differentiated its product from that of its competitors based on the software and stated that the upgrades extended the useful life of the product. Question: Would the software still be incidental to the product? Answer: It is likely that the Vendor would conclude that the software is not incidental to the product. The software is a key part of the Vendor's marketing efforts and would be a factor that its customers consider when purchasing the product. Also, another factor influencing the Customer's purchasing decision would be that the upgrades and enhancements provided by the maintenance agreements extend the useful life of the product. Example of incidental software The Vendor has a product that includes embedded software licensed from third-party vendors. The capitalized cost of the software is a component of the product's cost of sales. The Vendor provides a ninety-day warranty for the product, but does not provide maintenance. No mention of the software is made in the Vendor's marketing efforts. Question: Is the software incidental to the Vendor's product? 4 PricewaterhouseCoopers LLP

Answer: Yes. Although the cost of the software is capitalized, the Vendor does not develop the software internally, market the product based on the software, or license the software separately. Further, the Vendor offers no maintenance services to its customers. Example of software that is not incidental Consider the fact set as described in the above question, however, assume that the Vendor had developed the software internally and (1) the related costs were capitalized and (2) upgrades and enhancements were provided to the product's end users through maintenance agreements. Question: Would the software still be incidental to the product? Answer: Capitalizing software and providing upgrades and enhancements may indicate that the software is more than incidental. Capitalizing the software without providing upgrades and enhancements, however, may not indicate that it is more than incidental. All of the facts and circumstances would need to be evaluated, including (1) the impact of the upgrades and enhancements on the Vendor's marketing efforts, (2) whether the upgrades are licensed separately, and (3) how the upgrades and enhancements impact the Customer's purchasing decision. 1.2 Determining when software becomes more than incidental All companies should reassess their revenue recognition policies, and establish procedures for assessing the potential effects that changes in circumstances might have on those policies. Changes in circumstances might arise from the evolution of a company's product and/or service offerings or from revised contractual provisions. Although this is true for all areas of accounting, reviews may be required more frequently for revenue recognition policies, due to the complexity of revenue arrangements and because different types of earnings processes require the application of different revenue recognition guidance. Companies operating in the technology industry are especially prone to change, since the industry is inherently subject to new and rapid developments. The SEC Staff commonly addresses the appropriateness of revenue recognition models when software is embedded in a company's product or when software is used to provide a service. The role of software in a product or service offering may evolve in a way that makes the software "more-than-incidental" to the product or service as a whole. If software that was previously deemed to be not "more than incidental" is now determined to be "morethan-incidental" to a company's product and service offering, the company needs to re-evaluate its related revenue recognition accounting policies. The re-evaluation is necessary because while SAB 104 is largely derived from principles in SOP 97-2, there are differences between the two accounting models. For example, the impact of extended payment terms and the allowable evidence of fair value, among others, can generate different accounting results when applying these two accounting models. Footnote 2 of SOP 97-2 provides indicators that companies should consider in determining whether software is incidental to a product. At the 2004 AICPA National Conference on Current SEC and PCAOB Developments, the SEC Staff emphasized that the items in the footnote are neither fully inclusive nor determinative, also noting that the listed indicators may be difficult to assess for products or services that are traditionally viewed as "non-software-centric." The SEC Staff said that companies might wish to consider the following questions when assessing the indicators in Footnote 2 of SOP 97-2: www.pwcrevrec.com 5

Is the software a significant focus of the marketing effort? When considering the marketing focus, companies should assess whether any changes in the features and functionalities of the product or service being promoted by the advertisements are the direct result of software. Is the software sold separately? Over time, it may turn out that the embedded software can be marketed separately from the overall product. If the company begins to license its software for use in other companies' products or services, such licensing might be considered a change in circumstances that warrants accounting for the embedded software as more-than-incidental. Does the vendor incur significant software-related costs that are within the scope of FAS 86? In addition to affecting revenue-recognition policies, changes in circumstances may affect the appropriateness of accounting for the related software costs. Companies that believe their products or services are non-software-centric may want to consider the following additional questions, the SEC Staff stated: Does the right to use the software remain solely with the vendor, or does it transfer to the customer as part of the product or service offering? A right to use the software that goes beyond the term of the service (or past the product's point of sale) is an indicator that the software is more-than-incidental. Does the licensed software require that the customer provide dedicated informationtechnology (IT) support? Providing maintenance of and troubleshooting services for the software is an indicator that the software may be more-than-incidental. When a company is addressing changes in circumstances or contractual arrangements, it is important that the company document its considerations and conclusions, and ensure that the language in its revenue recognition policy reflects these conclusions. 1.3 Determining whether the software is essential to the functionality of nonsoftware deliverables Paragraph 9 of 97-2 defines software deliverables as software products, upgrades/enhancements, PCS, or services. Non-software deliverables may include such things as hardware, peripherals, services unrelated to software deliverable, or other deliverables (box of oranges). Under EITF 03-5, Applicability of SOP 97-2 to Non-Software Deliverables in an Arrangement Containing More Than Incidental Software, non-software deliverables should be accounted for under the scope SOP 97-2 if the software is essential to the functionality of the non-software deliverable. If software is considered more than incidental to the arrangement, taken as a whole, and the software is considered essential to the functionality of the nonsoftware deliverables, then such non-software deliverables are in the scope of SOP 97-2. If the software is considered not essential to the non-software deliverables, those non-software deliverables should be separated from the software deliverables using EITF 00-21, and recognized separately using the appropriate revenue recognition guidance. For example, in an arrangement that includes software, computer hardware that will contain the software, and additional unrelated equipment, if the software is essential to the functionality of the hardware, the hardware would be considered software-related and, therefore, included within the scope of SOP 97-2. However, if the software is not essential to the functionality of the unrelated equipment, the equipment would not be considered software-related and would, therefore, be excluded from the scope of SOP 97-2. In assessing whether software is essential to the functionality of the non-software deliverables, the factors included in Paragraphs 68-71 of SOP 97-2 should be considered. These factors in Paragraphs 68-71 of SOP 97-2 were developed for considering whether professional services are essential to the functionality of software elements. As is related to the consideration of software being essential to the functionality of non-software deliverables, such factors might be considered as follows: 6 PricewaterhouseCoopers LLP

The vendor always provides the software with the non-software deliverable. If the vendor always includes the software as part of the arrangement and never offers the non-software deliverable without the software, this suggests that the software deliverable is essential to the functionality of the non-software. The timing of payments for the non-software deliverables coincides with the delivery of the software. Payments which include amounts pertaining to the delivery of the software often may suggest that the customer views the software deliverable essential to functionality of the arrangement. Acceptance criteria requiring delivery of software arrangements. Arrangements where customer acceptance of the entire arrangement occurs only upon successful delivery of the software would suggest that the software is essential to the functionality of the non-software deliverables. The customer views the software from the vendor as a key differentiating factor in selecting the vendor's non-software deliverable. If a customer believes that the vendor's software provides it with the only means to meeting its objectives, the software may be essential in the eyes of the customer. Is the software available from other vendors? Software available through other vendors that would function on the non-software deliverables may indicate that the customers buying decision did not depend on the vendor's ability to buy the software. Questions and Answers Example of software essential to functionality of non-software deliverable A Vendor sells hardware and related operating software. The hardware will not run without the software. Additionally, the Customer purchases a maintenance contract for the software and a maintenance contract for the hardware. Question: Is the software essential to the functionality of the non-software deliverables? Answer: Yes. Since the hardware does not function without the software, the software is considered essential to the functionality of the hardware. As a result the hardware and its related services (hardware maintenance) should be accounted for pursuant to SOP 97-2. Example of software not essential to non-software deliverables Consider the fact set as described in the above question. However, assume that the hardware works for its intended purpose without the software, and payment for the hardware is not contingent on delivery of the software. Question: Would the software still be considered essential to the functionality of the non-software deliverables? Answer: No. If the hardware functions as intended without the software deliverable, the software is not considered essential to the functionality of the hardware. Accordingly the non-software deliverables should be separated using EITF 00-21, and accounted for under the appropriate guidance. www.pwcrevrec.com 7

Example of product with embedded software A Vendor enters into a multiple deliverable arrangement that includes both software and other nonsoftware deliverables (e.g. sale of an MP3 player with embedded operating software). Question: What is the proper separation and allocation model when a multiple deliverable arrangement includes the sale of a product with embedded software? Answer: An evaluation of all elements sold with software, based on EITF 03-5, should be performed to determine if these elements are in the scope of SOP 97-2. EITF 00-21 should then be used to separate and allocate the total arrangement fee between SOP 97-2 and non-sop 97-2 elements. Further separation and allocation of the SOP 97-2 elements is accounted for pursuant to SOP 97-2 while EITF 00-21 is applied for the non-sop 97-2 elements. An assessment must be made as to whether the product is in the scope of SOP 97-2 using the guidance in paragraph 2 of SOP 97-2 based on whether the embedded software is more-than-incidental to the product as a whole. If the embedded software is more than incidental to the MP3 player then SOP 97-2 is applied, otherwise SAB 104 is applied. Example of product with embedded software and other deliverables Consider the fact set in the example above, however, the embedded software is more-than-incidental to the MP3 player and the sale includes a pair of headphones. Question: What is the proper separation and allocation model when a multiple deliverable arrangement includes sale of a product with embedded software, which is more-than-incidental, and non-software deliverables? Answer: The embedded software is more-than-incidental to the MP3 player and is within the scope of SOP 97-2. An assessment based on EITF 03-5 must then be made to determine whether the non-software element (i.e. the headphones) is within the scope of SOP 97-2 as well. EITF 03-5 indicates that if the non-software element has functionality without the software then it is excluded from the scope of SOP 97-2, and the EITF 00-21 model should be used to separate the non-software elements from the software elements and allocate the arrangement consideration between the two. While the headphones are frequently used with the MP3 player that contains more-than-incidental embedded software (i.e. a software-related element), the headphones could be used with other devices (i.e. computer, portable video system, etc.) and therefore their functionality is not dependant upon the software-related element to function. Therefore, the headphones are outside the scope of SOP 97-2 and the arrangement consideration would be allocated based on EITF 00-21. 1.4 Determining whether a contract requires significant production, modification, or customization of the software SOP 97-2 recognizes that there can be fundamental differences among software products and that these differences must be considered when the appropriate revenue recognition model is being determined. For example, the licensing of a $100 off-the-shelf personal finance program may not be accounted for in the same way as the licensing of a multi-million-dollar software solution with a two-year implementation period. 8 PricewaterhouseCoopers LLP

Deciding whether a software contract requires significant production, modification, or customization is one of the most difficult judgments that must be made when proper revenue recognition is being determined. The primary factor that should be considered revolves around whether the services discussed in the arrangement are essential to the customer's desired software functionality. For cases in which it is determined that significant production, modification, or customization is required by the arrangement, SOP 97-2 requires that the guidance in Accounting Research Bulletin No. 45 (ARB 45), Long-Term Construction-Type Contracts, or SOP 81-1 be applied. The application of SOP 81-1 is generally referred to as contract accounting. Chapter 9 discusses the factors associated with determining whether it is appropriate to use contract accounting. It also provides some examples of situations in which contract accounting should or should not be used. 1.5 Determining if a hosting arrangement is a service contract outside the scope of SOP 97-2 EITF 00-03, Application of AICPA Statement of Position 97-2 to Arrangements That Include the Right to Use Software Stored on Another Entity's Hardware, provides guidance in determining whether SOP 97-2 applies to a hosting arrangement. Specifically, SOP 97-2 only applies to a hosting arrangement if the customer has the contractual right to take possession of the software at any time during the hosting period without significant penalty and it is feasible for the customer to either run the software on its own hardware or contract with another party unrelated to the vendor to host the software. Hosting arrangements that do not give the customer such an option are service contracts and are outside the scope of SOP 97-2 (i.e., SAB 104 guidance applies). The application of SOP 97-2 and SAB 104 to hosting arrangements is discussed in Chapter 10. Questions and Answers Example of enabling software A Vendor sells handheld computer devices and software that together enable the user to access or send e-mails from a user's personal or work e-mail application. There are two software components that enable this functionality: a software application that is installed on the customer's handheld device and software that interfaces with the e-mail server and handheld device (which is owned and operated by Vendor). The Vendor asserts that it is merely providing a service and all the delivered software simply enables the user to access the Vendor's e-mail distribution service. The Vendor contends that the guidance in EITF 00-3 is applicable instead of SOP 97-2. Question: Is this view acceptable for revenue recognition? Answer: In instances where software is delivered to enable a service, paragraph 2 of SOP 97-2 applies and requires that the delivered software be evaluated to determine if the software is more than incidental to the service. In this situation, the delivered software is more than incidental to the service. Without the software which is installed on the customer's handheld device, the customer could not use the device. The Vendor would account for the transaction under the guidance of SOP 97-2. Only in instances where the software used in providing services is not delivered or made available to the customer, or the delivered software is incidental to the service, would EITF 00-3 and SAB 104 apply. Delivered software that is more than incidental to providing services is subject to SOP 97-2. www.pwcrevrec.com 9

1.6 Determining if an arrangement includes a lease Paragraph 1 of FAS 13 defines a lease as "...an agreement conveying the right to use property, plant, or equipment (land and/or depreciable assets) usually for a stated period of time." This paragraph further states that agreements that transfer this right continue to meet the definition of a lease even though the agreement may involve the performance of substantial services by the lessor in connection with the operation or maintenance of the leased assets. EITF 01-8, Determining Whether an Arrangement Contains a Lease, addresses whether arrangements other than those that explicitly convey the right to use specifically identified property, plant and equipment are a lease. EITF 01-8 creates a model to be applied at the inception of each arrangement to evaluate whether the substance of a transaction creates a right to use property, plant, and equipment and thus, is a lease. An arrangement includes a lease that is within the scope of FAS 13 if the arrangement includes the following: specific identified property, plant or equipment the right to control the use of the underlying property, plant and equipment the right to operate or direct others to operate the property, plan and equipment the purchaser receives substantially all of the output A lease may be included in a multiple element arrangement with software or software related elements (subject to SOP 97-2). Although FAS 13 does not provide guidance on "how" to allocate arrangement consideration between leased and non-leased deliverables (i.e hardware) that are in the same arrangement, it does require entities to separate leased and non-leased deliverables and specifies the accounting for leased deliverables. EITF 01-8 states that the allocation should be done consistent with the separation and allocation guidance in EITF 00-21. When an arrangement contains both lease elements (e.g. lease of property and equipment and the associated executory costs) and non-lease elements, the guidance under FAS 13 is applied to the lease elements by both the purchaser and the seller; however, it is not applied to any non-lease elements of the arrangement because such elements are outside the scope of FAS 13. EITF 01-8 concluded that "substantial services" as contemplated by paragraph 1 of FAS 13 are not considered executory costs and, therefore, should not be considered FAS 13 deliverables. The total consideration in the arrangement should be allocated between the lease deliverables and the non-lease deliverables on the basis of relative fair values in accordance with paragraph 4(a) of EITF 00-21. The amount of payments to be allocated to minimum lease payments would be the consideration remaining after allocating payments to the non-lease deliverables, on the basis indicated in the previous sentence, and the executory cost items, on the basis of their aggregate fair value. 1.7 Determining whether an arrangement is a contract for funded software development A contract for funded software development may be accounted for under FAS 68, Research and Development Agreements, or SOP 97-2, depending upon the software's stage of development and the scope and terms of the arrangement. A third party may provide funds to a software vendor to develop additional features or functionality to the vendor's existing products or technology. Accounting for the proceeds received from these arrangements requires analysis of the facts and circumstances of each case. Funded software development arrangements are discussed in Chapter 8. 10 PricewaterhouseCoopers LLP

1.8 Determining the applicable guidance The following flowchart can be used as a guide to determine the applicable guidance for an arrangement. www.pwcrevrec.com 11

Chapter 2: Basic Principles of Software Revenue Recognition 2.0 Overview Paragraph 8 of SOP 97-2 defines the basic revenue recognition criteria as follows: Persuasive evidence of an arrangement exists. Delivery has occurred. The vendor's fee is fixed or determinable. Collectibility is probable. These criteria are also the same as those contained in SAB 104 - the major difference being that SAB 104 requires that collectibility be "reasonably assured." This is generally considered to be a higher standard than that contained within SOP 97-2 and is discussed in more detail below. Interwoven throughout SOP 97-2 is the concept of "customary business practice." Software vendors often have relationships with their customers that involve more than simply licensing a product. The success of a vendor's business is often affected by long-term customer relationships that last years. Often, a software vendor must ensure that its customers are satisfied in order to rely on them as "reference accounts" when making sales to future customers. Software vendors, particularly those licensing large and expensive systems, may have difficulty marketing their products if they have many dissatisfied customers. The complexity associated with the variety of platforms, hardware, and operating systems sometimes makes it difficult for a software vendor to meet all of a customer's expectations. Consequently, vendors frequently feel pressured to make concessions to a customer that are outside the original contract terms. It is this tendency to make concessions to ensure customer satisfaction that ultimately led to the specific mention in SOP 97-2 of the concept of "customary business practices." SOP 97-2 requires an analysis of a vendor's practices and their related impact on revenue recognition. This chapter provides guidance regarding common issues that arise in the interpretation of the four basic revenue recognition criteria, together with the impact that SAB 104 has had on the interpretation of these basic concepts. The impact of the concept of business practices is discussed in the individual sections of this chapter and in Chapter 6, where applicable. This chapter is organized as follows: 2.1 Persuasive evidence of an arrangement exists 2.1.1 Use of written contracts 2.1.2 Use of master agreements 2.1.3 Varying practices for different customers 2.1.4 Form of license: perpetual versus term 2.2 The software has been delivered 2.2.1 Specific terms for delivery 2.2.2 Electronic delivery 2.2.3 Software duplication 2.2.4 Delivery location 2.2.5 Intermediate delivery site 2.3 Fixed or determinable fees and collectibility 2.3.1 Extended payment terms 2.3.2 Third-party financing arrangements 12 PricewaterhouseCoopers LLP

2.3.3 Cancellation privileges 2.3.4 Fiscal-funding clauses 2.3.5 Forfeiture or refund clauses 2.3.6 Customer-acceptance clauses 2.1 Persuasive evidence of an arrangement exists SOP 97-2 recognizes that practice varies, particularly in the software industry, regarding the use of written contracts. Evidence of an arrangement should be consistent with the vendor's customary business practices. SOP 97-2 states that if the vendor customarily obtains a written contract, a contract signed by both parties is the only acceptable evidence that an agreement exists. If the vendor does not customarily obtain a signed contract, the vendor must have other forms of evidence documenting that an arrangement exists. Such forms of evidence may include a purchase order, online authorization, electronic communication or credit card authorization. Given the diverse means by which evidence of an arrangement may be documented, vendors should have formal written policies defining what constitutes an arrangement in their particular business. These policies should be applied consistently in determining the point at which the criterion for persuasive evidence of an arrangement has been met. The evidence of an arrangement at the time of revenue recognition must be the final form of the arrangement (i.e., no drafts, letters of intent, etc., would qualify). If the final document is a contract, it must be signed by the appropriate authorized individuals of both parties. Observation: The customary business practice notion does not need to be applied on an enterprise-wide basis. A company may have different practices for what constitutes evidence of an arrangement differentiated by type of customer, geography, size, product, etc. A vendor and customer will sometimes enter into "side" agreements to a master contract that amend the master contract. Side agreements (also referred to as side letters), are either verbal or written changes to the original master contract. Vendors should ensure that appropriate policies, procedures, and internal controls exist and are properly documented and operating so as to provide reasonable assurances that sales transactions, including those affected by side agreements are properly accounted for in accordance with GAAP. Public entities should also ensure compliance with Section 13 of the Securities Exchange Act of 1934 (i.e., the Foreign Corrupt Practices Act). Side agreements may include agreements to extend the original payment terms, provide products or services incremental to the original contract, including return rights, or other provisions that could affect revenue recognition. The existence of a subsequently executed side agreement may be an indicator that the original agreement was not final and revenue recognition may not have been appropriate. 2.1.1 Use of written contracts Practice varies with respect to the use of written contracts. Enterprise-wide software companies typically have extensive contracts, while consumer software companies often do not. Many times, the type of documentation obtained will depend just as much on the customer's established business practice as on the vendor's stated policies. The overriding consideration in the evaluation of the need for a signed, written contract is whether there will ever be a completed, signed arrangement. If a signed arrangement has been entered into subsequent to the date of revenue recognition, the criterion for persuasive evidence of an agreement had not been satisfied at the date revenue was recorded, and revenue was improperly recognized. Written contracts must be signed by both parties prior to revenue recognition. The signatures must be obtained no later than the balance sheet date in order to include the transaction in a given period's revenue. Contracts that are signed after the balance sheet date and back-dated to as of or effective as of the balance sheet date do not satisfy the revenue recognition criterion for the earlier period. From a legal perspective an www.pwcrevrec.com 13

obligation may exist at the as of date; however, SOP 97-2 looks for the date that the contract has been signed and completed as the point at which the requirement to have an evidence of an arrangement is fulfilled. Contracts should also be contemporaneously dated by each signatory as evidence of the date at which the parties have finalized the meeting of the minds. Contracts that lack a signature date may not be adequate evidence of an arrangement at a balance sheet date. When written contracts are the customary business practice, they must be signed by both parties because without the customer's signature, the contract does not represent an enforceable claim against the customer. If the vendor has not signed the contract, the contract represents only an offer to license the software and may subsequently be rejected or renegotiated by the vendor. 2.1.2 Use of master agreements In certain circumstances, a vendor may enter into a master agreement with a customer. The master agreement will define all of the basic terms and conditions for transactions between the parties and will be signed by both parties. To obtain the products under the master agreement, the customer may need to issue a second communication in the form of a purchase order or send an electronic request that will specify the software products, quantities, and requested delivery date. In these cases, the master agreement and the additional communication would constitute the total arrangement. The vendor would need to determine what the customary business practice is for the second communication in order to establish whether a valid arrangement has been entered into. Assuming that the second communication will evidence the arrangement and no subsequent documentation will be prepared, the criterion for evidence of an arrangement will have been met when the second communication is received. 2.1.3 Varying practices for different customers A vendor's customary business practice for documenting contracts may vary depending on the type of customer group involved. A business practice may result from a customer's ordering methods, as evidenced by signed contracts, purchase orders, electronic communications, or, in the case of consumer products, sales receipts. A business practice may also be based on geography or customer size and purchasing volume. Under SOP 97-2, it is important that the vendor document each method that is used to indicate what constitutes evidence of an arrangement for each of the customer groups. This will serve to validate the customary business practice for each group and will help the vendor to consistently apply the persuasive evidence of an arrangement criterion of SOP 97-2. If a vendor's customary business practice varies from customer to customer, the vendor will invariably be faced with customers who do not fall within an existing, established group. This might occur when a vendor opens a new market or launches a new product. Each new customer needs to be evaluated based on the facts and circumstances surrounding it. A documented approach to revenue recognition for each of these customers should be developed and monitored on an ongoing basis to ensure that actual results support the approach on a going-forward basis. For a new customer, the initial determination may be more supportable if a vendor can show that it has a history of not changing its business practice with a customer once a revenue recognition method has been established. TPA 5100.39 addressed the issue of vendors executing more than one contract or agreement with a single customer and whether or not such agreements should be considered as one multiple-element arrangement. In the event that two or more contracts or agreements can be linked as one multipleelement transaction, then the criteria to have a completed evidence of arrangement would not be met until all contracts or agreements have been signed by both parties. See additional discussion on this matter in section 3.1. 14 PricewaterhouseCoopers LLP

2.1.4 Form of license: perpetual versus term The term of a license is an important factor of an arrangement as it defines the period of time in which the licensee has a right to use the licensed software. The two types of license terms are commonly referred to as perpetual and term or time-based licenses. Perpetual licenses allow the licensee to use the software in perpetuity. Term licenses allow the licensee only to use the software for a specified period of time. Perpetual licenses are the most common, yet many enterprise software vendors also offer term licenses in order to accommodate their customers needs, including the period of time the customer intends to use the software and the pricing available to the customers. Term licenses are often negotiated at a lower price than perpetual licenses as the licensee is only receiving the right to use the software for a set period of time versus in perpetuity. See Chapter 3 for a discussion of PCS considerations particular to term licenses. As discussed later in this chapter, in no circumstances should revenue be recognized prior to the commencement of the initial license period (whether a perpetual or term license). This is consistent with TPA 5100.70 and SAB 104. Questions and Answers Vendor practice is to obtain written contracts The Vendor's third quarter ends on October 31. The Vendor customarily obtains signed contracts from its customers for each software order. The Customer calls on October 29 to say that it has just obtained 100 new computers and would like to order 100 copies of a software product from the Vendor. As a result of the proximity of the order to quarter's end, a signed licensing contract is not entered into until after the end of the quarter, even though the Vendor ships the software to the Customer on October 30. In lieu of a signed contract, the Vendor obtains a noncancelable letter of understanding from the Customer, which includes the significant terms and conditions of the licensing arrangement and states that the parties agree to finalize a mutually acceptable licensing contract within a certain period of time after the delivery of the software. Question: Does persuasive evidence of an arrangement exist on October 31? Answer: Paragraph 8 of SOP 97-2 notes that revenue should not be recognized until persuasive evidence of an arrangement exists. If the Vendor intends to obtain a signed license contract or has a business practice of obtaining a signed contract, the only acceptable evidence of an arrangement is a contract signed by both the Customer and the Vendor. Distinguishing between terms that are significant and those that are insignificant is not appropriate in an assessment of whether the criterion has been satisfied; therefore, the criterion has not been met as of October 31, and revenue recognition is not appropriate. Purchase order references terms of a previous contract Consider the fact set as presented in the example above, however, assume the Vendor had previously dealt with the Customer and the Customer issued the Vendor a purchase order prior to October 31, which referenced the terms and conditions of a previous contract. Question: Does persuasive evidence of an arrangement exist on October 31? www.pwcrevrec.com 15

Answer: We believe that even if all of the terms and conditions are stated in the purchase order, if the Vendor intends to subsequently obtain a signed contract or has a business practice of obtaining a signed contract, revenue should not be recognized until the signed contract is entered into. This is due to the uncertainty of whether the terms and conditions will remain unchanged when the actual contract is signed. Paragraph 16 of SOP 97-2 states that if a vendor requires a written contract, evidence of an arrangement is provided only by a contract signed by both parties. See related discussion in section 2.1.2 on the use of master agreements. Vendor practice is not to obtain written contracts The Vendor normally accepts orders transmitted electronically (for example, via electronic mail), and such orders are generally not signed. These orders often involve only a credit card number for billing purposes. Question: Is receipt of the credit card number sufficient evidence of the arrangement? Answer: If the Vendor's practice is to ship its product after receiving an online authorization from the Customer, this would then constitute acceptable evidence of an arrangement. Master agreement Vendor practice is to obtain a purchase order The Vendor and the Customer have entered into a master agreement pertaining to Product X. The maximum number of units covered by the agreement, the price per unit, and the shipping terms are all included in the master agreement, and it is signed by individuals with the appropriate level of authority. The Vendor's customary business practice is to receive a purchase order from the Customer to authorize the shipment of Product X. No additional documentation is provided. Question: Is receipt of the purchase order adequate evidence of an arrangement? Answer: Assuming that all other criteria for revenue recognition are met, receipt of a purchase order, in conjunction with the master agreement, is adequate documentation of the arrangement. Master agreement Vendor receives oral authorization Assume the fact set as presented above, however, on June 30, the last day of the quarter, the Customer calls the Vendor and authorizes the shipment of Product X. The purchase order is received on July 1. Question: Is revenue recognition on June 30 appropriate? Answer: Revenue recognition on June 30 would be inappropriate, as the Vendor's customary business practice is to obtain a purchase order, and therefore, persuasive evidence of the arrangement does not exist on June 30. 16 PricewaterhouseCoopers LLP

Master agreement purchase order exceeds authorized limits Assume the fact set as presented above, however, assume that on June 30 the Vendor receives a purchase order for Product X that exceeds the number of units covered by the master agreement. Question: Is revenue recognition appropriate on June 30? Answer: It is not likely that revenue recognition on June 30 would be appropriate for the units that exceed the authorized amount in the master agreement. If the Vendor and the Customer intend to enter into a new master agreement for future transactions and such an arrangement has yet to be finalized, revenue recognition for the portion of the shipment that exceeds the volume specified in the existing master agreement would not be appropriate. Different contract requirements for different types of customers The Vendor has historically licensed its products to original equipment manufacturers (OEMs) but will be expanding its market to include end users. For its OEM customers, the Vendor always obtains a signed contract. However, the Vendor does not expect that signed contracts will be obtained from end users. Instead, it expects to receive purchase orders via electronic communications for end-user sales. Question: Has the persuasive evidence of an arrangement criterion been met with regard to end users based on the electronic-communication purchase order, even though the Vendor's prior customary business practice was to always require signed contracts? Answer: Due to the new customer channel, a shift appears to have occurred in the business that will require the Vendor to establish business practices for this new customer base. The determination of whether the electronic communication is sufficient should be based on an analysis of the facts and circumstances, including subsequent activities with the new customer base. However, the Vendor's reliance on different methods to evidence an arrangement is acceptable under SOP 97-2 for situations in which operating practices support the differences. Customer requires special documentation of the arrangement The Vendor has a customary business practice of accepting purchase orders and shipping software without obtaining a signed contract. The Vendor obtains a new customer that requires a signed contract as evidence of an arrangement. The Vendor receives a purchase order from the Customer on June 30. Question: Assuming that all of the other criteria for revenue recognition have been met, has the persuasive evidence of an arrangement criterion been met upon the receipt of the purchase order on June 30? Answer: We believe that even if all of the terms and conditions are stated in the purchase order, if the Customer requires a signed contract, revenue should not be recognized until the signed contract is finalized. As such, revenue should be deferred as of June 30 and not recognized until the contract is signed and www.pwcrevrec.com 17

received by the Vendor. In this case, the Vendor has to establish a different business practice for the Customer than it uses for its other customers, because the Customer has a requirement for a signed contract that overrides the Vendor's customary business practice. 2.2 The software has been delivered Delivery under a software arrangement is a primary criterion for revenue recognition. However, what constitutes delivery may vary significantly based on the nature of the software vendor's products, its customary business practices, other elements of the arrangement, and additional factors. For example, the nature of some software products or a vendor's business practice may require that the software reside on a physical medium (i.e., be embedded in a PC board, on a floppy disk, in a CD ROM format, or via a similar media). Other products or business practices may require electronic transmission. Conversely, some software products may not meet all of the functional requirements of the customer until one or more additional elements is/are delivered. The complexity of interpreting what constitutes delivery truly demonstrates the uniqueness of the software industry. In most industries, the delivery requirement is fairly straightforward. For example, retail stores know definitively when a customer takes possession of goods and those goods have been delivered. Car dealers know that when a customer drives a car off the lot after signing a contract, the delivery has been completed. However, software vendors must look to the requirements of the arrangement and determine at what point those requirements have been met in order to conclude whether the delivery has been completed. In the glossary of SOP 97-2, delivery is defined as follows: A transfer of software accompanied by documentation to the customer. The transfer may be by the following: 1. A physical transfer of tape, disk, integrated circuit, or other medium; 2. Electronic transmission; 3. Making available to the customer software that will not be physically transferred, such as through the facilities of a computer service bureau; or 4. Authorization for duplication of existing copies in the customer's possession. If a licensing agreement provides a customer with the right to multiple copies of a software product in exchange for a fixed fee, delivery means transfer of the product master, or the first copy, if the product master is not to be transferred, assuming customer has the ability to make copies or that the cost of producing copies by the vendor are insignificant. Additionally, paragraph 18 of SOP 97-2 specifically addresses electronic delivery: For software that is delivered electronically, the delivery criterion of paragraph 8 is considered to have been met when the customer either (a) takes possession of the software via a download (that is, when the customer takes possession of the electronic data on its hardware), or (b) has been provided with access codes that allow the customer to take immediate possession of the software on its hardware pursuant to an agreement or purchase order for the software. In such cases, revenue should be recognized if the other criteria of paragraph 8 have been satisfied. A product or an element of an arrangement is considered to have not been delivered if there has not been a delivery of products or elements that are essential to the functionality of the delivered element(s). Accordingly one may conclude that absent the essential element which has not been delivered, the customer lacks the full utility of the delivered element(s). The license revenue allocated to a product or an element of a software arrangement that has been delivered but that will not meet the customer's functionality requirements until one or more additional product(s) or element(s) are delivered should not 18 PricewaterhouseCoopers LLP

be recognized until all of the elements that provide the customer with full use of the delivered elements has occurred. See Chapter 3 for a discussion of delivery issues related to arrangements involving undelivered elements. A related delivery consideration includes when the term of a software license actually begins. TPA 5100.70 concluded that even if all other revenue recognition criteria have been met, in no circumstances should revenue be recognized prior to the commencement of the initial license term. In situations where a customer extends/renews a pre-existing, currently active software license for the same product(s), TPA 5100.71 concluded that the arrangement fee allocated to the extension/renewal should be recognized when all other revenue recognition criteria are met (not at the commencement of the extension/ renewal period). This is because the customer already has possession of and the right to use the software to which the extension/renewal applies. TPA 5100.71 also stated that if the customer's pre-existing license for the product(s) had lapsed (i.e., not currently active), an extension/renewal should be accounted for as a new separate arrangement subject to all revenue recognition criteria, including that the term of the new license must start prior to any additional revenue being recognized. TPA 5100.73 discusses a situation where the provisions of a term license allow the customer to extend the license term indefinitely for an additional fee. Based on the facts outlined in the TPA, the conclusion was that the option to extend the term indefinitely is not considered an additional element as contemplated in paragraph 10 of SOP 97-2, as there is no additional deliverable. The accounting for the additional fee to extend the term of the license is the same as that previously discussed for an extension/renewal. If additional software media (as a result of a self-destruct or similar mechanism) was required to be delivered upon the exercise of the option, this would not create an element or deliverable to be accounted for in the original arrangement; however, such media would need to be delivered before the option exercise fee could be recognized as revenue. 2.2.1 Specific terms for delivery Delivery terms are relevant for transactions in which software is transferred physically, because the physical delivery of a product requires that either the vendor or the customer be responsible for the product while it is in transit. Contract terms generally specify which party retains risk of loss and when the legal title passes to the customer. As most software arrangements involve licenses that do not pass the title to the customer, revenue may be recognized absent the vendor's signing legal title over to the customer. The contract terms determine whether the transfer of the risk and rewards of ownership occurs (1) when the product is shipped by the vendor or (2) when it is received at the customer's site. SOP 97-2 does not specifically address delivery terms and their impact on software revenue recognition. However, TPA 5100.69 addresses the situation where an arrangement that requires physical delivery of software includes delivery terms that indicate when the customer assumes the risks and rewards of its licensing rights. Revenue cannot be recognized before the risks and rewards of ownership have passed to the customer. Therefore, when software is physically transferred, the arrangement's terms will determine when there has been an actual delivery, assuming that there is no uncertainty as to customer acceptance. For products shipped F.O.B. Shipping Point, the product is deemed delivered when it leaves the vendor's premises. For products shipped F.O.B. Destination, the product is deemed delivered when it is received by the customer. TPA 5100.69 also requires consideration of the requirements of SAB 104 as it relates to when delivery is considered to have occurred. 2.2.2 Electronic delivery Assuming that all other criteria are met, revenue recognition is appropriate under arrangements for which the product will be delivered electronically at the point at which the customer has possession of or full access to the software (whichever comes earlier). Arrangements involving electronic delivery of software often include the use of permanent or temporary keys or authorization codes. www.pwcrevrec.com 19

Authorization codes, also referred to as access codes or keys, are often used by software vendors to prevent unauthorized access to software and to allow customers access to otherwise restricted software. Permanent keys are used to allow access to software when the customer licenses the software or to allow for the duplication of the software. On the other hand, temporary keys can be used to control access for a distinct period of time and may be used to enhance the vendor's ability to collect payments. Although keys provide the customer with access to the software, delivery of a permanent or additional key is not necessarily required in order for the vendor to recognize revenue. In addition to the other requirements of SOP 97-2, paragraph 25 outlines the requirements for revenue recognition for arrangements involving the delivery of keys or authorization codes and states that the following conditions must be met: The customer has licensed the software, and the vendor has delivered a version of the software that is fully functional except for the permanent key or the additional keys (if additional keys are used to control the reproduction of the software). The customer's obligation to pay for the software and the terms of payment, including the timing of payment, are not contingent on delivery of the permanent key or additional keys (if additional keys are used to control the reproduction of the software). The vendor will enforce and does not have a history of failing to enforce its right to collect payment under the terms of the original arrangement. Sometimes vendors deliver temporary keys that can be turned off by the vendor or automatically expire if the customer does not pay the vendor. If a temporary key is used by the vendor to provide leverage to ensure collection of the fee, an evaluation must be made of the business purpose and intent of the vendor with regard to the use of a temporary key. The vendor should have a customary business practice of using temporary keys for this purpose as selective issuance of temporary keys might indicate software is being used only for demonstration purposes. The risk is that the fee is not fixed or determinable at the date of the delivery (i.e., the software has simply been delivered for evaluation by the customer). In these cases, revenue recognition would be precluded. If the vendor has a customary business practice of using temporary keys, delivery of the permanent key is not required for recognition of the license fee, as long as the criteria in paragraph 25 of SOP 97-2 (above) are met. 2.2.3 Software duplication In arrangements in which duplication of the software is involved, duplication must be incidental for the delivery criteria to be met upon the delivery of the first copy or the master to the customer. The determination as to whether duplication is incidental may depend on whether the arrangement with the customer involves multiple copies or multiple licenses. Although SOP 97-2 does not specifically define these terms, paragraph 21 provides some parameters for analysis. The following is a summary of the parameters outlined in paragraph 21 of SOP 97-2 : Multiple-Copy Arrangements. These generally occur when the customer has the right to (1) use multiple copies of a software product under a site license with an end user or (2) sell multiple copies of a product with a reseller for a fixed fee. Duplication is incidental under these arrangements, because the fee is fixed or determinable whether or not the customer receives, reproduces, or requests the additional copies. Revenue under these arrangements should be recognized upon the delivery of the product master (if it is to be delivered) or the first copy, assuming that all other revenue recognition criteria are met. If duplication is incidental to delivery, the estimated costs of duplicating the software should be accrued when the revenue is recognized. 20 PricewaterhouseCoopers LLP

Multiple-License Arrangements. These generally occur when the licensing fee is a function of the number of copies delivered to, made by, or deployed by the user or reseller. The fees from this type of licensing arrangement are not fixed or determinable. Duplication is not considered incidental under these arrangements and, therefore, revenue should be recognized as the copies are made by the user or sold by the reseller, if the other criteria in SOP 97-2 for revenue recognition are met. Some software arrangements may allow a user to change or alternate its use of multiple products/licenses (license mix) included in a license arrangement after the software vendor has delivered all of those products. Typically under such arrangements the user has the right to deploy and utilize at least one copy of each licensed product use may be limited to either the number of users who can simultaneously use the products or the cumulative value of the products in use at a given time. In such a case, as long as the other criteria for revenue recognition have been met, revenue should be recognized upon the delivery of the first copy or product master for all the products included in the license mix. Subsequent remixing by the customer is not considered to be an exchange or a return of software because the master or first copy of all products have been licensed and delivered and the customer has the right to use them all. (TPA 5100.45) In arrangements that involve duplication, the essence of the business transaction should be evaluated in conjunction with the legal requirements of the arrangement. For example, if an arrangement contains provisions that make the fee appear as though it is fixed, yet the payments are tied to expected deployment, it is likely that duplication is not incidental to the arrangement, as required by SOP 97-2. In such a situation, revenue should be recognized as the licenses are duplicated, similar to how revenue is recognized in a multiple-license arrangement such as that described above. (See Chapter 3 for discussion of arrangements that involve the duplication of multiple products.) 2.2.4 Delivery location The matter of delivering a product to a location other than the customer's location requires vendors to look beyond the legal requirements of the arrangement and examine the underlying economics of a business transaction. Paragraph 22 of SOP 97-2 specifically addresses software revenue recognition for arrangements that involve delivery to a location other than that of the customer. Paragraph 22 states the following: Delivery should not be considered complete unless the destination to which the software is shipped is the customer's place of business or another site specified by the customer. In addition, if a customer specifies an intermediate site but a substantial portion of the fee is not payable until the delivery by the vendor to another site specified by the customer, revenue should not be recognized until the delivery is made to that other site. The concern is whether the vendor has truly met the customer's requirements by delivering the product to the intermediate site. In these cases, an evaluation should be done of the business reason behind the shipment terms, particularly in relation to such shipments occurring near quarter- or year-end. The connection between a substantial portion of the fee and delivering a product to a second location may indicate that there was not a valid business reason for shipping the product to the initial delivery point and that the customer's requirements were not met at the date of the initial shipment. SOP 97-2 does not provide guidance on what constitutes substantial, as that word is used in paragraph 22 of SOP 97-2. Vendors should analyze payment terms in relation to standard business practices (as well as the guidance provided above), to determine the effect on revenue recognition. (See the discussion in section 2.3.1 on extended payment terms.) www.pwcrevrec.com 21

Shipment to a location other than that of the customer is common in two situations: (1) when there is a shipment to a delivery agent, which SOP 97-2 specifically addresses; and (2) a shipment to an intermediate delivery site. Software vendors sometimes use fulfillment houses (delivery agents) to duplicate and/ or deliver software products to end-user customers. Paragraph 23 of SOP 97-2 addresses the revenue recognition requirements for shipments to delivery agents. This guidance is consistent with other delivery concepts. The overriding principle is that revenue should not be recognized until the ultimate customer has full access to, or use of, the software, except in reseller situations. Paragraph 23 states the following: Revenue from transactions involving delivery agents should be recognized when the software is delivered to the customer. Transferring the fulfillment obligation to an agent of the vendor does not relieve the vendor of the responsibility for delivery. This is the case even if the vendor has no direct involvement in the actual delivery of the software product to the customer. For example, a software vendor may engage a fulfillment house to duplicate its products by using product masters and to deliver the products to customers. The fulfillment house will assume the risk of physical loss. The vendor directs customers to send orders directly to the fulfillment house. The vendor gives the fulfillment house the right to act on its behalf to fill those customer orders that meet the vendor's licensing standards. In this case, the software vendor retains title to the products and the ultimate obligation to satisfy the customer's order. The delivery agent is not a reseller and revenue is not recognizable until the vendor has evidence of a delivery having been made to the end user. 2.2.5 Intermediate delivery site As noted in section 2.2, SOP 97-2 states: Delivery should not be considered complete unless the destination to which the software is shipped is the customer's place of business or another site specified by the customer. Arrangements in which the vendor is able to bill for the software before it is delivered to the customer's ultimate destination are, in essence, bill and hold (or ship and store ) arrangements. The criteria under which the vendor may sometimes be permitted to recognize revenue under a bill and hold arrangement were codified by the SEC in SAB 104 based on several SEC Enforcement Releases. These criteria are as follows: The risk of ownership must have passed to the buyer. The customer must have made a fixed commitment to purchase the goods, preferably reflected in written documentation. The buyer, not the seller, requested that the transaction be on a bill and hold basis. The buyer also must have a substantial business purpose for ordering the goods on a bill and hold basis. There must be a fixed schedule for delivery of goods. The date for delivery must be reasonable, and must be consistent with the buyer's business purpose (e.g., storage periods are customary in the industry). The seller must not have retained any specific performance obligations such that the earnings process is not complete. The ordered goods must have been segregated from the seller's inventory and not available to fill other orders. The equipment [product] must be complete and ready for shipment. 22 PricewaterhouseCoopers LLP

Many of these criteria are similar to the provisions of SOP 97-2. However, SAB 104 should be considered in addition to SOP 97-2 when such arrangements exist. When such arrangements for revenue recognition are being evaluated, several additional factors should be considered in applying the SAB 104 criteria. These are as follows: The date the seller expects payment, and whether the seller has modified its normal billing and credit terms for this buyer. The seller's past experiences with and pattern of bill and hold transactions. Whether the buyer assumes the risk of loss in the event of a decline in the market value of the goods. Whether the seller's custodial risks are insurable and insured. Whether there is a need for discounting a related receivable (consider whether Accounting Principles Board Opinion No. 21 (APB 21), Interest on Receivables and Payables, is applicable). Whether further investigation is necessary in order to ensure that there are no exceptions to the buyer's commitment to accept and pay for the goods sold (i.e., that the business reasons for the bill and hold arrangement have not introduced a contingency to the buyer's commitment). The SEC has indicated that rarely would a customer or vendor be able to establish a valid business reason for requesting a bill and hold sale of software, because software generally occupies little space and, therefore, storage is rarely a significant issue. Questions and Answers F.O.B. Destination The Vendor ships the product to its customer F.O.B. Destination, but a common carrier assumes the risk of loss while the goods are in transit. Question: Can the Vendor recognize the revenue at the time of the shipment? Answer: Because title of the product does not transfer before the delivery of the product to the designated destination, revenue should not be recognized until delivery has occurred. Although the carrier is assuming the risk of loss, it is essentially acting as agent for the Vendor whose property the product remains until title has transferred. F.O.B. Destination records The Vendor does not maintain records of actual delivery dates for product shipped F.O.B. Destination due to the costs involved in compiling the data. Question: Can estimates of transit time be applied to the shipping dates to determine the amount of revenue to record? Answer: If reliable estimates of transit times can be determined for each group of shipment of similar products to similar destinations, the use of such estimates would be acceptable. Periodic verification will be needed to determine that the estimates being used are still reliable. www.pwcrevrec.com 23

Electronic delivery The Vendor enters into an arrangement with the Customer for Product C on June 29. The Vendor e-mails the Customer a fully functional version of Product C on June 29. The Customer does not open the e-mail to receive Product C until July 1. Question: Has the delivery criterion been met on June 29? Answer: The delivery criterion has been met on June 29. The Customer has full access to the software on June 29. Assuming that all other revenue recognition criteria have been met, revenue recognition would be appropriate at the point that the Customer has full access. The fact that the Customer did not utilize such access does not impact the timing of revenue recognition. Authorization keys The Vendor makes a sales call to the Customer. At the end of the sales call, the Customer and the Vendor reach an agreement on the licensing of Product E. The Vendor agrees to leave one fully functional copy of Product E with the Customer. On March 31, the Customer sends the Vendor a purchase order for 5,000 copies of Product E (which is the Vendor's customary documentation requirement). The Vendor e-mails the key to the Customer on April 2, which allows the Customer to make the 5,000 copies of Product E. Question: Has the delivery criterion under SOP 97-2 been met on March 31? Answer: Because the Customer already has a fully functional version of Product E on March 31, the software has already been delivered. Assuming that all the other requirements in paragraph 25 are met, the delivery criterion under SOP 97-2 has been met on March 31 inasmuch as duplication of the delivered software is considered incidental to the arrangement (see section 2.2.2). Electronic and Physical Delivery The Vendor licenses its software product to the Customer as evidenced by a license agreement signed by both parties. The license agreement states that the Vendor will deliver the software electronically (via download from the Vendor's site) and physically (by delivering a CD containing identical software). The Customer routinely uses electronically downloaded software in its operations, and maintains a physical copy of some software products for backup. On December 31, the Vendor places the software on a website where it is available for download by the Customer. The Vendor ships a CD containing the software on January 2, and it is delivered three days later. Question: Has the delivery criteria been met on December 31? Answer: Delivery occurred on December 31, when the electronic copy was available for download. Where the customer's expected use of the licensed software is not significantly affected by the form of delivery 24 PricewaterhouseCoopers LLP

(electronic or physical), the delivery criterion should be evaluated based on the first delivery which occurred, whether physical or electronic. As none of the Vendor's fee is contingent upon delivery of the CD, it is viewed as an additional copy of the software and not a separate element, based on the application of paragraph 21 of SOP 97-2. When revenue is recognized, the Vendor should accrue cost of sales for the undelivered physical copy. Duplication is incidental The Vendor enters into an agreement with the Customer whereby the Customer pays a nonrefundable fee of $100,000 for 1,000 copies of Product D. On June 30, the Vendor delivers to the Customer a fully functional version of Product D on a CD. Pursuant to the terms of the arrangement, the Customer may request that the Vendor duplicate Product D for branch offices. Question: Is it appropriate for the Vendor to recognize the $100,000 fee on June 30? Answer: It is likely that duplication in this arrangement would be incidental and involve little effort by the Vendor. The fee is nonrefundable, even if additional duplication is not requested by the Customer. The Vendor should recognize the $100,000 fee on June 30 and accrue the estimated costs of duplication. Duplication is not incidental The Vendor enters into an agreement with the Customer. Pursuant to the terms of the arrangement, the Customer purchases 5,000 seats of Product H for a total fixed fee of $500,000 on September 28. The payments due are $100,000 per month, to be paid over the next five months. (For purposes of this example, assume that these terms are not indicative of extended payment terms. ) In negotiations leading to these terms, the Customer indicated to the Vendor that the five-month period is approximately how long their deployment of Product H should take. Question: Assuming that all other revenue recognition criteria have been met, has the delivery criterion of SOP 97-2 been met on September 28? Answer: The answer would be based on the facts and circumstances particular to a given case. The linking of the payment terms to the expected deployment of the software would likely result in the conclusion that duplication is not incidental and that the Customer does not view those fees as payable until the duplication process has occurred. This might be overcome if the Vendor were to supply persuasive evidence of an ability to collect this type of payment structure under the original terms of the agreement, regardless of the Customer's deployment of copies. Delivery intermediate locations The Vendor licenses a software product that is embedded in a proprietary chip that resides on a PC board and is shipped to customers. On September 26, the Vendor receives a large order from the Reseller. In the purchase order, the Reseller requests that the Vendor ship the product to a warehouse that is designated by the end user. The request indicates that the Reseller's end user customer will be installing the boards on all of its new computers. However, the new computers will not be delivered for three weeks. The Reseller indicates that it expects that the products will be delivered to the end user by www.pwcrevrec.com 25

the end of the following month. The payment terms for the order are consistent with the Vendor's normal terms. The Reseller has made similar requests in the past, and in those cases, payment was made under the Vendor's normal terms. Question: Is the software considered delivered upon its being shipped? Answer: The delivery criterion is met when the software is shipped to the warehouse. There is a valid business purpose for this; the request was made directly by the end user. Furthermore, past experience supports the Reseller's representations in the request, and, payment does not depend on the software's being shipped from the intermediate site. However, it is rare that all of the criteria will be explicitly addressed in the licensing arrangement, and in many situations judgment will be required. Each of the criteria in SAB 104 is important when the facts and circumstances surrounding a ship-and-store arrangement are being evaluated. Any arrangement under which the software vendor ships products to an intermediate site should be evaluated carefully based on the facts and circumstances specific to that arrangement. Delivery of beta version The Vendor licenses a software product that is not yet available for general release. The Vendor sends the Customer a beta version of the software until the product is available for general release. Question: Is the software considered delivered upon shipment of the beta version? Answer: The delivery criterion has not been met when the beta version of the software is shipped to the customer. The Vendor has an implied obligation to deliver the final product when it is available for general release. Until the Vendor delivers the final version that is available for general release and has completed the Vendor's quality assurance process, it should not recognize revenue. 2.3 Fixed or determinable fees and collectibility SOP 97-2 requires that the vendor's fee be fixed or determinable in order for a software vendor to recognize the license revenue upon the shipment of the software. The glossary of SOP 97-2 defines a fixed fee as a fee required to be paid at a set amount that is not subject to refund or adjustment. A fixed fee includes amounts designated as minimum royalties. The concept is that on the date of shipment, the vendor must know the amount of revenue that will result from an arrangement and all the elements that will be included in the arrangement if the vendor is to recognize revenue. If the vendor subsequently adjusts the fee or adds elements at no extra (or at a reduced) cost, the fee in the arrangement may not have been fixed or determinable at the outset of the arrangement. If a vendor cannot conclude that a fee is fixed or determinable at the outset of an arrangement, revenue should be recognized as the payments become due, assuming all other criteria for revenue recognition are met. Fixed or determinable fees and collectibility related to reseller arrangements are addressed in Chapter 7. In addition, the requirement that the fee from the arrangement must be collectible has not changed. The collectibility criterion is clearly related to the other basic criteria for software revenue recognition. An issue that impacts the collectibility criterion may also impact the other basic criteria and vice versa. Also, the collectibility criterion specifically focuses on the creditworthiness of the customer. The overriding principle with regard to collectibility and software revenue recognition is whether collection of the fixed or determinable fee, as discussed above, is probable. The definition of probable in FAS 5, Accounting for 26 PricewaterhouseCoopers LLP

Contingencies, is the future event or events is likely to occur. As such, an assessment must be made regarding the probability of collecting the resulting receivable when all other revenue recognition criteria are met. The assessment is based on the probability of collecting from the customer. In some cases, a vendor will sell the customer receivable to a third party or purchase insurance on the collection of the receivable. The collectibility criteria is not satisfied by selling the receivable to a third party or purchasing insurance. Paragraph 8 of SOP 97-2 includes a requirement that the collection of the fee is probable at the time of revenue recognition. The rationale for including collectibility as one of the four criteria is that the FASB's Concepts Statements state that revenues represent actual or expected cash inflows and describe revenue-generating transactions as involving products exchanged for cash or claims for cash. SAB 104 adjusts the standard of collectibility to reasonably assured. The term reasonably assured represents a higher threshold than the term probable as that term is used in FAS 5 and SOP 97-2. The assessment of collectibility should be documented at the time that revenue is recognized and should be based on facts and circumstances at the time of revenue recognition. In the event that the fee included within the arrangement is not considered to be collectible revenue would be deferred until collection becomes reasonably assured. Other factors that affect the assessment of whether a fee is fixed or determinable and collectible are discussed in other sections of this monograph. These factors include the right to return or exchange products (discussion in Chapter 4) and the impact of discounting (discussion in Chapter 6). Issues regarding fixed or determinable fees and collectibility that are specific to resellers are discussed in Chapter 7. 2.3.1 Extended payment terms Paragraph 27 of SOP 97-2 states that certain arrangements have payment terms that extend over a substantial portion of the period during which the customer is expected to use or market the software. The existence of any extended payment terms may indicate that the fee is not fixed or determinable. This is because the risk that a vendor will make concessions to a creditworthy customer outside the contractual requirements of the arrangement increases as the payment terms are extended over longer periods. A product's continuing value is likely to be reduced over time due to technological obsolescence and other external factors, such as the vendor or its competitors subsequently introducing enhanced products, making it more difficult for a vendor to collect outstanding amounts under the original terms of the agreement. The guidance provided by Paragraph 27 of 97-2 makes it clear that the risk of collectibility is separate from the determination of fixed or determinable fees. In fact, a history of software vendors that actually make concessions outside contractual provisions led to this specific guidance on extended payment terms. Paragraph 28 of SOP 97-2 further states that if payment of a significant portion of the software licensing fee is not due until after expiration of the license or more than twelve months after delivery, the licensing fee should be presumed not to be fixed or determinable. However, the term significant is not explicitly defined in SOP 97-2. Significance can be evaluated only through a consideration of all relevant factors particular to a situation. For example, if the arrangement involves multiple elements and the payment terms are tied to the delivery of the undelivered elements, the vendor may conclude that the fee is not fixed or determinable. Consideration should also be given to the business purpose of extended payment terms. For example, the existence of extended payment terms may suggest that the customer is evaluating the software and will only pay the portion of the fee that is extended if it is satisfied with the product when the payments become due, irrespective of the contractual obligation. Another factor might be that the vendor has www.pwcrevrec.com 27

recently announced a release of a future version of the product that is not yet deliverable at the time of the initial arrangement. If a substantial portion of the fee is tied to the expected release date of the new version, the payment terms may suggest that the fee is not fixed or determinable and collectible until delivery of the new version, regardless of there being an explicit obligation to deliver the new version. Additionally, it must be noted that the twelve-month period referred to in paragraph 28 of SOP 97-2 does not constitute a bright-line test. Rather, SOP 97-2 again refers to the concept of customary business practice, which is another area of intense scrutiny by the SEC. Vendors typically have established standard payment terms for typical arrangements. Any arrangements that provide for payments beyond those standard terms may be considered extended, even though they are for a period of fewer than twelve months. This leads to the question of what constitutes a standard business practice and at what point such a practice is considered established. No single factor would be individually persuasive enough to support the assertion that a standard business practice has been established; rather, various facts and circumstances in each case must be considered. A modification of the payment terms at a subsequent date would not by itself cause a reassessment of extended payment terms. If a vendor originally assessed an arrangement as having extended payment terms, a subsequent modification of the terms would not alter the extended payment terms assessment. However, if other terms in the arrangement were also significantly modified, it would be appropriate to reassess the payment terms in the arrangement. For start-up software companies, the concept of establishing a standard business practice presents a transition issue. These companies may recognize revenue as the payments become due in the initial years of operation; however, at some point, a standard business practice of using extended payment terms may be established. In these cases, the vendor should evaluate and document the evidence that such a practice has been established. The vendor should then evaluate disclosure requirements and its effect on comparability. Several of the topics covered by the AICPA Staff in its Technical Questions and Answers (Q&As) release on SOP 97-2 deal with extended payment terms. TPA 5100.57 states that the presumption that the fee is not fixed or determinable when extended payment terms exist could be overcome by evidence that the vendor has a standard business practice of using long-term or installment contracts and a history of successfully collecting under the original payment terms without making concessions. TPA 5100.71 states that in determining whether the arrangement fee in a license extension/renewal is fixed or determinable, the date that the extension/renewal arrangement is executed should be used to determine whether the extension/ renewal payment terms are extended. To support a history of successfully collecting under the original payment terms without making concessions, a vendor would have had to collect all payments as due under comparable arrangements without providing concessions. For example, one year of payments under three-year payment arrangements would not provide sufficient history because all of the payments under the contracts would not yet have been paid as due. In addition to a history of collecting payments as due without making concessions, paragraph 14 of SOP 97-2 requires that the software vendor must intend not to provide refunds or concessions that are beyond the provisions of the arrangement. In evaluating a vendor's history, the historical arrangements should be comparable to the current arrangement relative to terms and circumstances to conclude that the history is relevant. To overcome the presumption of concessions, in extended payment term arrangements, a company's history should support the current situation. In addition, the number of historical arrangements needed to overcome the presumption of concessions increases with a greater number of instances in which concessions have been given in extended payment term situations in the past. Examples of factors that should be assessed in this evaluation include, but are not limited to, the following: 28 PricewaterhouseCoopers LLP

Similarity of customers Type or Class of Customer: A population of new arrangements with substantially the same types and class of customer is an indicator that the history is relevant. Significant differences call into question the relevance of the history. Similarity of products included Types of Products: Similarity in the types of products included under the new license arrangement (for example financial systems, production planning, and human resources). Stage of Product Life Cycle: Product maturity and overall stage within its product life cycle should be considered when assessing the relevance of history. The inclusion of new products in a license arrangement should not automatically preclude the vendor from concluding that the software products are comparable. For example, if substantially all of the products under one license arrangement are mature products, the inclusion of a small number of newly developed products in a subsequent arrangement may not change the overall risk of concession and economic substance of the subsequent transaction. Elements Included in the Arrangement: Are there significant differences in the nature of the elements that are included in the arrangements? The inclusion of significant rights to services or discounts on future products in some arrangements, but not others, could indicate that there is a significant difference between the arrangements. For example, a history developed for arrangements that included bundled PCS and rights to additional software products would not be comparable to an arrangement that does not include these rights. Similarity of license economics Length of Payment Terms: In order for the history to be considered relevant, the overall payment terms should be similar. Although a nominal increase in the length of payment terms may be acceptable, a significant increase in the length of the payment terms may indicate that the terms are not comparable. Economics of License Arrangement: The overall economics and term of the license arrangement should be reviewed to ensure that the vendor can conclude that the history developed under a previous arrangement is relevant, particularly if the primary products licensed are near the end of their lives and the customer would not be entitled to the updated version under a PCS arrangement. Additionally, the costs incurred by the customer to implement the software should be considered when evaluating if the arrangement includes extended payment terms. When the customer incurs significant implementation costs or the software is integrated into a large complex system with persuasive use in the organization, it would provide additional evidence that the extended payment terms are fixed or determinable as the customer is committed to the success of the software's rollout in its organization. It is also important that the software vendor has documented policies for customers that are granted extended payment terms and has sufficient documentation of its adherence to these policies. Evidence should exist that the vendor's business practice of granting extended payment terms is consistently applied based on the population attributes used to define the class of customer. If a vendor (1) concludes that extended payment terms are considered fixed or determinable at the outset of the arrangement and (2) can support that conclusion, the vendor should recognize all of the revenue upon the delivery of the software, assuming that all other revenue recognition criteria have been met. Conversely, if a software vendor does not have an established business practice of granting extended www.pwcrevrec.com 29

payment terms and collecting on such terms without forfeitures, refunds, or concessions, revenue from arrangements with extended payment terms should be recognized as the payments become due, assuming that all other revenue recognition criteria are met. The determination of when payments are due should be based on the invoice payment terms, not merely the date of the invoice. Specifically an invoice dated December 31 with 30 day payment terms is not technically due until January 30. The vendor must consider the impact that discounting may have on any recorded long-term receivables. This is consistent with APB 21, paragraph 8, which states the following: A note exchanged for property, goods, or service represents two elements... 1) the principal amount... and 2) an interest factor to compensate the supplier over the life of the note for the use of funds... Notes so exchanged are accordingly valued and accounted for at the present value of the consideration exchanged between the contracting parties at the date of the transaction in a manner similar to that followed for a cash transaction. Paragraph 13 of APB 21 provides guidance on the appropriate interest rate to use in this situation: In any event, the rate used for valuation purposes will normally be at least equal to the rate at which the debtor can obtain financing of a similar nature from other sources at the date of the transaction. The vendor should record interest income on the note on a monthly basis by using the appropriate rate, as described above. A question may arise regarding the impact that reserving for bad debts may have on the conclusion that the fees are fixed or determinable and collectible. A provision for bad debts represents the vendor's estimate of the potential risk of collecting fees based on the current events surrounding the customer or the order; however, the vendor generally continues to pursue its collection of fees under the original payment terms and amounts. The determination of whether the fee is fixed or determinable is made only once at the outset of the transaction. Therefore, unless information becomes known that was not available to the vendor at the outset and would have changed the vendor's evaluation at the time of the original arrangement (thereby suggesting that an error was made), the provision for bad debts does not impact the original revenue recognition. Additionally, providing reserves for, or writing off, receivables would generally not impact the future determination of whether fees are fixed or determinable for prospective customers. To the extent that accounts receivable from a specific customer are provided for with an allowance for doubtful accounts, additional revenue should not be recognized from this customer, as management has not concluded that historical amounts from this customer are not collectible. Observation: Factors such as (1) providing for reserves or taking write-offs in conjunction with agreeing to collect less than the originally stated fees or (2) granting extensions of scheduled payments to creditworthy customers may indicate that the vendor would make concessions. This would impact the determination of whether fees should be considered fixed or determinable under future arrangements. 2.3.2 Third-party financing arrangements Financing arrangements for the payment of fees due under software licensing agreements are not uncommon in the software industry, particularly when vendors license software, related PCS, and other services in volume quantities or at a high cost. The introduction of the specific fixed or determinable criterion in SOP 97-2 has led to numerous questions regarding the impact that a third-party financing arrangement has on revenue recognition. Because the risk of inappropriate revenue recognition associated with extended payment terms is not one of collectibility, the receipt of cash from a third-party financing agent by a software vendor does not necessarily lead to the conclusion that the fee in the arrangement should be considered fixed or determinable at the outset. This factor is further highlighted by TPA 5100.41, which seeks to distinguish the revenue treatment for prepayments in extended payment term situations where the vendor participates in the customer's financing arrangements from those where the vendor has no involvement. 30 PricewaterhouseCoopers LLP

Financing arrangements may be arranged solely between the customer and a third-party financing agent, or, the vendor may be involved in arranging the financing. The vendor's involvement may vary significantly, from maintaining a list of third-party financing agents to providing financing directly to the customer. Generally, when the customer arranges financing and the order is not contingent upon the customer's receipt of the financing, the mere existence of the third-party financing does not impact revenue recognition. However, as the vendor's involvement in the financing increases, so does the risk that the vendor may grant a refund or other concession in order to obtain payment of the fee. To the extent the vendor's involvement results in incremental risk, the presumption is that the fees are not fixed or determinable. The vendor may wish to retain its relationships with those who provide third-party financing to its customers, which may lead it to grant concessions to its customers to encourage payment to the third-party financiers. TPA 5100.58 considers the situation where a software vendor transfers the right to receive future amounts to a third party without recourse. The transfer of the extended payment term arrangement does not change the nature or structure of the transaction between the vendor and the customer. The transfer by a software vendor of the right to receive amounts due on an extended payment term to an independent third party without recourse to the vendor will not overcome the presumption that the licensing fee is not fixed or determinable. Although the AICPA has provided additional guidance in recently issued technical practice aids, the determination of the impact that a third-party financing arrangement has on whether a fee is fixed or determinable remains highly subjective. TPA 5100.62 provides examples of indicators of incremental risk arising from the participation of a software vendor in the end user's financing with a party unrelated to itself, which would either preclude a determination by the software vendor that the software arrangement fee is fixed or determinable pursuant to paragraph 28 of SOP 97-2 or lead to a rebuttable presumption that the fee is not fixed or determinable under that paragraph. Under that guidance any one of the following conditions or software vendor actions will result in incremental risk to the software vendor and a presumption that the fee is not fixed or determinable: 1. Provisions that require the software vendor to indemnify the financing party above and beyond the standard indemnification provisions that are explicitly included in the software arrangement between the software vendor and the end-user customer. 2. Provisions that require the software vendor to make representations to the financing party related to customer acceptance of the software that are above and beyond the written acceptance documentation, if any, that the software vendor has already received from the end-user customer. 3. Provisions that obligate the software vendor to take action (such as to terminate the license agreement and/or any related services), which results in more than insignificant direct incremental costs, against the customer on behalf of the financing party in the event that the enduser customer defaults under the financing, unless, as part of the original arrangement, the customer explicitly authorizes the software vendor upon request by the financing party to take those specific actions against the customer and does not provide for concessions from the vendor as a result of such action. 4. Provisions that prohibit or limit the ability of the software vendor to enter into another software arrangement with the customer for the same or similar product if the end-user customer defaults under the financing, unless, as part of the original arrangement, the customer explicitly authorizes the software vendor upon request by the financing party to take those specific actions against the customer. 5. Provisions that require the software vendor to guarantee, certify, or otherwise attest in any manner to the financing party that the customer meets the financing party's qualification criteria. 6. Software vendor has previously provided concessions to financing parties or to customers to facilitate or induce payment to financing parties. 7. Provisions that lead to the software vendor's guarantee of the customer's indebtedness to the financing party. www.pwcrevrec.com 31

If the vendor is not able to overcome the presumption that the fee is not fixed or determinable due to the existence of any of the above conditions, it should recognize revenue as payments from the customer become due and payable to the financing company (assuming all other revenue recognition criteria have been met). TPA 5100.63 provides some commentary on how a software vendor may be able to rebut the presumption from TPA 5100.62 that the fee is not fixed or determinable. The overriding guidance the vendor needs to follow is provided by paragraph 28 of SOP 97-2 and TPA 5100.57 (covered in greater detail earlier in this chapter). To overcome the presumption, there should be evidence that the software vendor has a standard business practice of entering into similar arrangements with financing parties that have substantially similar provisions, and has a history of not providing refunds or concessions to the customer or the financing party. Additionally, for those situations where the vendor has guaranteed the indebtedness of the customer, if the software vendor has relevant history with arrangements in which it granted extended payment terms to its customers, the software vendor should consider that history. A history of the software vendor granting concessions to either: 1. its customers in similar arrangements in which it provided extended payment terms; or 2. unrelated financing parties in similar arrangements in which the software vendor participated would prevent the software vendor from overcoming the presumption that the fee is not fixed or determinable. TPA 5100.64 provides further guidance on the level of involvement a software vendor can have in a financing arrangement that would generally not cause the vendor to assume an incremental risk that it may have to provide a refund or concession to either the end user or the financing party: 1. Software vendor introduces the customer and financing party and facilitates their discussions. 2. Software vendor assists the customer in pre-qualifying for financing as long as the software vendor does not guarantee, certify, or otherwise attest in any manner to the financing party that the customer meets the financing party's qualification criteria. 3. Software vendor represents to the financing party that the software vendor has free and clear title to the licensed software or the right to sublicense if the software vendor makes the same written representations in the software arrangement with the end-user customer. 4. Software vendor warrants to the financing party that the software functions according to the software vendor's published specifications if the software vendor makes the same written warranty in the software arrangement with the end-user customer. 5. Software vendor takes action, which was explicitly authorized by the customer in the original arrangement, to terminate the license agreement and/or any related services, or to not enter into another arrangement for the same or similar product. 6. Software vendor makes customary recourse provisions to its customer related to warranties for defective software. Given the potentially subjective nature of the assessment of whether a software vendor is assuming residual risk, it is essential for vendors who use third-party financing arrangements to maintain proper documentation of their analysis of the impact that these arrangements have on their revenue recognition policy. They should make sure that individuals within their respective organizations understand the policies and procedures surrounding these arrangements and that the proper control structure is in place to ensure adherence to those policies and procedures. Even in circumstances where there is sufficient evidence to overcome the presumption that the fee is not fixed or determinable, the software vendor still needs to evaluate the nature of any incremental risk in the arrangement to determine if there are other accounting ramifications; for example, accounting for the software vendor's continuing involvement that results from a guarantee of the customer's indebtedness (recourse). 32 PricewaterhouseCoopers LLP

In some situations a software vendor may assist a customer in obtaining finance from an unrelated third party at a more attractive interest rate than is typically available from that financing party. This would include situations where the vendor arranges to buy down the interest rate the finance house would otherwise charge to the borrower. In such cases TPA 5100.65 considers whether either: 1. awareness by the customer of the buy down arrangement; or 2. the point in time that the buy down occurs would impact revenue recognition. Whether or not the customer is aware of the buy down is irrelevant to revenue recognition. However, the timing of the buy down will impact revenue recognition. If the buy down is evidenced contemporaneously and occurs simultaneously with the original arrangement between the software vendor and customer, it is considered to be an integral part of the arrangement because of its timing. In this situation, the amount of interest rate buy down should be treated as a reduction of the total arrangement fee being recognized in accordance with SOP 97-2. If the buy down is not evidenced contemporaneously and it occurs other than simultaneously with the original arrangement it cannot be considered to be an integral part of the original arrangement. Rather, it represents a concession because it is a reduction in the arrangement fee not contemplated at the time of the original arrangement. Although all the guidance in TPAs 5100.60 through 5100.65 are written specifically in terms of an arrangement between a software vendor and an end-user customer, it is intended that they also apply to arrangements with reseller customers, as clarified by TPA 5100.66. Reseller arrangements are discussed in Chapter 7. 2.3.3 Cancellation privileges Paragraph 31 of SOP 97-2 states the following: "Fees from licenses cancelable by customers are neither fixed nor determinable until the cancellation privileges lapse. Fees from licenses with cancellation privileges expiring ratably over the license period are considered to become determinable ratably over the license period as the cancellation privileges lapse. In applying the provisions of this paragraph, obligations related to warranties for defective software, including warranties that are routine, short-term, and relatively minor, should be accounted for in conformity with FASB Statement No. 5. Additionally, short-term rights of return, such as thirty-day money-back guarantees, should not be considered cancellation privileges; the related returns should be accounted for in conformity with FASB Statement No. 48." A software vendor may have a practice of granting cancellation privileges to customers in general or may grant these privileges periodically to specific customers. SOP 97-2 indicates that, generally, fees from licenses that may be cancelled by customers are neither fixed nor determinable; consequently, revenue must be deferred until the cancellation privileges lapse. In an initial evaluation, cancellation privileges may be interpreted as being similar in nature to a right of return, which would allow for the right to be accounted for under FAS 48, Revenue Recognition When Right of Return Exists. However, further analysis indicates that there is a significant inherent difference between cancellation privileges and a right of return. The difference lies in the fact that a right of return is generally extended when a vendor expects that only a limited portion of the fee associated with the software arrangement may be subject to the right of return or that only a few customers of a large homogeneous population are expected to return the product. FAS 48 requires that there must be an adequate historical basis on which a vendor can base its estimate of returns. Since this type of right of return is generally given to all customers in a consistent fashion, it is possible in many situations for a software vendor to develop a pool of homogenous customers with the same right of return that can www.pwcrevrec.com 33

provide a historical basis for estimating returns. Further, when a customer will only accept a delivery in circumstances in which the arrangement can be unilaterally cancelled by the customer, it is clear that the customer has not committed to pay the related fee. Cancellation privileges and return rights should be evaluated to determine whether the substance of the clause puts the entire fee at risk. If so, the fee is not fixed or determinable until the cancellation privileges lapse. As discussed in paragraph 31 of SOP 97-2, for arrangements in which the cancellation privileges lapse ratably, revenue should be recognized as the cancellation privileges lapse, assuming that all other revenue recognition criteria are met. There are two exceptions to this guidance: (1) a short-term right of return and (2) warranties for defective software, including warranties that are routine, short-term, and relatively minor. A short-term right of return, including a 30-day money-back guarantee, as mentioned in SOP 97-2, should be evaluated in accordance with FAS 48. FAS 48 requires that there must be an adequate historical basis on which a vendor can base its estimate of returns. Warranties that are routine, short-term, and relatively minor should be accounted for according to the guidance provided in FAS 5. Such warranties should generally be given to all customers in a routine and consistent manner. If warranties vary significantly among customers, an evaluation would have to be made of whether the criteria of routine, short-term, and relatively minor have really been met. The impact on revenue recognition when customer acceptance is required in an arrangement is addressed in section 2.3.6. Additionally, some arrangements include provisions that allow customers to receive credit for current purchases at a future date. This type of situation is evaluated in Chapter 6. Lastly, certain arrangements contain cancellation provisions related to fiscal-funding clauses, which are addressed in section 2.3.4. 2.3.4 Fiscal-funding clauses Fiscal-funding clauses are generally associated with arrangements with governmental entities. Governmental entities are generally operated under strict funding guidelines that allow the entity to order products or services up to only (1) the amount of predetermined funding or (2) the budgeted amounts. Such entities generally include fiscal-funding clauses in their software arrangements, which provide that the license is cancelable if the legislature or funding authority does not appropriate the funds that the governmental unit needs to fulfill its obligations under the licensing arrangements. Consistent with FASB Technical Bulletin No. 79-10 (FTB 79-10), Fiscal Funding Clauses in Lease Agreements, SOP 97-2 requires an evaluation of the probability of contract cancellation. If the probability of cancellation is determined to be a remote contingency, the contract should be considered noncancellable, and the existence of such a clause would not impair revenue recognition. FAS 5 defines remote contingency as the chance of the future event or events occurring is slight. Funding clauses in arrangements with nongovernmental entities would preclude revenue recognition until all the requirements of the clause, and the other revenue recognition criteria, have been met. The AICPA Audit and Accounting Guide, Audits of State and Local Governmental Units, contains guidance on whether an entity should be considered a governmental entity. 2.3.5 Forfeiture or refund clauses One of the most significant factors affecting the determination of whether a multiple-element fee is (1) fixed or determinable and (2) collectible, relates to undelivered elements. SOP 97-2, paragraph 14, states that no portion of the fee (including amounts otherwise allocated to delivered elements) meets the criterion of collectibility if the portion of the fee allocable to delivered elements is subject to forfeiture, refund, or other concession if any of the undelivered elements are not delivered. This is based on the view that a potential concession indicates that the customer would not have originally licensed the 34 PricewaterhouseCoopers LLP

delivered products without simultaneously having had access to an undelivered element. Specific factors to consider (as outlined in paragraph 14 of SOP 97-2 ) when evaluating whether a portion of the fee is subject to forfeiture or a refund are as follows: Acknowledgement in the arrangement of products not currently available or not to be delivered currently; Separate prices stipulated in the arrangement for each deliverable element; Default and damage provisions as defined in the arrangement; Enforceable payment obligations or due dates for the delivered elements that are not dependent on the delivery of the future deliverable elements, coupled with the intent of the vendor to enforce rights of payment; Installation and use of the delivered software; and Support services, such as telephone support, related to the delivered software being provided currently by the vendor. Observation: These factors are items that should be considered in the analysis of whether a fee in an arrangement is fixed or determinable and collectible and should be evaluated in conjunction with all available evidence. Any portion of an arrangement's fee that is subject to forfeiture, refund or concession may not be recognized until such provisions are settled or resolved. Concessions, although not specifically defined in SOP 97-2, generally encompass those actions taken by vendors that are otherwise not required by the original terms of the arrangement. As discussed in more detail in TPA 5100.56 concessions can include: (1) changes that impact the original amount of revenue recognized, (2) changes that reduce the arrangement fee or extend the payment terms and (3) changes that increase the deliverables or extend the customer's rights beyond those in the original contract. However, certain actions are not considered to be concessions, including, but not limited to: (1) an increase in the deliverables with an appropriate corresponding increase in the fee, or (2) an elimination of the vendor's obligations without a refund of cash. Paragraph 14 of SOP 97-2 indicates that a vendor's historical practice of making refunds or granting concessions beyond those required by the original contract should be more persuasive than the terms included in the current arrangement. For example, if an arrangement contains provisions that outline payment terms that are based on the delivery of the various elements, the software vendor must have a history of enforcing such payment terms successfully and without concessions. Determining whether past business practices have resulted in a historical pattern of concessions that would impact the vendor's revenue recognition is a judgmental area and is dependent upon facts and circumstances. The following questions, among others, should be considered when making such an assessment: How often has the vendor made concessions and for what purpose? What is the underlying reason for providing concessions and is the root cause expected to permeate through to other arrangements? How does the value of the concession compare to the arrangement's fees? Software vendors may offer a form of price protection, commonly known as "Most Favored Nation" pricing. These clauses are generally structured such that when the Vendor contracts with Customer A to sell Product B, and subsequently sells Product B to another customer at a lower price, Customer A has the right to purchase future licenses for Product B at that lower price. Consideration must be given to determine whether this is a concession, and therefore impacts the software vendor's revenue recognition. Examples of such situations are considered below. www.pwcrevrec.com 35

2.3.6 Customer-acceptance clauses Software arrangements may include a contractual acceptance provision that states the acceptance criteria or a specific period in which the product must be accepted or returned. Conversely, implicit acceptance provisions may also exist based on the vendor's customary business practices. Paragraph 20 of SOP 97-2 states that if uncertainty exists about customer acceptance of the software, license revenue should not be recognized until acceptance occurs. TPA 5100.67 (which incorporates SAB 104 acceptance clause guidance) provides some interpretation of this paragraph and states that it was not intended to suggest that the existence of an acceptance clause would preclude revenue recognition until formal customer acceptance has occurred. In these situations, all available evidence should be considered when a determination is being made of the effect that acceptance language in an arrangement or the implicit existence of an acceptance period has on revenue recognition. Generally, if the acceptance criteria are based on the product's meeting normal published specifications and the acceptance period is short, revenue recognition would not be precluded. TPA 5100.67 refers to the guidance provided in SAB 104 and the associated frequently asked questions and includes a discussion of other factors that should be considered. These include: Historical experience with similar types of arrangements or products; Whether the acceptance provisions are specific to the customer or are included in all arrangements; The length of the acceptance period; and Historical experience with the specific customer. Observation: When considering the above it is important to understand and assess the effects of the following areas on the acceptance provisions: The length and complexity of the installation period; The significance of modifications made to the software during the period between its delivery and customer acceptance; The length of the period between (1) delivery and/or installation and (2) the expiration of the acceptance period; and Whether the product is a new or existing product. Generally, acceptance criteria can fall into four distinct types: 1. Acceptance provisions that purport to be for a trial period or evaluation purposes; o It is not uncommon in the software industry for vendors to supply products for a trial period or for evaluation purposes. In general, the customer does not agree to purchase the product until the evaluation time period has elapsed or specific instructions are issued, such as a valid purchase order. In these circumstances, the vendor has essentially provided the purchaser with product on a consignment basis and accordingly revenue would not be recognized until the earlier to occur of the formal acceptance of the product or the lapsing of the acceptance time period occurs. 2. Acceptance provisions that grant a right of return or exchange on the basis of subjective matters; o One such example of this type of acceptance clause would be if the customer is allowed to return the product if they are dissatisfied. These types of provisions are not dissimilar from general rights of return and as a result should be accounted for using the guidance given in SFAS 48. 36 PricewaterhouseCoopers LLP

o SFAS 48 requires that the amount of future returns can be reasonably estimated. (The criteria for estimating returns are discussed in Chapter 4.) 3. Acceptance provisions that grant a right of replacement on the basis of vendor-specified objective criteria; o These kinds of terms are common within software licensing transactions and generally take the form of allowing the customer a right of return or replacement if the product is defective or fails to meet the vendor's published performance criteria. Such rights are generally granted to all customers, or all customers of a specific class, and do not consider any customer-specific criteria. Provided that the vendor has previously demonstrated compliance with the specified criteria these provisions are, in general, no more than warranty clauses and should be accounted for as warranties in accordance with FAS 5. Generally this would mean that the cost of potentially defective goods could be estimated based on a demonstrated history of substantially similar transactions. If, however, the vendor has not previously demonstrated that the delivered product meets their own specifications, revenue should be deferred until it can be shown that the specifications have been achieved; and 4. Acceptance provisions based on customer-specified objective criteria. o These provisions are generally referred to as customer-specific acceptance provisions and require compliance with specific criteria laid down by the customer against which completion and fulfillment must be evaluated. While formal customer sign-off provides the best evidence that these criteria have been met, revenue recognition would also be appropriate, assuming all other criteria have been met, if the vendor is able to reliably demonstrate that the delivered product meets all the specified criteria prior to formal acceptance. o If an arrangement includes customer acceptance criteria or specifications that cannot be effectively tested before delivery or installation at the customer's site, revenue recognition would generally be deferred until it can be demonstrated that the criteria have been met. Questions and Answers Fixed or determinable extended payment terms The Vendor offers three-year term software licenses that provide three-year payment terms. Forty percent of the license fee is paid upon the delivery of the software and the remainder of the fee is paid on a monthly basis over the term of the license. The Vendor represents that this is standard in its sector of the software industry and that it has no history of writing off the receivables or otherwise making concessions. Question: Is a "significant" portion of the fee considered extended? Answer: Considering that 40% of the total arrangement fee is not due until twelve months after the date of delivery, it would appear that a significant amount of the payments have been extended. There are no bright lines that determine what is considered "a significant portion of the fee" in applying provisions of SOP 97-2; significance can be determined only in the context of the particular facts and circumstances surrounding a given transaction. The belief that these types of payment terms are standard in a particular sector of the software industry may or may not be relevant. If competitors offer these types of payment terms, the Vendor may have a valid business purpose for granting such terms (i.e., to remain competitive). However, we do not believe that the experience of others in the industry is relevant to assessing a particular vendor's past experience in granting extended payment terms and making concessions related thereto. In other words, it is the individual vendor's experience that must be considered in a determination of whether fees are fixed or determinable at the outset of the contract, not the industry standard. www.pwcrevrec.com 37

Accordingly, if one concludes that in this fact pattern a significant portion of the fee is considered extended, then until the Vendor has a history of collecting the receivables without concession from a number of similar transactions, revenue from the arrangement should be recognized as payments become due, assuming all other revenue recognition criteria have been met. No history of extended payment terms The Vendor manufactures software products that provide its customers with an enterprise-wide solution. Within the solution are individual suites that are separately licensed and provide functionality in a specific area, such as accounting, inventory management, and sales-force automation. Payment is almost always due 30 to 60 days after shipment. The Vendor introduces a new suite within its enterprise-wide solution to deal with the human resources area. The Vendor has no history of offering extended payment terms, but intends to offer them with the introduction of this human resources suite. The Vendor has not had a history of granting concessions, refunds, or forfeitures in the past, even though it has introduced several new suites and platforms in recent years. The Vendor licenses the upgraded enterprise-wide solution to three customers and offers payment terms of 10% down upon delivery of the software, with the remaining 90% due in six months. Assume that all other revenue recognition criteria have been met. Question: Should the Vendor record revenue upon the delivery of the enterprise-wide solution? Answer: The first issue is whether six-month payment terms represent extended payments. In spite of the fact that the payment period falls within the twelve-month window in SOP 97-2, if the Vendor's standard business practice is to require payment within 30 to 60 days, it may be reasonable to conclude that the six-month payment terms are outside normal practices and therefore represent extended terms. While the Vendor does not have a history of making concessions, it has never extended its payment terms beyond its standard 30-to-60-day terms. It would appear that the Vendor may have effected a change in its business practices, coincident with the introduction of a new functionality. Therefore, the Vendor's historical business practice of not granting concessions, forfeitures, or refunds may not apply after the adoption of the new business policy. Another factor that may be relevant in this assessment is the impact that the introduction of the new suite is having. The introduction may be causing a change in the Vendor's payment-terms business model, due to uncertainty about acceptance or customer satisfaction with the new human resources suite. However, the Vendor could be changing its practices for payments because of market conditions or competitors' pricing structures that may not have anything to do with the introduction of the new human resources suite. Consequently, this new business practice may lead to the conclusion that it would not be appropriate to record revenue upon the delivery of the software. Although the above example clearly requires the use of judgment, the information above would suggest that the revenue from the arrangement should probably be recognized as payments become due. History of granting extended payment terms of fewer than 12 months The Vendor has introduced a new product that it expects it will be able to market to customers who will deploy the product worldwide. For its volume customers, the Vendor will enter into several arrangements and expects to grant payment terms of 12 to 18 months. The Vendor has not had any significant write-offs of its receivables from customers when extended payment terms (which the Vendor has defined as more than 60 days) have been granted in the past. The Vendor has no history of granting payment terms of 12 months or longer. 38 PricewaterhouseCoopers LLP

Question: Does the Vendor need to demonstrate that it can collect receivables with payment terms of more than 12 months without granting concessions? Will the Vendor's history of granting extended payment terms of fewer than 12 months be sufficient to overcome the presumption that the fee is not fixed or determinable? Answer: It is important to emphasize that the Vendor's history of collections is not the only critical factor in a determination of whether the fee is fixed or determinable. Other factors to consider are whether the Vendor has a practice of granting extended payment and has not made subsequent concessions that modified the original payment terms. The 12-month provision of SOP 97-2 that allows for the presumption that the fee is not fixed or determinable is arbitrary but is, nonetheless, included in order to create comparability in the industry. Therefore, the individual facts, circumstances, and practices pertaining to each vendor should be evaluated. In other words, (1) the business purposes for granting the extended terms and (2) the Vendor's history of collecting the fees related to extended payment terms of fewer than 12 months without having granted concessions is needed to support the conclusion that fees are fixed or determinable. However, the Vendor will also need to analyze and support its assertion that it is able to collect the fees billed under the extended payment terms. Accordingly, assuming that the lengthening of payment terms is considered significant as compared to its history, until the Vendor has a history of collecting the receivables without concession from a number of similar transactions, revenue from the arrangement should be recognized as payments become due, assuming all other revenue recognition criteria have been met. Fixed or determinable extended terms and financings Assume that the same facts hold true as those that were presented above, except that the fee in the arrangement is $500,000 and is deemed fixed or determinable. Additionally, assume that the Vendor issued a non-interest-bearing note receivable for the payments due under the arrangement. Assume that the Vendor's borrowing rate is 8%. Assume also that there were 18 monthly payments due in equal amounts. Question: How should revenue under the arrangement be recognized? Answer: Since the conclusion that the fee in the arrangement is fixed or determinable has already been made, the net present value of the payments would be recorded as revenue upon the delivery of the software product, assuming that all other revenue recognition criteria have been met. This is consistent with APB 21. As such, $469,693 should be recorded upon delivery of the software. The $469,693 represents the present value of 18 monthly payments of $27,778 each, at an annual interest rate of 8%. The amount of unrecorded income ($30,307) would be recorded as interest income during the 18-month period. www.pwcrevrec.com 39

Recording revenue as payments become due On December 31, X1, a software vendor entered into an arrangement for a total fee of $1,000,000. The Vendor has concluded that its software license arrangement with the Customer does not meet the fixed or determinable criterion. Payment terms and collections of fees related to the arrangement are as follows: Fees Payment Due Date Date Cash is Collected $250,000 January 1, X2 March 1, X2 $250,000 September 1, X2 October 1, X2 $250,000 March 1, X3 April 1, X3 $250,000 September 1, X3 September 30, X3 $1,000,000 Question: What revenue can be recognized at December 31, X1? Answer: The AICPA Staff addressed this question in the Q&As (TPA 5100.42). Because the first payment of $250,000 is not due until January 1, X2, no revenue should be recognized at December 31, X1. Had the initial payment due date been December 31, X1, $250,000 of revenue would have been reported in that year, assuming that all other revenue recognition criteria have been met. The remainder of the fee will be recorded in revenue during the period in which payments become due. TPA 5100.59 addressed the issue of subsequent cash receipts in an extended payment term arrangement. In the above example, if all of the extended payments were received subsequent to yearend but before the financial statements were issued, the conclusion in TPA 5100.59 would indicate that those payments would only be revenue in the period received (i.e., no impact on revenue recognition for the previous period). Actual payment dates and recording revenue Assume in the above example that cash is collected at later dates than provided in the arrangement. Question: Is there an impact on when the revenue should be recorded? Answer: The fact that the cash is collected on later dates does not have an impact on when the revenue should be recorded. Prepayments and recording revenue Assume in the above example that cash is collected at earlier dates than provided in the arrangement. Question: Could the Vendor have recorded revenue when the cash was collected if the Customer paid the January 1, X2 installment on December 29, X1? 40 PricewaterhouseCoopers LLP

Answer: TPA 5100.41 states that a vendor could recognize revenue for amounts (related to an arrangement with extended payment terms) received directly from customers (without the software vendor's participation in its customers' financing arrangements) in advance of scheduled payments. In that example, the Vendor should be able to recognize into revenue the first payment received at December 31, X1, assuming that all other criteria have been met. Vendor records revenue and subsequently determines amounts that will not be collected The Vendor makes a determination at the outset of a sales arrangement that a fee is fixed or determinable and records the appropriate amount of revenue upon delivery of the software (all revenue recognition criteria have been met). A portion of the payments is not received when they become due and, in a subsequent period the Vendor determines that some of the payments will not be collected. Question: Should the Vendor restate the previously recorded revenue on the basis that the revenue was improperly recorded and an error had been made? Answer: If the Vendor appropriately determined that the fees were fixed or determinable at the outset, and all other revenue recognition criteria were met, the write-off of the receivable should be recorded as a bad-debt charge in the period that it was determined that the amounts would not be collected. To the extent that the product is returned, the reversal related to amounts not received charge should be recorded against revenues. Extended payment terms similarity of payment terms The Vendor has been in business for 4 years and sells perpetual software licenses. The Vendor's standard business practice is to extend the payment of the arrangement fee in equal installments over 3 or 5 years. Because of these extended payment terms, SOP 97-2, paragraph 28, indicates that the arrangement fee is presumed not to be fixed or determinable (i.e., because a significant portion of the software licensing fee is not due until more than twelve months after delivery of the software) and revenue should be recognized as the payments from customers become due. This presumption can be overcome if the Vendor can demonstrate that it has a standard practice of using long-term or installment contracts and a history of successfully collecting under the original payment terms without making concessions. The Vendor can demonstrate a history of successfully collecting under the original terms of its 3 year arrangements without making concessions. Additionally, this arrangement is not viewed to be a subscription. Question: Can the Vendor overcome the presumption that the fees are not fixed or determinable for their 5 year arrangements by successfully demonstrating a history of collecting under the original terms of their 3 year arrangements without making concessions? Answer: No. The AICPA Staff addressed the question in the Q&A's (TPA 5100.57). To overcome the presumption that fees are not fixed or determinable in extended payment term arrangements, the Vendor must have a history of successfully collecting under the original payment terms of comparable arrangements without making concessions. Further, in evaluating a vendor's history, the historical arrangements should be comparable to the current arrangement relative to terms and circumstances to conclude that the history is relevant. Factors that should be assessed in this evaluation and include, among other factors, that in order for the history to be considered relevant, the overall payment terms should be similar. Although a www.pwcrevrec.com 41

nominal increase in the length of payment terms may be acceptable, a significant increase in the length of the payment terms may indicate that the terms are not comparable. Accordingly, a history of successfully collecting on 3 year arrangements without providing concessions is not sufficient to overcome the presumption that a Vendor will provide concessions on its 5 year arrangements. In this case, the Vendor would need to demonstrate a history of successfully collecting pursuant to the original payment terms on comparable 5 year arrangements in order to overcome the presumption that the fees in its 5 year arrangements are not fixed or determinable. However, such history is not available because the Vendor has only been in business for 4 years. Fixed or determinable third-party financings Consider the following scenarios, which depict different levels of involvement between the Vendor and the Customer with regard to a financing arrangement. Assume that the Vendor has a history of granting extended payment terms but does not have a history of making concessions. The Customer arranges its own financing, the arrangement is not contingent upon the receipt of financing, and the Vendor does not have any involvement in facilitating the financing process. (Scenario 1) The Customer requests extended payment terms and the Vendor refers the Customer to several thirdparty financing agents who are known to finance deals for similar products. (Scenario 2) The Vendor has a prearranged relationship with a third-party financing agent whereby customers of the Vendor can receive financing at pre-negotiated rates and terms once their creditworthiness has been ascertained. (Scenario 3) The Vendor has a captive financing company that provides the financing. (Scenario 4) Question: How would each scenario affect the determination of whether the fee is fixed or determinable? Answer: Scenario 1 Because the software arrangement's payment terms are not extended, as contemplated in paragraph 28 of SOP 97-2, and the Vendor does not participate in the end-user customer's financing, the Vendor would be able to recognize revenue upon delivery of the software product, provided all other requirements of revenue recognition in SOP 97-2 are met. (TPA 5100.60) Scenario 2 While not quite as clear as Scenario 1, the fact pattern would generally support the assertion that the fee is fixed or determinable, as long as the business reason for the desired payment structure is valid and unrelated to future deliverables. (TPA 5100.64) Scenario 3 The nature of the business relationship between the parties (as much as their contractual obligations) should govern the underlying assessment of whether the underlying fee is fixed or determinable. Factors to consider in evaluating this scenario include, but are not limited to, the following: What are the terms of the agreement between the Vendor and the third-party financing agent? What are the ramifications for the Vendor if the Customer stops making payments to the thirdparty financing agent due to financial difficulty or any other reason? 42 PricewaterhouseCoopers LLP

What are the ramifications for the Vendor if the Customer stops making payments to the thirdparty financing agent due to a lack of satisfaction with the performance of the product or its inability to purchase additional products from the Vendor? Whether the Vendor has a history of providing concessions to financing parties or to customers to facilitate or induce payment to the financing parties. Scenario 4 Given that the Vendor does have a history of collecting fees without making concessions, the use of a captive financing company would not, by itself, preclude the Vendor from concluding that the fees are fixed or determinable. Conversely, if the Vendor had no historical evidence of collecting fees without making concessions for this type of receivable, revenue would be recognized as the payments became due, as the fee would generally not be deemed fixed or determinable at the outset of the arrangement. (TPA 5100.63). Fixed or determinable third-party financing without recourse The Vendor enters into an arrangement with the Customer on December 29, X1. The total fee in the arrangement is $1,000,000. Of the total fee, $250,000 is due immediately. The remaining $750,000 is due in installments as follows: Payment Due Date Fees June 30, X2 $250,000 December 30, X2 $250,000 March 30, X3 $250,000 All products due under the arrangement were delivered on December 29, X1. There are no products or services deliverable in the future, and there are no updates expected by the Customer. The Vendor has a limited history of utilizing extended payment terms, and therefore the Vendor cannot conclude that the fees are fixed or determinable at the outset of the arrangement. However, management has never made concessions in the past and has no intention of making them in this arrangement. Question: Assume that on June 29, X2, the Vendor factors the remaining fees to a third-party financing agent (the "Agent"). The Agent bears all risk of collection for any reason, and the deal is nonrecourse to the Vendor. Are the amounts received from the factoring recognizable as revenue when received? Answer: The factoring of the remaining amounts due under the arrangement does not change the nature or the structure of the transaction between the Vendor and the Customer (TPA 5100.58). Therefore, as the fees were not considered fixed or determinable at the outset, the factoring has not changed that determination. Revenue should be recorded when the original payment terms become due on June 30, X2, December 30, X2, and March 30, X3. Fixed or determinable short-term returns On September 30, the Vendor enters into an arrangement with the Customer for total fees of $500,000 to license Product Z. Pursuant to the terms of the arrangement, the Vendor delivered Product Z on September 30. The arrangement contains the following provision: "The Customer can return the product for a full refund within 60 days after the completion of the installation." Assume that the Vendor generally www.pwcrevrec.com 43

gives customers a 30-day period during which they can return the product for a refund but that the 30-day clause generally is not linked to the completion of the installation. Additionally, the Customer's number of users is substantially higher than that of the majority of the Vendor's other customers. Question: Are the fees under the arrangement fixed or determinable on September 30? Answer: Despite the fact that the contract uses the word return, the essence of the clause is that this is a cancellation privilege. Additionally, the linking of the "return" clause to installation may indicate some uncertainty on the part of the Customer regarding the product's performance in the Customer's environment. Lastly, the fact that the cancellation privilege cited in this clause is different from the return right granted to other customers would be another indicator that the fees in the arrangement are not fixed or determinable at the outset of the arrangement. As such, the $500,000 of revenue should be recognized when the cancellation privilege lapses. Most-favored nation clauses - prospective application Vendor A enters into a contract with Customer B to provide software Product X. Customer B requests that the contract include a clause stating that if Vendor A offers Product X at a lower price to any of its customers, then Customer B will have the right to purchase additional Product X at the lower price. Question: Does the inclusion of this clause impact Vendor A's revenue recognition? Answer: No. While "Most Favored Nation" clauses provide the customer with price protection for future price decreases, the timing and amount of such price reductions are within the control of the vendor. Accordingly such clauses would generally result in the vendor concluding that the arrangement's fee is fixed or determinable. Most-favored nation clauses - retrospective application Assume the facts as set out in the example above. Question: Would the conclusion above differ if Vendor A has a history of providing retroactive price adjustments to its customers? Answer: The most-favored nation clause could impact the revenue recognition. Consideration is needed as to whether Vendor A: (1) can control the price at which it sells products to all of its customers under price protection programs; and (2) can reliably estimate its price-protection obligation at the time of revenue recognition. Refer to Chapter 7 for a further discussion of considerations related to price protection. 44 PricewaterhouseCoopers LLP

Fixed or determinable payment dependent on delivery of additional product On June 29, X2, the Vendor entered into a software agreement with the Customer. Pursuant to the terms of the agreement, Product A and Product B were delivered on June 29, X2. Product C, which is not currently deliverable, is scheduled for delivery on July 15, X2. The total fair value of the agreement and the total fees are $1,000. VSOE of fair value (as discussed in Chapter 3) for the products is as follows: Product Fair Value Product A $250 Product B $600 Product C $150 The agreement contains a provision that if Product C is not delivered on or by July 15, X2, the Customer will receive a refund of $200 against the fee of $1,000. Question: What is the appropriate revenue recognition? Answer: Paragraph 14 of SOP 97-2 states, "No portion of the fee (including amounts otherwise allocated to delivered elements) meets the criterion of collectibility if the portion of the fee allocable to the delivered elements is subject to forfeiture, refund, or other concession if any of the undelivered elements are not delivered." As such, no portion of the revenue for Products A and B that would be subject to forfeiture (in the event that Product C were not delivered) can be recognized. Therefore, $800 ($1,000 total contract value less $200 potential refund) would be recognized on June 29, X2. The $200 would be recognized upon the delivery of Product C, if it is delivered by July 15, X2. Observation: Penalties cannot be used to establish VSOE of fair value. In this scenario, VSOE of the fair value of the undelivered element was known, and, since it was less than the potential penalty, the amount of the penalty would need to be deferred. Under SOP 98-9, if VSOE of fair value of the undelivered products is not known, revenue cannot be recognized. Fixed or determinable effect of business practices The Vendor has recently announced a new software product. The Vendor's related marketing literature advertises that the product includes significant enhancements of prior products and will operate in a new operating environment that will make it more user-friendly. The Vendor's standard software arrangement does not have contractual acceptance or rights-of-return provisions. However, the Vendor has a history of delaying collections on licenses of new products, which appears to indicate that the customers were evaluating the software to determine whether it met the advertised functionality. Additionally, the Vendor accepts returns of new products if customers are not satisfied, and it has made concessions in the past. Question: Do the Vendor's business practices impact the determination of collectibility? Answer: The Vendor's past practices may indicate that the software is being tested in the marketplace during the product's initial release phase and that the fee is not fixed or determinable and collectible at the time of shipment. Customers may have, in substance, a cancellation privilege. License revenue for all products www.pwcrevrec.com 45

that are delivered during the initial phase should be deferred until (1) sufficient evidence exists that the products will be accepted by the customers or (2) the Vendor no longer accepts returns, makes concessions, or changes its collection practices for the product. Acceptance provisions Vendor A enters into arrangements with two customers to deliver a modified version of its standard software. The first arrangement includes customer acceptance provisions relating to standard performance criteria which, under its license, Company X is able to reject the software if it uses more than a fixed amount of memory to run. The second arrangement includes customer acceptance provisions relating to standard performance criteria which, under its license, Company Y is able to reject the software if it does not operate when integrated with a new software product being developed by Company Y. The integration services do not involve significant production, modification or customization of the software. Question: Assuming that all the criteria for revenue recognition other than related to acceptance have been met, when can Vendor A recognize revenue under these two arrangements? Answer: For the sale to Company X, Company A is able to demonstrate that in addition to meeting the published specifications, it will run using less than the fixed amount of memory. Consequently, although the contract has an acceptance provision, this can be seen to be a warranty under FAS 5. As long as Vendor A can estimate the amount of warranty obligation, it should recognize revenue on delivery of the software, with an appropriate liability for probable warranty obligations. For the sale to Company Y, Vendor A is not in a position to demonstrate that its software can be successfully integrated with that of Company Y before shipment and, consequently, the customer acceptance provision is substantive and is not overcome on shipment. Thus, no revenue can be recognized until it can be demonstrated that Company Y has successfully integrated the software. This would be best evidenced by formal customer acceptance, although other objective evidence may be available. Fixed or determinable customer acceptance and collectibility The Vendor and the Customer enter into a software agreement pertaining to Product A. The Vendor's standard license agreement contains the following provision: "The Customer has 30 days from delivery to accept Product A. If the Customer does not accept Product A due to a defect in Product A, the Vendor has 15 days to cure the defect in Product A." The Vendor is an established software company. Since the introduction of Product A three years ago, there have been an extremely small number of situations in which there has been a defect in Product A. In all of these limited situations, the defect was caused during shipment, and the Vendor cured the defect by shipping a new Product A. No concessions have been granted in relation to the acceptance provisions. Also, there have been no cases in the Vendor's history in which Product A was not ultimately accepted by a customer. Question: Is the collection of fees probable upon the delivery of Product A? 46 PricewaterhouseCoopers LLP

Answer: Although all the facts and circumstances would have to be evaluated, particularly regarding the Customer's computing environment and the number of users compared to the past customer base, it is likely that the Vendor would be able to mitigate the uncertainty surrounding the stated acceptance clause for fee collectibility and recognize revenue upon the delivery of Product A, assuming that all other revenue recognition criteria have been met. Fixed or determinable additional time needed to cure defect and collectibility Assume that the Vendor is a relatively new software company. Product A was introduced one year ago. The Vendor has 25 customers. All customers are provided with a stated acceptance clause similar to the one described in the example in section 2.3.3, and the Vendor has experienced some defects in Product A. However, in all but two cases, the Vendor's service engineers have been able to fix the problem within 15 days, and the Customer ultimately accepted the product. In the two cases in which the problem had not been fixed within 15 days, Product A was eventually accepted by the Customer, but the Vendor committed to providing additional training days at no additional cost. Question: Is the collection of fees probable upon the delivery of Product A? Answer: All the available evidence would have to be evaluated. Despite the fact that Product A has always eventually been accepted, the fact pattern shows that the Vendor had to incur time and expense to cure defects after the product's delivery and provide concessions to ensure acceptance. This presents reasons for concern over the ability of the Vendor to record revenue upon the delivery of Product A. Acceptance of Software linked to performance of services The Vendor enters into an arrangement to sell the Customer software and services that are not essential to the functionality of the software (e.g., training and installation) and would otherwise be accounted for separately from the software. The arrangement includes an acceptance clause where the acceptance of the software is linked to the Vendor's performance of the services. Question: How does the acceptance clause affect the accounting? Answer: Since the Customer's acceptance of the services is generally viewed as a subjective right of return, the Vendor should account for the customer acceptance provisions that are linked to the non-essential services as a right of return under the provisions of FAS 48. www.pwcrevrec.com 47

Chapter 3: Arrangements Involving Multiple Elements 3.0 Overview A multiple-element software arrangement is any arrangement that provides the customer with the right to software along with any combination of additional software deliverables, services, or postcontract customer support (PCS), plus non-software deliverables considered to be within the scope of SOP 97-2 after applying the guidance in EITF 00-21 and EITF 03-05 (see Chapter 1). Unlike sales of many other types of products in other industries, multiple elements are common in software arrangements because of the nature of the industry in particular with regard to future products, maintenance, and implementation services. SOP 97-2 does not distinguish between significant and insignificant vendor obligations and stipulates that, for revenue recognition purposes, when-and-if-available contract language must be considered equivalent to an actual obligation to deliver a product. All future obligations, including additional software deliverables that will be delivered only on a when-and-if-available basis, are considered elements to which the arrangement fee should be allocated, based on the fair values of the individual elements as discussed later in this chapter. This conclusion is based on the concept that if an undelivered element is specifically mentioned in a contract, it must be an important factor in the customer's purchasing decision. Revenue recognition for multiple-element arrangements is complicated and will vary with the nature of each of the deliverables and how, if at all, each deliverable relates to or impacts another element. A substantial portion of SOP 97-2 is dedicated to discussing the recognition of revenue for multiple-element arrangements, and it is essential that vendors thoroughly understand the accounting for the various types of arrangements. This chapter will discuss the following aspects of multiple-element arrangements: 3.1 Revenue recognition for multiple-element arrangements 3.2 Vendor-specific objective evidence 3.2.1 Residual method 3.2.2 Establishing VSOE of fair value 3.3 Postcontract customer support 3.3.1 General guidelines for recognition of PCS revenue 3.3.2 VSOE of fair value for PCS and other undelivered elements does not exist 3.3.3 PCS revenue is recognized with the initial license fee 3.3.4 Distinguishing between warranty obligations and PCS 3.4 Determining VSOE of fair value for PCS arrangements 3.4.1 Fair value of PCS in a short-term time-based license 3.4.2 Fair value of PCS in a multi-year time-based license 3.4.3 Fair value of PCS in perpetual and multi-year time based licenses 3.4.4 Coterminous PCS 3.4.5 Fair value of PCS with a consistent renewal percentage but varying renewal dollar amounts 3.4.6 PCS arrangements involving a maximum charge 3.4.7 PCS renewals based upon users deployed 3.4.8 Fair value of PCS with usage-based fees 3.5 Explicit versus implied PCS arrangements 3.6 Services 3.6.1 PCS offered in arrangements involving significant customization or modification 3.7 Presentation and disclosure of product and services revenue 48 PricewaterhouseCoopers LLP

3.1 Revenue recognition for multiple-element arrangements For arrangements that involve multiple elements, the entire fee from the arrangement must be allocated to each of the individual elements, based on each element's fair value. For revenue to be recorded for the delivered elements, the amount allocated to delivered elements may not be subject to a future adjustment. The portion of the fee that is allocated to an element should generally be recognized as revenue when all of the criteria for revenue recognition have been met with respect to that element. SOP 97-2, however, requires that if evidence of the fair value of each of the elements does not exist, all revenue from the arrangement must be deferred until the earlier of when (1) such evidence does exist for each element, (2) all elements have been delivered, or (3) the evidence of fair value exists for the undelivered elements (the SOP 98-9 exception, see below). As discussed below, an exception also exists for PCS, other services, and subscriptions. If it appears that the portion of the fee allocated to an undelivered element will not be sufficient to cover the vendor's selected costs for delivering that element of the arrangement, a loss must be recognized pursuant to FAS 5. The following are exceptions to the general guidance above: If the only undelivered element is PCS, the deferred amount should be recognized ratably over the contract period; If the only undelivered element consists of services that do not involve significant production, modification, or customization of software (for example training or installation), the deferred amount should be recognized over the period during which the services are expected to be performed; If the only undelivered elements consists of services that do not involve significant production, modification, or customization of software and PCS, which are performed over the same period and in the same pattern of performance (e.g., ratably), the entire fee should be recognized ratably over the contract period; and If (1) the arrangement is for additional software products and provides for a specified price per copy and (2) an allocation of the fee cannot be made at the outset, revenue should be recognized as copies are made by the customer (or furnished to the customer, if the vendor is duplicating the software). Once the vendor has delivered the product master (or the first copy of all products covered by the arrangement), any licensing fees that were not previously recognized should be recognized. If in substance the arrangement is a subscription, the entire fee should be recognized ratably. This situation is discussed in section 5.3. The concept of allocating value to all elements, including those elements described as being provided only on a when-and-if-available basis, is one of the fundamental principles of the software revenue recognition rules. Determining what that value is, as well as providing the necessary evidence to justify that amount, has become one of the most controversial issues surrounding the application of the rules. SOP 97-2 introduced very narrow criteria for what constitutes the evidence that would be required if an arrangement were to be unbundled. If the prescribed level of evidence (defined as vendor-specific objective evidence ("VSOE") of fair value) is not available to the vendor, all revenue from the arrangement must be deferred (unless one of the exceptions described above exists or the residual method which is further discussed this Chapter can be applied). One of the topics covered by the AICPA Staff in its Technical Questions and Answers (Q&As) release on SOP 97-2 deals with the form of a multiple-element arrangement (TPA 5100.39). The AICPA Staff has concluded that "a group of contracts or agreements may be so closely related that they are, in effect, parts of a single arrangement." The Staff indicated that the following conditions (not all-inclusive) may also indicate that a group of contracts is really a multiple-element arrangement (i.e., the form of the arrangement is not the only indicator): All the contracts or agreements are negotiated or executed within the same, short time frame; The different elements are closely interrelated or interdependent in terms of design, technology, or function; www.pwcrevrec.com 49

The fee for one or more contracts or agreements is subject to a refund or forfeiture or other concession if one of the other contracts is not completed satisfactorily; One or more elements in one contract or agreement are essential to the functionality of an element in another contract; Payment terms under one contract or agreement coincide with performance criteria of another contract agreement; and The negotiations are conducted jointly with two or more parties (for example, from different divisions of the same company) to do what in essence is a single project. Questions and Answers Group of contracts considered a single arrangement Assume that on June 30 the Vendor and the Purchaser have been negotiating a contract that includes a product license and services which are essential to the functionality of the software. Both parts of the contract are being negotiated by the same teams. Agreement is reached on the terms of the licensing transaction on June 30, but agreement on the scope of the services isn't reached until July 5. The Purchaser issues a purchase order for the licensing transaction on June 30, which states that the scope of the services is to be defined. The customary business practice for the Vendor is to obtain a purchase order for all licensing transactions. Question: Is revenue recognition appropriate for the Vendor as of June 30? Answer: It is unlikely that revenue recognition would be appropriate as of June 30. Based on the facts of the example, the Vendor and Purchaser have completed negotiations on one element of a multiple-element transaction. As they did not complete negotiations on the other element until July 5, a completed evidence of arrangement for the entire arrangement needs to be completed before revenue recognition would be appropriate. 3.2 Vendor-specific objective evidence Paragraph 10 of SOP 97-2 describes two circumstances that provide acceptable vendor-specific objective evidence. VSOE of fair value is limited to the following: The price charged when the same element is sold separately; or For an element not yet being sold separately, a price established by management having the relevant authority; it must be probable that the price, once established, will not change before the separate introduction of the element into the marketplace. Observation: In situations where VSOE of fair value is determined by management for an element that is not yet being sold separately, the period of time until the element is expected to be sold separately should be relatively short. SOP 97-2 states that the separate prices in contracts may not be indicative of the fair value of the related elements. Therefore, AcSEC developed the concept of VSOE of fair value. The idea behind VSOE is that there are inherent differences between similar products that are offered by different vendors. 50 PricewaterhouseCoopers LLP

Consequently, although products may be similar, their fair values may be different. AcSEC concluded that the use of industry averages or competitor prices did not properly account for these differences and, therefore, only VSOE of fair value is acceptable. The fee from a software arrangement with multiple elements should be allocated to the various elements based on VSOE of fair value of those separate elements, regardless of the separate prices for each element stated within the contract. When VSOE of the fair value of the elements of a software arrangement is being determined, all of the factors that the vendor used in determining its pricing should be considered. For example, the vendor may base its pricing on factors such as the following: A combination of user fees, joined with a module or suite fee; The number of products delivered; The number of copies made (or to be made); The type or quantity of services being purchased from the vendor; The number of users; The type of customer (end user, reseller, etc.); and The volume of purchases made by/expected from the customer. Observation: List prices should not be misconstrued as being indicative of fair value. Many software vendors regularly offer customers discounts on list prices. We believe that by gathering historical pricing information over time, vendors will develop VSOE of fair value for each of their product offerings based on actual prices. The fair value of products may differ based on the type or size of a customer, the size of the purchase, or even the channel of distribution to that customer. Fair values may also be different for the same basic product sold in different territories around the world, due to environmental or marketing variables. In other words, there conceivably could be more than one fair value for a given product because of the variety of considerations that impact the pricing in an arrangement for that element. To the extent that a significant percentage of actual transaction pricing falls outside of a reasonable range, it may be difficult to determine VSOE. VSOE of fair value should be analyzed on an annual basis, unless there is a significant change in a company's business that may necessitate a more timely analysis. See discussion on determining VSOE of fair value of PCS and services later in this chapter. A vendor must determine if VSOE of fair value exists for each element at the outset of the contract, except in circumstances covered by SOP 98-9 (see below). If VSOE of fair value is not available, revenue must be deferred in accordance with the aforementioned guidance. If VSOE of fair value for all elements becomes available prior to the date that all deliverables are provided under the contract, the appropriate revenue recognition should be recorded for the delivered elements on the date that the VSOE of fair value becomes known. In its Q&As (TPA 5100.38), the AICPA Staff addressed the issue of whether VSOE of fair value may be established after the balance sheet date but before the issuance of the financial statements. The AICPA Staff determined that the establishment of VSOE of fair value after the balance sheet date represented a Type II subsequent event, as discussed in Professional Standards AU Section 560. Therefore, VSOE of fair value would not exist as of year-end, and revenue would be deferred in accordance with paragraph 12 of SOP 97-2. The authors of SOP 97-2 spent a significant amount of time determining what criteria should be used to establish the fair value of an element, and AcSEC debated the issue extensively. In the end, the strict definition noted above was adopted, and all others were rejected. It is noteworthy that the words "sold separately" apply to every element in the arrangement. Unless the vendor sells or licenses every element by itself, the "sold separately" criteria will never be met. As a consequence, if each element will not be or has not been sold or licensed by itself, VSOE of the fair value of the entire arrangement cannot be www.pwcrevrec.com 51

determined. A "with and without" approach was rejected by the authors of SOP 97-2, as was an approach to establish VSOE of fair value based on a defined penalty or fixed damages that would result if the additional element was not delivered. Neither of these potential situations was considered sufficient evidence to establish VSOE of the fair value of an element. Observation: The necessary evidence for VSOE of fair value required by SOP 97-2 generally involves a great deal of record keeping by a vendor. Vendors need to collect information based on product and on class of customer. Generally, vendors need to have a significant amount of sales for it to be proven that a class of customer has sufficient VSOE of fair value. In the case of a new company, this may mean that revenue will have to be deferred until a sufficient history is established to substantiate the fair value of the vendor's products. 3.2.1 Residual method As stated earlier, the narrow definition of VSOE created an implementation problem that has been hotly debated. After the release of SOP 97-2, significant concern was raised about the application of the limitations on what constitutes VSOE. Several examples that illustrate the limitations were brought to the attention of AcSEC. One of these examples highlighted a situation in which a software license is never sold without PCS, but PCS is sold without the license. Because the license is never sold separately, the requirements for VSOE of fair value cannot be met. Based on the guidance in SOP 97-2, all revenue would have to be deferred and recognized over the life of the PCS arrangement. Many people believed that this was an overly conservative pattern of revenue recognition and that this was not the intent of the authors of SOP 97-2. AcSEC did, however, approve SOP 98-9, which provides a limited exception to the full deferral of revenue that is required (pursuant to paragraph 12 of SOP 97-2) when VSOE of fair value is not available for all elements. The exception pertains to those software arrangements in which VSOE exists for the fair value of each of the undelivered elements (e.g., PCS). SOP 98-9 measures the amount of the arrangement fee allocated to the delivered elements based on the difference between the arrangement fee and the VSOE of the fair value of the undelivered elements. In practice this is sometimes referred to as the residual method. It should be noted that discounts offered in a contract could have a substantial effect on the allocation of the total fee to each element. In effect, the discount must be allocated to all elements in the transaction (one exception is made for specified upgrades further discussed in Chapter 5), assuming that VSOE of fair value can be determined for each element. For companies using the residual method under SOP 98-9, any discount will generally be allocated in full to the delivered elements. See Chapter 6 for further discussion of discounts. 3.2.2 Establishing VSOE of fair value VSOE of fair value may be established through two different approaches, where applicable: 1) Bell Shaped Curve Approach or 2) Stated Renewal Approach, both described in further detail below. In most instances, a vendor will use the Bell Shaped Curve Approach to establish VSOE of fair value. Typically, a vendor will sell a product or service at more than one stated price. The Bell Shaped Curve approach involves plotting actual prices charged/realized for the element when the element is sold separately against the frequency of those prices with the intent of determining a normal pricing pattern using statistically averaging. Such an analysis will produce a range of prices charged for recent, actual transactions, and VSOE of fair value is determined as a reasonable range as indicated by where the substantial portion of transactions fall within that range. Vendors may exclude outlier transactions that do not fall within a reasonable range in reaching this determination. 52 PricewaterhouseCoopers LLP

We believe that an acceptable application of this approach would be as follows: 1. Group the vendor's sales transactions into groups based on the type or size of a customer, the size of the purchase, or even the channel of distribution to that customer or other relevant groupings. 2. For each group, review the amount charged in recent transactions when the element was sold separately. In some cases, the vendor may apply a sampling approach to derive this information. 3. For each group, analyze the data obtained in step 2 to determine whether a substantial portion of the results fall within a reasonable range of prices that would represent VSOE of fair value. All relevant facts and circumstances must be considered in making this determination. If a vendor has established VSOE of fair value for an undelivered element, the revenue attributed to that element for which the contract price of the undelivered element does not fall within the VSOE-of-fair-value range (i.e., an outlier) should be based on VSOE of fair value. When VSOE of fair value for an undelivered element is represented by a reasonable range of prices, and the contractual price for the undelivered element falls below that range, the revenue allocated to that element can be based on either (1) the midpoint of the range, or (2) the lower limit of the range nearest to the contract price. This allocation is an accounting policy election and should be applied consistently to all of the vendor's arrangements, regardless of product or customer. By analogy to the example on VSOE and Refunds of Contractual Prices below, elements which are contractually priced above VSOE of fair value should not be adjusted as such an application could result in the premature recognition of contingent revenue. Another acceptable interpretation for establishing VSOE of fair value is the Stated Renewal Approach. Renewal rates in a contract can establish VSOE of fair value for PCS in a software arrangement only if both the PCS renewal rate and its term are each "substantive". Such a determination requires judgment. A PCS renewal rate simply stated in the customer contract should not be presumed to be fair value of PCS. When considering whether the rate is substantive, a vendor should consider whether a) the renewal rate is significantly below the vendor's normal pricing practices and b) the vendor's historical practice indicates that actual renewal rates charged will differ from the stated renewal rate in the related contract. When considering whether the renewal term is substantive, a vendor should consider the length of the initial PCS term in the contract as compared to the renewal PCS term. In its Q&As (TPA 5100.52 -.55), the AICPA Staff provided guidance on determining whether a renewal term is substantive. We believe when a vendor has established VSOE of fair value under a Bell Shaped Curve Approach and the Stated Renewal Approach in a multiple element arrangement, the vendor should determine which approach it will follow and should apply that approach consistently. However, in the absence of having VSOE of fair value under the approach elected, a vendor would utilize the alternative approach to establish VSOE of fair value, if available. Questions and Answers VSOE of the fair value of an undelivered element only (residual method) The Vendor offers an arrangement that includes a license for an accounting program and one year of PCS. The total fee for the arrangement is $115,000. The Vendor does not have VSOE of the fair value of the accounting program, as it is always licensed with PCS. The Vendor always sells renewal PCS for $15,000 and has sufficient evidence to support that price as a fair value. Question: What amount of revenue would the Vendor be able to recognize upon the delivery of the accounting program? www.pwcrevrec.com 53

Answer: SOP 98-9 provides a limited exception to restrictions on what constitutes VSOE. The Vendor knows the VSOE of the fair value of the undelivered element ($15,000) and has a total contract fee of $115,000. The revenue related to the accounting program ($100,000) can be derived through the residual method by limiting revenue recognition to the difference between the total arrangement consideration and the VSOE of fair value of the undelivered element ($115,000 $15,000 = $100,000) and recorded upon the element's delivery, assuming that all other revenue recognition criteria have been met. Products always sold in combination with other products The Vendor licenses a variety of software products. None of the products is ever licensed separately. However, each product is licensed in many different combinations with the other products. The prices for each of the individual products are always stated separately in the software arrangement, and the stated prices are derived from negotiations with customers and represent a discount on the Vendor's published prices. The Vendor can demonstrate, based on historical data, that the prices stated in its software arrangements for each individual product fall within a reasonable range of prices for that product, regardless of the combination of products included in the arrangement. The Vendor enters into an agreement with the Customer to deliver four separate products for a fee of $500,000. The prices stated in the agreement for the products fall within the Vendor's reasonable price range for each product. Two of the four products are delivered at the time that the agreement is finalized. However, the remaining two products are not delivered right away, nor is a delivery date specified in the arrangement. Question: Assuming that all of the other criteria for revenue recognition have been met, can the Vendor allocate the fee based on the prices stated in the agreement and, therefore, recognize revenue on the two delivered elements based on their allocated fees? Answer: Because SOP 97-2 defines VSOE of fair value, which requires that each element be sold separately, it would be unlikely that the Vendor would be able to establish a verifiable fact pattern to support the "reasonable range" described in the example. A great deal of judgment will be required in determining whether VSOE of fair value for each element exists. If it is concluded that the evidence is insufficient, all revenue from the arrangement should be deferred until sufficient vendor specific objective evidence does exist for the fair value of the undelivered products or all four products are delivered to the Customer. "Group" VSOE Consider the facts in the example above. However, the Vendor sells Product A separately, but always sells Product B with Product C. Vendor enters into a contract to sell Products A, B and C. Product A will be delivered immediately on 12/1/ X2 and Products B and C will be delivered on 2/1/X3. VSOE exists for Product A, but not for Products B and C separately. Question: Can any revenue be recognized upon delivery of Product A? Answer: Yes. Although the Vendor never sells Product B and C separately and therefore VSOE of fair value does not exist for each product, the Vendor does have VSOE of fair value for the combined B and C offering, as B and C are always sold together. In this case, the Vendor can consider the B and C combination as 54 PricewaterhouseCoopers LLP

one element instead of two. The Vendor would allocate the entire arrangement fee based upon the relative VSOE of fair value for Product A and the Product B and C combination and record the pro rata amount of revenue related to Product A upon delivery of Product A. Observation: An additional example illustrating the application of Group VSOE related to Post Contract Support is discussed further below (section 3.4). VSOE and refunds of contractual prices The Vendor enters into a multiple element arrangement with a customer for a perpetual license to software and receives one year of PCS for a combined fee of $100,000. Contractually the fee has been allocated between the elements as $760,000 for the license and $240,000 for the PCS. The software is delivered at the time of the signing of the arrangement and payment of the fee is received in 30 days. The provisions of the arrangement indicate that the customer may terminate PCS at any point during the first year and receive a pro-rata refund for the PCS services that were not delivered. The Vendor has concluded that it does not have VSOE of fair value for the license, but that VSOE of fair value for similar PCS services is $180,000. Question: What is the appropriate revenue recognition for this transaction? Answer: In conformity with SOP 97-2 (paragraph 12), the Vendor can utilize the residual allocation method and defer the fair value of the undelivered element. However, paragraph 14 of SOP 97-2 states: "No portion of the fee (including amounts otherwise allocated to delivered elements) meets the criterion of collectibility if the portion of the fee allocable to delivered elements is subject to forfeiture, refund, or other concession if any of the undelivered elements are not delivered." Thus, although the VSOE of fair value for the PCS services is $180,000, the Vendor's obligation to refund up to $240,000 for the portion of the PCS service that is not delivered, results in the Vendor deferring $240,000 as contingent revenue pursuant to paragraph 14, and recognizing the residual of $760,000 as revenue upon delivery of the software (presuming all other revenue recognizing criteria are met.) The $240,000 allocated to the PCS would get recognized ratably as PCS is delivered. 3.3 Postcontract customer support Postcontract customer support (PCS) is an inherent element in virtually every software arrangement other than consumer "shrink wrap" products. PCS may be a separate element, bundled with other products and services or implicitly included in an arrangement. Regardless of whether PCS is separately stated in a contract, every software arrangement should be evaluated for the potential impact of PCS and, if it proves to be part of an arrangement, it should be considered a separate element in determining revenue recognition. The glossary of SOP 97-2 defines PCS as follows: The right to receive services (other than those separately accounted for as described in paragraphs 65 and 66 of the SOP) or unspecified product upgrades/enhancements, or both, offered to users or resellers, after the software license period begins, or after another time as provided for by the PCS arrangement. Unspecified upgrades/ enhancements are PCS only if they are offered on a when-and-if-available basis. PCS does not include the following: Installation or other services directly related to the initial license of the software; www.pwcrevrec.com 55

Specified upgrade rights; Rights to additional software products; Bug fixes to maintain compliance with product specifications. TPA 5100.43 states that such costs should be accounted for as warranty costs in accordance with SFAS No. 5; and Intellectual property infringement indemnifications. PCS may be included in the license fee or offered separately. The right to receive services and unspecified upgrades/enhancements provided under PCS is generally described by the PCS arrangement. Typical arrangements include services, such as telephone support and unspecified upgrades/enhancements when and if developed by the vendor during the period in which the PCS is provided. PCS arrangements include patterns of providing services or unspecified upgrades/enhancements to users or resellers, although the arrangements may not be explicitly evidenced by a written contract signed by the vendor and the customer. Under SOP 97-2, rights to unspecified upgrades and enhancements that are offered on a when-and-if-available basis are considered PCS. Upgrades and enhancements are defined in SOP 97-2 as follows: An improvement to an existing product that is intended to extend the life or improve significantly the marketability of the original product through added functionality, enhanced performance, or both. The terms upgrade and enhancement are used interchangeably to describe improvements to software products; however, in different segments of the software industry, those terms may connote different levels of packaging or improvements. This definition does not include platform-transfer rights. The qualifier when-and-if-available is broadly used to refer to a variety of contractual commitments. In the case of unspecified upgrades and enhancements, the qualifier serves to emphasize that the upgrade or enhancement would not have been known or expected to be delivered at the time that the right was granted. SOP 97-2 makes it clear that PCS may result from business practices and need not be specifically stated in a contract. It also addresses PCS arrangements with resellers (discussed in Chapter 7). Additionally, the concept of VSOE of fair value as it pertains to the allocation of the fee among the elements, including PCS, has resulted in a number of implementation issues. We have highlighted these, and each are discussed in further detail in this chapter below. 3.3.1 General guidelines for recognition of PCS revenue Fees related to PCS, whether sold separately (e.g., renewal-period PCS) or as an element of a multipleelement arrangement, should generally be recognized as revenue ratably over the term of the PCS arrangement. The PCS obligation is met (1) by the vendor's delivery of the services, upgrades, and enhancements or by its fulfilling other obligations under the arrangement, or (2) by the mere passage of time. It is usually not practical to estimate the timing of the costs for delivering PCS over the term of the arrangement. As such, SOP 97-2 concludes that fees should generally be recognized as revenue on a straight-line basis over the term of the arrangement. In some relatively rare situations, the costs of fulfilling the PCS obligations may be incurred in such a manner that the use of the straight-line basis does not approximate the timing of when the software vendor actually incurs the costs. In those situations, revenue should be recognized on a pro rata basis, based on when the amounts are expected to be charged to expense. The nature of PCS services that are provided will often vary, depending on the nature of the software, the method of delivery, or the complexity of the software product. Consequently, there are certain exceptions to the above guidance on revenue recognition for PCS. These exceptions are discussed below. 56 PricewaterhouseCoopers LLP

Observation: The rules for accounting for PCS in SOP 97-2, as originally issued, appear to contemplate PCS in arrangements involving perpetual software licenses. However, term licenses have become increasingly common in the software industry. Term licenses involve a license to use the software for a specific period, generally one to five years. Because of the shorter-term nature of these arrangements versus perpetual licenses, it is common for PCS for all or part of the license term to be bundled together with the term license. Because the vendor nearly always sells the term license and the PCS together, issues arise as to how, and whether, VSOE of fair value of the PCS exists. PCS considerations particular to term licenses are discussed in more detail in section 3.4 of this chapter. 3.3.2 VSOE of fair value for PCS and other undelivered elements does not exist SOP 97-2 requires that the fee under the software arrangement be allocated to the various elements based on VSOE of the fair value of each element. However, VSOE of fair value may not always be determinable for PCS, because of the vendor's business practices. Based on the general framework of SOP 97-2, it might be concluded that in those situations, vendors would be required to defer the revenue associated with the arrangement until the PCS is delivered; that is, until the end of the PCS period. However, paragraphs 12 and 58 of SOP 97-2 provide that if VSOE of fair value does not exist and PCS is the only undelivered element, the entire fee under the arrangement should be recognized ratably over: The contractual PCS period (for those arrangements with explicit rights to PCS); or The period during which PCS is expected to be provided (for those arrangements with implicit rights to PCS). Observation: There are situations in which, for example, VSOE of fair value exists for one-year PCS arrangements but not for two-year arrangements. TPA 5100.52 states that, provided the PCS renewal rates are substantive (please see paragraph 3.2.2 and 3.4.2 for additional information regarding substantive renewal rates), the value of a one-year PCS arrangement can be multiplied by two to determine the VSOE of the fair value of a two-year bundled PCS arrangement. However, this is possible only when the services that are to be provided in both arrangements are substantially the same. Just because a PCS renewal rate is not specified in an arrangement does not mean that there is not VSOE of fair value of PCS. One must also look to renewal rates being offered to existing similarly situated holders of licenses of a similar nature as a source of VSOE of fair value. The existence of VSOE of fair value of PCS would then require up-front revenue recognition for license revenue, assuming all other SOP 97-2 revenue recognition criteria have been met. The wording of paragraphs 12 and 58 requires recognition of an arrangement fee ratably over the PCS period when PCS is the only undelivered element. Paragraph 12 also provides a similar exception for services that do not involve significant production, modification or customization of software, when these services are the only undelivered element. The question often arises in practice as to whether the fee in an arrangement including both undelivered PCS and services (that do not involve significant production, modification or customization of software), in which the PCS and services would otherwise qualify for the paragraph 12 exception separately if each were the only undelivered element, can be combined and recognized ratably over the PCS/services term. SOP 97-2 requires the entire fee be deferred until either the services or PCS becomes the only remaining undelivered element (or when both are delivered). At the point where only one deliverable remains, the revenue would be recognized over the remaining service period. www.pwcrevrec.com 57

Observation: There may be instances where the earnings process of the services and PCS would require ratable recognition and the services/pcs offering is better viewed as one element, thereby meeting the requirements of paragraphs 12 and 58 of SOP 97-2. The Questions and Answers section below provided examples of these situations. 3.3.3 PCS revenue is recognized with the initial license fee Paragraph 59 of SOP 97-2 states that if certain criteria are met, PCS revenue may be recognized simultaneously with the initial license fee when the software is delivered. If the criteria are met, all of the estimated costs of providing the services, including upgrades and enhancements, must be accrued at that time. All of the following criteria set forth in paragraph 59 of SOP 97-2 must be met: The PCS fee is included with the initial licensing fee. The PCS included with the initial license is for one year or less. The estimated cost of providing PCS during the arrangement is insignificant. Unspecified upgrades/enhancements offered during PCS arrangements historically have been and are expected to continue to be minimal and infrequent. The last criterion requires that the software vendor demonstrate not only that upgrades and enhancements have been minimal and infrequent in the past, but also that they will continue to be so. Additionally, "minimal" and "infrequent" are characteristics that are subjectively determined, and thus the definition of those terms may vary from vendor to vendor. We believe that it would be rare that this criterion would be met in an arrangement in which upgrades and enhancements are provided. 3.3.4 Distinguishing between warranty obligations and PCS Generally, PCS services include both customer support and the right to unspecified upgrades, updates, and enhancements on a when-and-if-available basis. In some circumstances, terms of a software license may only provide a product warranty of the type within the scope of FAS 5, Accounting for Contingencies, as discussed in TPA 5100.43 ("Corrections of errors in computer software [bug fixes]"). In those circumstances, the guidance in FAS 5 should be followed with respect to the recognition of costs associated with the warranty. However, if PCS, as defined in SOP 97-2, is being provided, it must be accounted for as PCS, regardless of whether it is characterized as warranty in the arrangement with the customer. If a vendor commits, either explicitly or implicitly, to provide unspecified upgrades and enhancements in a software arrangement such that the software product will be modified to comply with any changes in law or regulation when and if such changes occur (e.g., to comply with new tax rates), the commitment is a PCS arrangement. The vendor has granted the customer rights to receive unspecified upgrades or enhancements to the software on a when-and-if available basis which extends the life of the licensed software and significantly increases its marketability. If the software is not updated, it would become obsolete whenever a significant change occurs. 58 PricewaterhouseCoopers LLP

Questions and Answers Revenue recognition for a software arrangement where there are multiple undelivered service elements for which VSOE of fair value is not available The Vendor enters into an arrangement to provide a perpetual license to a software product, one year of PCS, and services that are to be provided within the first year from the delivery of the software product. The services are not considered to be essential to the functionality of any other element of the transaction, and do not involve significant production, modification, or customization of the software. Question: The Vendor does not have VSOE of fair value for either the PCS, or the service element included the arrangement. How should the Vendor recognize the revenue for this arrangement? Answer: Under the guidance provided under paragraph 12 of SOP 97-2, the Vendor should defer the revenue until there is only one undelivered element remaining, and at that point, recognize the fee over the period of the last to-be-delivered element. On the other hand, if both the non-essential services and the PCS ("combined services") have the same revenue attribution, e.g., expected to be earned ratably over the same term, then once both the services have commenced, we believe it is acceptable to recognize the entire arrangement consideration over the period following the pattern that the combined services are expected to be performed. This method is only appropriate in situations where the non-essential services are expected to be provided in the same pattern of performance as PCS, or are delivered earlier in the contract in order to eliminate the risk of premature revenue recognition for either of the two elements. For example, if the two services were performed over the same period, but, the majority of one service was performed towards the end of the term of the arrangement, the combined services approach may NOT be appropriate. In that case, if revenue was recognized ratably over the period, premature revenue recognition could result for the service element performed toward the end, which is inconsistent with SOP 97-2's underlying concepts. However, if the two services were performed over the same period, but, the majority of one of them occurred toward the beginning of the period, the combined services approach may still be appropriate since recognizing revenue ratably over the entire period in that case would not result in premature revenue recognition for either service. If revenue is being deferred until there is one remaining undelivered element, is it appropriate to do a cumulative catch entry at the point that only one element is remaining The Vendor enters into an arrangement to provide a perpetual license to a software, PCS, and services for total consideration of $150,000. The software was delivered on 1/1/01, the PCS service period is from 1/1/01-12/31/01, and the right to utilize the services is only valid from 1/1/01 through 9/1/01. The services are not considered to be essential to the functionality of any other element of the transaction, and do not involve significant production, modification, or customization of the software. Question: The Vendor does not have VSOE of fair value for either the PCS, or the service element included in the arrangement, and thus, cannot separate the elements in the arrangement. The customer utilizes the nonessential services by 4/1/01. What is the appropriate revenue recognition model for this arrangement? www.pwcrevrec.com 59

Answer: Under the guidance provided under paragraph 12 of SOP 97-2, the Company should defer the revenue until there is only one undelivered element remaining. Once the customer utilizes the services by 4/1/01, at that point the only undelivered element is PCS and the Company should start recognizing the revenue at that point. However, since the PCS and the services were being provided from 1/1/01, the Vendor could apply the residual method by calculating the amount allocable for the undelivered services, and recognize the remaining as revenue. In other words, on 4/1/01, the Company has a remaining obligation to provide 9 months of PCS services, $112,500 ($150,000*9/12) should be recorded as deferred revenue, and the remaining $37,500 could be recognized as revenue. Extended warranty on hardware with embedded software that is more than incidental A Vendor enters into a multiple element arrangement with a customer (who is not a reseller) to provide a hardware storage system that includes: embedded software that is more than incidental to the product as a whole, bug fixes on the software and a standard warranty that includes 24/7 uptime with a four hour warranty claim response time. In addition, Company D offers a premium warranty that includes 24/7 uptime with a 2 hour response time. The Vendor accounts for the storage system product revenue in accordance with SOP 97-2. As the Vendor is only providing bug fixes to the software (that are necessary to maintain compliance with the products published specifications) these bug fixes should be accounted for in accordance with FAS 5, Accounting for Contingencies (see TPA 5100.53, Correction of Errors in Computer Software (bug fixes)). Question: What is the proper accounting treatment for the premium hardware warranty service which provides a faster on-site response time? Answer: FTB 90-1, Accounting for Separately Priced Extended Warranty and Product Maintenance Contracts, paragraph 2 defines an extended warranty as an agreement to provide warranty protection in addition to the scope of coverage of the original warranty. When the customer purchases the premium hardware warranty service, they are purchasing an extended warranty. Revenue from separately priced extended hardware warranties should be deferred and recognized on a straight-line basis over the life of the extended warranty service in accordance with FTB 90-1, paragraph 3. 3.4 Determining VSOE of fair value for PCS arrangements Determining when there is VSOE of fair value of a PCS arrangement raises several issues. Paragraph 57 of SOP 97-2 states that the fair value of PCS should be determined by reference to the price the customer will be required to pay when it is sold separately (that is, the renewal rate). Accordingly, VSOE of the fair value of PCS is generally based on renewal rates for PCS, which are to be charged once the initial PCS period contained in the original licensing arrangement expires. If a vendor offers PCS rates that are lower than the fully deployed PCS renewal rates, a discount is embedded in the transaction. Several examples of the impact of such discounts are provided in Chapter 6. PCS generally includes both (1) customer support (provided either by phone or electronically) and (2) the right to unspecified upgrades, updates and enhancements on a when-and-if-available basis. In some PCS arrangements, a customer may actually be receiving just one of these two types of benefits. This is certainly the case when a customer is entitled to receive, or the vendor's business practice is to provide, upgrades, updates, and enhancements during an implementation period. The customer may not be willing to pay for PCS until the implementation is completed, because no customer support will be received (nor is it necessary) until the software is installed. Some have suggested that the 60 PricewaterhouseCoopers LLP

aforementioned two benefits offered under a PCS arrangement are of equal value to a customer. Therefore, the VSOE of the fair value of updates, upgrades, and enhancements should be only half of the rate customers pay for typical PCS, which includes customer support. Correspondingly, if customer support alone is provided, the VSOE of the fair value of the support should be equal to only half of the normal PCS rate. However, because few vendors sell PCS with customer support alone or with only the right to unspecified upgrades, updates and enhancements, it is unlikely that in determining the VSOE of the fair value of the PCS a vendor will be able to use anything other than the maximum PCS rate that is charged to customers. Dividing the value of a PCS contract between the two types of benefits can be supported only if a vendor actually separately sells each of the benefits, instead of combining them under a PCS arrangement. 3.4.1 Fair value of PCS in a short-term time-based license TPA 5100.53 addresses arrangements that include time-based software licenses and PCS services wherein the duration of the time-based software license is so short that a renewal rate or fee for the PCS services does not represent VSOE of the fair value of the bundled PCS. For example, assume a vendor sells a multiple-element software arrangement consisting of a 12-month time-based software license that includes six months of bundled PCS services for a total fee of $100,000. The specified renewal rate for a six-month PCS contract is $5,000. TPA 5100.53 states unequivocally that for time-based software licenses with a duration of one year or less, the fair value of the bundled PCS services cannot be reliably determined. We understand that the AICPA reached this conclusion by reasoning that the short time frame during which any unspecified upgrade provided under the PCS agreement can be used by the licensee creates a circumstance whereby one cannot objectively demonstrate the VSOE of fair value of the licensee's right to unspecified upgrades. Accordingly, the total arrangement fee would be recognized ratably over the PCS period in accordance with paragraph 12 of SOP 97-2. 3.4.2 Fair value of PCS in a multi-year time-based license TPA 5100.54 addresses arrangements for multi-year time-based software licenses that may include (1) initial (bundled) postcontract customer support (PCS) services for only a portion of the software license's term (for example, a five-year time-based software license that includes initial PCS services for one year) and (2) a renewal rate for PCS for an additional year(s) within the time-based license period. In this case, the issue is again whether VSOE of the fair value for the PCS exists. In such situations the renewal rate constitutes VSOE of the fair value of the PCS provided that the renewal rate is substantive. Judgment is required when determining if the PCS renewal rate and term are "substantive". One primary factor to consider is if the stated renewal rate is determined by the vendor's normal pricing practice. If it is, then the stated renewal rate is an acceptable model to determine VSOE of fair value of PCS. Other factors when evaluating if the renewal rate is substantive is the percentage of PCS fees to the total license fees of the arrangement or companies can stratify their software arrangement population by class of customers, geography, different levels of PCS (platinum, gold), or other attributes. It is important to note that whichever method a Vendor uses to determine the renewal rate for PCS should be applied consistently across all of their software arrangements. The TPA provides the following examples of circumstances in which the renewal rate is not substantive: The period of initial (bundled) PCS services is relatively long compared to the term of the software license (for example, four years of initial PCS services in connection with a five-year time-based software license, with a specified PCS renewal rate for the remaining year). www.pwcrevrec.com 61

The aggregate PCS renewal term is less than the initial (bundled) PCS period (for example, a five-year time-based software license with three-year bundled PCS and two annual PCS renewals). A PCS renewal rate that is significantly below the vendor's normal pricing practices in combination with a time-based software license that is for a relatively short period (for example, a two-year time-based software license that includes initial [bundled] PCS for one year for a total arrangement fee of $1,000,000 and that stipulates a PCS renewal rate for the second year of $25,000 when the vendor's normal pricing practices suggest higher renewal rates). 3.4.3 Fair value of PCS in perpetual and multi-year time based licenses TPA 5100.68 addresses the issue of using VSOE for PCS sold with a perpetual license as a "surrogate" for VSOE for PCS in a term license. Assume a vendor currently offers licenses for the same product on both a perpetual basis and on a multi-year term license basis. Pricing of the licenses reflects the duration of the license rights. VSOE of fair value exists for PCS services in the perpetual licenses. For the multiyear time-based licenses, PCS services for the entire license term are included (bundled) in the license fee and there is no renewal rate as the time-based license rights are coterminous with the PCS service period. SOP 97-2 states that VSOE of fair value is provided by the price charged when the same element is sold separately. PCS services for a perpetual license and PCS services for a multi-year time-based license are two different elements. Though the same unspecified product upgrades or enhancements may be provided under each PCS arrangement, the time period during which the software vendor's customer has the right to use such upgrades or enhancements differs based on the terms of the underlying licenses. In this case, because PCS services are bundled for the entire term of the multi-year time-based license, those PCS services will never be sold separately. The TPA does list rare circumstances in which the PCS renewal terms in a perpetual license provide VSOE of the fair value of the PCS services element included (bundled) in the multi-year time-based software arrangement. Those circumstances are when (1) the term of the multi-year time-based software arrangement is substantially the same as the estimated economic life of the software product and enhancements during that term and (2) the fees charged for the perpetual (including fees from the assumed renewal of PCS for the estimated economic life of the software) and multi-year time-based licenses are substantially the same. Observation: Except in the limited circumstances described in the previous paragraph, VSOE of the fair value of PCS sold with perpetual licenses cannot be used as a "surrogate" for VSOE of fair value for PCS in a term license. 3.4.4 Coterminous PCS Time based or perpetual software arrangements sometimes contain contractually stated annual PCS renewal rates and a requirement that the licensee be current with PCS in order to maintain its rights to use the software. We understand vendors may include such a requirement as a means of maximizing the occurrence of PCS renewals. This language essentially transforms a perpetual or multi-year time-based license into an annual license. As a result, such a clause dramatically impacts how revenue is recognized. In this arrangement the customer is not making the decision to only renew PCS, but is in fact making a decision to renew both PCS and the software license. Since the customer is not renewing PCS alone, the renewal is not considered a PCS renewal rate (that is, PCS being sold separately). Accordingly VSOE of fair value of PCS is not established by reference to that renewal rate. By reference to TPA 5100.53 and by the fact that VSOE of fair value for PCS does not exist, the fee should be recognized ratably over the PCS period. Any up-front fee received in the first year would represent a premium over 62 PricewaterhouseCoopers LLP

any other year (that is, the years being renewed are at a discount). If significant and incremental (as discussed in TPA 5100.50), the premium would be deferred and recognized over the expected discount period in accordance with the discount guidelines discussed in Chapter 6. 3.4.5 Fair value of PCS with a consistent renewal percentage but varying renewal dollar amounts An issue arises as to whether the existence of varying dollar amounts of PCS renewal fees for the same software product indicates an absence of VSOE of the fair value for the PCS or the possible presence of discounts. For example, assume a vendor charges Customer A $100,000 for a software license with a PCS renewal rate of 15% of the license fee while charging Customer B $150,000 for the same software license with a PCS renewal rate of 15% of the license fee. This example comes from TPA 5100.55, which states that in this case, as long as the PCS renewal rate expressed as a consistent percentage of the stipulated license fee for customers is substantive, that PCS renewal rate would be the VSOE of the fair value of PCS. 3.4.6 PCS arrangements involving a maximum charge In today's technology-driven business environment, more and more companies are implementing software packages that are integrated into every facet of a business. These packages are commonly referred to as being "enterprise-wide software." In many cases, enterprise-wide software is licensed based on the number of users. PCS frequently is part of a multiple-element arrangement and is also sold based on the number of users. A customary business practice that has evolved due to the size of the fees involved in these arrangements has come to be known as "capped maintenance" or "capped PCS." Customers have required vendors to limit the amount of additional PCS fees charged as more users are added, under the theory that each additional user does not actually add incremental costs to the vendor's expenses. Determining VSOE of fair value in these situations may be difficult. See the Question and Answers section below for examples of these situations. 3.4.7 PCS renewals based upon users deployed TPA 5100.75 addresses arrangements that include a perpetual license with a fixed PCS fee during a three-year unlimited deployment period but optional PCS for year four and thereafter based on the ultimate number of copies of software deployed. In this case, VSOE is not established and the entire fee should be recognized ratably over the three-year deployment period. However, if the vendor could demonstrate that the renewal rate in year four and thereafter is more likely than not to approximate or be less than the amount charged in year two and three, VSOE would be established based on the pricing during the unlimited deployment period. For example, assume a vendor offers a perpetual license to an end-user customer for a software product with PCS bundled for the initial year. The initial fee is $1,150,000. The end-user customer is entitled to deploy an unlimited number of copies of the licensed software product for a three-year period. During the three-year unlimited deployment period, the end-user customer has the option to renew PCS annually for years two and three for a stipulated fee of 15% of the stated license fee ($1M), which is $150,000 per year. After the expiration of the three-year unlimited deployment period, the end-user customer is required to pay additional license and PCS fees if it deploys additional copies of the software product. The optional PCS fee for year four and annually thereafter is based on the ultimate number of copies of the software product deployed by the end-user customer at the end of the three-year unlimited deployment period. TPA 5100.75 states that since there are two different pricing methodologies for PCS, there is no basis for determining which pricing methodology produces the appropriate VSOE of fair value www.pwcrevrec.com 63

of the PCS bundled in year one and offered in years two and three. Accordingly, the vendor should recognize the entire arrangement fee ($1,450,000) ratably over the three-year deployment period. If the customer does not renew PCS in year two or year three, the vendor should recognize the remaining deferred revenue at the time PCS is no longer being provided. TPA 5100.75 also states that if sufficient objective evidence demonstrated that the renewal rate in year four and thereafter is more likely than not to approximate or be less than the amount charged in years two and three, the annual PCS renewal rates stipulated for years two and three would constitute VSOE of fair value of PCS. See TPA 5100.75 for further guidance. 3.4.8 Fair value of PCS with usage-based fees TPA 5100.76 addresses arrangements that include contingent usage-based fees. Usage-based fees are generally fees in excess of any up front license fee based on the frequency that the licensee uses the software. If usage-based fees are not paid timely, the licensee's perpetual license to use the software is generally vacated and there is no continuing obligation to provide PCS. In arrangements where VSOE for PCS is determinable, the addition of usage-based fees will not impact the accounting for the license or the PCS. The usage-based fees would then be recognized when reliable estimates can be made of the actual usage. In arrangements where VSOE of PCS is not determinable (or when PCS is included in the usage-based fee), the initial license fee should be recognized ratably over the period the vendor expects to provide PCS since there is no contractual PCS period. In arrangements where the usage-based fee represents payment for both the perpetual license and PCS, revenue would be recognized when reliable estimates can be made of the actual usage. The above arrangements all assume the software functionality is only used in the processing of activity that generates the usagebased fee. See TPA 5100.76 for further guidance. Questions and Answers VSOE of fair value for PCS without customer support does not exist The Vendor licenses a software package to the Customer. The software package requires that the Customer be responsible for installation, during which the Vendor will provide upgrades but no customer support. The Vendor's typical PCS arrangement provides customer support, as well as upgrades, and VSOE of fair value exists for the typical PCS arrangement and for the license. Question: If the Vendor does not separately sell PCS without customer support, is the Vendor required or able to use the VSOE of the fair value of a typical PCS arrangement as VSOE of the fair value of the PCS that provides upgrades only? Answer: We believe that even though VSOE of fair value does not exist for the PCS that does not provide customer support, the Vendor can use the VSOE of the fair value of a typical PCS arrangement in determining the appropriate amount of revenue to defer. We do not believe that the Vendor could sustain a position that only a portion of the fair value of a typical PCS arrangement represented VSOE of the fair value of the PCS that does not provide customer support. 64 PricewaterhouseCoopers LLP

Coterminous PCS The Vendor customarily offers its customers the following options to license its proprietary software product: 1. License software for a three year term: In this arrangement, the customer also always gets PCS during the three year term. The customer has no right to opt out of PCS. The customer can renew the license for another three year term and PCS is automatically renewed for the same term (e.g., in the contract there is a stated renewal rate of $300,000 for a new three year term). The right to use the software is coterminous with the right to PCS. 2. License software for a three-year term where there is one year of PCS bundled with an option to renew the PCS service for each of the remaining two years of the license term. The annual renewal rate for the PCS for each of years 2 and 3 is $45,000. The Vendor enters into an arrangement with a customer where for an up-front $320,000 fee, the customer receives a three year term license, as well as 10 days of training (VSOE of fair value for training is $2,000 per day of training). The training is delivered at various dates over the three year term. Question: What is the accounting for the multiple element software arrangement with the customer where the license and PCS are coterminous? Answer: Since PCS services relative to this software are sold separately in other arrangements (Option 2 above) it may be difficult to sustain an argument that the coterminous license and PCS in this arrangement is one element. However, pursuant to TPA 5100.68, the renewal terms in those transactions where the PCS service is only bundled for a portion of the license term may provide VSOE of fair value of the PCS services. The Vendor would need to determine if the renewal rate and term are substantive pursuant to the guidance in TPA 5100.54. If the Vendor can establish VSOE of fair value of the PCS services, then the fair value of the PCS services and the training days would be deferred and the residual would be recognized when the software is delivered, assuming that all other revenue recognition criteria are met. For example, the PCS renewal rate in years 2 and 3 of the three year term license in option 2 above may provide VSOE of fair value for the three years of PCS bundled with the three year term license in option 1 above (i.e., one year renewal multiplied by three). Accordingly, the Vendor would defer $135,000 for the bundled PCS ($45,000 x 3) and $20,000 for the training days ($2,000 x 10), and the residual ($165,000) would be recognized when the software is delivered, assuming that all other revenue recognition criteria are met. It should be noted that the renewal rate in Option 2 would not provide VSOE of fair value for the PCS bundled with a one year term license. Coterminous PCS and other elements Assume the same facts as the above example, except that the Vendor never sells PCS on a standalone basis (i.e. option 2 is not offered) Question: What is the revenue recognition related to the license, PCS, and training? Answer: There are two acceptable views of how revenue should be recognized with respect to this arrangement. www.pwcrevrec.com 65

View A: There are three deliverables (software license, PCS services, and 10 days of training). The undelivered elements are PCS and the training days. There is VSOE of fair value for the undelivered training days; however, there is no VSOE of FV for the PCS services, as the PCS is never sold separately. The first paragraph in the Reply of TPA 5100.68, states, "SOP 97-2 states that VSOE of fair value is provided by the price charged when the same element is sold separately. Because PCS services are bundled for the entire term of the multi-year time-based license, those PCS services are not sold separately." Consequently, the Vendor would not have VSOE of fair value of the PCS services. o Pursuant to paragraph 12 of SOP 97-2, as the Vendor does not have VSOE of fair value for all of the undelivered elements, all revenue from the arrangement should be deferred until all of the training days are delivered and the only remaining undelivered element is the PCS service, at which point the arrangement consideration should be recognized ratably over the PCS term. View B: There are two deliverables: (combined software license/pcs services, 10 days of training). In this fact pattern, the license to the software is always sold coterminous with the PCS services. The arrangements have renewal terms for the combined license/pcs services ($300,000) which provide VSOE of fair value for the single element (i.e., license/pcs). The Vendor also has VSOE of fair value for the undelivered days of training. o Under View B, the Vendor would allocate the arrangement consideration ($320,000) between the combined software license/pcs services ($300,000) and training ($20,000). It would recognize the amount allocated to the combined software license/pcs element ratably over the 3 year term, commencing with the delivery of the software and recognize the amount allocated to the days of training as the training is delivered. o o Another way that View B is often defended is by describing the same three elements as View A, however, "Group" VSOE of FV exists for the software license and PCS services which are sold together on a coterminous basis. In this particular fact pattern, we would support either View A or View B. Note that in this fact set, the Vendor only offers the software through a term license together with coterminous PCS, so it would not be inappropriate to consider the software license and coterminous PCS services to be one element, as described in View B. Additionally, we would support the Group VSOE argument. PCS renewal rate adjusted for an independently established inflation measure A Vendor provides PCS for its products and the contractually stated renewal rate charged for PCS is 15% of the contractually stated license fee (net license fee), adjustable by an independently determined inflation factor, such as CPI. Question: Presuming that the Vendor has established that the 15% renewal rate and related term are substantive, would a renewal rate with an adjustment tied to an independently established inflation measure be acceptable in establishing VSOE for fair value of PCS? Answer: Generally yes. The potential adjustments to the PCS renewal rate based upon an independently established inflation index would not impact the Company's ability to establish VSOE of fair value of the PCS. In reaching this conclusion, the guidance provided in FAS 13, Accounting for Leases, was considered which indicates that rental adjustments to lease payments based on changes in an index, such as the CPI, should be excluded from minimum lease payments and therefore not considered when determining lease classification. Similar to excluding rental increases based on changes in an index, such as the CPI, from minimum lease payments under FAS 13, by analogy it is also appropriate to exclude the inflation factor increases from the consideration of VSOE of fair value. Therefore, the contractually stated renewal rate would serve as VSOE of fair value in accordance with paragraph 57 of SOP 97-2 provided the rate and associated term were deemed substantive. 66 PricewaterhouseCoopers LLP

Observation: The appropriateness of the measure of inflation used should consider the individual facts and circumstances. The CPI factor published by the U.S. Department of Labor may not be the most appropriate measure of inflation in all circumstances. The measure of inflation used should be an independent well established and accepted measure. Capped PCS arrangement with a maximum number of seats The Vendor licenses an enterprise-wide software package to the Customer. The arrangement calls for the Vendor to install 1,000 seats for a fee of $1,000,000 (or $1,000 per seat). The arrangement also calls for the Vendor to provide PCS services for a fee of 15% of the per-seat license fee, per year, for two years. Both the per-seat license fee and the PCS fee stated above are the fair values, which are supported by VSOE. Question: Assume that the arrangement also allows the Customer to purchase up to 1,000 additional seats for $1,000 per seat. The fee for PCS services related to the additional seats remains at 15% of the per-seat license fee, unless the additional 1,000 seats are licensed by the end of the first year, in which case the PCS fee for the subsequent year will be fixed at $200,000 for all 2,000 seats. How should revenue be recognized under the arrangement? Answer: This arrangement has a potential discount of $100,000 (2,000 seats x $150 [15% of $1,000 per-seat price] $200,000 maximum PCS fee) that needs to be allocated to all elements of the arrangement (licenses and PCS). The potential discount related to the licenses would be allocated as follows: Maximum Allocation of Contract VSOE of Fair Percentage of Potential Allocated Price 1 Value Total Fair Value Discount Fees License fee $2,000,000 $2,000,000 87.00% $87,000 $1,913,000 PCS $200,000 $300,000 13.00% $13,000 $287,000 $2,200,000 $2,300,000 100.00% $100,000 $2,200,000 1 Assumes that the maximum 2,000 seats are licensed. Upon the delivery of the first 1,000 seats, the Vendor would record $956,500 ($956.50 per seat x 1,000 seats) of license revenue and defer $43,500 of revenue related to the discount. For each subsequent seat delivered, the Vendor would record $956.50 of license revenue and defer $43.50 related to the discount. If at the end of the first year, the Customer has not licensed 2,000 seats, the Vendor would record all deferred revenue as income. If all 2,000 seats are licensed, the deferred revenue of $287,000 would be recognized over the remaining 12 months of the PCS arrangement. Capped PCS arrangement with no maximum number of seats Assume the facts in the example above, except that the arrangement does not provide for a maximum number of seats, but there is still contains the clause that allows the PCS fees for the second year to be capped at $200,000, if at least 2,000 seats are licensed by the end of the first year. Question: How should revenue be recognized? www.pwcrevrec.com 67

Answer: The Vendor does not know the potential discount because the number of seats has not been fixed. Therefore, the Vendor would have to defer all revenue under the agreement until the end of the first year, which is when the number of seats subject to the second-year PCS coverage would be known. At that point, the discount could be determined and the appropriate allocation of license fees and PCS fees made (allocated license fees would be recognized immediately, whereas the PCS fees would be recognized over the remaining 12 months of the PCS arrangement). However, if the Vendor could reliably estimate the maximum number of seats based on the number of employees the Customer has or the Customer's hardware configuration, the maximum discount may be calculable and an allocation of license and PCS fees could be made. 3.5 Explicit versus implied PCS arrangements Generally PCS is explicitly stated in a software arrangement. However, a vendor may have developed a historical pattern of regularly providing all customers, or certain classes of customers, with services or unspecified upgrades and enhancements that are normally associated with PCS, even though the vendor is under no written contractual obligation to provide these additional features. In these situations, there may be an implied PCS arrangement that commences upon the delivery of the software. An example of an implied PCS arrangement is one in which a vendor offers a "warranty" period, during which the customer would have the right to both phone support and to unspecified upgrades and enhancements that significantly enhance the functionality of the delivered software. This type of warranty clearly goes beyond conventional warranties offered with products sold in other industries because it involves much more than a representation that the product will perform up to certain specifications or that the vendor will replace or fix the product if it ceases to work properly. Under those same specifications "bug fixes" that are offered pursuant to a warranty do not represent an implied PCS arrangement and can therefore be accounted for as a warranty cost (TPA 5100.43). Another example of implied PCS is a case in which (1) a vendor updates software with enhancements that were released during an implementation period and (2) the customer does not have to purchase PCS until after the implementation of the software has been completed. In this situation there is implied PCS during the implementation period, which must also be accounted for as a separate element. VSOE of the fair value of the implied PCS would be necessary for purposes of allocating the arrangement fee. As discussed in Chapter 7, PCS can also be implied in reseller arrangements where software is prepaid inventory and upgrades or enhancements are provided upon sell through to an end user when such user subscribes to PCS (i.e., business practice to update the reseller's software inventory for upgrades or enhancements to the software). As noted above, any implied PCS is considered an additional element of the software arrangement, to which a portion of the total fees should be allocated. SOP 97-2 states that, for purposes of determining whether an implied PCS arrangement exists, PCS, in theory, "includes" a vendor's expected performance based on historical patterns, even if that performance is entirely at the vendor's discretion and not pursuant to a formal agreement. Questions and Answers Customer support implied arrangement The Vendor licenses software for $35 per copy. The Vendor does not offer upgrades and enhancements, since the Vendor licenses new versions of the product each year. The software license provides the 68 PricewaterhouseCoopers LLP

Customer with a customer service number that the Customer may call should it have any questions, but it does not explicitly state that customer support is provided as part of the software arrangement. However, if the Customer calls and requests customer support, the customer service representative will request a product identifier that indicates the year of purchase and will assist only those customers that licensed the software within the past year. The historical and expected cost of providing the PCS is insignificant. Question: Does a PCS arrangement for customer support exist? If so, may revenue be recognized upon the delivery of the software license? Answer: This appears to be an implied one-year PCS arrangement that goes beyond a product warranty within the scope of FAS 5. In order to not account for such implied PCS as a separate service in accordance with paragraphs 57/58 and 12 of SOP 97-2, and, instead, recognize the costs of such implied PCS at the time the software license revenue is recognized, all the conditions specified in paragraph 59 would have to be satisfied. Determining the term of implied PCS A Vendor enters into an arrangement to grant a customer a license to software as well as bundled technical support. Technical support includes post-delivery helpdesk support for an indefinite period which begins on the date of sale of the software product and ends with the next major version release of the applicable software product. It also includes free "dot releases" which comprise of non-major product releases with the same version as the purchase license. The period of free technical support is silent in the arrangement, however, once a major new release is rolled-out, past license-only customers no longer receive the free technical support or dot releases. Question: Since the arrangement does not specify the term of the implied PCS, how should the Vendor determine what is the appropriate term to use? Answer: The guidance in SOP 97-2 dictates that the Vendor should recognize revenue related to the license and PCS over the period in which the PCS is expected to be provided. Since the arrangement is silent as to the term, the period the PCS is expected to be provided would be that equal to the estimated economic life of the software. This viewpoint is supported by the fact that the Vendor ceases to provide implied PCS upon the roll-out of a new version. Additionally, the Vendor should continually re-assess the estimated period of the next major version release during the actual term of each major release and prospectively adjust the estimated term used for the recognition of the revenue when it becomes evident that the estimated term has changed prior to the expiration of the originally estimated term. Implied PCS arrangements upgrades and enhancements provided during installation period - no VSOE for the license. The Vendor enters into an arrangement to license a software package with several modules. The arrangement fee is $1,000,000 and provides that the Customer will install the software a process that is expected to take approximately nine months. VSOE of the fair value of the software package is not available. The VSOE of the fair value of one year of PCS is $160,000. As a matter of business practice, the Customer will be upgraded to new software enhancements that are rolled out during the installation period. www.pwcrevrec.com 69

Question: Does this business practice create an implied PCS arrangement? Answer: Yes. By providing upgrades and enhancements during the installation period, the Vendor implies that it is providing PCS for the software package during that period. The implied PCS should be (1) accounted for as an element that is separate from the other elements of the software package and (2) unbundled from the licensing fee if all revenue recognition criteria have been met. Deferred revenue of $120,000 [($160,000 12 months) X 9 months] should be recorded and recognized as revenue ratably during the installation period. The Vendor should record the remaining $880,000 (determined by the residual method assuming no VSOE of the fair value of the license) upon the delivery of the software, assuming that all other revenue recognition criteria have been met. Implied PCS arrangements upgrades and enhancements provided during installation period - VSOE for the license exists. Assume the facts as presented in the example above. Question: Would the answer be different had VSOE of the fair value of the license been known to be $1,000,000? Answer: Yes. In this scenario, the implied PCS would be subject to accounting that would allow the discount to be allocated as VSOE of the fair value of all elements becomes available. The effect that this would have on revenue recognition would be an allocation of the discount to each element that is included in the arrangement (since the amount of the discount is determinable), as follows: VSOE of Fair Value Percentage of Total Fair Value Allocation of Discount Allocated Fees License Fee $1,000,000 89.30% $107,160 $892,840 Implied PCS $120,000 10.70% $12,840 $107,160 $1,120,000 100.00% $120,000 $1,000,000 License revenue of $892,840 would be recorded upon the delivery of the software, and only $107,160 would be deferred as implied PCS revenue and recorded ratably during the installation period, instead of the $120,000 cited above. See Chapter 6 for further discussion of discounts. Observation: The fair value, based on VSOE of actual PCS renewal contracts, may reflect VSOE of the fair value of the implied PCS when the length of the installation period is determinable. However, when the length of the installation period cannot be reasonably determined, VSOE of the fair value of the implied PCS during the installation period may not be determinable. In such cases, the total arrangement fees allocated to the licensing arrangement and the implied PCS would be deferred and recognized when the installation is completed, assuming that PCS is the only undelivered element. 70 PricewaterhouseCoopers LLP

Implied PCS arrangements deployment period Assume the facts as presented in the example above. Question: Would PCS recognition be different if PCS effort and price increased over the deployment period? Answer: TPA 5100.44 addresses VSOE of fair value for deployment-based PCS where the PCS rate inherent in the license fee increases over time based on the customer's deployment of the product. In this situation, the predetermined renewal rate (i.e., $160,000) is the only indicator of fair value because it is the only arrangement under which PCS is sold separately and, therefore, it should be used to establish VSOE of fair value of the PCS during the deployment period. Implied PCS arrangements PCS provided during warranty period The Vendor licenses its software products with a 90-day warranty. The Customer may also purchase an annual PCS arrangement that commences upon expiration of the warranty period. The warranty provides for standard limited warranties (merchantability, performance specification, bug fixes, etc.). Additionally, the Customer will have the right to receive customer support and unspecified upgrades and enhancements, if any, during the 90-day period. Question: Does the right to customer support and unspecified upgrades and enhancements during the warranty period represent an implied PCS arrangement? Answer: Yes. The warranty constitutes an implied PCS arrangement. The VSOE of the fair value of the implied PCS arrangement would be necessary for the fee to be allocated among the multiple elements. Any fees allocated to the implied PCS would be recognized ratably over the warranty period. Implied PCS arrangements - correction of errors necessary to maintain compliance with published specifications during warranty period Assume the facts as presented in the example above. Question: Would the answer be different if the Customer were entitled to no more than a correction of errors that would be necessary to maintaining the software's compliance with published specifications ("bug fixes" only and not other unspecified upgrades and enhancements) during the warranty period? Answer: The Vendor does not have an implied PCS arrangement in this situation, as a bug fix is usually considered a correction of a defective product and, therefore, is not indicative of a PCS arrangement. TPA 5100.43 addresses this issue and states that a vendor's obligations related to warranties for defective software that are routine, short-term, and relatively minor should be accounted for on the cost accrual basis. The estimated costs to provide bug fixes that are necessary to maintain compliance with published specifications should be accrued in accordance with FASB Statement 5. www.pwcrevrec.com 71

3.6 Services Services other than PCS-related services generally include training, installation, and consulting. Consulting services often include implementation support, data conversion, software design or development, and customization of the licensed software. Chapter 9 of this guide discusses the proper accounting for these types of services. The initial and critical consideration in addressing revenue recognition related to services is whether the services can be accounted for separately from other elements in an arrangement. The services, other than PCS, must meet the following criteria if the fee that is allocated to the services is to be accounted for separately from the other elements of the arrangement: VSOE of fair value is sufficient for revenue to be allocated to the various elements; The services are not essential to the functionality of any other element of the transaction; and The services are described in the contract such that the total price of the arrangement would be expected to vary as a result of the inclusion or exclusion of the services. If all of the preceding criteria exist, revenue should be allocated to the various elements based on VSOE of fair value. Additionally, SOP 97-2 states that services need not be priced separately in order for them to be accounted for separately. Revenue allocated to the services should be recognized as the services are performed, or, if no pattern of performance is discernible, on a straight-line basis over the period during which the services are performed. Conversely, if the services do not meet the aforementioned criteria, they do not qualify for separate accounting, and contract accounting must be applied to the total fees from the software and service elements. See Chapter 9 for a detailed discussion. 3.6.1 PCS offered in arrangements involving significant customization or modification Arrangements that are accounted for by either the percentage-of-completion or completed-contract methods described under SOP 81-1 (i.e., contract accounting) often include free PCS, both during and after the implementation of the software is completed. Although contract accounting for software arrangements is the subject of Chapter 9, it is worth noting here the special considerations given PCS bundled in an arrangement that is accounted for using contract accounting. TPA 5100.49 addresses circumstances where an arrangement subject to contract accounting includes PCS for which there is VSOE of its fair value. The TPA concludes that such PCS services must be "unbundled" from the contract accounting that is applied to the remainder of the arrangement. However, the TPA does not address the accounting if VSOE of the fair value of the PCS does not exist. Observation: As mentioned above, if VSOE of the fair value of the PCS services is available, then such PCS is unbundled from the arrangement and accounted for according to the guidance in paragraph 57 of the SOP. If VSOE of the fair value of the PCS does not exist, then the entire arrangement, including PCS, must be accounted for following the guidance for contract accounting as discussed in paragraphs 74 through 91 of the SOP. If contract accounting applies and VSOE for PCS does not exist, determining the inputs for measuring progress towards completion can be challenging. It is often the case that a software vendor may be unable to make reasonably dependable estimates of the costs of providing PCS services or other PCS. When these circumstances arise, the circumstances should be reviewed thoroughly to determine which contract accounting method should be applied (i.e., completed contract or the percentage of completion method described in paragraph 25(c) of SOP 81-1). If VSOE for PCS is not available and the range of 72 PricewaterhouseCoopers LLP

estimated costs to provide PCS are material to the contract as a whole, such that a reliable estimate of the profit on the contract cannot be made, the entire contract should be accounted for under the completed contract method. This circumstance often arises because of the uncertain nature of the PCS deliverable, both as to timing and quantity (i.e., unspecified upgrades), the manner in which those upgrades are often developed, e.g., as a by-product of the general research and development efforts when the software vendor does not maintain adequate cost accounting records that reliably measure the portion of the general research and development spending that relates only to PCS deliverables, or when the vendor otherwise does not have a history of making reasonably dependable estimates. When the completed contract method is applied in such circumstances, upon completion of the development efforts, i.e., when the only remaining undeliverable is PCS, the arrangement's revenues and accumulated contract costs would then be recognized ratably over the remaining PCS period. This is analogous to the guidance in paragraphs 12 and 58 of the SOP for other software arrangements in circumstances where there is not VSOE of PCS and the PCS is the only remaining undelivered element. In appropriate circumstances, it may be appropriate to apply the guidance in paragraph 25(c) of SOP 81-1, i.e., recognize revenue in amounts equal to the development costs (zero estimate of profit), and upon completion of the development efforts recognize the remaining unrecognized revenue and the entire profit ratably over the remaining PCS period. These situations arise when reliable estimates to complete are available, but due to uncertainty regarding the profitability of the contract, one can only be assured that no loss will be realized on the contract. Some companies may believe they can accurately measure the estimates to complete and the profitability of a contract. This would be rare, especially if the PCS includes unspecified upgrades, and would indicate that either PCS is not part of the arrangement or VSOE of fair value is available in which case this section would most likely not apply. Questions and Answers Determining if a contractual renewal rate can be used to establish VSOE of fair value for services other than PCS SOP 97-2, paragraph 57 states that renewal rates can establish VSOE of fair value for PCS in a software arrangement. TPA 5100.44 states that a predetermined renewal rate is an indicator of fair value of PCS. TPA 5100.44 further states that a renewal rate can constitute VSOE of fair value for PCS if the PCS renewal rate and term are substantive. Question: SOP 97-2, paragraph 57 provides guidance specifically related to determining VSOE of fair value for PCS by using the contractually stated renewal rate, but is it appropriate to apply the concepts in paragraph 57 to services other than PCS, such as services? Answer: Yes. While services other than PCS are not specifically referred to in SOP 97-2, paragraph 57, we believe that since the customer has the right to purchase the services on a stand-alone basis in subsequent periods, the renewal rate may establish VSOE of fair value for those services as long as the renewal rate and term are substantive. www.pwcrevrec.com 73

3.7 Presentation and disclosure of product and services revenue Even if the revenue related to the delivery of product and services cannot be separately recognized (ie. when no VSOE of fair value exists and the arrangement is considered a single unit of accounting), vendors still need to consider the presentation of such items within the income statement. For publicly quoted entities, the SEC requires separate presentation in the statement of operations for products and services revenue (among other categories) and related costs if the separate categories exceed 10% of total revenues. A company is not always able to allocate the deliverables in an arrangement into separate accounting units in accordance with SOP 97-2, for example, but instead must account for the deliverables as a single accounting unit. The SEC has stated that it does not believe a company should be precluded from separately displaying product and service revenues in the income statement solely because the company is unable to separate the deliverables for revenue recognition purposes. This breakout may provide a desired level of transparency to investors. Therefore, the SEC would not object to a separate display of product and service revenues so long as: (1) a company has a reasonable and systematic basis for developing a separation methodology, and (2) the method of separating is consistently applied, clearly disclosed, and not misleading. If a Company is not able to meet these criteria, presentation of a single line item (i.e. combining service and product revenue in the same line items for these types of arrangements) would be acceptable. For example, assume that a software company, Company X, has a multiple element arrangement for $100 which includes products and services. The entire arrangement is accounted for pursuant to SOP 97-2. The stated contractual values are $60 for the software and $40 for the services; however, Company X does not have VSOE of fair value for any of the deliverables. Accordingly, the arrangement will be accounted for as a single accounting unit for recognition purposes. Company X determines that the appropriate revenue recognition model is to recognize the $100 ratably over the period the services are delivered. Although the company does not have VSOE for all of the deliverables, the company believes that separately presenting product and service revenues and the related costs in their statement of operations provides more useful information to investors than a single line item presentation. Company X determined an allocation methodology based on a comparison of prices charged by its peers for largely similar products and services (i.e. third-party evidence of fair value or VOE). Based on this analysis, Company X determined an allocation of $45 to software and $55 to services. Company X will therefore report $45 as product revenue and $55 as service revenue ratably in its statement of operations for this arrangement over the service period. Therefore, if the service period was 5 months, 1/5 or $9 of product revenue and $11 of service revenue would be recognized after the first month of service delivery. The related product and service costs will also be presented separately in the statement of operations, utilizing the actual costs of the products and services. Such presentation would be acceptable as long as the allocation methodology is consistently applied and clearly disclosed. Observation: Determining whether a company has a reasonable basis for separately displaying revenues for deliverables comprising a single unit of accounting requires judgment. A company may not simply default to the contractual value in the arrangement or a subjective allocation, even if consistently applied. A reasonable basis generally consists of estimates based on objectively verifiable inputs. For example, third party evidence of fair value (i.e., verifiable objective evidence or "VOE") would be a reasonable basis for separately displaying software deliverables that require vendor specific evidence of fair value (i.e., VSOE) for recognition purposes. 74 PricewaterhouseCoopers LLP

Chapter 4: Giving End Users Rights to Return or Exchange Software 4.0 Overview Software vendors frequently change their business practices to respond to changes in the industry. Once one vendor begins to offer customers certain beneficial arrangements, such as return rights, trade-in credits, or exchange rights, competitors often match the offer. This is compounded by a customer's feeling of anxiety and uncertainty about major technology purchases. Consumers are asking questions such as those below: What if a better product or version is released? What if the software doesn't work as well as we expected in our current technology environment? What if we want to migrate to a new platform in the future? What if the software doesn't really solve the problem we licensed it for? What if the software fails to meet future requirements? Some vendors are mitigating these concerns by giving their customers flexibility by way of certain rights of return or exchange. It can be difficult to determine whether a right that is given to a customer (as is implied by a vendor's business practices or contractually stated) should be categorized as a right to return or a right to exchange the delivered software. Paragraph 50 of SOP 97-2 indicates that the accounting for returns is significantly different from the accounting for exchanges. Further, if the customer has a license to continue using the previously delivered software, any additional software that is delivered constitutes an additional product and is not considered either a return or an exchange. Additional products must be accounted for as part of a multiple-element arrangement as discussed in Chapter 5. The distinction between an arrangement that should be accounted for as a return and an arrangement that should be accounted for as an exchange pivots on the similarity of the products involved. Rights given to an end user (not a reseller - reseller rights are discussed in Chapter 7) that allow for the return or exchange of one product for a similar product, with no more than minimal differences in price, functionality, and features are considered exchange rights (i.e., like-kind exchange). For example, take a case in which a retail store customer can exchange a green shirt for a red shirt. Arrangements of this type are generally subject to exchange accounting. If the product that is to be received by the customer is a product that is more than minimally different from the product that was originally delivered, the right would be considered a right of return and should be accounted for as such. This chapter will discuss specific matters regarding return and exchange rights that software vendors frequently confront. Those matters are as follows: 4.1 Return rights 4.1.1 Implicit and explicit 4.1.2 For specified products 4.1.3 For unspecified products 4.1.4 In multiple-element arrangements 4.2 Exchange and platform-transfer rights 4.2.1 For specified products currently available 4.2.2 For specified products not currently available 4.2.3 For unspecified products 4.2.4 Sunset clauses www.pwcrevrec.com 75

4.1 Return rights The accounting for a right of return is set forth in FAS 48. FAS 48 outlines six basic criteria (see paragraph 2.3.3) that must be met in order for revenue to be recognized upon a product's delivery when a right of return exists. SAB 101 provides a number of guidelines for interpreting the provisions of FAS 48, including determining what is adequate history, reasonable/reliable estimates, analogies to FAS 48, etc. If a right is considered a right of return because it pertains to a dissimilar product, the customer must surrender the right to use the originally delivered product and, assuming that the criteria for revenue recognition that are set forth in FAS 48 are met, the vendor should make an estimate of the expected returns. The recorded revenue and related costs should be reduced to reflect the estimated returns. Additionally, any costs or losses that may be expected in connection with any returns should be accrued in accordance with FAS 5. However, FAS 48 also discusses, in paragraph 8, certain factors that may impair the vendor's ability to make a reasonable estimate of returns (one of the criteria that must be met in order for revenue to be recognized upon the product's delivery): The susceptibility of the product to significant external factors, such as technological obsolescence or changes in demand; Relatively long periods in which a particular product may be returned; An absence of historical experience with similar types of sales of similar products, or an inability to apply such experience because of changing circumstances (for example, changes in the selling enterprise's marketing policies or relationships with its customers - see discussion in section 2.3.1 regarding Class of Customer); and An absence of a large volume of relatively homogeneous transactions. Certain of these criteria, particularly "the susceptibility of the product to significant external factors, such as technological obsolescence or changes in demand" and an "absence of a large volume of relatively homogeneous transactions," are directly applicable to the software industry. If a vendor cannot reasonably estimate returns, due to the above factors, revenue must be deferred until such a reasonable estimate can be made or until the return right lapses (as the estimate of returns at that point would be zero). SAB 104 outlines additional criteria that should also be considered, as appropriate. 4.1.1 Implicit and explicit rights of return A vendor may have a right of return specifically stated in arrangements (explicit) or may have established a right of return with all, or a certain class of, customers based on its customary business practices (implicit). Whether the right of return is explicit or implicit, the FAS 48 criteria must be met in order for revenue to be recognized upon the delivery of the initial product. All available evidence should be evaluated when a determination is being made of whether a vendor has an established business practice of granting rights of return. For example, it is not uncommon for vendors to agree to take products back on a limited basis when the customer has a valid business purpose for requesting the return. If the right to return software occurs only in selective instances and cannot be reasonably anticipated at the time of delivery, the practice may not be considered indicative of an overall implicit right of return, and the return should be accounted for at the time that the return and refund or credit is made. However, if the practice of accepting returns is pervasive or the customer could reasonably believe that it has the right to return the product because of prior vendor business practices, the vendor's practice indicates an implicit right of return. In this situation, the criteria in FAS 48 should be evaluated in a determination of whether revenue should be recognized, including whether the vendor can reasonably estimate the amount of returns. 76 PricewaterhouseCoopers LLP

4.1.2 Return rights for specified products The ability to reasonably estimate returns in accordance with the provisions of FAS 48 can be affected by whether or not the "specified products" that are noted in a vendor's arrangements with customers are currently available. For example, if a vendor has recently announced that it intends to release a new version of its product next year, it may need to provide customers with an incentive to purchase the current version. One way would be to allow the customers to "return" the current version and receive partial credit towards the purchase of the new version. Reasonably estimating returns in this situation would be particularly difficult for vendors that have not previously completed a similar marketing promotion that was aimed at a similar population of customers. Factors that would make such a reasonable estimation difficult to reach are: The period of time that the return right exists; The inherent susceptibility of software to technological obsolescence; A lack of definitive evidence regarding the introduction of competing products that might impact the demand for current products; and A lack of historical data from which to prepare estimates if this is the first time that such a marketing campaign had been launched. If a reasonable estimate of returns cannot be made upon the delivery of the initial product, revenue should be deferred until the earlier of (1) when the return privilege is considered to have substantially expired or (2) when a reasonable estimate of returns can be made. Conversely, if a return right relates to products that are currently available, a reasonable estimation of returns might be easier to make. 4.1.3 Return rights for unspecified products It is difficult to estimate returns for a product that is not currently available, but estimating returns for unspecified products can prove even more problematic. For example, a software vendor may attempt to mitigate a potential customer's technological obsolescence risk by allowing a customer to "trade in for full credit" any current product and put the credit amount toward the purchase price of any product that is introduced in the future. As mentioned, with regard to returns related to products that are not currently available, factors that would make a reasonable estimation difficult to make are as follows: The length of time that the return right exists; The inherent susceptibility of software to technological obsolescence; A lack of definitive evidence regarding introductions of competing products that might impact demand; and A lack of historical data with regard to the products that are subject to the return right. 4.1.4 Return rights in multiple-element arrangements A vendor may extend a right of return in a multiple-element arrangement whereby only one element, or some combination of the elements, can be returned in the future. In multiple-element arrangements, reasonably estimating returns can present certain challenges. In order to reasonably estimate returns, a vendor must have a value on which to base the estimate of the fees that are covered by the return right. This value should be the greater of (1) VSOE of fair value for each of the elements that is subject to the return right or (2) the portion of the fee that is subject to refund whether implied or required under the conditions of the arrangement. Refer to paragraph 14 of SOP 97-2. www.pwcrevrec.com 77

SOP 97-2 states that if VSOE of fair value does not exist for all the elements in an arrangement, revenue must be deferred until (1) such evidence does exist or (2) all elements have been delivered, whichever comes earlier. If VSOE of fair value does not exist at the outset of an arrangement, but subsequently becomes available, a vendor may then be able to make a reasonable estimate of returns based on the VSOE of fair values, if all the FAS 48 criteria have been met. Observation: We would expect that for situations in which VSOE of fair value does not exist for all elements of a multiple-element arrangement, it would be extremely difficult to reasonably estimate the dollar amounts that would be involved in a return. In some cases, it may be possible to estimate the maximum amount of potential returns, which would allow the recognition of some revenue from the arrangement. In its Q&As (TPA 5100.45), the AICPA Staff addressed the effect on software revenue recognition of arrangements that allow a user to change or alternate its use of multiple products/licenses (license mix) after the vendor has delivered those products. The products may or may not be similar in functionality. These arrangements may limit the customer's use at any time to any mix or combination of the products as long as the cumulative value of all products in use does not exceed the total license fee. Certain of these arrangements may not limit usage of a product or products, but rather, they may limit the number of users that simultaneously can use the products (referred to as concurrent user pricing). The AICPA Staff determined that as long as the other criteria in SOP 97-2 for revenue recognition are met, revenue should be recognized upon delivery of the first copy or product master for all of the products within the license mix. Subsequent remixing is not an exchange or a return of software because the master or first copy of all products has been licensed and delivered, and the customer has the right to use them. Questions and Answers Business practice of rights of return that are not explicitly stated in arrangement The Vendor licenses its products to end users and resellers. The terms and conditions of the licenses are set forth in standard contracts for each customer type. The licensing arrangements do not provide customers with a right of return. However, in practice, the Vendor has historically agreed to take the product back and issue a refund, make concessions, or credit other outstanding balances of customers, even if there was nothing wrong with the product. Question: Does the Vendor's practice represent an implicit right of return for all licensing arrangements? If so, how should the right be treated? Answer: It is not uncommon for a vendor to agree to take products back in circumstances that could not have been reasonably anticipated at the time of delivery. In those situations, the return should be accounted for at the time that the return and refund or credit is made. Generally, such returns would not suggest that a vendor is offering an implicit right of return in its licensing arrangements. However, if a vendor's practice of accepting returns is common and customers believe that they have the right to return a product, the vendor's practice represents an implicit right of return. In this situation, the criteria in FAS 48 should be evaluated in the determination of whether revenue should be recognized, including whether the Vendor can reasonably estimate the amount of returns. If no estimate of returns can be made, the Vendor should not record revenue upon the delivery of the product, rather it should be deferred until such a reasonable estimate can be made or until the vendor communicates that the return right has lapsed. 78 PricewaterhouseCoopers LLP

Rights of return products are currently available The Vendor currently has four products: Product A, Product B, Product C, and Product D. The products are all in the same product family, have been available for five years, and are marketed to high-income adults. However, they have different functionality levels and are licensed at significantly different prices, but VSOE of fair value can be determined for each. The Vendor's history suggests that 10 to 20% of these products are returned. The Vendor plans to introduce Product N early next year. Product N will be the first in a new family of products that will be marketed to children. Question: The Vendor enters into an arrangement with Customer X for the licensing of Product A for $500. Included in its arrangement with Customer X is a clause that states, For six months from the date of delivery, Customer X can return Product A and receive a credit off the license fee for Products B, C or D equal to 50% of the purchase price of Product A ($250). How should revenue under the arrangement be recognized? Answer: The facts and circumstances in each case would have to be evaluated to determine if a reasonable estimate of returns could be made. In the fact pattern above, the details suggest that a reasonable estimate of returns could be made. Factors to consider in drawing this conclusion are as follows: Products A, B, C and D have been marketed for five years; Products A, B, C and D are marketed to a homogeneous population; and Products A, B, C and D are all in the same product family. If a reasonable estimate of returns can be made, revenue under the arrangement should be recognized upon the delivery of Product A, assuming that all other revenue recognition criteria have been met. The Vendor would record a returns reserve, based on its FAS 48 analysis of returns. Rights of return products are not currently available Assume that the same fact pattern as that which is stated in the last fact set pertains here. Question: The Vendor enters into an arrangement with Customer Y for the licensing of Product B for $1,000. Included in its arrangement with Customer Y is a clause that states, Upon the introduction of Product N, Customer Y can return Product B and receive 50% off the license fee of Product N for six months after the date that Product N first becomes available. VSOE of the fair values of Products B and N exist. How should revenue under the arrangement be recognized? Answer: Facts and circumstances will vary from case to case and need to be evaluated individually to determine if a reasonable estimate of returns can be made. Based on the facts presented above, it would seem that a reasonable estimate of returns cannot be made. Factors to consider in drawing this conclusion are as follows: Product N is a new product and not yet available; Product N will be marketed towards a new population of consumers; Product N is in a new product family, with which the Vendor has no experience; and The period for returns is long (i.e., Product N will not be introduced until next year and the return right extends for six months after the date that Product N first becomes available). www.pwcrevrec.com 79

If a reasonable estimate of returns cannot be made, revenue under the arrangement should be deferred until Product N has been delivered or the return right lapses, assuming that all other criteria for revenue recognition have been met. Return rights for unspecified products specified term The Vendor enters into an arrangement with the Customer whereby the Customer licenses Product A for $5,000. The Vendor's strategy is to make its lower-end product, Product A, very attractive to potential customers by pricing it below the competition. However, all of the Vendor's arrangements include a clause that states, the Customer can receive full credit for the license fee of Product A when licensing any of the Vendor's other existing products or new products for a 12-month period starting at the date of delivery of Product A. The Vendor's objective is to induce customers to license its higher-end products, for which the margins are substantially greater, during the 12 months after the delivery of Product A. Question: The Vendor has concluded that it can reasonably estimate returns for Product A at 20% of the total sales. How should the $5,000 of revenue be recognized? Answer: Because the Vendor can reasonably estimate returns, $4,000 (80% x $5,000) should be recognized upon the delivery of Product A, and the remaining $1,000 deferred and recognized when the return privilege has substantially expired or when Product A has actually been returned and the new product(s) delivered, assuming that all other criteria for revenue recognition have been met. Return rights for unspecified products unlimited term The Customer agrees to license Product Z from the Vendor for $100,000. Product Z is an inventory tracking system that is for Platform A. The Vendor also has developed Products A, B, and C, which operate on Platform B. As part of the license agreement, the Customer obtains the right to return Product Z at any time for 40% off the license fee of one or more of the other products. The Vendor's products are not typically sold at a discount from list. Question: How should the $100,000 of revenue be recognized? Answer: As the term of the return privilege is indefinite, the Vendor may have difficulty reasonably estimating returns. If no such estimate can be made, all the revenue must be deferred until a reasonable estimate of returns can be made. 4.2 Exchange and platform-transfer rights If a right to exchange a delivered element for another element qualifies for exchange accounting and all other revenue recognition criteria have been met, all revenue from the arrangement should be recorded upon the delivery of the initial software. The subsequent exchange of products has no impact on revenue recognition. We again emphasize that if the customer is entitled, either by contractual terms or business practices, to continue using both the software that was initially delivered, as well as the software received in the exchange, the right must be accounted for as a right to an additional product as discussed in Chapter 3. The originally delivered software does not have to be physically returned, as long as the customer's contractual right to use the originally delivered product has terminated. 80 PricewaterhouseCoopers LLP

Paragraphs 50 through 54 of SOP 97-2 address the issue of exchange and platform-transfer rights. A platform-transfer right is defined in SOP 97-2 as a right granted by a vendor to transfer software from one hardware platform or operating system to one or more other hardware platforms or operating systems. SOP 97-2 specifically addresses the fact that the revenue ramifications of an exchange right are different from those of a right of return. Paragraph 50 states, "As part of an arrangement, a software vendor may provide the customer with the right to return software or to exchange software for products with no more than minimal differences in price, functionality, or features." (Emphasis added.) With regard to platformtransfer rights, paragraph 53 notes that they can be accounted for in a manner similar to how an exchange right is accounted for when the right "1) is for the same product (see paragraph 54) and 2) does not increase the number of copies or concurrent users of the software product available under the license arrangement." Paragraph 54 adds that the products involved in the exchange right must also be "marketed as the same product." It must be noted that exchange accounting cannot be applied to exchange rights that are granted to resellers. Because a reseller is not the end user, such rights must be accounted for as returns. Exchange rights granted to resellers are addressed in Chapter 7. 4.2.1 Exchange and platform-transfer rights for specified products currently available If a right that is included in an arrangement meets the criteria discussed above, recognizing revenue upon the delivery of the initial product is appropriate, assuming that all other revenue recognition criteria have been met and the products and/or platforms eligible for exchange are currently available. Paragraph 51 of SOP 97-2 states, Conversely, exchanges by users of software products for dissimilar software products or for similar software products with more than minimal differences in price, functionality, or features are considered returns, and revenue related to arrangements that provide users with the right to make such exchanges should be accounted for in conformity with FAS 48. SOP 97-2 does not provide guidance on interpreting the word minimal in paragraph 50. Revenue recognition in these cases is subjectively determined and should be decided on a case-by-case basis. Paragraph 54 indicates that two products may be considered the same even though there may be differences between them that arise from environmental variables such as operating systems, user interfaces, and platform scales. Indications that products have been marketed as the same product include the same product name (although version numbers may differ), similar pricing, and/or an emphasis on the same features and functions. Factors that may indicate that there are more than minimal differences between a product and other products or that the product is not marketed in the same way as other products may include the following: The product that is to be received in the exchange has a different name; The new product performs functions in areas outside the domain in which the original product operated; The reporting options available to the customer in the new software are either more numerous or more limited than the original software; Marketing materials promote significantly increased functionality or features; and The customer orders more copies or site licenses for the new product than it had for the old product, indicating that functionality may have increased, which enables more users to benefit from the product. www.pwcrevrec.com 81

4.2.2 Exchange and platform-transfer rights for specified products not currently available Paragraph 51 of SOP 97-2 addresses product exchange rights for cases in which all the products are not currently available. It states, If the other product(s) is not available at the time the initial product is delivered, there should be persuasive evidence that demonstrates there will be no more than minimal differences in price, features, or functionality among the products in order for the right to quality as a right to exchange. Additionally, if the vendor expects to incur a significant amount of development costs related to the other product, the other product should be considered to have more than a minimal difference in functionality. The evaluation of what constitutes persuasive evidence should be made on a case-by-case basis. Factors to consider in determining whether the evidence is sufficient to support the assertion that there will be no more than minimal differences in price, features, or functionality include the following: Whether the specifications for the new product are similar to those for the old product; Whether the difference between the prices of the two products can be reasonably estimated as minimal; Whether the marketing material for the two products is similar; Whether potential customers are awaiting the release of the new product to place an order; and Whether the period preceding the introduction of the new product into the market is short, and whether the impact of possible changes in environmental factors that could change the vendor's plans is minimal. In a situation where a customer orders a product but the vendor delivers a substitute product because the ordered product is not currently available, the vendor may grant the customer a right to exchange the delivered product for the ordered product when available. Additional considerations beyond those above include: Whether the customer can use the substitute product after the ordered product is delivered; Whether the fee is subject to refund or concession if the ordered product is not delivered; Whether the vendor intends to grant or has a history of granting a refund or other concession if the ordered product is not delivered. 4.2.3 Exchange and platform-transfer rights for unspecified products Some software arrangements involve exchange rights for unspecified products or platforms. If the criteria in paragraphs 50 through 55 of SOP 97-2 are met, the right may qualify for exchange accounting. Paragraphs 48 and 49 of SOP 97-2 indicate that if the right does not qualify for exchange accounting, subscription accounting should be applied. 4.2.4 Sunset clauses Oftentimes customers will negotiate the right to exchange a product if the vendor discontinues the product and ceases providing support for the product (i.e., "sunsets the product"), to protect itself against the risk of early product obsolescence commonly referred to as a sunset clause. Considerations in assessing the impact of such clauses on revenue recognition include: Does the agreement require that the "replacement product" has no more than minimal differences in price, features, and functionality as the already owned product? If the customer avails itself of the option to receive the "replacement product", must the customer return, destroy, or contractually cease using the already owned product? 82 PricewaterhouseCoopers LLP

If the answer to both considerations is yes, then the exchange right is not considered an additional element of the arrangement and would not impact the revenue recognition. If, however, the answer to either of the considerations is no, then the contractual provision is considered an additional element of the arrangement and could potentially impact the revenue recognition. If VSOE of fair value does not exist for the additional element, the arrangement should be accounted for as a subscription and the entire fee should be recognized over the contractual term or the estimated economic life. Judgment is required based on the economic substance of the arrangement to determine the conclusion of whether the fee should be recognized over the contractual term or the estimated economic life. Questions and Answers Exchange rights for the same product The Vendor enters into an arrangement with the Customer for $250,000 on June 30, X1 to license Product A on Platform X. Pursuant to the terms of the arrangement, the Customer can exchange Product A on Platform X for Product A on Platform Y at any point. Product A on Platform X has the same features and functionality as Product A on Platform Y and is (1) marketed as having the same features and functionality and (2) currently licensed at the same price. The arrangement specifically states, The Customer surrenders the right to continue to use Product A on Platform X upon receiving Product A on Platform Y. Question: Does the arrangement qualify for exchange accounting? Can the Vendor recognize the $250,000 on June 30, X1? Answer: The arrangement does qualify for exchange accounting. The Customer's right to Product A on Platform X terminates upon its receipt of Product A on Platform Y. On June 30, X1, the Vendor can recognize $250,000 related to this arrangement, assuming that all other criteria for revenue recognition have been met. Exchange rights continued use of original version Assume that the same fact pattern as that which is stated in the last fact set pertains here, except that the Customer has no contractual obligation to return Product A on Platform X and will be entitled to continue using that version. Question: Does the arrangement qualify for exchange accounting? Can the Vendor recognize the $250,000 on June 30, X1? Answer: The arrangement does not qualify for exchange accounting. Paragraph 50 of SOP 97-2 states, If the software is not returned physically and the customer contractually is entitled to continue to use the previously delivered software, the arrangement should be accounted for in the manner prescribed in the section herein entitled 'Additional Software Products.' See Chapter 5 for discussion of accounting for additional products as part of a multiple-element arrangement. www.pwcrevrec.com 83

Platform-transfer rights for specified product not currently available insignificant development costs yet to be incurred On January 31, X1, the Vendor enters into a licensing arrangement with the Customer for Product X, which is operating on Platform A (the platform that is currently being used by the Customer), for $500,000. Pursuant to the terms of the arrangement, the Vendor delivers Product X on January 31, X1. The arrangement also contains a provision that the Customer can exchange its current version of Product X for a new version of Product X that operates on a different operating system (Platform B). The Customer is in the process of converting to Platform B. The Vendor anticipates that the new version of Product X will be available on October 29, X1. The price for the two versions will be the same, and the same features and functionality are being marketed with both versions. Question: Does the arrangement qualify for exchange accounting? Can the Vendor recognize the $500,000 on January 31, X1? Answer: The right may be accounted for as an exchange if the Vendor has persuasive evidence that (1) there will be no more than minimal differences in price, functionality, or features between the two versions, (2) all of the other criteria for revenue recognition have been met, and (3) the Customer will not be entitled to continue using the Platform A version of Product X after the exchange occurs. Even though this situation appears to involve a platform-transfer right that would be subject to exchange accounting, since the Customer is in the process of converting to Platform B, delivery of the new version of Product X may likely be required under the agreement. If delivery of the new version of Product X is required, the $500,000 would be deferred until the new version is delivered (as the price for the two versions is the same). Platform-transfer rights for specified product not currently available significant development costs yet to be incurred Assume that the same facts as those in the last fact set pertain here, except that the Vendor does not anticipate that the Platform B version of Product X will be available until December 29, X3, which is more than two years after the delivery of the Platform A version of Product X. The Vendor anticipates that the development costs for the new version of Product X will be in excess of the arrangement fee of $500,000 but significantly less than the anticipated revenue for the year ended X2. Question: Does the arrangement qualify for exchange accounting? Can the Vendor recognize the $500,000 on January 31, X1? Answer: Given that the timeline for the delivery of the new version extends more than two years beyond the delivery of the initial product, it is unlikely that this arrangement would qualify for exchange accounting. Because of the extended time until the new version will be available, the risks of changes in market conditions and the underlying technology is very high. Consequently, it may be difficult for the Vendor to establish that the features, functionality and pricing of the new version will be the same as the old version. If the Vendor were to conclude that exchange accounting is not appropriate, the right to receive the new version would be evaluated as a right of return. Considering how long it will take to release the new version, it is unlikely that an estimate of returns could be made. 84 PricewaterhouseCoopers LLP

Platform-transfer rights for unspecified products not qualifying for exchange accounting On September 30, X1, the Vendor enters into a licensing arrangement with the Customer for Product X, which is operating on Platform A (the platform that is currently being used by the Customer), for $750,000. Pursuant to the terms of the arrangement, the Vendor delivers Product X. The arrangement also contains a provision that the Customer can exchange its current version of Product X for another version of Product X that operates on a different operating system. The different operating system is not specified in the arrangement. Question: Does the arrangement qualify for exchange accounting? Can the Vendor recognize the $750,000 on September 30, X1? Answer: Given that the Vendor has granted the Customer an unspecified platform-transfer right (as no other platform has been identified) that does not expire, it is unlikely that this arrangement would qualify for exchange accounting. Because of the extended time, the risks of changes in market conditions and the underlying technology is very high. Consequently, it may be difficult for the Vendor to establish that the features, functionality and pricing of the new product will be the same as the original. If the Vendor were to conclude that exchange accounting is not appropriate, all software-related revenue from the arrangement should be recognized over the term of the arrangement beginning with the delivery of the first product. As the term of the arrangement is not stated, the revenue should be recognized ratably over the estimated economic life of the products. Intent on the part of the Vendor not to develop new products during the term of the arrangement does not relieve the Vendor of the requirement to recognize revenue ratably. Observation: The above example highlights the accounting for a transaction with only a software deliverable and an unspecified platform-transfer right. However an assessment is required of the revenue criteria in conjunction with paragraph 12 of SOP 97-2 to determine the appropriate accounting in a multiple-element arrangements where there are additional deliverables. Refer to Chapter 3 or further discussion of application on subscription accounting related to unspecified additional future products. Platform-transfer rights for unspecified products exchange accounting applies Assume that the same facts as those in the previous example pertain here, except that the Vendor includes specific language in the arrangement such that an exchange can occur only at the Vendor's determination that the exchanged product has similar pricing, features and functionality to that of the original. Question: Does the arrangement qualify for exchange accounting? Can the Vendor recognize the $750,000 on September 30, X1? Answer: Although all relevant facts and circumstances would need to be considered, the right may be accounted for as an exchange if the Vendor has persuasive evidence that (1) there will be no more than minimal differences in price, functionality, or features between the two versions, (2) the Vendor does not have a business practice of accepting platform-transfers which do not qualify as exchanges, (3) all of the other criteria for revenue recognition have been met, and (4) the Customer will not be entitled to continue using the Platform A version of Product X after the exchange occurs. www.pwcrevrec.com 85

Chapter 5: Specified upgrades, additional products and other considerations 5.0 Overview As noted in Chapter 3, revenue recognition for multiple-element arrangements is complicated and will vary with the nature of each of the deliverables and how, if at all, each deliverable relates to or impacts another element. This chapter will discuss the impact of the following common multiple-elements considerations: 5.1 Specified upgrades and enhancements 5.1.1 Required and implicit unspecified upgrade rights and post contract support 5.2 Additional products 5.3 Specified versus unspecified additional software products 5.4 Intellectual property infringement indemnifications 5.5 Undelivered elements to be provided by third-party vendor 5.1 Specified upgrades and enhancements SOP 97-2 defines an upgrade right as the right to receive one or more specified upgrades or enhancements, even if it is offered on a when-and-if-available basis. It is important to emphasize that the granting of an upgrade right may be evidenced not only by a specific agreement or commitment, but also by a vendor's established business practices. Specified upgrades and enhancements can also be encountered when a request for proposal (RFP) is included in or specifically referenced in a license agreement. RFPs can typically include specific discussions on the future functionality of the vendor's software products. When these discussions are included in a license contract (e.g., RFP is an exhibit, RFP covered by warranty or product representations, etc.) specified upgrade and enhancement revenue recognition issues could exist depending on the specific details in the arrangement. It is sometimes difficult to distinguish between a right for a specified upgrade and an additional software product. As discussed in detail in section 5.2, this distinction is extremely important when the appropriate revenue recognition is being determined. Additionally, the right to specified upgrades or enhancements should be distinguished from the right to receive unspecified upgrades or enhancements on a when-and-if-available basis, which is considered to be part of PCS, as defined by SOP 97-2. PCS rights are discussed further in Chapter 3. A specified upgrade right generally allows a customer to upgrade to a newer version of the same software product for a fee that is substantially less than the price a new customer would pay to license the newer version. Such rights are often granted to customers when the vendor will soon be releasing a new version of the software product. Customers may decide to go ahead and license the current version, with the right to receive the newer version at a lower price when it becomes available. Specified upgrade rights should be accounted for as separate elements and, therefore, should be allocated a portion of the fee based on the VSOE of the fair value of the upgrade. Paragraph 37 of SOP 97-2 indicates that this would be the price that existing users of the software product will be charged for the upgrade. Unlike SOP 97-2's general requirement that discounts be considered in the allocation of fees to the elements of an arrangement, no portion of any discount should be allocated to the upgrade right. See Chapter 6 for a detailed discussion of accounting for discounts. Such allocated fees should be recognized as revenue when all of the criteria for revenue recognition have been met for the upgrade right. 86 PricewaterhouseCoopers LLP

Observation: It appears that the rules related to accounting for specified upgrades were specifically written for situations in which the upgrade will be licensed separately. Many vendors make major upgrades available to customers without charging an upgrade fee, as the specified upgrades are included as part of PCS. This represents an accounting issue for such vendors, because specified upgrades will not be licensed separately, and, therefore, no VSOE of fair value can be determined for the undelivered specified upgrade. Accordingly, no revenue from the arrangement can be recorded until the upgrade is delivered. Note that even a when-and-if-available specified upgrade cannot be accounted for as PCS, as it is not unspecified. We believe that these rules substantially impact a vendor's business practices and its willingness to offer upgrades in contracts on a specific or an implied basis, and may even impact whether a vendor decides to charge a separate fee for major upgrades of its software products. Observation: SOP 97-2 indicates that when a vendor is allocating an arrangement fee based on VSOE of the elements that are covered by the arrangement, the value that is to be assigned to a specified upgrade right is the price that will be charged to existing users of the software upon its being upgraded. In practice, this amount will often vary according to whether a customer is current with its PCS payments or whether it has not paid for PCS. Sometimes a vendor will require customers to become current with their PCS payments before they can be entitled to the reduced upgrade prices, or the vendor will require the customer to pay the full price of a license for the upgraded software. This raises the question of what Paragraph 37 of SOP 97-2 means by the price...that would be charged to existing users of the software being updated. The amount could vary from the upgrade fee to the full price of a license for the upgraded software. We believe that, for cases such as this, the intent of SOP 97-2 is that the fees from an arrangement should be allocated based on the upgrade fee for customers that are current on their PCS payments. License arrangements may include rights to specified upgrades or enhancements. Such rights may be evidenced by a specific agreement, commitment, or the vendor's established practice. Allocation of revenue to the specified upgrade or enhancement is required even if the customer will be entitled to receive the upgrade or enhancement under PCS, because the obligation is specified. However, the amount allocated may be reduced for the percentage of licenses that are not expected to be upgraded if sufficient evidence exists to support this expectation. If the vendor does not have sufficient evidence to estimate the percentage, then it should be presumed that all customers would exercise the upgrade right. The estimate of the number of customers who will take advantage of an upgrade needs to be periodically reviewed. Due to the nature of the software industry, products and customers tend to change frequently. As a result, the objective evidence that once supported an estimate may change in the future. If a change is made to the estimate, the effect of the change should be accounted for as a change in an accounting estimate and dealt with prospectively. Several situations that may cause customers not to exercise the upgrade right are presented below. These are also relevant to determining VSOE of the estimated upgrade percentage: The benefits gained from the related upgrade or enhancement may not be important to the customer; The customer may not wish to learn how to use the upgraded software for what may be perceived by that customer as marginal improvements; The upgrade or enhancement would require more hardware functionality than the customer currently has; and/or The implementation of the upgrade may require too much effort on the part of the customer. www.pwcrevrec.com 87

Questions & Answers Specified upgrade rights VSOE exists for all elements The Vendor offers a software package over the Internet for $35. The Customer is advised that an upgrade of the software package will be released in 60 days, and, as part of the licensing arrangement, the Customer will receive the right to license the upgrade for $10. VSOE of the fair value of the software package is $35 (without the upgrade). The Vendor believes that minimal effort will be required to develop the upgrade, as the upgrade is being designed only to allow the program to take advantage of improved operating systems. The upgrade will be marketed to existing users for $15, which represents VSOE of the fair value of the upgrade. The Vendor expects that the Customer will exercise the upgrade right. Question: What amount of revenue would the Vendor be able to recognize once all of the revenue recognition criteria for the original version have been met? Answer: In this case, the Vendor has VSOE of the fair value of the original version and of the upgrade $35 and $15, respectively. However, the total fee from the arrangement is only $45, so there appears to be a $5 discount involved in the transaction. SOP 97-2 requires that the entire $15 be deferred until the delivery of the specified upgrade, with the remaining $30 being recognized with the delivery of the original software. This effectively allocates the entire discount to the delivered element. See Chapter 6 for further discussion of the impact of discounts. Vendor can reasonably estimate extent of exercise of upgrade rights The Vendor licenses a Web site development tool. The tool has a wide array of features and functionality that enable users to develop both simple and highly elaborate Web sites. The Vendor has a practice of charging customers a fee for upgrades. In order to continue attracting new customers and encourage existing customers to purchase upgrades, the Vendor continually updates the features and functionality of its tool, as well as incorporates all upgrades and enhancements into it as they are developed and tested. The Vendor has an established practice of marketing new features and functionality that it expects to incorporate into its tool in the near future (generally four to six weeks prior to the upgrade's expected general release), as well as a practice of including and specifying these upgrades in the contracts, for a specified fee. The Vendor licenses its products to a variety of end users, including individuals that purchase software for their personal use, small-business owners, and programmers for large, corporate IT functions. Historically, therefore, all customers have not exercised upgrade rights, because their software needs and uses vary. Because the Vendor is continually upgrading its product, each upgrade or enhancement offered is developed and introduced for a specific target market. The Vendor's service department has maintained records that the Vendor uses to determine the number of customers that are expected to exercise a given upgrade right. The Vendor licenses Product A to 50 customers in multiple-element arrangements that include a specified upgrade right. The total arrangement fee for each arrangement is $100. VSOE of the fair value of Product A is $100, and the Vendor expects to charge existing customers $20 to upgrade to the new version of Product A, representing VSOE of the fair value of the upgrade right. The Vendor's historical analysis clearly supports that only one-half of the customers will exercise the upgrade right. 88 PricewaterhouseCoopers LLP

Question: Can the Vendor estimate the number of customers that will not exercise the upgrade right and thus reduce the portion of the fee allocated to the upgrade right (i.e., the portion of the revenue deferred at the time that the current software product is delivered)? If so, how much revenue should be recorded at that date? Answer: Yes, as the Vendor has sufficient VSOE to estimate the percentage of customers that will not exercise the upgrade right. The Vendor should record $4,500 in license fees from the arrangements when Product A is delivered and defer an aggregate of $500 ($20 VSOE of the fair value of the upgrade x 50 customers x 50% of customers expected to exercise the upgrade right). The $500 of deferred revenue should be recognized over the period of time the upgrade rights are exercised or when they expire. Vendor cannot reasonably estimate exercise of upgrade rights Consider the facts as presented in the above example, however, the Vendor does not have sufficient VSOE of fair value to estimate the percentage of customers that will not exercise the upgrade right. Question: How should the upgrade rights be accounted for? Answer: If in such situations, there is not sufficient historical information on which an estimate may be based, it should be presumed that all customers would exercise the upgrade right. In the example above, the Vendor should record $4,000 of revenue for the arrangements upon the delivery of the software and defer an aggregate of $1,000, assuming that all other revenue recognition criteria have been met. The $1,000 of deferred revenue should be recognized over the period of time the upgrade rights are exercised or when they expire. 5.1.1 Required and implicit unspecified upgrade rights and post contract support SOP 97-2 defines PCS as: The right to receive services (other than those separately accounted for as described in paragraphs.65 and.66 of this SOP) or unspecified product upgrades/enhancements, or both, offered to users or resellers, after the software license period begins, or after another time as provided for by the PCS arrangement. Unspecified upgrades/enhancements are PCS only if they are offered on a when-and-ifavailable basis. PCS does not include the following: Installation of other services directly related to the initial license of the software, The right to receive one or more specific upgrades/enhancements that are to be sold separately, Rights to additional software products. The obligation to deliver one unspecified software upgrade per year fails to meet the definition of PCS. While the software upgrade that is to be delivered may be unspecified as to features, functionality or exact timing of release, the software upgrade is not being made available on a when-and-if-available basis. In addition to the above considerations, many vendors have "implicit specified upgrades" in which the vendor has indicated that updates, if any, will be released a certain number of times per year. These programs are being initiated in response to IT managers who have asked software organizations to www.pwcrevrec.com 89

bundle their patches in order to reduce the amount of flux in their customers' systems. This raises the question of whether this type of program creates an expectation of specified upgrades. Each situation would need to be carefully considered, but oftentimes the language around this plan does not guarantee updates at each release date, but instead they merely provide for a set date at which updates, patches, etc that become available for maintenance are released. Companies should continue to: discuss these implicit specified upgrades throughout their organization continue to review contract terms to determine whether any obligation exists continue to review marketing literature or program announcements clearly include language in the program announcements that reinforce the "if any" and "whenand-if-available" language Questions & Answers Consideration of whether required but unspecified upgrade rights is part of post-contract customer support or a separate element of the arrangement A Software Vendor recently introduced a new premium PCS agreement for a separate fee that includes maintenance and unspecified software upgrades over the term of the premium service agreement. The premium service requires the Vendor to deliver one software upgrade per year. The maintenance under the premium service agreement is clearly part of PCS. Question: How should the required annual unspecified software upgrade be accounted for? Answer: The terms of the agreement stipulates that the customer will receive one software upgrade per year. Therefore, the if in the when-and-if criteria has not been fulfilled. Revenue should be allocated to this specified deliverable (i.e., the one unspecified upgrade element) based on VSOE of fair value and be recognized as the upgrade is delivered. If VSOE of fair value cannot be determined the entire arrangement consideration should be deferred until the only remaining undelivered element is PCS absent a specified product. Also if this arrangement requires an unspecified upgrade every year in the arrangement, the VSOE of the last specified product would need to be determined. Specified upgrades that will be included as part of PCS, with no separate charge The Vendor offers a version of a software package for $35. The Customer is advised that an update of the software will be coming out in 60 days, and, as part of the arrangement, the Customer receives the right to receive the specific upgrade for free. VSOE of the fair value of the software package is $35 (without the upgrade). The Vendor is going to offer the upgrade for free to all of its customers that are currently paying for PCS. Question: What amount of the fee should be allocated to the upgrade right? 90 PricewaterhouseCoopers LLP

Answer: It is not appropriate to allocate zero value to an upgrade right that is specified in the contract but that will be made available for free to customers paying for PCS. Note that the upgrade right is specified and therefore cannot be accounted for as PCS. Since VSOE of fair value is not available for the undelivered element of the contract, all arrangement fees would have to be deferred until the upgraded version is delivered or VSOE of fair value becomes available, assuming that all other revenue recognition criteria have been met. Observation: There are often revenue recognition implications for vendors with respect to the discussion and inclusion of product roadmaps in dealings with customers. For more detailed guidance on the implications of product roadmaps, see the further discussion of this topic in section 6.4.1. Vendor specifically states it will update software for necessary changes The Vendor licenses its payroll product along with a one-year PCS contract. The Vendor also sells renewal-period PCS contracts. Under the PCS contracts, the Vendor's business practice is to provide updates for changes in tax laws and other reporting requirements that may arise during the period that the payroll software is under a PCS contract. The Vendor also specifically states in its PCS contracts that, as necessary, it will update the payroll software for changes in tax laws. Question: Does the PCS contract involve a specified upgrade right? Answer: In conformity with SOP 97-2, specified upgrade rights are distinguished from unspecified upgrade rights and the accounting for each differs significantly. SOP 97-2 does not provide guidance that software vendors may consider when differentiating between specified and unspecified upgrade rights. However, specified upgrade rights generally relate to upgrades and enhancements that are known or expected. In the above example, the potential updates for changes in tax laws are not known, because they are outside the control of the Vendor. Additionally, in conformity with SOP 97-2, unspecified upgrade rights must be stated on a when-and-if-available basis in order to qualify as PCS. Although this is not explicitly stated in the above example, the upgrade or enhancement would not be delivered unless there were changes in tax laws, etc., that would result in the Vendor's providing an update. Because possible changes in tax laws are outside the control of the Vendor, the upgrade right is implicitly on a when-and-ifavailable basis. Further, the need to implement the change would be required with respect to the Vendor's ongoing product offering, and it is not likely that the required efforts would be significant relative to the original development effort; therefore, the incremental cost should be de minimis. Although specific facts need to be considered in each situation, the right in this example could be considered an unspecified upgrade right and accounted for as PCS. This is consistent with the AICPA Staff's views expressed in the Q&As ( TPA 5100.43). Vendor commits to maintain compliance with a platform as part of initial arrangement The Vendor enters into an arrangement to license a software package and provide PCS for one year. As part of the PCS contract, the Vendor agrees to maintain its software so that it complies with newly developed versions of Platform A. Platform A is one of two platforms on which the Vendor's software operates. www.pwcrevrec.com 91

Question: Is the contract's reference to maintaining compliance with Platform A such that it must be accounted for as a specified upgrade in conformity with SOP 97-2? Answer: Although facts and circumstances particular to each case must be considered, we do not necessarily believe that the commitment to maintain compliance with the specified platform is required to be accounted for as a specified upgrade. If the specified platform is something that the Vendor is currently focusing (and intends to continue focusing) its development efforts on, the Vendor's commitment to maintain compliance may not be considered a specified upgrade right. This is because the changes in Platform A are outside the control of the Vendor, and the Vendor would otherwise need to upgrade its ongoing product offering to deal with the changes, as discussed in the preceding example. 5.2 Additional products In practice, software arrangements often include the right to obtain specified additional products that are often similar to specified upgrade rights. A great deal of judgment must be exercised in evaluating whether an undelivered element represents an upgrade or a new product, because the accounting for each is very different. Although SOP 97-2 does not provide specific guidance on distinguishing between additional software products and specified upgrade rights, we believe that several factors should be considered: Significance of differences in features and functionality: What constitutes significant may vary. However, we believe that if the new features do not enhance the basic functionality of the software, but rather, can operate independently from the previously delivered software, this may indicate that the right relates to a product and not an upgrade. Use of the undelivered element: An additional software product generally does not supersede or replace the delivered element, whereas an upgrade frequently does. Pricing: New features and functionality that will substantially increase the price of the delivered product may indicate that the right to receive these new features and functionality relates to an additional software product. Conversely, if the new features and functionality would provide the vendor only with the ability to keep prices at a constant rate, the right to receive these would be considered an upgrade. The magnitude of the upgrade fee should also be considered. Upgrade rights are frequently priced at 10 to 20% of the original license fee when sold separately to existing users. Development effort: The more significant the development effort to create the undelivered element, the more likely it is that the element will be a product and not an upgrade. Marketing: New features and functionality offered in connection with the delivered product (i.e., as an optional or added feature of the same product) would indicate that the right to receive the features and functionality is an upgrade. Alternatively, marketing efforts that are focused solely or substantially on the new features and functionality would indicate that the right to receive these relates to a new product. Additionally, new features and functionality that are marketed toward new industries, applications, or customer bases could indicate that these rights relate to a product. Performance domain: If the undelivered element performs functions in areas outside the domain of the delivered version of a product, it is likely that the element provides a solution that the delivered product does not. This may suggest that the undelivered element is a product rather than an upgrade. Same name: If the undelivered element has the same name as the product's original version, this may indicate that it is an upgrade and not an additional product. 92 PricewaterhouseCoopers LLP

Questions & Answers Undelivered element is considered an additional product The Vendor enters into an arrangement with the Customer to license software package A for $1,000,000. The arrangement also specifies that the Vendor will provide software package B for no charge when it becomes available in a couple of months. Software package B will be licensed for $500,000 when it becomes available. The Customer will install software package A. VSOE of fair value for both software package A ($1,000,000) and software package B ($500,000) exists. Question: Is software package B considered an additional product or a specified upgrade? Answer: It would appear that software package B might be an additional product rather than a specified upgrade, because both packages will be utilized independent of each other. However, all the factors indicated in this section would need to be considered in drawing a conclusion. If it is determined that software package B is an additional product, the Vendor would recognize 66.66% of the $1,000,000 license fee or $666,666 upon the delivery of software package A (assuming that all other revenue recognition criteria have been met). The remaining $333,334 would be deferred and recognized when all revenue recognition criteria have been met for software package B. Undelivered element is considered a specified upgrade Consider the facts in the example above, however, the Vendor notes that software package B (1) enhances the current functionality of software package A, (2) will replace software package A, and (3) will actually be marketed as an improvement of software package A. Question: How would the answer be different? Answer: Software package B appears to be an upgrade of software package A. In this case, the Vendor would record only $500,000 when software package A is delivered, assuming that all other revenue recognition criteria have been met. This is because, as discussed in Chapter 6, no discount in an arrangement can be allocated to a specified upgrade right. 5.3 Specified versus unspecified additional software products SOP 97-2 distinguishes specified additional software products from unspecified additional software products. Generally, specified additional software products are evidenced by a vendor's commitment to deliver a specific product or a product with specific features and functionality. Conversely, rights to unspecified additional software products are generally such that the vendor will deliver the new products it introduces over time, without regard to specific features and functionality, since these may not be known yet. Specified additional software products, including those offered on a when-and-if-available basis, should be accounted for separately, so that a portion of the fee is allocated to the additional software products based on VSOE of fair value. If VSOE exists, revenue allocated to the additional software products should be recognized when an additional element is delivered and all of the other criteria for revenue www.pwcrevrec.com 93

recognition have been met. As with other elements, if VSOE of the fair value of the additional software products does not exist, all revenue from the arrangement should be deferred until (1) such sufficient VSOE does exist or (2) all elements of the arrangement have been delivered, whichever point comes earlier. Discounts in arrangements will again affect this allocation, as discussed in Chapter 6. Observation: TPA 5100.72 states that in situations where a customer extends/renews a pre-existing, currently active software license and licenses additional software products, the vendor should allocate the additional arrangement fees as discussed in this chapter (i.e., VSOE of fair value of the elements or residual method, as appropriate in the circumstances). The portion of the extension/renewal fee allocated to the additional software products should be recognized when all revenue recognition criteria have been met related to the additional products and when the license period for the new products has commenced. See additional discussion on license extension/renewals in paragraph section 2.2. Additional software products may be incorporated into multiple-element software arrangements in a variety of forms. In many circumstances, the fee associated with the additional software products is stated on a price-per-product basis. As stated earlier, in those situations, revenue for the additional software products should be recognized when the additional software products are delivered, assuming that there is VSOE of the fair value of each specified product. However, in other circumstances, the vendor may license its products at a specified price per copy of the software product. When such arrangements are entered into for a fixed fee and include two or more products, an allocation of the fee to the multiple products generally cannot be made, because the total revenue that is to be allocated to each product depends on the choices that the customer makes. When no allocation can be made, revenue should be recognized as each copy of the software product is delivered or until the first copy or product master of each product under the arrangement has been delivered to the customer. Assuming that VSOE of fair value exists, revenue from the price-per-copy or fixed-fee arrangements should not be fully recognized until either: Delivery is completed for all products covered by the arrangement; or The aggregate revenue attributable to all copies of the software products delivered is equal to the fixed fee, provided that the vendor is not obligated to deliver additional software products under the arrangement. At this point, all remaining license fees that were not previously recognized as revenue should be recognized, and any costs associated with subsequent duplication should be accrued. If the arrangement terminates before all of the fees are recognized under the revenue recognition criteria, then the vendor should recognize any license fees that were not previously recognized. Unspecified additional software products are sometimes included in software arrangements. Such arrangements allow customers to obtain limited new products (for example, within a family or suite of products), over a limited period. A vendor may offer customers such a right under PCS arrangements to encourage them to maintain a current service arrangement or to help customers to maintain the latest available technology (e.g., a technology protection program). These arrangements are similar to PCS arrangements. However, the rights relate to unspecified products instead of unspecified upgrades or enhancements. Therefore, SOP 97-2 precludes accounting for these rights as PCS, because the future products are unspecified such that VSOE of fair value cannot be determined for purposes of allocating the fee. If a vendor is obligated to deliver additional products only if they are available during the term of the arrangement, there may be situations in which delivery is never required. The Task Force concluded that in such situations, the deferral of all revenue to the end of the arrangement was too onerous. As a result, subscription accounting has been deemed the most appropriate method for avoiding the acceleration of revenue related to future deliverables. That is, the fee should not be allocated among any of the elements of the arrangement. Instead, the total arrangement fee should be recognized ratably over the term of the arrangement, or over the economic life of the products if no term is stated, beginning with the delivery of the first product (assuming that all other revenue recognition criteria have been met). 94 PricewaterhouseCoopers LLP

Questions & Answers Specified additional software products no limit to duplication The Vendor enters into an arrangement with the Customer for three products: Product P, Product W and Product C. The arrangement is dated December 30, X1 and has a total value of $1,000,000. Pursuant to the terms of the agreement, the Vendor can duplicate the software based on the following values, but only to the extent that the total value of all deployed seats cannot exceed $1,000,000: Software Product P Product W Product C Value $25,000 per seat $10,000 per seat $30,000 per seat Payment terms for the $1,000,000 fee are 30 days. Question: Assume that Product C was not delivered until June 15, X2 and that there were no specifications in the arrangement with regard to a maximum number of times that a particular product can be duplicated. Product P and Product W were delivered on December 30, X1. At what point have the basic criteria for revenue recognition been met? How should revenue be recognized under the arrangement? Answer: Although Product P and Product W were delivered on December 30, X1, the arrangement does not set a limit on duplication by product. Revenue recognition upon the delivery of the initial two products would result in inappropriate revenue recognition because the Vendor does not know how many seats of Product C the Customer will desire. As such, between the period of December 30, X1 and June 15, X2, the Vendor should recognize revenue as the software is duplicated by the Customer. Upon the delivery of Product C, all remaining revenue should be recognized, as the delivery criterion for all three products will have been met, assuming that all other revenue recognition criteria also have been met. This is consistent with the AICPA Staff's views expressed in the Q&As (TPA 5100.45), which concluded among other things, that in this situation, remaining revenue should be recognized when all products have been delivered. See additional discussion on TPA 5100.45 in Chapter 4. Specified additional software products limited duplication Consider the facts in the example above, however, assume that the arrangement states that, upon the delivery of Product C, the Customer can duplicate Product C a maximum of only four times. Question: When has the delivery criterion been met? How should revenue be recognized under this arrangement? Answer: Paragraph 46 of SOP 97-2 provides guidance in this situation. It states, This allocation should be made assuming that the customer will elect to receive the maximum number of copies of the undeliverable product(s). As such, the Vendor should recognize $880,000 on December 30, X1, upon the delivery of Product P and Product W. This is based on the assumption that the maximum number of copies of Product C (which is four) will be made at $30,000 per copy. The remaining $120,000 would be recognized on June 15, X2, upon the delivery of Product C. www.pwcrevrec.com 95

However, if the Customer duplicates Product P and Product W, such that the number of copies multiplied by the price per copy exceeds $880,000, the Vendor would recognize the revenue, in excess of $880,000, since the Customer has proceeded with the duplication. Specified additional software products various delivery dates and duplication is incidental Software Product A Product B Product C Price $250 per copy $400 per copy $750 per copy The fee is fixed and nonrefundable regardless of whether the Customer accepts the delivery of any or all of the products. The Customer has six months to accept the delivery of all of the products available under the arrangement. The arrangement commences on July 1, X1 and ends on December 31, X1. On July 31, the Customer accepts a delivery of 15 copies of Product A. On September 15, X1, the Customer accepts a delivery of five copies of Product C and five copies of Product A. On October 20, X1, the Customer accepts a delivery of 10 copies of Product B. Question: How should revenue be recognized under the arrangement? Answer: Revenue should be recognized based on the number of copies delivered of Product A and Product C until October 20, at which time all of the remaining fees should be recognized as follows: Date Copies Delivered Price per copy Revenue July 31 15 $250 $3,750 September 15 5 $750 5 $250 $5,000 October 20 10 $400 $6,250 $15,000 * Since Product B was the only product that was not delivered before October 20, when Product B is delivered, all of the remaining fees should be recognized because all of the criteria for revenue recognition will have been met, including the delivery criterion (as the fee is fixed and nonrefundable regardless of whether the delivery of any or all of the products is accepted). This is consistent with the AICPA Staff's views expressed in the Q&As (TPA 5100.45). Specified additional software products fixed fee with delivery of any or all Assume that the same situation as that described above, except that no further copies were requested after the July 31 delivery of Product A. Question: How should revenue be recognized? 96 PricewaterhouseCoopers LLP

Answer: The remaining revenue ($11,250 [$15,000 $3,750]) should not be recognized until December 31, X1 because the delivery was not complete for all of the products prior to December 31, X1, nor were sufficient copies of Product A, B or C ordered such that the price per copy multiplied by the copies was equal to or in excess of the fixed fee of $15,000. The remaining $11,250 may be recognized at the end of the arrangement, because the fee is nonrefundable and the Vendor has no obligation to deliver any other products. Arrangement includes undelivered product functionality Refer to the fact set, Specified additional software products - various delivery dates and duplication is incidental, for the relevant background for this scenario. Now, assume that in addition to the three products, the Vendor commits to delivering Enhancement X. Enhancement X does not directly impact the core functionality of any of the three products. Instead, it enables the three products to work more effectively in the Customer's software environment. The Customer would not have entered into the agreement without the Vendor's commitment to develop and deliver Enhancement X. Question: Has the delivery criteria of SOP 97-2 been met on December 30, X1 upon the delivery of the initial three products? How should revenue be recognized? Answer: A product is considered not to have been delivered if the delivery did not include certain products that are essential to the functionality of the delivered element, because the Customer would not have full use of the delivered element. When a product or an element of a software arrangement has been delivered but will not meet the Customer's functionality requirements until one or more additional product(s) or element(s) are also delivered, the license revenue allocated to the product or element should not be recognized until all of the elements have been delivered and the Customer has full use of them. Although it is unclear in the fact pattern whether the enhancement is essential to the functionality of the delivered element, the fee related to the delivered element may be subject to forfeiture only if Enhancement X is not delivered. It is likely that revenue under the arrangement will be recognized when Enhancement X is delivered. Unspecified additional software products The Vendor licenses its products in the form of a suite and historically has added new products to the suite. Customers may choose to become a member of the Vendor's subscriber network, which allows customers to gain access to a portion of the Vendor's Web site and to download all new product offerings in the suite. Customers pay an annual fee to become subscribers. The Vendor has determined that for its Product Suite A it will not offer any new products for a specified period. Question: Is it appropriate for the Vendor to recognize all of the product-related revenue upon the delivery of Product Suite A for those arrangements with a term that falls within the specified period for which no new product offerings are planned for Product Suite A? Answer: Vendors offering unspecified products, particularly under programs such as that described above, do so in order to ensure a constant cash flow for their investments in new products. That is, customers who enter into such arrangements willingly agree to pay an additional fee for the right to receive new products. It is unlikely that vendors would be able to market these arrangements if new products were not offered www.pwcrevrec.com 97

for extended periods. Therefore, regarding the question above, an intent on the part of the Vendor not to develop new products during the term of the arrangement does not relieve the Vendor of the requirement to recognize revenue ratably over the term of the arrangement or the economic life of Product Suite A if no term is stated, beginning with the delivery of the first product. Differences between new products and enhancements/upgrades Company A has a standing license arrangement with software provider, Company B, in which Company A receives the right to sell Company B software. In addition to the license, Company A also receives "software assurance" which entitles Company A to any new versions of the software. Company A packages the software and, resells it to its customers. Customers who purchase "software assurance" are provided with the same terms Company B provides Company A. Company A applies SOP 97-2. Question: The question is whether (a) "software assurance" is PCS and can be separated from the initial license by reference to a renewal rate for the software assurance or (b) "software assurance" provides additional products as well, therefore the arrangement should be accounted for as a subscription. The difference in accounting would be as follows: (a) the license fee can be recognized upon delivery (assuming Company A has VSOE of PCS) versus in (b) where the license fee is combined with the subscription and recognized ratably over a time period. Answer: In conformity with SOP 97-2, contract terms that provide for additional products to be delivered on a when-and-if available basis are to be recognized as a subscription. Accordingly, Company A needs to evaluate whether the "versions" that they will pass onto their customers as part of software assurance would include new products. While the versions will carry the same title, if there is a substantive software code change and dramatic functionality difference, the customer would receive a version very different than the previous. Under that circumstance, the new version would be considered a new product and the related accounting would follow the subscription model. This is the case even if historically, significant changes in versions are not made- the consideration is what does the customer have contractual rights to, not what is most probable of happening. Factors to consider in distinguishing between additional software products and specified upgrade rights are discussed in section 5.2. Recognition of up-front software license fee when no further deliverables or obligations exist Company F enters into a license agreement with a software game console maker to license certain technology to enable the console maker, at the console maker's option, to make the next generation game console. The license agreement was necessary as Company F was the sole supplier of a critical graphics chip component of the previous generation game console, but will not be the supplier for the next generation game console. In connection with the license agreement, the console maker is required to pay Company F a nonrefundable license fee of $5 million when the console maker announces the next generation game console. Although the license fee is non-refundable, the agreement notes that such fee shall be applied as an advance against, and be recoupable from, future royalties that may be due to Company F under the agreement. Company F has no further deliverables or obligations under the license agreement. Future royalties become due only if and when the console maker releases the next generation game console that includes Company F's licensed technology. The console maker may choose to release the next generation game console without Company F's licensed technology, in which case no future royalties would be due the Company. 98 PricewaterhouseCoopers LLP

Question: When should Company F recognize the up-front non-refundable $5 million license fee? Answer: The arrangement is a license of intellectual property (IP). As the IP is software, SOP 97-2 would permit the recognition of the $5 million when delivery of the IP has occurred and the $5 million is due assuming that all other criteria for revenue recognition have been met. 5.4 Intellectual property infringement indemnifications FIN 45, Guarantors Accounting and Disclosure Requirements for Guarantees, Including Indirect Guarantees of Indebtedness of Others, specifies accounting and disclosure requirements for certain guarantees. FASB Staff Position FIN 45-1, Accounting for Intellectual Property Infringement Indemnifications under FIN45 (FSP FIN 45-1), clarifies that indemnification clauses provided by software vendors to licensees are within the scope of FIN 45. FSP FIN 45-1 further concludes that because a third-party infringement claim covered by such an indemnification could impair the licensee's ability to use the licensed software (e.g., if an injunction is issued or the claim is ultimately proven), the underlying indemnification in this arrangement is related to the performance of the licensed software - that is, the licensed software cannot function as intended until the vendor cures the alleged infringement defect. Accordingly, the indemnification clause is similar to a product warranty that qualifies for a scope exception from the initial recognition and measurement provisions of FIN 45 as set forth in paragraph 7(b) of FIN 45. Although not subject to the initial recognition and measurement provisions of FIN 45, such indemnification clauses are subject to the disclosure requirements of FIN 45. In accordance with FSP FIN 45-1, a vendor is required to disclose the following information related to such indemnification clauses, if material: The nature of the guarantee provided by the indemnification clause, including the approximate term of the guarantee, how the guarantee arose, and the events or circumstances that would require the vendor to perform under the guarantee. The current carrying amount of the liability, if any, for the vendor's obligations under the guarantee (including the amount, if any, recognized as a loss contingency pursuant to paragraph 8 of FASB Statement No. 5, Accounting for Contingencies), regardless of whether the guarantee is freestanding or embedded in another contract. The nature of 1) any recourse provisions that would enable the vendor to recover any of the amounts paid under the guarantee from third parties and 2) any assets held either as collateral or by third parties that, on the occurrence of any triggering event or condition under the guarantee, the vendor can obtain and liquidate to recover all or a portion of any amounts paid pursuant to the guarantee. The vendor would need to indicate, if estimable, the approximate extent to which the proceeds from liquidation of such assets would be expected to cover the maximum potential amount of future payments that it might be required to make pursuant to the guarantee. 5.5 Undelivered elements to be provided by Third-Party Vendor A software license arrangement may include additional software or hardware that is to be provided by a third-party vendor. Oftentimes, the vendor's software will not work without this additional element. Therefore, when the third-party vendor has not delivered the hardware or software to the customer, the questions arise as to whether delivery occurred for the vendor's software since there are undelivered elements that are essential to the functionality of the delivered software. www.pwcrevrec.com 99

Assuming that all other revenue recognition criteria have been met, we believe that the revenue should be recognized upon delivery of the software if the following conditions are met: 1. the customer bargains separately and independently with the third-party vendor to provide the essential element (i.e., the vendor is not reselling the third-party vendor's essential hardware or software as part of the arrangement); 2. the vendor's fee is not subject to refund, forfeiture, or other concession if the third-party vendor fails to deliver the hardware or software; and 3. the vendor does not intend to grant and does not have a history of granting a refund, forfeiture, or other concession for any portion of the fee if the third-party vendor fails to perform. If any of the above criteria are not met, we believe that revenue recognition would be deferred until the third-party vendor's hardware or software is delivered. 100 PricewaterhouseCoopers LLP

Chapter 6: Impact of Discounts, Marketing Programs, and Barter Transactions 6.0 Overview SOP 97-2 actually says very little about discounts inherent in an arrangement. In fact, the only specific discussion of such discounts is in paragraph 11. Paragraph 11 states, If a discount is offered in a multiple-element arrangement, a proportionate amount of the discount should be applied to each element included in the arrangement based on each element's fair value without regard to the discount. An exception to this guidance is that no discount is to be allocated to upgrade rights or, if you meet the criteria of SOP 98-9, to the undelivered element (i.e., if VSOE is available for all elements then the discount is generally applied on a pro rata basis to all elements. If VSOE is only available for undelivered elements and the residual method under SOP 98-9 is being used, then no discount is allocated to the undelivered elements). The scope of SOP 97-2 (paragraph 3) also specifically excludes small discounts that a vendor offers on additional licenses of the licensed product or other products that exist at the time of the offer but are not part of the arrangement. However, the right to purchase additional licenses of the same product or additional products at more than an insignificant discount creates an additional element (see SOP 97-2, footnote 3). SOP 97-2 notes, however, that such marketing and promotional activities are not unique to the software industry. Footnote 3 to paragraph 3 of SOP 97-2 states that if the discount or other concessions in an arrangement are more than insignificant, a presumption is created that an additional element(s) (as defined in paragraph 9) is being offered in the arrangement. The question thus becomes: what is a more than insignificant discount as referred to in footnote 3 to paragraph 3 of SOP 97-2 and how should they be accounted for? AICPA TPA 5100.50 addresses this issue and notes that a discount is presumed to be more than insignificant when it is (1) incremental to the range of discounts reflected in the pricing of the other elements of the arrangement, (2) incremental to the range of discounts typically given in comparable transactions, and (3) significant. Observation: Insignificant discounts and discounts that are not incremental to discounts typically given in comparable transactions (for example, volume purchase discounts comparable to those generally provided in comparable transactions) are not unique to software transactions and are not included in the scope of SOP 97-2. Judgment is required when assessing whether an incremental discount is significant. The matter of determining when the size of a discount is so significant that it must be considered an element under SOP 97-2 has generated much discussion. For discounts that are considered significant, and therefore a separate element, an allocation of a discount to the fair values of the products that are to be licensed is required (except for specified upgrades). However, for the purpose of applying the provisions of SOP 97-2 in determining whether discounts need to be considered elements, the evaluation of the significance of any discounts that are extended to customers should be based on the software vendor's historical business practices and other vendor-specific evidence (i.e., 5% per paragraph 3 of SOP 97-2 is not intended to be the threshold for determining significance). The evaluation of significance should be made from the perspective of the customer. In other words, the difference between the discount offered and the discount that is generally offered to other customers (i.e., the difference between the contract amount and VSOE) is the amount that should be assessed for significance. This evaluation should consider, among other things, the following factors: www.pwcrevrec.com 101

How does the discounted price for the product compare to the price actually paid by the vendor's other customers? Does the discounted price result in a margin that is consistent with the software vendor's normal product margin? Does the vendor believe that the extension of the discount offer was a significant consideration in the customer's decision to purchase a license to the software? Does the vendor expect that a large percentage of customers that received the discount will use it (perhaps indicating significance)? Was the discount extended for the purpose of matching a competitor's price, either on a permanent or temporary basis? Was the discount offered to induce customers to license a current version of the vendor's product subsequent to the announcement of the release of a new version? An area that is particularly confusing and frustrating to many software vendors is the actual definition of a discount. It is rare for software and services in the software industry to be licensed/sold strictly at list price, particularly for complex, high-end software products. The actual fees received generally result from lengthy negotiations between the vendor and the customer over fairly long sales cycles. Inherent in these negotiations is a measure of give-and-take on both sides. Prices can vary significantly based on: the timing of the arrangement; the number of seats; where the product is in its life cycle; the prestige of the customer; the total volume with the customer; and the stage of vendor (e.g., early or later stage). Each of these factors can impact the negotiation and the resultant pricing of an arrangement. Two contracts involving the same product can render drastically different pricing arrangements depending on any one of these factors. The complexity of the pricing schemes in the software industry makes it difficult to determine what a discount, as contemplated by SOP 97-2, really means. It is important to remember that a discount must always be evaluated relative to VSOE of the fair value of the element in question and not its list price. Two other areas discussed in this chapter that can be cumbersome, as they relate to revenue recognition, are (1) promotional and marketing activities, including distribution of a product roadmap to customers and (2) barter transactions. The vendor's promotional and marketing activities can have a significant impact on the recognition of revenue, as in some cases, these activities may be considered an actual part of an arrangement to license software. Barter transactions, on the other hand, are not specifically addressed by SOP 97-2, but are becoming more prevalent as vendors work to expand their customer bases. Difficult accounting issues related to discounts, what considerations must be given to a vendor's promotional and marketing activities, and how to treat barter transactions are discussed in this chapter. These issues are addressed in the following manner: 6.1 Discounts 6.1.1 Multiple-element arrangements in which VSOE exists for all elements 6.1.2 Multiple-element arrangements in which VSOE exists only for undelivered elements 6.1.3 Multiple-element arrangements involving an upgrade right 6.1.4 Coupons for or discounts on future products 6.2 Volume purchase arrangements 6.3 Discounts in PCS arrangements 6.4 Impact of a vendor's marketing and promotional activities 6.4.1 Creating customer expectations of future deliverables and product roadmaps 6.4.2 Consideration paid by vendor to customer/reseller/oem 6.5 Barter transactions 102 PricewaterhouseCoopers LLP

6.1 Discounts 6.1.1 Multiple-element arrangements in which VSOE exists for all elements The practice of allocating discounts to the various elements of an arrangement is fairly straightforward if VSOE of fair value exists for all the elements. The concept is that a vendor may offer products at one price if a customer is going to buy only one product. However, if the customer intends to purchase several products, the pricing becomes more advantageous to the customer. This practice is consistent with other industries, as most customers would expect a greater discount if they were purchasing both a car and a truck than if they were purchasing a single car. If VSOE of fair value exists for all elements (delivered and undelivered) in the arrangement and none of the elements are an upgrade right (discounts are not allocated to specified upgrade rights), the vendor should total the sum of the fair values of all the elements. The vendor would then recognize revenue for the amount of the total arrangement fee that is proportionate to the aggregate VSOE of fair value of the delivered elements as compared to the total VSOE of fair value of all elements Observation: For example, a vendor enters into an arrangement involving a license, PCS services, and five days of training for $5,000. VSOE of the fair value of each of the elements is as follows: License, $4,000; PCS, $500; and Training, $1,500. The total fair value or VSOE of the arrangement is $6,000, but the total fee in the arrangement is $5,000. As such, the inherent discount is 16.7% and the allocated revenue to each element is based on a factor of 83.3% (100%-16.7%) of the VSOE of each element. If the license fee is the only revenue recognizable upon the delivery of the elements, a total fee of $3,332 ($4,000 x 83.3%) would be recognized upon delivery of the license. The remaining revenue of $1,668, or training of $1,250 ($1,500 x 83.3%) and PCS of $418 ($500 x 83.3%) would be deferred and recognized when the applicable revenue recognition criteria were met for these undelivered elements. 6.1.2 Multiple-element arrangements in which VSOE exists only for undelivered elements Normally, VSOE of fair value is not established for the software product independent of PCS as the software is seldom sold separately without PCS. SOP 98-9 provides a narrow exception to the original guidance of SOP 97-2 for situations in which VSOE exists for undelivered elements(s) (e.g., PCS), but not for the delivered element(s). SOP 98-9 allows the fair value of the undelivered elements to be deferred and the difference between the total arrangement fee and the VSOE of the undelivered elements to be assigned to the delivered element(s). Any discount in such an arrangement is allocated solely to the delivered element(s). Observation: To illustrate, assume that a vendor licenses a software package for $10,000, which includes one year of PCS. The vendor has never licensed the software without PCS, so VSOE of fair value for the license without PCS does not exist. Similar agreements indicate that there is an inherent discount in the arrangement. The VSOE of the PCS is $1,500. SOP 98-9 requires the vendor to defer $1,500 for the PCS and to recognize the difference of $8,500 on delivery for the licensing fee, even though VSOE does not exist for the license. www.pwcrevrec.com 103

6.1.3 Multiple-element arrangements involving an upgrade right For cases in which one of the elements in the arrangement is a specified upgrade right, SOP 97-2 specifically precludes the allocation of the inherent discount to the upgrade right. As noted in sections 5.1 to 5.2 of this guide, the accounting for specified upgrades is distinct from the accounting for additional products and unspecified upgrades. 6.1.4 Coupons for or discounts on future products Footnote 3 of SOP 97-2 states, if the discount or other concessions in an arrangement are more than insignificant, a presumption is created that an additional element(s) (as defined in paragraph 9) is being offered in the arrangement. How should this guidance be applied to situations in which a coupon for or discount on future products has been given? It is not an uncommon business practice for a vendor that is licensing Product A to offer a discount (sometimes in the form of a coupon) on the purchase price of Product B when a customer purchases a license to Product A. The discount, when significant, should be applied consistently to all elements of the arrangement, including future products; therefore, Product B is an additional element, to which the discount needs to be applied. It should be noted, however, that the products subject to the discount may not always be known, nor the maximum amount of the discount. AICPA TPA 5100.51 addresses how a vendor should account for incremental discounts by stating that a proportionate amount of the significant incremental discount be applied to each element covered by the arrangement based on each element's VSOE (without regard to the significant incremental discount). In addition: If (a) the future product(s) or service(s) to which the discount is to be applied is not specified in the arrangement or (b) the fair value of the future purchases cannot be determined, but the maximum amount of the incremental discount on the future purchases is quantifiable, that quantifiable amount should be allocated to the elements of the arrangement and the future purchases assuming that the customer will purchase the minimum amount necessary to utilize the maximum discount. If the maximum amount of the significant incremental discount on future purchases is not quantifiable (for example, the future purchases that can be purchased under the significant incremental arrangement are not limited by quantity of product(s) or services(s)), revenue otherwise allocated to each element covered by the arrangement without regard to the significant incremental discount should be reduced by the rate of the significant incremental discount. The portion of the fee that is deferred as a result of the significant incremental discount should be recognized as revenue proportionately as the future purchases are delivered, assuming all other revenue recognition criteria are met, such that a consistent discount rate is applied to all purchases under the arrangement. If the future purchases are not limited by quantity of product(s) or service(s), the portion of the fee that is deferred as a result of the presence of a significant incremental discount should be recognized as revenue as a subscription. Although revenue recognition in these situations should be determined on a case-by-case basis, the following factors will play an important part in each determination: Is there VSOE for the product that is covered by the discount or coupon? Is the discount predefined? Does the coupon relate to a specified element? Is the element that is covered by the discount currently deliverable? Is there a limit to the discount? Can the maximum value of the discount be quantified? 104 PricewaterhouseCoopers LLP

In situations where a vendor grants a customer a coupon (e.g., $30 off) for the purchase of a product that has not yet been developed or specifically identified, the face value of the coupon would be deferred until either (1) the vendor can objectively determine that no future products will be developed, or (2) the coupon is utilized by the customer or expires. If a discount is offered on products that are not yet developed or specifically identified, VSOE of fair value may not be available. If the discount on future purchases of future products is significant and incremental to the discount provided on the delivered elements in the initial arrangement, the vendor should apply the significant and incremental discount on future purchases to the initial arrangement using the guidance in TPA 5100.51. TPA 5100.74 provides additional guidance in situations where the vendor is required to use the residual method, as outlined in the examples below. Questions and Answers Allocation of discount when specified upgrade right present Vendor licenses software, an upgrade right, PCS, and five days of training for $10,000. VSOE of the fair value of the elements is as follows: License, $7,000; Upgrade right, $2,000; PCS, $1,500; and Training, $2,000. The total fair value of VSOE of the arrangement is $12,500. As such, the inherent discount in the total arrangement is 20% ($2,500 $12,500). Question: How should the discount be allocated? Answer: None of the discount can be allocated to the upgrade right. The inherent discount in the arrangement, without consideration of the upgrade right, is 23.8%, computed as follows: VSOE for license $7,000 VSOE for upgrade right + $2,000 VSOE for PCS + $1,500 VSOE for training + $2,000 $12,500 Total fair value of arrangement $12,500 VSOE of upgrade right -$2,000 VSOE of the other elements $10,500 Total fee from arrangement $10,000 VSOE for upgrade right -$2,000 $8,000 Calculation of the percentage discount: Fair value excluding upgrade right $10,500 VSOE excluding upgrade right $8,000 Discount $2,500 Percentage of fair value 23.8% With the upgrade right receiving a full allocation of $2,000, the remaining fee of $8,000 is allocated to the other elements in proportion to their respective VSOE. The aggregate VSOE of the other elements is $10,500 (total VSOE of $12,500 less VSOE of the upgrade right of $2,000). The difference of $2,500 www.pwcrevrec.com 105

($10,500 less $8,000) results in an inherent discount for these elements of 23.8% of VSOE ($2,500 divided by $10,500), so the revenue allocated to each of these elements is 76.2% (100.0% less 23.8%) of their VSOE. If the license is the only element delivered at inception of the arrangement, license revenue of $5,334 ($7,000 x 76.2%) would be recognized at that time. Fee amounts allocated to the PCS of $1,143 ($1,500 x 76.2%) and training of $1,524 ($2,000 x 76.2%) will be recognized as they meet the criteria for revenue recognition. The full $2,000 of VSOE of the upgrade right will be recognized upon delivery of the upgrade. Coupon ("discount") for a specific product when VSOE is known for all elements The Vendor licenses Product A for $40 and delivers it to the Customer. As part of a promotion, the Vendor licenses Product A with a right to a discount for $30 on another of its software products, Product B. VSOE of the fair value of Product A is $40, and VSOE of the fair value of Product B is $60. Product B is currently available for delivery, but has not yet been delivered. Question: How much revenue should be recorded upon the delivery of Product A? Answer: The transaction represents a multiple-element arrangement involving Products A and B. However, the $30 discount on Product B is a significant incremental discount that would not normally be given in comparable transactions. As a result, this represents a third element within this transaction, and thus, the $30 discount associated with Product B would need to be allocated to all elements of the arrangement. The result would be as follows: Elements VSOE of Fair Value Percentage of Total Fair Value Allocation Of Discount 1 Allocated Fees Product A $40 40% $12 $28 Product B $60 60% $18 $42 $100 100% $30 $70 1 A discount for $30 is allocated to Product A and Product B based on each product's percentage of total value. Assuming that all other criteria for revenue recognition have been met, when the Vendor delivers Product A, the Vendor will recognize $28 of revenue and record $12 of deferred revenue. If the Customer were to subsequently use the coupon and license Product B, the Vendor would recognize $42 upon the delivery of Product B ($30 of cash received plus $12 of deferred revenue). If the discount were to expire unused, the $12 of deferred revenue would be recognized on the expiration date. Discount for specific products when VSOE for covered elements varies The Vendor licenses Product A for $40. As part of a promotion, with each license of Product A, the Vendor gives a discount for $20 off the license of any of the Vendor's other currently available software products, Products B through Z (key here is currently available products). The VSOE of the fair value of Product A is $40, and VSOE of the fair value of and list prices for all of the Vendor's other currently available products range from $30 to $100. 106 PricewaterhouseCoopers LLP

Question: How should the discount be accounted for? Answer: Similar to the example above, this transaction is a multiple-element arrangement that includes a significant incremental discount that would not normally be given in comparable transactions. As a result, this discount represents an additional (yet unspecified) element within this multiple-element arrangement that is limited to those products that are currently available. Thus, per TPA 5100.51, the $20 discount associated with the discount would need to be allocated across Product A and the assumed purchase of whichever of Products B through Z has the lowest fair value or VSOE ($30). This is illustrated below: Elements VSOE of Fair Value Percentage of Total Fair Value Allocation Of Discount 1 Allocated Fees Product A $40 57.1% $11.43 $28.57 Other Products $30 42.9% $8.57 $21.43 $70 100% $20.00 $50.00 1 A discount for $20 is allocated to Product A and other products based on each product's percentage of total value. The overall discount is 28.57% ($20/$70). Upon the delivery of Product A, the Vendor would recognize $28.57 of revenue and defer $11. When the discount is used and the Customer purchases the additional Product with a VSOE of fair value of $30, the Vendor would recognize $21.43 in revenue upon delivery ($11 previously deferred plus additional cash license fee of $10 [$30 fair value - $20 discount]). If the discount expires unused, the $11.43 of deferred revenue would be recognized on the expiration date. Discount for unspecified products The Vendor sells Product A for $40 along with a right to a discount of 50% off list price on any future purchases of its other software products, Products B through Z, with a maximum cumulative discount of $100. VSOE of fair value for Product A is $40 and VSOE of fair value for Products B through Z ranges from $20 to $100. The 50% discount is a significant incremental discount that would not normally be given in comparable transactions. Question: How should revenue be recognized in this scenario? Answer: The Vendor should assume that the maximum discount will be utilized. Therefore, the Vendor would allocate the $100 discount across Product A ($40) and the assumed additional products to be purchased ($200 fair value for Products B through Z purchased in order to generate a maximum discount of $100). The overall discount is 41.67% ($100/$240). Therefore, upon the delivery of Product A, the Vendor would recognize $23.33 of revenue and defer $16.67. If the Customer uses the discount by purchasing additional products with a fair value totaling $200, the Vendor would recognize $116.67 in revenue upon delivery of those products ($100 in cash received plus the $16.67 previously deferred). If the discount expires unused, the $16.67 in deferred revenue would be recognized at that time. www.pwcrevrec.com 107

Discount offered on future purchases - maximum determinable The Vendor sells Product A for $60, which represents a 40% discount off its list price (VSOE) of $100. In the same transaction, it also provides the right to a discount of 60% off of the list price (VSOE) on any future purchases of units of software Product B for the next six months with a maximum discount of $200. The discount of 60% on future purchases of units of Product B is a discount not normally given in comparable transactions. Question: How should revenue be recognized in this scenario? Answer: Because the discount offered on future purchases of Product B is not normally given in comparable transactions and is both significant and incremental in relation to the 40% discount, it must be accounted for as part of the original sale. The Vendor should assume that the maximum discount will be utilized. Therefore, the Vendor would allocate the $240 discount ($40 discount on Product A and $200 maximum on future purchases) across Product A and the assumed additional products to be purchased. The overall discount is 55.38% ($240/$433.33)($433.33 is the sum of the $100 list price of Product A and the $333.33 accumulated list price of Product B that results in a maximum discount of $200). Therefore, upon the delivery of Product A, the Vendor would recognize $44.62 of revenue and defer $15.38. If the Customer uses the discount by purchasing additional products with fair value totaling $333.33, the Vendor would recognize $148.71 in revenue upon delivery of those products ($133.33 in cash received plus the $15.38 previously deferred). If the discount expires unused, the $15.38 in deferred revenue would be recognized at that time. Discount offered on future purchases - no maximum determinable The Vendor sells Product A for $40 along with a right to a discount of 50% off list price on any future purchases of its other software products, Products B through Z, with no maximum cumulative discount. VSOE of fair value for Product A is $40 and VSOE of fair value (which equals list price) of Products B through Z ranges from $20 to $100. The 50% discount represents a significant incremental discount that would not normally be given in comparable transactions. Question: How should revenue be recognized in this scenario? Answer: The Vendor should apply the 50% discount to Product A and all future products purchased using the discount. Therefore, upon the delivery of Product A, the Vendor would recognize $20 of revenue and defer $20. If the Customer purchases additional products using the discount, the Vendor would recognize revenue equal to the cash received upon the delivery of those products. The previously deferred $20 should be accounted for as a subscription in accordance with paragraphs 48 and 49 of SOP 97-2 and recognized pro rata over the discount period or if no period is specified in the arrangement, over the estimated period during which additional purchases will be made. Guaranteed discount on list prices The Customer licenses the Vendor's software for five sites. As part of the contract, the Vendor agrees to guarantee the Customer a 10% discount off the list price of all currently available products for purchases made by the Customer over the next two years. The Vendor generally sells its currently available products at an average discount of 10-20% off list price. 108 PricewaterhouseCoopers LLP

Question: How should this discount be treated if VSOE of fair value exists for all currently available products? Answer: This future discount would not affect the revenue recognition on the software license for the five sites if the Vendor can determine that the 10% discount off the list price does not represent a significant incremental discount relative to the VSOE of fair value of products that could be covered by the arrangement. In effect, the guaranteed reduction of the list price is not indicative of a true discount in this situation because other customers could obtain the same products at the same price. As discussed previously, under TPA 5100.50, the discount on future purchases in this arrangement is not incremental to the discount inherent in the current arrangement, or in comparable transactions, and therefore does not result in any accounting in the original sale for the discount offered on future purchases. Time-bound discount on yet-to-be-developed products On December 31, 20X1, the Vendor licenses Product A (with a published list price of $100) on a perpetual basis, bundled with PCS for the first year, to a Customer for $80. The Vendor does not have VSOE of fair value for its software products. The Customer may elect to renew PCS following the initial year at a stipulated rate of $15. In conjunction with the licensing of Product A, Software Vendor offers the Customer a 55% discount off of its published list price on the purchase of all new products to be released during the three years subsequent to December 31, 20X1, with no maximum cumulative discount. Question: How should the discount on future products be accounted for? Answer: Based on the guidance in TPA 5400.74, the Vendor would perform the calculation below to assist in determining whether the discount offered on future purchases of future products is significant and incremental (as discussed in TPA 5100.50): Published List Price Residual Value Discount From Published List Price Product A $100 $65 35.00% Future Products Unknown Unknown 55.00% Additional discount from published list price 20.00% Assuming that the software vendor concludes that the additional discount (that is, 20.00% in this example) on future purchases is significant and incremental, the Vendor should allocate such discount to Product A and defer revenue related to the PCS in the initial arrangement as follows: Published List Price Additional Discount Revenue Deferral For Additional Discount Revenue Deferral For PCS Total Revenue Deferral Arrangement Fee Up-front Revenue Product A $100 20% $20 $15 $35 $80 $45 Consistent with Example 5 in TPA 5100.51, upon delivery of Product A, the Vendor should recognize $45 of revenue and defer $35, provided all other requirements of revenue recognition in SOP 97-2 are met. The revenue related to PCS ($15) deferred pursuant to the residual method should be recognized over the initial year of the license in accordance with paragraph 57 of SOP 97-2. The deferred revenue related www.pwcrevrec.com 109

to the discount ($20) should be accounted for as a subscription in accordance with paragraphs 48 and 49 of SOP 97-2 and recognized pro rata over the three-year discount period. If the Customer purchases additional products using the discount, the Vendor would recognize revenue equal to the fee attributable to those additional products, provided all other requirements of revenue recognition in SOP 97-2 are met. One-time discount on specified future product Assume that the facts in the example above pertain here as well, except that the Vendor offers the Customer a 55% discount off of its published list price on the purchase of Product B once it has been developed, instead of all new products released by the Vendor. Question: How should the discount on the future product be accounted for? Answer: Based on the analysis performed above, the Vendor has concluded that the incremental discount of 20% is significant and incremental and the deferred revenue has been calculated as per the above calculations. However, in this case, the deferred revenue related to the discount on the future purchase of Product B would be recognized upon the earlier of the offer's expiration or the utilization of the offer by the Customer, as the discount is for a one-time purchase of a specified product. The deferred revenue would not be recognized over the discount offer period as it relates to a discount offered on the one time purchase of a specific product. Purchase right for specified future product Assume that the facts in the example above pertain here as well, except that the Vendor offers the Customer the right to purchase Product B at a fixed price once it has been developed, instead of discounting all new products to be released. Question: How should the fixed price purchase right be accounted for? Answer: Because the Vendor has not established the list price or fair value of Product B, it is undeterminable whether a discount exists for the future purchase right of Product B. As a result, the Vendor cannot ascertain whether a significant incremental discount exists, which would result in an additional element. Therefore the Vendor should defer the entire arrangement fee until the earlier of: (a) the Vendor can establish fair value for Product B, which would allow the Vendor to determine whether a more than incremental discount exists in the arrangement, (b) the right to purchase Product B lapses, or (c) the Vendor delivers Product B. Observation: The establishment of fair value prior to the introduction of the software product into the market can be difficult. Refer to Chapter 5 for a more detailed discussion of this topic. 6.2 Volume purchase arrangements A volume purchase arrangement (VPA) is an arrangement in which the price per seat or per license of software decreases as the number of a customer's seats or licenses increases. This type of situation may result from a contract in which there is wording such as the Customer can license 1,000 seats of software for $100 blended cost per seat today and has the option to license an additional 500 seats at 110 PricewaterhouseCoopers LLP

$50 per seat, if such option is exercised by June 30, X2. However, a vendor may offer the customer the ability in the future to purchase additional copies of delivered software. TPA 5100.50, which addresses the definition of more-than-incidental discounts, also clarifies the accounting for discounts granted by the vendor on future purchases of additional copies (seats) of delivered software. TPA 5100.50 states that the provisions of footnote 3 to paragraph 3 of SOP 97-2 (as discussed in section 6.0 should not be applied to an option within an arrangement that allows the customer to purchase additional copies of products licensed by, and delivered to, the customer under the same arrangement. Revenue should be recognized as the rights to additional copies are purchased, based on the price per copy as stated in the arrangement. Additional copies of delivered software are not considered an undelivered element. Paragraph 21 of SOP 97-2 says that duplication of software is considered incidental to an arrangement, and the delivery criterion is met upon the delivery of the first copy or product master. Questions and Answers Volume pricing "discounted" additional seats or licenses granted to all customers The Vendor and the Customer enter into an arrangement on June 30, X1, whereby the Customer purchases licenses for 10,000 seats of Product D for $1,000,000 ($100 per seat), with an option to license additional seats of Product D at a later date. No PCS, services, or other elements are included in the arrangement. The product master is delivered to the Customer on June 30, X1. The only potential future deliverable is a "key" that would unlock the additional seats if the option were to be exercised. Question: Consider that the Vendor is an established software company and it closes numerous deals of this volume every quarter. The option states that "the Customer has the option to purchase licenses of Product D for an additional 50,000 seats for $2,500,000 ($50 per seat), if this option is exercised by December 31, X1." The Vendor has a standard price list that allows for this type of pricing for volume purchases. The Vendor does not have evidence that supports a business practice (for deals of this size) of granting this pricing to all customers. How should revenue under the arrangement be recognized upon the delivery of the product if the option is exercised on December 31, X1 and the "key" is e-mailed to the Customer on that day (assume that all other criteria for revenue recognition have been met)? Answer: As the Vendor set the pricing for additional copies of the software already licensed and delivered to the customer in the original terms of the arrangement ($50 per seat), in accordance with TPA 5100.50, revenue can be recognized as the rights to additional copies are purchased based on the price per copy as stated in the arrangement. This would allow for the recognition of the $2,500,000 on December 31, X1, when the customer exercised the option. The option to buy additional seats of the delivered software is not considered another element of the arrangement as the license has already been delivered and the duplication of software is considered incidental to an arrangement. The delivery criterion is met upon the delivery of the first copy or product master. 6.3 Discounts in PCS arrangements Discounts related to PCS may be negotiated for a variety of business reasons. A vendor may want to induce the customer to license seats upfront by offering volume pricing and then negotiating PCS pricing based on the actual deployment of seats. Another reason a vendor may be willing to accept such a pricing structure is that it may believe that this type of structure will simulate the effort that the vendor expects to expend in providing the customer support element of PCS. www.pwcrevrec.com 111

In connection with a new arrangement to license software, a vendor may offer an initial period of PCS for free or offer to provide a renewal period of PCS for a fee that is lower than that charged to existing customers. In those situations where renewal rates are not used to establish VSOE of fair value (i.e., not substantive), the arrangement should be evaluated to determine whether the discount offered on the initial-period PCS or on PCS supplied the subsequent year is a discount element to which a portion of the total fee should be allocated. Arrangements that are accounted for by either the percentage-of-completion method or completedcontract method described in SOP 81-1 often provide free maintenance during and after the implementation of the software. See Chapter 9 for a discussion of the accounting for PCS in these types of situations. Observation: When discounted PCS is offered as part of an arrangement, the timing of the recording of revenue is clearly impacted. Specifically, the amount of revenue recorded upon the delivery of a product will be reduced, because of the allocation of the discount to the license fee. Questions and Answers PCS discounted PCS in the initial contract in which renewal rates are not used to establish VSOE of fair value The Vendor enters into an arrangement with the Customer to deliver Product A and to provide PCS for a period of one year for a nonrefundable fee of $100,000. In addition, the arrangement specifies that the Customer may renew the PCS for an additional one-year period for $10,000. The VSOE of the fair value of Product A and the annual fee for PCS related to the product both exist and are $80,000 and $20,000, respectively. Question: In the renewal offer, is there a discount that must be considered? If so, how should the Vendor account for the arrangement? Answer: The Vendor has offered a discount of $10,000 ([$80,000 + $20,000 + $20,000] - [$100,000 + $10,000] = $10,000) on the renewal-period PCS that needs to be accounted for in the allocation of the fee of $100,000 to the elements covered by the arrangement. Based on VSOE of the fair value of all the elements, the allocation would be as follows: VSOE of Fair Value Percentage of Total Fair Value Allocation of Discounts Allocated Fees Product A $80,000 66.6% $6,660 $73,340 Initial-Period PCS $20,000 16.7% $1,670 $18,330 Renewal-Period PCS $20,000 16.7% $1,670 $18,330 $120,000 100% $10,000 $110,000 The portion of the fee allocated to Product A ($73,340) would be recognized upon the delivery of the product, assuming that all of the other criteria for revenue recognition have been met. The fee allocated to the initial-period PCS would be deferred and recognized ratably over the one-year PCS term. The discount allocated to Product A and the renewal-period PCS would be deferred until the Customer 112 PricewaterhouseCoopers LLP

renews the PCS, and then recognized ratably over the PCS term together with the additional $10,000 PCS payment. If the Customer notifies the Vendor that it will not renew the PCS arrangement, the deferred revenue would be recognized at that time. Discounted PCS offered based on expected deployment of licenses where VSOE exists for all elements The Vendor enters into an arrangement with the Customer for a license fee and three years of PCS for $100,000 (license fee), $5,000 (Year 1), $10,000 (Year 2), and $15,000 (Year 3), respectively, for a total fee of $130,000. The pricing structure is intended to mirror the Customer's deployment of seats over the next three years. The annual renewal rate for PCS in year four is (1) expected to be (and currently is) $15,000 and (2) considered to be VSOE of the fair value of the PCS. VSOE of the fair value of the license has been established as $100,000. The total fee is paid up-front. Based on the total VSOE of the fair value of $145,000 ($100,000 for the license and $45,000 for the three years of PCS), there is a $15,000 discount built into the arrangement. Question: How should the discount be allocated and the revenue from the arrangement be recorded? Answer: As VSOE of the fair value of each element is available, the total fees of $130,000 should be allocated as follows: VSOE of Fair Value Percentage of Total Fair Value Allocation of Discounts Allocated Fees License $100,000 68.98% $10,347 $89,653 PCS Year 1 $15,000 10.34% $1,551 $13,449 PCS Year 2 $15,000 10.34% $1,551 $13,449 PCS Year 3 $15,000 10.34% $1,551 $13,449 $145,000 100.00% $15,000 $130,000 The $89,653 should be recorded as revenue upon the delivery of the product, assuming that all other criteria for revenue recognition have been met. The fees allocated to the periods covered by PCS ($40,347) should be recorded as PCS revenue and in the amount of $13,449, during Years 1, 2 and 3. Observation: Discounted PCS based on deployment is a fairly common practice and some might argue that VSOE of PCS is justifiably less in the years 1 and 2 in the example above because fewer users have deployed the software. Those who make this argument would not defer license revenue due to discounted pricing of the PCS because they believe the discounted PCS reflects fair value. It is extremely rare to have VSOE for the discounted rates as PCS of this type would not be sold separately. TPA 5100.44 indicates that the predetermined renewal rate is the only indicator of fair value because it is the only arrangement under which PCS is sold separately, and therefore, it should be used to establish VSOE of fair value of the PCS. In this situation, in which there is no VSOE for the license and the residual method is used, the vendor should initially defer the portion of the arrangement fee related to the three years of PCS provided under the arrangement based on the predetermined renewal rate. www.pwcrevrec.com 113

Discounted PCS offered or expected deployment with only VSOE of the fair value of the PCS element Assume that the facts in the above example also pertain here, except that VSOE of the fair value of the license fee does not exist because the Vendor always licenses the software with PCS. This is normally the case with software vendors, as they do not usually sell software licenses without the PCS. Question: How should the discount be allocated? Answer: This specific situation represents the narrow exception permitted in SOP 98-9 known as the residual method and is further exemplified by TPA 5100.44. As VSOE of fair value is available for only the undelivered elements through the use of a predetermined renewal rate, the entire discount should be applied to the delivered element. This would result in only $85,000 of license-fee revenue being recorded at the time of the product's delivery, assuming that all other revenue recognition criteria have been met. Consequently, $45,000 of the fees from the arrangement would be deferred and recognized ratably over the three-year period of PCS covered by the arrangement. PCS discounted maintenance with a "free" software product Assume that the facts the above example pertain here as well, except that the Vendor offers three years of PCS for $45,000 and includes the software license for no charge. Assume that VSOE is available for all elements, as previously stated. Question: How should the discount be allocated? Answer: As VSOE for each element is available, the total fee of $45,000 should be allocated as follows: VSOE of Fair Value Percentage of Total Fair Value Allocation of Discounts Allocated Fees License $100,000 68.98% $68,980 $31,020 PCS Year 1 $15,000 10.34% $10,340 $4,660 PCS Year 2 $15,000 10.34% $10,340 $4,660 PCS Year 3 $15,000 10.34% $10,340 $4,660 $145,000 100.00% $100,000 $45,000 The $31,020 should be recorded as revenue upon the delivery of the product, assuming that all other criteria for revenue recognition have been met, including the "fixed or determinable" criterion discussed in Chapter 2. The fee allocated to the periods covered by PCS ($13,980) should be recorded as PCS revenue, in the amount of $4,660 in Years 1, 2 and 3. Observation: The effect of this methodology is the creation of license revenue, even though the contract stated that the license was granted for free. 114 PricewaterhouseCoopers LLP

6.4 Impact of a vendor's marketing and promotional activities 6.4.1 Creating customer expectations of future deliverables and product roadmaps Customers of software vendors have a tendency to view the licensing of software as part of a long-term relationship with (or even an investment in) the software vendor rather than as the purchase of a discrete product. Consequently, a software vendor's customers often want a relationship that will involve more than just a straightforward purchase of currently available products and services. As part of its marketing efforts, a software vendor's plans for future software product releases and the strategic direction of software development initiatives, commonly referred to as product roadmaps, may be referenced or published in various forms, including (but not limited to) product development plans, press releases, information on the vendor's website, marketing materials, and executive presentations. These communications may influence the customer's decision to select that particular vendor's software over the software product of another. In such cases, customers may believe that development efforts and strategies are part of what they are buying thereby the vendor has created an expectation that there will be future deliverables and/or specified upgrades and enhancements. These factors and others have sparked much debate and have caused consideration to be given to the impact that marketing and promotional activities have on a vendor's analysis of various aspects of SOP 97-2, specifically whether such activities results in either an implied or explicit deliverable to which fair value should be ascribed. Software vendors should review their marketing and promotional materials (including the vendor's Web site) and activities to evaluate whether customers could believe that commitments to develop or deliver products or specified upgrades and enhancements outside a written arrangement are being made implicitly. For example, a vendor may announce that it plans to release its product on a new platform. This announcement may significantly impact a customer's purchasing decision, if the customer is in the process of migrating (or plans to migrate) to that platform. A determination of the impact that marketing and promotional activities (including the vendor's Web site) have on software revenue recognition has been and likely will continue to be highly subjective. In addition, this area continues to receive scrutiny from the SEC. As discussed throughout this publication, the legal requirements of an arrangement, while important, represent only one factor in the analysis. Another important factor is also represented by a vendor's customary business practices, particularly if the customer in question is considered a prestigious reference account. It is essential that regardless of what a contract states, the vendor understands what the customer is really buying: the products that are being delivered or the products that are discussed in the vendor's marketing materials. Vendors should also ensure that sales and marketing personnel fully understand the ramifications of oral commitments made to customers with regard to future product development and product deliverables, if such commitments increase the likelihood that the vendor will make concessions in the future. 6.4.2 Consideration paid by vendor to customer/reseller/oem Software vendors often enter into reseller or OEM arrangements which require the software vendor to pay its customers (reseller or OEM) for their marketing efforts related to the software vendor's product or the OEM product which embeds the software vendor's product. Although SOP 97-2 does not address these items specifically, EITF 01-09, Accounting for Consideration Given by a Vendor to a Customer/Reseller, addresses the accounting for these types of arrangements. Generally, EITF 01-09 presumes any consideration paid (including cash, credits or equity) by a vendor to a customer/reseller is a reduction of revenue unless the vendor receives a separate and identifiable benefit such that the vendor could have entered into an exchange transaction with a party other than a purchaser of its products in order to receive that benefit and the fair value of such benefit is determinable. www.pwcrevrec.com 115

Questions and Answers Communication of product roadmap to customer Vendor A enters into a contract with Customer B to provide software product X. The transaction does not include the right to receive future when-and-if available updates/upgrades. As part of its sales and marketing efforts, Vendor A also communicates its product development roadmap to Customer B. Note that at the time of sale to Customer B, neither Vendor A nor Customer B anticipates any updates/upgrades related to the software product purchased by Customer B in the near future. Question: Does the discussion of the product development roadmap create a specified upgrade right? Answer: No. Although the discussion of the product development roadmap may have influenced Customer B's decision to purchase Vendor A's software, since it did not purchase the right to receive future when-and-if available updates/upgrades, the sharing of the product development roadmap would not give Customer B an expectation of a deliverable. In other words, in the event Vendor A releases any updates/upgrades to software X, Customer B would make an independent buying decision whether to purchase the updated product. Observation: On the other hand, if the customer had purchased the right to receive when-and-if available updates/upgrades, the inclusion of the product roadmap may result in the creation of a deliverable because Customer B would be entitled to receive all future updates/upgrades. The product roadmap may create a specified upgrade right. Determining whether a specified upgrade right has been created is a matter of judgment. Consider the following indicators: Was the product roadmap customized for the customer? Customization is an indicator that the vendor has committed to deliver a specified upgrade. Does the product roadmap contain a high degree of specificity, including features, functionality and the timing of the release, such that it is reasonably likely to have created an expectation by the customer that the customer will receive a specific upgrade/enhancement? Judgment is required to determine to what extent specificity may indicate existence of a deliverable. Are the items on the product roadmap essential to the functionality of other deliverables in the arrangement? Interdependence may indicate a specified upgrade, or may affect the vendor's assessment of the delivery criterion in SOP 97-2. Does the arrangement contain explicit language stating that the items on the product roadmap are truly when-and-if available, and the customer will have to purchase the items separately in the future? Consideration should be given to whether the vendor's verbal communications are consistent with the written limitations. Is the product roadmap generally made available to new and existing customers via the website, or other marketing material? A roadmap that is generally available to non-customers and customers alike would not be a deliverable specific to the arrangement with the customer, and therefore should not affect the allocation of revenues. 116 PricewaterhouseCoopers LLP

Marketing development funds provided to reseller A marketing development fund (MDF) is provided to a reseller of a Vendor's products to reimburse the cost the reseller expects to incur related to the vendor brand/ product awareness. The reseller is not required to provide any accounting as to how it spends the MDF (i.e., no supporting documentation is required to be provided). Question: How should the Vendor account for payments made to the reseller for this MDF? Answer: In accordance with EITF 01-09, the payments would be treated as an offset to revenue, as no identifiable benefit is generated for the Vendor that is sufficiently separable as the MDF would only be provided to a reseller of the Vendor's product. If the structure of the MDF were set up such that the Vendor paid specific bills of the reseller this could result in no offset to revenue. Cash incentive paid to reseller's sales representatives The Vendor initiates an incentive program whereby Reseller A's sales representatives are eligible to receive a cash incentive directly from the Vendor if certain sales quotas are met. The program is communicated by Reseller A to its sales representatives. All payments made by the Vendor directly to the sales representatives are reported on Form 1099's for tax purposes. Question: How should the Vendor account for cash payments made to Reseller A's sales representatives? Answer: The scope of EITF 01-09 (paragraph 2) includes vendor consideration paid to any purchaser of a vendor's products at any point in time along the distribution chain, even if the purchaser is not the direct customer of the vendor. The scope was intended to be broad and includes substantially all payments made by a vendor to a third party with the intent to sell the vendor's products. Accordingly this cash incentive program is subject to the guidance in EITF 01-09. Although Reseller A's sales representatives are receiving payment from the Vendor, the purpose of the cash incentive is to stimulate demand of the Vendor's products. Therefore the payments to Reseller A's sales representatives are tantamount to direct payments from the Vendor to Reseller A and are within the scope of EITF 01-09. According to paragraph 9 of EITF 01-09, cash consideration given by a vendor (i.e., Vendor) to a customer is presumed to be a reduction of the selling price of the vendor's products or services and should be recorded as a reduction of revenue unless the vendor (1) received an identifiable benefit in exchange for the consideration, and (2) the fair value of the benefit can be reasonably estimated. With respect to criterion 1, EITF 01-09 further indicates that the benefit received must be sufficiently separable from the customer's purchase of the vendor's products such that the vendor would have paid a party other than the purchaser of its products in order to receive the benefit. In this case, the benefit beyond the sale of Vendor's products cannot be identified nor objectively valued, thus Vendor should account for the cash incentive program as a reduction of revenue. In accordance with paragraph 22 of EITF 01-0-9, the cost of a sales incentive offered voluntarily by a vendor and without charge to a customer that will not result in a loss on the sale should be recorded at the later of (1) the date at which the related revenue is recognized by the vendor, or (2) the date at which the sales incentive is offered. Because Vendor recognizes revenue at a later point in time than when the www.pwcrevrec.com 117

program was offered, Vendor should record the estimated cost of providing the program as a reduction in revenue when the revenue is recorded. Vendor would need to estimate the cost of the program because the sale of the products to Reseller A would precede the sale by Reseller A to the ultimate customer and the incentive payment to Reseller A's sales representatives. Cash incentive paid to selling agent's sales representatives Assume the same facts as above, however Reseller A is a net reporting entity or effectively the agent of the Vendor. Question: How should the Vendor account for cash payments made to Reseller A's sales representatives? Answer: Because Reseller A is not considered a customer of Vendor, the transaction would not be within the scope of EITF 01-09 because the payment is being made to someone other than a customer. The payment would be classified as a commission expense rather than a reduction of revenue. Observation: The above examples are only a few of many potential scenarios in which software vendors are providing consideration to their customers/resellers/oems that may lead to an offset to revenue. Careful consideration to all the facts and circumstances should be given to any arrangements involving vendor consideration paid to customers/resellers/oems. EITF 01-09 allows for expense classification for these payments only in cases where there is an identifiable, separate benefit and fair value is established or where the form of consideration is "free" products or services. Careful up-front structuring of some of these arrangements can prevent the offset to revenue treatment. 6.5 Barter transactions Although SOP 97-2 does not specifically address the accounting for exchanges of one software product for another software product or other nonmonetary elements (e.g., hardware, services), these types of transactions have become more common. These transactions are frequently referred to as swaps, barter transactions, or roundtrip transactions. Accounting Principles Board Opinion No. 29 (APB 29), Accounting for Nonmonetary Transactions, addresses the accounting for nonmonetary transactions. In addition, the FASB's EITF addressed barter transactions in Issue No. 93-11 (EITF 93-11), Accounting for Barter Transactions Involving Barter Credits, as well as in EITF 01-02, Interpretations of APB Opinion No. 29. Lastly, the AICPA issued TPAs 5100.46 and.47 as additional guidance for applying SOP 97-2 in this area. Each of these pronouncements should be referred to when determining the proper accounting treatment for these types of transactions. APB 29 acknowledges that there are basically two types of nonmonetary exchange transactions: (1) an exchange that culminates the earnings process and (2) an exchange that does not culminate the earnings process. To properly account for barter transactions, vendors need to determine what type of transactions they are dealing with. APB 29 provides additional guidance on determining what exchanges do not culminate the earnings process. Paragraph 21 of APB 29 (supported by TPA 5100.46) states the following: The Board believes that the following two types of nonmonetary transactions do not culminate an earnings process: An exchange of a product or property held for sale in the ordinary course of business for a product or property to be sold in the same line of business to facilitate sales to customers other than the parties to the exchange; and 118 PricewaterhouseCoopers LLP

An exchange of a productive asset held for sale in the ordinary course of business for a similar productive asset or an equivalent interest in the same or similar productive asset. Observation: The presumption exists that the exchange of one software product that is offered for sale to customers for a different software product to be sold to customers (even if vastly different) is considered to be an exchange in the same line of business to facilitate sales to customers and therefore it does not represent the culmination of an earnings process. We expect that situations in which such an exchange would represent the culmination of an earnings process would be rare, particularly when software is exchanged between software vendors in ther ordinary course of business (i.e. inventory). In situations where software is exchanged for internal use and not resale to customers, judgment should be applied in considering if such an exchange represent the culmination of an earnings process, applying the considerations discussed within this section as well as FAS 153, Exchanges of Nonmonetary Assets, an amendment of APB Opinion No. 29. In accounting for barter transactions, companies need to consider the following factors: Has the earnings process reached culmination? Is the software or other element(s) intended for (1) use in the company's operations or (2) resale to its customers? Does the business purpose for each party in the transaction make economic sense? Is fair value reasonably determinable (i.e., fair value of the software given up, or value of products received, as if the vendor had received or paid cash)? If (1) there is a valid business purpose for the transaction, (2) it is determined that the vendor or customer will be using the software and/or other element(s) in its respective operations, and (3) the vendor has considered item (b) above, the vendor may conclude that there has been a culmination of the earnings process. In such cases, revenue may be recognized based on the fair value of the transferred software and/or other element(s) (the fair value of the assets received should be used if it is more clearly evident ). Observation: When analyzing the business purpose of a transaction, entities should consider each party's intention with respect to utilizing the assets or services received. If an enterprise does not immediately intend to use the asset or services received or does not have a need for such benefits in its business that reflects the value assigned to them in the transaction, the earnings process may not have culminated. Another factor that might indicate whether revenue should be recorded is whether PCS is being purchased. If so, this would probably suggest that the earnings process has been completed, because the customer is purchasing support services for any property that is received in the exchange. Similarly, if installation has been completed, this might suggest that the earnings process is complete. When (1) the fair value of the products and other elements that are exchanged cannot be reasonably determined or (2) the earnings process has not culminated, the exchange should be recorded at the amount at which the vendor's assets were recorded on its books. APB 29 states that when major uncertainties exist about the realizability of the value that would be assigned to an asset received in a nonmonetary transaction accounted for at fair value, fair value should not be regarded as reasonably determinable. Observation: Barter transactions should be carefully evaluated, as the facts and circumstances of each transaction will vary. Determining fair value is a critical step in selecting the appropriate accounting method and may require considerable investigation and judgment. Vendors must also be aware that, under APB 29, they may be required to disclose these transactions in the financial statements, as well as the basis of accounting for the assets transferred and any gains or losses that have been recognized. www.pwcrevrec.com 119

When exchanges that would otherwise be based on the recorded amounts (as discussed in this section above) include an amount of monetary consideration, paragraph 22 of APB 29 states that the recipient of the monetary consideration has realized a gain on the exchange to the extent that the amount of the monetary receipt exceeds a proportionate share of the recorded amount of the asset surrendered. The accounting for these situations is very fact-specific. All of the facts and circumstances of a given transaction should be understood and reviewed in light of APB 29, EITF Issue 93-11 and TPAs 5100.46 and 47. The following matrix summarizes TPAs 5100.46 and 5100.47: Software Vendor's Technology Exchanged Software product held for sale in the ordinary course of business (i.e., inventory) 1 Software product held for sale in the ordinary course of business (i.e., inventory) Software Vendor's Use of Technology Received Same Line of Business Accounting Treatment Technology to be held for sale in the ordinary course of business (i.e., inventory) 2 1. Yes 2. No 1. Record at historical cost. 2. Record at fair value 3 Internal-use software 4 N/A 3. Record at fair value 3 1 Licenses to software products, source code, and object code that the software vendor sells, licenses, or leases in the ordinary business would constitute inventory. course of 2 A software vendor that receives any of the following would be receiving inventory: i. a product to resell, sublicense, or sublease; ii. a right to embed the technology received into a product; or iii. a right to further develop the technology received into a product. 3 Assumes that fair value is determinable and the transaction has a business purpose. 4 A software vendor that receives any of the following would be receiving something other than inventory: i. a product or technology that only can be used internally (e.g., a financial or management application); or ii. a product or technology that only can be used internally to make a product but which does not become part of the product. Observation: As mentioned previously, we believe it is rare that the exchange of one software product that is offered for sale to customers for a different software product to be sold to customers (even if vastly different) would be considered to be an exchange in the same line of business to facilitate sales to customers that represents the culmination of an earnings process. Questions and Answers Barter transaction software license exchanged for advertising services The Vendor agrees to license software package A to the Customer in exchange for the right to advertise on the Customer's Web site. Question: How should the Vendor account for this transaction? Answer: In determining whether this transaction represented the culmination of the earnings process, the Vendor's business purpose for doing this transaction would need to be evaluated. The following factors, while not all-inclusive, may be important in this analysis: 120 PricewaterhouseCoopers LLP

Does the Vendor normally advertise in the manner received in the exchange? Does the arrangement specify when the advertising will take place? Has the Vendor entered into these types of transactions before? Is the fair value of the software readily determinable (i.e., VSOE of fair value of software given up)? the fair value of the advertising readily determinable? Does the timing of the advertising coincide with the Customer's use of the software? If the answers to any of these questions is no, this would suggest that the fair value was not readily determinable and that the business purpose was not clear, and thus no revenue should be recognized. If, however, the answer to each is yes, this may suggest that there is a valid business purpose for the transaction and that revenue may be recognized. Barter transaction software license exchanged for property to be used in operations The Vendor enters into an agreement with the Customer whereby the Vendor will give the Customer a single software license in exchange for 100 of the Customer's personal computers. The Vendor is going to use the personal computers in its operations, and the Customer will use the Vendor's software in its operations. The computers and the software have been sold/licensed prior to this transaction and their values are readily determinable. Question: How should the Vendor account for this transaction? Answer: All of the factors surrounding the transaction (similar to those mentioned in the preceding example) would have to be considered. However, based on the fact set above, it would appear that the earnings process has been completed because the Customer exchanged property held for sale (100 personal computers) for a productive asset (software license), which were used by the Customer as an amortizable asset. Revenue could be recorded at an amount equal to the fair value of whichever side of the transaction is more evident. The computers would be capitalized according to the Vendor's normal fixed-asset capitalization policies. This is consistent with the conclusions in TPA 5100.47. In accordance with TPA 5100.47, providing that the fair value of either of the nonmonetary assets involved in the transaction can be determined within reasonable limits, the Vendor should record the exchange at fair value. Thus, if the exchange is concluded to be the culmination of the earnings process that exchange should be recorded at fair value provided that: 1. the fair value of the technology/products exchanged or received can be determined within reasonable limits (that is, VSOE of fair value of the software given up, or the value of the technology/products received, as if the software Vendor had received or paid cash); and 2. the technology/products received in the exchange are expected, at the time of the exchange, to be deployed and utilized by the software Vendor and the value ascribed to the transaction reasonably reflects such expected use. If neither the fair value of the technology/products exchanged nor the fair value of the technology/products received can be reasonably determined, the exchange should be recorded at carryover basis. Paragraph 26 of APB Opinion No. 29 states that "if neither the fair value of a nonmonetary asset transferred nor the fair value of a nonmonetary asset received in exchange is determinable within reasonable limits, the recorded amount of the nonmonetary asset transferred from www.pwcrevrec.com 121

the enterprise may be the only available measure of the transaction." For software vendors, if there are no significant capitalized software development costs (FAS 86) the recorded amount of the software product transferred may not be significant. Paragraph 4 of EITF 99-17, Accounting for Barter Transactions, states that "an exchange between the parties to a barter transaction of offsetting monetary consideration, such as a swap of checks for equal amounts, does not evidence the fair value of the transaction." This guidance should also be considered for barter transactions involving software. Barter transaction software license exchanged for property to be resold Assume the facts set out in the preceding example, however, instead of using the computers for its operations, the Vendor bundled its software with the computers and sold the computers to other customers Question: How should the Vendor account for this transaction? Answer: Once again, we believe that all of the factors surrounding the transaction would have to be considered. If, after an analysis of the business purposes for the transaction, it was determined that, for this transaction, the earnings process was complete, revenue could be recorded at the fair value of the software and the computers included in the Vendor's inventory as a normal product purchase that is in keeping with the Vendor's business practices. However, if after a review of the business purposes for the transaction it was noted that (1) the Vendor has rarely entered into this type of arrangement before and (2) the Vendor has never before bundled the software with computers, nor does the Vendor have any orders for this combined product, it is likely that the conclusion would be that this did not represent the culmination of the earnings process and that, therefore, no revenue should be recognized on the transaction. We believe that in most of these types of situations, the latter conclusion will be reached, as these transactions are simply inventory-for-inventory swaps that preclude revenue recognition. In accordance with paragraph 21a of APB Opinion No. 29 and TPA 5100.46, an exchange of a product or property held for sale in the ordinary course of business for a product or property to be sold in the same line of business to facilitate sales to customers other than the parties to the exchange does not culminate an earnings process. Therefore, if the technology/products received by the software Vendor in the exchange were to be sold, licensed, or leased in the same line of business as the software Vendor's technology/products delivered in the exchange, the software Vendor should record the exchange at carryover basis. However, if the technology/products received by the software Vendor in the exchange were to be sold, licensed, or leased in a different line of business from the software Vendor's technology/ products delivered in the exchange, the exchange is the culmination of the earnings process and the exchange should be recorded at fair value, as discussed in the preceding example. If neither the fair value of the technology/products exchanged nor the fair value of the technology/products received can be reasonably determined, the exchange should be recorded at carryover basis, as discussed further at the end of the answer in the preceding example. 122 PricewaterhouseCoopers LLP

Chapter 7: Issues Related Specifically to Resellers 7.0 Overview Paragraph 8 of SOP 97-2 states the following: If the arrangement does not require significant production, modification, or customization of software, revenue should be recognized when all of the following criteria are met: Persuasive evidence of an arrangement exists; Delivery has occurred; The vendor's fee is fixed or determinable; and Collectibility is probable. As difficult as it is to interpret these criteria for arrangements between vendors and end users, it is even more difficult to interpret these guidelines for arrangements between vendors and resellers. Reseller arrangements have historically contributed an unusually high level of troublesome revenue recognition situations. The term reseller has often been used in the high-technology industry, particularly the software industry, to refer to an entity that acts solely as an intermediary channel for the vendor's products (i.e., it purchases the software and resells it to endusers or otherresellers). The glossary of SOP 97-2 defines a user and a reseller as follows: User: Party that ultimately uses the software in an application. Reseller: Entity licensed by a software vendor to market the vendor's software to users or other resellers. Licensing agreements with resellers typically include arrangements to sublicense, reproduce, or distribute software. Resellers may be distributors of software, hardware, or turnkey systems, or they may be other entities that include software with the products or services they sell. Note that SOP 97-2 expands the concept of a reseller to include any entity that does not use a licensed software product for its own purposes. Other entities that commonly act as intermediary channels (and should therefore be considered resellers) include: Distributors; Value-added resellers (VARs); Original equipment manufacturers (OEMs); and System integrators. Arrangements between resellers and vendors are often more complex than those between vendors and end users, because they sometimes include: return, exchange, platform-transfer and stock-rotation rights (i.e., vendors allow resellers to return products or to exchange unsold or returned products for other products); price protection; a fixed, minimum fee for a combination of products; a co-marketing agreement; www.pwcrevrec.com 123

a right to obtain licenses to distribute additional, selected products, with a fixed, minimum purchase required for: o existing products, o products being developed, or o some combination of both; an upgrade of products held by the reseller, in spite of there being no formal PCS arrangement; implied PCS; an obligation to provide PCS to the reseller's customers (i.e., end users); and the reproduction of the software by the reseller under the same contract or under a separate contract. Additionally, complexity may exist because the payment terms for arrangements with resellers often include nonrefundable advance payments, fixed fees, or royalties. The fees may be impacted by the passage of time, the volume of use, some other variable pricing arrangement, or fixed prices plus royalties. Given the number of variables in many of these arrangements, it is often difficult to determine the true economics behind the arrangements and where the various risks reside. For example, which party bears the technological-obsolescence risk? When can a fee be considered fixed? Which party is providing support? What is the vendor's obligation to the end user with regard to updates and enhancements? The answers to all of these questions impact revenue recognition for these types of arrangements. The purpose of this chapter is to review the basic criteria for revenue recognition and provide additional guidance with regard to arrangements with resellers. The specific topics addressed in this chapter are as follows: 7.1 Persuasive evidence of an arrangement 7.2 Delivery 7.3 Fixed or determinable fees and collectibility 7.4 Rights of return or exchange and price protection 7.5 Implied PCS arrangements 7.6 Prepaid royalties 7.7 Multiple-element arrangements with resellers 7.1 Persuasive evidence of an arrangement Arrangements with resellers vary in form and should be closely reviewed for their specific terms and conditions. Generally, the arrangements do not present unique interpretation issues with regard to the first revenue recognition criterion, "persuasive evidence of an arrangement." However, a layer of complexity may be added if the terms and conditions of the vendor's contract with the reseller incorporates or attaches to the arrangement the contract, or provisions thereof, between the reseller and the end user. A legal opinion may be required to determine the vendor's obligation to the end-user customer. 7.2 Delivery The delivery requirements under SOP 97-2 apply to both users and resellers. However, in certain circumstances, questions may arise as to whether the basic revenue recognition criterion has been met when an arrangement is entered into with a reseller. The delivery issues associated with resellers frequently relate to whether the reseller has actually taken responsibility for the product such that the vendor will not be requested to accept returns, provide price protection, conduct exchanges, or agree to payment terms that are subject to the reseller's receiving payment from its customer, which may or may not be the end user. Not only do matters such as these raise concerns about whether the fee is fixed or determinable, they are also delivery issues, because ultimately they relate to whether the reseller has accepted the vendor's product. 124 PricewaterhouseCoopers LLP

Also, arrangements between the reseller and end user, or between the reseller and the vendor, may obligate the vendor to provide services to the end user (e.g., installation or configuration) that are subject to user acceptance. These arrangements present a heightened risk that delivery may not be deemed to occur until the user accepts the services. 7.3 Fixed or determinable fees and collectibility Paragraph 30 of SOP 97-2 outlines several factors that should be considered when an evaluation is being made of whether the fee in an arrangement with a reseller is fixed or determinable and collectible. Specifically, it indicates the following: Business practices, the reseller's operating history, competitive pressures, informal communications, or other factors may indicate that payment is substantially contingent on the reseller's success in distributing individual units of the product. Footnote 7 of paragraph 30 indicates that contractual arrangements under which the reseller is obligated to pay only as, and if, sales are made to users should be accounted for as consignments on a sell-through basis. Resellers are new, undercapitalized, or in financial difficulty and may not demonstrate an ability to honor a commitment to make fixed or determinable payments, until they collect cash from their customers. Uncertainties about the potential number of copies that will be sold by the reseller may indicate that the amount of future returns cannot be reasonably estimated upon the delivery of the software; such factors include the newness of the product or marketing channel, competitive products, or a dependence on the market potential of another product that is being offered (or it is anticipated will be offered) by the reseller. Distribution arrangements with resellers that require the vendor to rebate or credit a portion of the original fee if the vendor subsequently reduces its price for a product and the reseller still has rights with respect to that product (sometimes referred to as price protection). If a vendor is unable to reasonably estimate future price changes in light of competitive conditions or, if significant uncertainties exist about the vendor's ability to maintain its price, the arrangement fee is not fixed or determinable. In such circumstances, revenue from the arrangement should be deferred until the vendor is able to reasonably estimate the effects of future price changes and the other conditions of the SOP have been satisfied. Resellers that present the highest risk of uncertainty as to whether revenue should be recorded upon the delivery of a product due to uncertainty regarding fixed or determinable fees and collectibility are: those that are thinly capitalized; those that are significant customers and/or significantly larger than the vendor; those that are international; and those for which the reliability of the reseller paying for the software has not been established. Of additional concern are resellers that act solely for the vendor or for a limited number of vendors and that market the products to specific customers. These resellers generally work under a short lead-time commitment to customers. Therefore, they are more likely to accept a delivery of the vendor's products and maintain inventories. As a result, the risk that concessions will be made implicitly or agreed to explicitly is generally higher. Another factor that impacts the assessment of whether the fee in the arrangement is fixed or determinable at the outset of the arrangement is whether vendors have a customary business practice of subsequently providing resellers with concessions or return rights, including platform-transfer rights, that are in addition to the initial terms of the arrangement. Evaluating these situations can be particularly difficult to do when a reseller does a high volume of business with the software vendor, because the tendency to provide concessions to ensure a continued deal flow would generally increase. Arrangements www.pwcrevrec.com 125

with distributors, particularly those at international locations, that may not require a substantial portion of the fee to be paid upon the delivery of a product also gives rise to special concerns. This situation can be exacerbated by extended payment terms, vendor participation in customer financing and, in some cases, foreign-currency risk. Additionally, when the conditions of a prepaid license result in the reseller's having a large "inventory" of licenses, the situation should be approached with skepticism. TPA 5100.56,Concessions and Software Revenue Recognition, states examples of modifications to an arrangement that increase the deliverables under the arrangement and are considered concessions. Specific to resellers, the TPA lists the following: For term licenses, extending the time frame for a reseller to sell the software or an end user to use the software; and For limited licenses, extending the geographic area in which a reseller is allowed to sell the software, or the number of locations in which an end user can use the software. In addition to the factors listed in paragraph 30 of SOP 97-2, for software arrangements that contemplate vendor participation in reseller financing, the nature of the vendor's participation in the reseller's financing is important to determining whether fees are considered fixed or determinable for revenue recognition. TPA 5100.66,Consideration of other TPAs on customer borrowing when customer is a reseller and software revenue recognition, confirms that the concepts of the following TPAs regarding financial arrangements apply to resellers as well (See Chapter 2 for a further discussion of these TPAs): TPA 5100.60 - Customer financing with no software vendor participation and software revenue recognition; TPA 5100.61 - Effect of prepayment on software revenue recognition when vendor participates in customer financing; TPA 5100.62 - Indicators of incremental risk and their effect on the evaluation of whether a fee is fixed or determinable and software revenue recognition; TPA 5100.63 - Overcoming the presumption that a fee is not fixed or determinable when vendor participates in customer financing and software revenue recognition; TPA 5100.64 - Indicators of vendor participation in customer financing that do not result in incremental risk and software revenue recognition; and TPA 5100.65 - Software vendor interest rate buy downs on customer financing and software revenue recognition. Furthermore, TPA 5100.66 acknowledges that the existence of financing by a reseller customer may increase the risk that payment of the fee is contingent upon the reseller's success at reselling the product. It also may indicate that the reseller does not have the ability to honor a commitment to pay, increasing the risk of vendor concessions. Finally, the increased risk of concession may negatively impact the ability to reasonably estimate returns or price protection. If a vendor's participation in a reseller's financing results in incremental risk that the vendor will provide a refund or concession, there is a presumption that the arrangement fee is not fixed or determinable. Observation: Often, because of the factors discussed in the previous paragraphs, it is appropriate to defer recognition until there is a "sell-through" by the reseller to an actual end-user customer. This is in contrast to "sell-in" where revenue is recognized by the vendor upon delivery of the software to the reseller (assuming all other revenue recognition criteria have been met). 126 PricewaterhouseCoopers LLP

The terms "sell-in" and "sell-through" are merely common business terms and not accounting models. The determination of whether revenue should be recognized upon "sell-in" or "sell-through" is solely dependent on the facts and circumstances of a specific arrangement and evaluation of the relevant revenue recognition guidance. In determining whether the fixed or determinable requirement has been met, the vendor must be able to demonstrate that none of the concessions referred to in the preceding paragraphs, except to the extent that they meet the requirements of paragraph 6 of FAS 48, will be extended to the reseller. The evidence provided by the vendor may vary based on the type of reseller because, depending on the vendor's product and how it is used, certain resellers may take more responsibility for risk of loss than others. Questions and Answers Reseller is new The Vendor licenses its imaging product strictly through a reseller channel and has no end-user sales force. The Vendor has licensed its imaging products for three years and has a history of collecting all amounts due from resellers without granting concessions, refunds or forfeitures. All licensing arrangements to date have been through domestic resellers. During the current year, the Vendor begins licensing its products to new international resellers on a limited basis. The Vendor has not been able to obtain reliable credit information regarding these international resellers, some of whom operate in troubled economic environments. Some of these new resellers are granted extended payment terms. Question: Should the Vendor continue to record revenues from these new distributors upon the delivery of the product to these resellers (i.e., on a sell-in basis)? Answer: The fact that the Vendor has never licensed the imaging product through these new international distributors indicates that it does not have a history of collections with this type of reseller. This raises a concern that some of the fees may not be fixed or determinable and/ or collectible. This is exacerbated by the fact that (1) no credit reviews or financial analysis is available to substantiate recording revenues upon the delivery of the product, and (2) some distributors are operating in troubled economic environments. In many of these cases, the Vendor should consider a sell-through method of recording license revenue to these types of distributors, particularly when extended payment terms are granted. Fixed or determinable fees - reseller has the financial ability to pay The Vendor enters into an arrangement with the Reseller on June 28, X1 whereby the Reseller can license up to 100,000 copies of Product J for $1,500,000. Product J was delivered on June 28, X1. The Reseller is financially stable and has the economic wherewithal to pay the $1,500,000 without requiring any cash collections from end users. The payment terms related to the $1,500,000 to the Vendor are tied to the Reseller's subsequent licensing of Product J to end users. The Vendor has no further service obligation to the Reseller or the Reseller's customers. Question: Are the fees in the arrangement fixed or determinable and collectible on June 28, X1? www.pwcrevrec.com 127

Answer: The fees in this example appear collectible because the Reseller has the financial wherewithal to pay on its own. However, the fact that the payment of the fee under the arrangement is tied to subsequent licensing to end users would generally lead the Vendor to conclude that the Reseller does not perceive that an obligation exists until such licenses are issued, despite the contractual obligation in the arrangement. Revenues should be recognized as the Reseller licenses Product J to the end users on a sell-through basis. Fixed or determinable fees - reseller does not have the ability to pay Assume in the above example that the Reseller owed the $1,500,000 after ninety days but that it did not have the economic wherewithal to pay the $1,500,000 fee without collecting the corresponding cash from end users. Question: Are the fees in the arrangement fixed or determinable and collectible on June 28, X1? Answer: Even if the uncertainty surrounding the fixed or determinable nature of the arrangement could be overcome, if the Reseller does not have the economic wherewithal to pay the fee due under the arrangement without receiving cash receipts from end users, the fees would not be collectible under the arrangement until cash collections were received from the end users. In this situation, revenue under the arrangement should be recognized as the cash is received from the Reseller or, at the earliest, when the Vendor receives notice from the Reseller that it has received the cash. 7.4 Rights of return or exchange and price protection As part of their license terms or as a matter of practice, vendors may grant resellers the right to exchange unsold software for other software (including software that runs on a different hardware platform or operating system) or the right to simply return the software altogether. Additionally, vendors may induce resellers to license a product by promising to provide rebates for any future decreases in the pricing of affected products, which is sometimes referred to as price protection. All of these rights, including exchange rights, return rights, platform-transfer rights and price protection, should be accounted for in accordance with FAS 48, regardless of whether these rights relate to software products among which there are no more than minimal differences in price, functionality, and features. SAB 104 provides a number of guidelines for interpreting the provisions of FAS 48, including determining what is adequate history, reasonable/reliable estimates, analogies to FAS 48, etc. Paragraph 121 of SOP 97-2 also provides guidance on interpreting the difference between exchanges and returns for cases in which resellers are involved. Paragraph 121 states, "Accordingly, AcSEC concluded that the accounting for exchanges of software for products with no more than minimal differences in price, functionality, and features by users qualify for exchange accounting because, as discussed in footnote 3 to FASB Statement No. 48, (a) users are 'ultimate customers' and (b) exchanges of software with no more than minimal differences in price, functionality, and features represent 'exchanges of one item for another of the same kind, quality, and price.' AcSEC concluded that because resellers are not 'ultimate customers,' such exchanges by resellers should be considered returns." Consequently, exchange accounting can never apply to a right given to a reseller. 128 PricewaterhouseCoopers LLP

SOP 97-2 notes that the competitive conditions of the software industry make the process of estimating exchanges, returns and the level of price protection problematic. For example, the newness of the product, the vendor's lack of a history of doing business with certain resellers, or the possible introduction of a competing product that has superior functionality and features (or even the same vendor's introduction of an enhanced version of its product) may result in the vendor's inability to reasonably estimate returns, especially if the expected period of the sell-through of the "inventory" of licenses that are delivered to the reseller is lengthy. A reseller may allow its customers to return software to it. The reseller may then have the right (either contractually or based on the vendor's business practice) to return the product to the software vendor. This exposure to returns may not be limited to only the inventory maintained by the reseller. The SEC's interpretation of these issues are discussed in detail in SAB 104. As such, if the vendor does not have adequate evidence with which to document that a reasonable estimate of the level of exchanges, returns or price protection has been made, revenue recognition would be precluded until such an estimate could be made or until the product is delivered to the end user (i.e. sell-through basis). Other problematic situations arise when resellers are allowed to "upgrade" or "rotate" their inventory by receiving upgrades and enhancements that are not universally provided under normal PCS arrangements. These situations constitute a return by the reseller of the product originally purchased in exchange for (1) the software on a new platform or (2) the upgraded product. An estimate of such returns must be made at the time that the revenue from the original license is initially recorded, and products that are subject to return should not be reflected in revenue or cost of sales upon their initially being delivered to the reseller. If conditions do not permit a reasonable estimate, revenue recognition of the sale must be deferred until a reasonable estimate can be made or until the reseller licenses the product to the end user. Such situations should also be evaluated to determine if an implied PCS arrangement exists. Implied PCS arrangements are discussed later in this chapter and in Chapter 3. As discussed above, because resellers are not end users, arrangements with resellers can never qualify for exchange accounting. When a right of return or exchange exists in an agreement with a reseller, the situation must be evaluated according to its specifics. For example, a vendor might enter into an agreement with a reseller that involves stock-balancing or the right to receive unspecified additional software products. If the arrangement involves a specified time period, as well as current and future products, subscription accounting might be appropriate. Conversely, if such an arrangement were to include terms whereby the right to return or exchange a product would expire only upon the reseller's having licensed the product to end users, sell-through accounting might be appropriate. Finally, with regard to delivered products, some resellers grant the right of return to end users in the form of the right to receive unspecified future products; in turn, the reseller has the right to return such products to the vendor. In this case, the appropriate method of revenue recognition might be to recognize revenue as the return right that is granted to the end user is exercised or expires. Situations in which a vendor grants a return or exchange right to a reseller for unspecified undelivered products will present significant difficulties in estimating how much of a delivered product is not subject to return. In these situations, it would be extremely rare for a vendor to be able to reasonably estimate returns in accordance with FAS 48 and SAB 104. Questions and Answers Rebate clause The Vendor enters into an arrangement with the Reseller to sublicense 1,000 copies of a new product, Product B, for $1,000,000. Under the arrangement, the Reseller pays the Vendor's list price, less 15%. Under the current master licensing agreement between the Vendor and the Reseller, the Vendor is obligated to issue a rebate to the Reseller for any future price reductions the Vendor makes on the www.pwcrevrec.com 129

software product. The rebate applies to only those copies that remain unlicensed by the Reseller at the time of the price reduction. The effect of the rebate clause is that the Reseller has the right to "return" the higher-priced Product B and license the lower-priced Product B. Question: Under this arrangement with the Reseller, how should revenue be recognized? Answer: FAS 48 indicates that licenses with a right of return can be recorded upon the delivery of the product if certain criteria are met. In order for the Vendor to reasonably estimate the amount of the revenue reserve that is necessary to cover the price-protection clause granted to the Reseller, it must be able to reasonably estimate the number of products that the Reseller will have on hand at the time that a price reduction is made. Because the Vendor has stated that Product B is a new product and also because the arrangement with the Reseller is new, the Vendor's ability to make such an estimate is likely to be diminished. If a reasonable estimate of the effect of the rebate clause cannot be made, revenue under the arrangement with the Reseller should be recognized as the software is licensed to end users. Rebate clause with a cap Fact Set Assume the same facts as above, except the rebate is applicable to any software product purchased within 90 days of the price reduction and is capped at a maximum amount of $100,000 in any calendaryear period. The Vendor does not have a history of providing concessions or refunds in excess of the maximum amount. Question: Under this arrangement with the reseller, how should revenue be recognized? Answer: Because Product B is a new product and also because the arrangement with the Reseller is new, the Vendor's ability to make an estimate of returns under this clause is likely to be difficult. However, since the maximum amount of price protection is incorporated in the contract with the Reseller, the Vendor would recognize revenue from the arrangement upon delivery of Product B, net of a revenue reserve for $100,000, the potential maximum price reduction to be given, assuming that all of the other revenue recognition criteria have been met. This conclusion is consistent with the treatment of refunds or rebates described in Issue 4 of EITF 01-9 Observation: In contrast, the practice of reserving for the maximum possible returns would not be appropriate for product returns that cannot be reasonably estimated, as discussed in SAB104, Section A4(b), Question 5. Right of return - unspecified products The Vendor grants the Reseller the right to duplicate and sublicense any of its current or future products in Country X for one year, in exchange for a fee of $1,000,000. The Vendor and the Reseller sign a binding agreement on the last day of the quarter. Fully functional versions of all the Vendor's current products are delivered on that day. The Reseller has free right of return on all of the Vendor's products during the one-year term. Question: Assuming that all other revenue recognition criteria have been met, how should the $1,000,000 fee be recognized? 130 PricewaterhouseCoopers LLP

Answer: The Vendor would recognize the $1,000,000 fee as a subscription beginning with the delivery of the currently available products (i.e., ratably over the term of the arrangement). The Reseller has licensed rights to access and to distribute the Vendor's products on an unlimited basis, but for a set term and geography. 7.5 Implied PCS arrangements Many software vendors use a reseller channel to distribute their products. In many cases, the reseller sells PCS to its end users and charges them a fee. The PCS arrangement between the reseller and the end user includes both customer support and the right to receive unspecified upgrades, updates and enhancements on a when-and-if-available basis. Obviously, few resellers are upgrading a vendor's product through development efforts. Generally, the arrangement between the vendor and the reseller provides that a portion of the PCS fees that are charged by the reseller to its end users will be paid to the vendor. The fees that the reseller pays to the vendor are to compensate the vendor for its having provided the reseller with updates, upgrades and enhancements that the latter will distribute to the end user. The fees that are paid to the vendor may also compensate the vendor for its having provided a secondary level of technical support to end users that is typically beyond what the reseller can provide. In this situation, the PCS fees that are paid by the end user are frequently allocated between the vendor and the reseller based on the benefits that each party provides the end user. If a vendor is providing (1) secondary (or primary) customer support whether to the reseller or directly to end-user customers or (2) resellers with upgrades, updates and enhancements that resellers may then pass on to end users, a PCS arrangement obviously exists between the vendor and reseller. If there is no contract that discusses a PCS-type arrangement, then implied PCS exists. SOP 97-2 indicates that if the reseller is not paying the vendor any fee for these types of services, a portion of the fee related to the license of a product equal to the VSOE of the fair value of PCS must be considered related to the PCS element and therefore, accounted for as such. Since resellers are a different class of customer than enduser customers, the VSOE of PCS provided to resellers may differ from the VSOE of PCS provided to end-user customers. Situations in which the vendor and the reseller divide the responsibility for providing PCS can vary from arrangement to arrangement. In some cases, it is the reseller, and not the vendor, that is providing customer support during the PCS period. In other cases, the vendor provides second- or third-level customer support, whereas the reseller provides first-level support. If the vendor does not provide any customer support or the right to upgrades and enhancements, the vendor would not defer revenue, as no PCS arrangement exists. For situations in which the reseller is providing customer support but the vendor is contractually obligated to allow the reseller to offer upgrades and enhancements to its end users free of charge, an implied or stated PCS arrangement exists. Paragraph 62 of SOP 97-2 addresses implied PCS arrangements with resellers. It states the following: An arrangement in which a vendor grants a reseller the right to provide unspecified upgrades/ enhancements to the reseller's customers is an implied PCS arrangement between the vendor and the reseller, even if the vendor does not provide direct telephone support to the reseller's customers. If sufficient vendor-specific objective evidence does not exist to allocate the fee to the software and the PCS, revenue from both the licensing arrangement and the PCS should be recognized ratably during the period that PCS is expected to be provided. Much as is the case in arrangements with end users, in arrangements with the reseller not only the contractual requirements, but also the economics of the transaction and the vendor's customary business practices should be evaluated in a determination of whether an implied PCS arrangement exists between the vendor and the reseller. For example, if a vendor has announced the release of a product upgrade for the next quarter and a reseller is still generating revenue from the previous version of the product, the www.pwcrevrec.com 131

vendor should evaluate the ramifications for the relationship with the reseller if an upgrade right is not granted. In such a situation, if the vendor intends to grant the reseller the right to offer the upgrade to end users (even if it is not required to do so by the contractual arrangement with the reseller), the appropriate accounting would be that which is applied to an implied PCS arrangement, as discussed in paragraph 62 of SOP 97-2. Another common situation in which a vendor and a reseller may have an implied PCS arrangement is one in which a reseller's unlicensed product is updated by the vendor to include newly released upgrades, updates and enhancements. This is generally the case when a reseller holds an "inventory" of the vendor's product for license to end users, instead of ordering the product from the vendor only when an end-user customer has been identified. Frequently, there is no contractual language that indicates that the reseller's inventory will be updated for new releases, nor is a fee being paid by the reseller for this benefit. This situation clearly represents an implied PCS arrangement between the vendor and the reseller that must be accounted for as PCS if revenue is being recorded by the vendor upon the delivery of the product to the reseller. It is noteworthy that the reseller would not be receiving customer support services for unlicensed inventory, which has value in any PCS relationship. Therefore, the only PCS benefits that the vendor is providing are in the form of updates, upgrades and enhancements. Therefore, it would follow that if this type of situation exists, the fair value of the PCS would be less than the fair value of a normal PCS arrangement with an end user that includes both customer support and the right to updates, upgrades and enhancements. However, as discussed in section 3.3.3, it would be rare for a vendor to be able to demonstrate that this type of PCS should be allocated a lower value than normal PCS for accounting purposes under SOP 97-2, unless there were separate sales for a modified PCS arrangement. Questions and Answers Implied PCS for providing upgrades The Vendor entered into an arrangement with Reseller A such that Reseller A obtained the right to distribute Product R. This arrangement was signed on March 31, X2, and Product R was delivered. The arrangement included a $500,000 nonrefundable, up-front fee. The Vendor has no obligation to provide Reseller A or Reseller A's customers with any further services. Question: Assume that the Vendor anticipates that Reseller A will account for 25% of its revenue on an ongoing basis. To maintain its amicable relationship with Reseller A, the Vendor decides that it will probably allow Reseller A to offer to its end users all upgrades and enhancements that are developed over the next year for no additional charge, despite the fact that it has no obligation to do so. Upon the delivery of Product R, is revenue recognition of the nonrefundable fee appropriate on March 31, X2? Answer: Revenue recognition of the full nonrefundable fee is not appropriate on March 31, X2. If the Vendor intends to allow Reseller A to offer end users upgrades and enhancements that lie outside its contractual obligations, the arrangement would be deemed as having an implied PCS arrangement embedded in it. If VSOE of fair value does not exist for the PCS, the entire up-front fee should be recognized ratably over the period in which the PCS is expected to be provided. If VSOE of the fair value of the PCS does exist, the Vendor may be able to defer the VSOE of the fair value of the PCS and record the license fee upon the delivery of the product. 132 PricewaterhouseCoopers LLP

Observation: Situations like the one cited above should be approached with extreme caution. The Vendor in the above example might establish that the PCS period is one quarter, because the upgrade will be released in the next quarter. However, the granting of such a concession to a reseller with such a significant sales volume would be apt to set a precedent in the mind of the Reseller. In which case, it might be more appropriate if the PCS period were the length of time covered by the reseller arrangement. Implied PCS with upgrade rights - business practice Assume the fact pattern in the example above and that the Vendor did allow Reseller A to distribute the upgrade. Then, on December 30, X2, the Vendor entered into an arrangement with Reseller B that had the same contractual terms as the arrangement with Reseller A. Reseller B intends to account for at least 25% of the Vendor's annual revenue, but the Vendor is skeptical of the projections. Question: Would recognition of the up-front fee of $500,000 that is received from Reseller B be appropriate upon the delivery of Product R to Reseller B on December 30, X2? Answer: Although the Vendor may have business practices specific to resellers that have a varying sales volume, the fact that a concession was made to Reseller A should be weighed heavily in a determination of the appropriate revenue recognition for the $500,000 up-front fee that is received from Reseller B. If the Vendor concludes that it is likely to make the same concession to Reseller B, the arrangement should also be deemed as including an implied PCS arrangement. 7.6 Prepaid royalties In certain situations, a vendor's customer will license the software to its customers. The agreement between the vendor and the customer may stipulate that the prepayment of the license fee is to be based on minimum royalties. Additional fees would then be payable if the minimum royalty fee were exceeded as a result of the customer's sales. License fees for software should be evaluated based on the criteria in SOP 97-2, regardless of whether they are based on minimum royalty amounts. If all of the requirements of SOP 97-2 are met, including the determination that the fees in the arrangement are fixed or determinable, then the royalty prepayment fee should be recognized upon the delivery of the software (with deferral of an appropriate portion for PCS, if applicable). The additional fees that will be payable if the minimum is exceeded are generally based on a price per copy and, therefore, do not impact the revenue recognition of the minimum fee. The requirements of SOP 97-2 should be evaluated at the time that the minimum royalties are exceeded, based on the facts and circumstances that exist at that time. Questions and Answers Prepaid royalty fees - nonrefundable The Vendor enters an arrangement to license an unlimited number of copies of Product X to the Reseller on June 28. Product X was delivered to the Reseller on June 28, and the Reseller will reproduce all necessary copies. Under the arrangement, the Reseller will pay the Vendor $100,000, which is the value of the license fee. No future deliverables are due under the arrangement. After the Reseller licenses 10,000 copies of Product X to end users, royalties will be due to the Vendor at a rate of $15 per copy of Product X. www.pwcrevrec.com 133

Question: What is the appropriate revenue recognition for the $100,000? Answer: License fees for software should be evaluated based on the criteria in SOP 97-2, regardless of whether they are based on minimum royalty amounts. Assuming that all other revenue recognition criteria have been met, the $100,000 of revenue would be recognized upon the delivery of Product X on June 28. If the Reseller has licensed over 10,000 copies of Product X to end users, the Vendor should record the additional royalty revenues when the Reseller notifies it of sales. Prepaid royalty - refundable Assume that the same facts as those in the example above pertain here, except that the $100,000 fee is refundable if the Reseller is not able to license 10,000 copies in six months. In such a case, the Vendor would receive $20 per copy of Product X that is actually licensed by the Reseller. Question: What is the appropriate revenue recognition for the $100,000? Answer: As the fee is not fixed or determinable at the outset of the arrangement, the $100,000 should be recognized on a sell-through basis as end users license the software. The Vendor would record $20 per copy, up to the $100,000 fee. 7.7 Multiple-element arrangements with resellers Software licensing arrangements with resellers often include additional services, such as co-marketing services and PCS. Consideration should be given to whether these additional services constitute separate elements of the arrangement. A high level of judgment is involved in determining whether the services constitute a separate element based on the facts and circumstances present and, if so, whether the services can be accounted for separately. It is important to evaluate the contractual requirements of the agreement, the economics of the transaction and the vendor's customary business practices in order to determine whether a co-marketing services agreement constitutes a separate element of the arrangement. In some cases, the parties acknowledge in the contract that they will each expend best efforts to market the product; since the vendor has no obligation to perform specific or significant services, the co-marketing services would not be considered a separate element. However, if the vendor has committed to perform specific and significant services under the co-marketing agreement, such as attending customer sales presentations or spending money on a joint advertising campaign, the co-marketing services should be considered a separate element. For situations in which the vendor is contractually obligated to perform specified services, a portion of the arrangement fee equal to the VSOE of fair value of the co-marketing services must be accounted for separately. If sufficient VSOE does not exist to allocate the fee to the delivered software and the undelivered co-marketing services (as is often the case), revenue from both the licensing arrangement and the co-marketing services should be recognized ratably during the period in which the co-marketing services are provided. If the vendor is not obligated to provide any specific services, the vendor would not defer revenue, as no separate element exists. Revenue should be recognized when the SOP 97-2 criteria for each element have been met. 134 PricewaterhouseCoopers LLP

Questions and Answers Multiple-element arrangement - no specific marketing services The Vendor entered an arrangement to license 100 copies of Product A to a Reseller for a fee of $750,000 and delivered the software licenses. Under the terms of the arrangement, the Vendor and the Reseller agree to participate in joint marketing efforts to end-user customers. The Reseller is financially stable and has the economic wherewithal to pay the $750,000. There is no PCS (implied or explicit) in this arrangement. Question: What is the appropriate revenue recognition for the $750,000 fee? Answer: The significance of the co-marketing services should be evaluated based upon the nature of the Vendor's commitment and the Vendor's customary business practices in accordance with FAS 48 paragraph 6(e). Under this particular arrangement, the marketing services do not constitute a separate element since the Vendor is not obligated to perform specific marketing services. The $750,000 of revenue would be recognized upon delivery of the software, assuming all other revenue recognition criteria have been met. Multiple-element arrangement - specific marketing services Assume that the same facts as those in the example above pertain here, except that the Vendor and Reseller have agreed to a number of specific joint marketing activities to be undertaken over a one-year period. Question: What is the appropriate revenue recognition for the $750,000 fee? Answer: As the Vendor is contractually obligated to participate in a number of specific joint marketing activities, the co-marketing services constitute a separate element. Revenue equal to the VSOE of fair value of the services should be deferred and recognized as the services are delivered, in this case presumably over one year. FAS 48 paragraph 6(e) may also require deferral of the entire $750,000 if the co-marketing services are considered significant. If no VSOE exists for the co-marketing services (because the Vendor does not typically "sell" such services), the entire $750,000 fee should be recognized as the services are delivered, again presumably over the one-year period. Multiple-element arrangement - specific marketing services Assume that the same facts as those in the example above pertain here, except that the Vendor has agreed to spend $100,000 on joint marketing/advertising to be placed through independent agencies over the one-year period. Question: What is the appropriate revenue recognition for the $750,000 fee and accounting for the $100,000 marketing expense? www.pwcrevrec.com 135

Answer: As the Vendor is contractually obligated to pay $100,000 for joint marketing/advertising, these comarketing services constitute a separate element. Revenue equal to the $100,000, the fair value of the advertising services, should be deferred and recognized as spent over the one year. Additionally, the $100,000 in actual advertising payments should be recorded as a direct offset to the revenue over the same period. This conclusion is consistent with EITF 01-09, which requires cash incentives paid by a vendor, which do not meet certain criteria (see Chapter 6), to be recorded as a reduction of revenue. In this case, the arrangement would have achieved the same economic result if the Vendor had provided cash of $100,000 for the Reseller to spend on the advertising services. Observation: Situations like the ones cited above should be approached with extreme caution. Multiple-element arrangements that include co-marketing services require careful evaluation. Conclusions regarding whether the services constitute a separate element will involve a high level of judgment and a careful analysis of the facts and circumstances of the particular transaction. See additional discussion on marketing consideration and EITF 01-09 in chapter 6, section 6.4. 136 PricewaterhouseCoopers LLP

Chapter 8: Funded Software Development Arrangements 8.0 Overview Funded development arrangements are common in the software industry. Often a third party will provide funds to a vendor to expedite the development of additional features and functionality to the vendor's existing products or technology (e.g., customization of a core technology). The structure of these arrangements is generally based on the goals of the funding party and the stage of the software's development. The funding party may provide cash, issue equity instruments, or use a combination of the two, and generally will receive one or more of the following in return: Royalties payable to the funding party based solely on the vendor's future licensing of the product (that is, reverse royalties); Discounts on the funding party's future licenses of products that are developed under the arrangement; and A nonexclusive sublicense granted to the funding party, at no additional charge, for the use of any product that is developed (a prepaid or paid-up nonexclusive sublicense). Accounting for the proceeds received from these arrangements requires an analysis of the facts and circumstances of each particular case. The structure of funded development arrangements may resemble a borrowing transaction, with the vendor obligated to repay the borrowed funds. In other funded development arrangements, the vendor has a contract to perform research and development for others, with the financial risks and future use of the results of the research and development transferred to the funding party. This transfer of future use may be exclusive, affected by a transfer of ownership or by a perpetual license, or nonexclusive via license where ownership is retained by the vendor who can otherwise sell the resulting software products. The accounting for funded software-development arrangements falls under the guidance of either FAS 68 Research and Development Agreements, or SOP 97-2, depending on the software's stage of development. In accordance with paragraph 73 of SOP 97-2, if technological feasibility has not been established prior to the vendor's entering into the arrangement, FAS 68 applies. Under FAS 68, proceeds received from the arrangement are considered either (1) a liability on the part of the vendor, with the vendor's repaying the funding party (or parties) or (2) an agreement that the vendor will perform contractual services, from which revenue will be derived. If the vendor is obligated to repay any of the funding, regardless of whether or not the research and development has any future economic benefit, the funding should be treated as a liability until the software is delivered and the research and development costs expensed as incurred. If there is no repayment provision or repayment depends solely on the results having a future benefit (i.e., as a royalty based solely on future sales of the developed product), the vendor should record the funding as revenue (or offset it to research and development expenses) when it is earned, generally by using contract accounting. If the vendor does not have the right to use the results of the funded software development arrangement and the financial risk associated with the arrangement rests with the funding parties, these facts clearly indicate that the arrangement should be treated as a service contract and revenue would be recognized as performed. In determining the nature of the arrangement, vendors should consider their contractual obligations, as well as other facts and circumstances. Vendors should apply caution when analyzing funded software development arrangements. They should evaluate these contracts to determine the specific commitments that the vendor has made with regard to the delivery of an end product and the nature of the relationship with the funding party. In some cases, www.pwcrevrec.com 137

contracts may contain commitments to produce an end product, with all fees under the arrangement refundable if the vendor cannot meet such a commitment. Some funded development arrangements contain provisions for contingent fees or penalties. In such arrangements, revenue recognition or expense offset may not be appropriate until the arrangement has been completed. Situations such as these should be evaluated on a case-by-case basis, and the vendor should evaluate all the facts in conjunction with the guidance provided in SOP 97-2, FAS 68, FAS 86 and SAB Topic 5-O,Research and Development Arrangements If technological feasibility has been established prior to the vendor's entering into the arrangement, FAS 68 does not apply. With regard to a pre-existing research and development project, upon entering a funding arrangement, paragraph 73 of SOP 97-2 states, "if capitalization of the software-development costs commences pursuant to FAS 86, any income from the funding party under a funded softwaredevelopment arrangement should be credited first to the amount of the development costs capitalized. If the income from the funding party exceeds the amount of development costs capitalized, the excess should be deferred and credited against future amounts that subsequently qualify for capitalization. Any deferred amount remaining after the project is completed should be credited to income." Significant judgment is required in determining whether to record funding as revenue or as an offset to research and development expense. It is important to evaluate the specific contractual requirements of the agreement, the status of the technology at the point the funding is received, the percentage of the total development effort being funded by the third party, and the vendor's customary business practices in order to determine whether revenue or research and development expense offset should be recorded. If the vendor's customary business practice is to enter into funded research and development contracts with no repayment provision or repayment is dependent only upon the results having a future benefit, the funding can be recorded as revenue. In situations where the vendor does not ordinarily enter into funded development contracts and funding is received at a point where product development is almost complete, recording the funding as an offset to research and development expense may be most appropriate. In other words, the more the vendor is in the business of selling and providing software development services, the more appropriate the treatment is to record the funding as revenue; on the other hand, the more "one-off" such arrangements are, the more appropriate the treatment is to record the funding as a research and development expense offset. The facts and circumstances of these types of transactions require a careful evaluation to determine the appropriate accounting. Observation: As discussed in the paragraphs above, a number of factors contribute to the determination of the appropriate accounting for funded software development arrangements. As a general guideline, if as part of a software license arrangement a vendor is performing significant modification or customization on one of its existing software products (for which technological feasibility has been established) then the provisions of paragraph 7 of SOP 97-2 would apply (i.e., revenue transaction using contract accounting). Any unusual terms contained in this type of an arrangement (i.e., repayment, refund provisions, etc.) would also have implications on the revenues recognized. Questions and Answers Funded development arrangement risk remains with funded party The Vendor and the Customer enter into an arrangement to deliver Product A for a fee of $200,000, which the Customer will pay upon the execution of the contract. Product A has not achieved technological feasibility as defined under FAS 86; consequently, no software-development costs have been capitalized. As part of the arrangement, the Customer shall receive a royalty based on the future licensing of Product A. In the event that Product A is not licensed (or the future licenses are insufficient to generate $200,000 in royalty payments), the Vendor must repay the $200,000 (or the portion that is not recovered through the royalties on the future licenses of Product A). 138 PricewaterhouseCoopers LLP

Question: How should the vendor account for this arrangement? Answer: Since Product A has not yet achieved technological feasibility, FAS 68 applies. Given that the repayment of the $200,000 in funding is not based solely on Product A's having a future economic benefit, the Vendor must record a liability for the $200,000, and software-development costs should be expensed as incurred, until technological feasibility is achieved. If Product A is subsequently licensed, the royalties that the Vendor pays the Customer should be offset against the liability. If at the completion of the contract term the Vendor has not generated sufficient license revenue from Product A to cover the remaining liability, it is likely that the Vendor will have to pay off the liability. Funded development arrangement risk transferred to funding party Assume that the original facts in the example above apply here, except that the Vendor has no obligation to repay the $200,000. Question: How should the Vendor account for this arrangement? Answer: Since Product A has not yet achieved technological feasibility, FAS 68 applies. Given that the repayment of $200,000 in funding is based solely on Product A's having a future economic benefit through the potential royalty stream, the Vendor should account for its obligation as a contract to perform research and development services for others. The Vendor should record the funding as revenue (or offset it to research and development expenses) when it is earned, generally by using contract accounting. Funded development arrangement risk transferred to funding party and funding less than capitalized costs The Vendor and the Customer enter into an arrangement to deliver Product A for a fee of $75,000, which is to be paid on the date that the contract is signed. Product A has achieved technological feasibility as defined under FAS 86, but is not yet generally available. On the date that the arrangement is entered into, the Vendor has capitalized $100,000 in software-development costs associated with Product A. In return for entering into this arrangement, the Customer shall receive a royalty based on the future licensing of Product A. The repayment of the $75,000 is contingent on the licensing of Product A and if no such licensing occurs, no repayment will be required (i.e., the Customer is at risk for the recoverability of the $75,000). Question: How should the Vendor account for this arrangement? Answer: The Vendor should credit the $75,000 in funding against the amount of development costs that are capitalized on the Vendor's books, leaving a $25,000 balance in capitalized software-development costs. Future development costs should continue to be capitalized until there is general availability of the software. Amortization of the capitalized costs should commence on the date of the general release of Product A. Royalty expense should be recognized as Product A is licensed. www.pwcrevrec.com 139

Funded development arrangement risk transferred to funding party and funding exceeds capitalized costs Assume that the original facts in the example above apply here, except that the fee paid by the Customer is $125,000, and the Vendor incurs an additional $15,000 in capitalizable software-development costs for Product A after entering into the arrangement. Question: How should the Vendor account for this arrangement? Answer: The Vendor should credit $100,000 of the funding against the amount of development costs previously capitalized on the date of the arrangement. The remaining $25,000 should be recorded as deferred revenue on that date. Of the $25,000 in deferred revenue, $15,000 should be credited against the capitalizable software-development costs for Product A that were incurred subsequent to the Vendor's entering into the arrangement. When Product A is delivered (the date on which the arrangement is completed), the remaining $10,000 of deferred revenue should be recorded as income. 140 PricewaterhouseCoopers LLP

Chapter 9: Services and Contract Accounting 9.0 Overview In Chapter 2, the requirements for revenue recognition for a software license sold alone were outlined. Chapter 3 addressed the sale of a software license bundled with other elements such as PCS and/or services that do not involve significant production, modification, or customization of the software. This chapter discusses revenue recognition when a software license is sold with other services elements. When software is sold with other elements that include services to provide significant production, modification, or customization of software, those services are not separable from the software and are accounted for in conformity with Accounting Research Bulletin No. 45 (ARB 45), Long-Term Construction- Type Contracts, and the relevant guidance provided by SOP 81-1 as prescribed by paragraphs 74 through 91 of SOP 97-2. Accounting for services delivered over time under ARB 45and SOP 81-1 is often referred to as contract accounting. Observation: SOP 97-2 paragraph 7 states that when the arrangement requires significant production, modification or customization of software, the entire arrangement should be accounted for in conformity with contract accounting. Note that one does not have to go through a filter to first determine if the services are essential to the functionality of the other elements of the arrangement (as discussed in paragraphs 63, etc., of SOP 97-2) to fall within contract accounting. This is sometimes where confusion arises. We need to first focus on the determination of whether such services result in significant production, modification or customization of the software. If they do, the factors in paragraph 65 of SOP 97-2 with respect to whether one can separately account for a service element (and that might also lead to contract accounting) are not relevant; the arrangement is already in contract accounting. SOP 97-2 addresses many arrangements that include both software and services. Services may include PCS, training, installation, hosting or consulting. Consulting services often include implementation support, software design or development, customization or modification of the licensed software. The accounting for PCS revenue under SOP 97-2 is discussed in Chapter 3. Hosting arrangements are discussed in Chapter 10. The accounting for service revenue from training is generally straightforward, in that the related revenue is recorded when the training is performed, provided that VSOE of fair value for the training is available. Accounting for consulting and installation services can involve more complexity, because of the high level of judgment involved in determining whether these types of services can be accounted for separately. The initial and critical consideration in addressing revenue recognition related to services is whether the services can be accounted for separately from the other elements in the arrangement, particularly whether license revenue can be recognized separately from services revenue. Services, other than PCS, must meet the following criteria (as mentioned earlier, the services cannot include significant production, modification, customization or development of software) in order for the fee that is allocated to the services to be accounted for separately from the other elements of the arrangement: Sufficient vendor-specific objective evidence of fair value must exist to be able to allocate revenue to the various elements; The services to be provided must not be essential to the functionality of any other element of the transaction; and The services are described in the contract such that the total price of the arrangement would be expected to vary as a result of the inclusion or exclusion of the services. www.pwcrevrec.com 141

As discussed in Chapter 3 (specifically TPA 5100.39), it is important to remember that other contracts or agreements may be considered so closely related that they are, in effect, part of a single arrangement. Additionally, SOP 97-2 states that services in a single agreement or arrangement need not be priced separately in order for them to qualify for separate accounting. If all three of the criteria listed in the above paragraph exist, revenue should be allocated to the various elements based on VSOE of fair value. Revenue allocated to the services should be recognized as the services are performed or, if no pattern of performance is discernible, on a straight-line basis over the period during which the services are performed. If the services do not meet all of the criteria set forth in the paragraph above, they do not qualify for separate accounting, resulting in accounting for the entire arrangement in conformity with 81-1 contract accounting. An exception to the requirement to use contract accounting would arise when (1) VSOE of fair value does not exist for the service element, and (2) the only undelivered element is services that do not involve significant production, customization, or modification of the software (e.g., PCS, installation, training). In this case, the total revenue from the arrangement should be recognized as the services are performed. If no pattern of performance is discernible, the revenue should be recognized on a straightline basis over the service period. Observation: We are seeing, with increasing frequency, a shift in the software distribution channel. For example, the software vendor may be directly hosting the software for the customer, known as Software-as-a-Service ("SaaS"). Additionally, the software vendor's customer may now be an Application Service Provider (ASP) or another software vendor that is distributing the licensed software only by bundling it with their software. In other words, the software vendor's customer is not the ultimate end user of the software. In these circumstances, we are also seeing that the software vendor often provides a relatively significant level of services to its customer to assist in the implementation of the new delivery channel that allows the ultimate end user to access the software. This requires that the scope of the software vendor's service commitment be carefully evaluated as to whether such services are expected to result in significant production, modification or customization of software to allow the ultimate end-user access to the licensed software. These and other types of complex software arrangements involving multiple elements which include a significant level of services, generally require contract accounting. This chapter will discuss the following: 9.1 Determining if services can be accounted for separately 9.2 Applying contract accounting 9.3 Interaction of SOP 97-2, SOP 81-1 and SAB 104 9.3.1 Separation and allocation 9.3.2 Evidence of arrangement and collectibility 9.3.3 Impact of customer-acceptance clauses 9.3.4 Impact of PCS and other services 9.3.5 Extended payment terms 9.3.6 NRE arrangements that include subsequent manufacturing 9.4 Accounting for installation services 9.1 Determining if services can be accounted for separately As outlined in the overview above, there are three criteria which all need to be met to account for services separately from the related license fee. The first of these requires that VSOE of fair value has been established, which is discussed in detail in Chapter 3. The second criterion requires that the services are not essential to the functionality of any other element (usually the software license) of the transaction. As the complexity of software product offerings increases, vendors often notice a corresponding increase in the amount of customization and modification services that must be provided to meet the customer's functionality requirements. This is particularly the case when a software product is new and unproven in the market. In these cases, the vendor may be more willing to perform customization and modification 142 PricewaterhouseCoopers LLP

services in order to induce customers to take a chance on a new product. Arrangements involving the use of core software (as discussed below) or arrangements that involve a disproportionate level of service hours or service revenue relative to the vendor's standard business arrangements should be evaluated to determine whether the services are essential to the functionality of the software. A key factor in this analysis is the impact that the customization will have on the functionality of the software. This analysis should be done from the customer's perspective, not that of the vendor. For example, if (1) customization work is required to ensure that a vendor's software can manipulate and produce data in a certain format, (2) that particular functionality is a key factor in the customer's decision to license the software, and (3) the customization work is significant, contract accounting may be appropriate for the total arrangement fee (excluding PCS as discussed later in this chapter). This would hold true regardless of the vendor's view of the importance of the customization relative to the software's overall functionality. It is common for arrangements to include non-essential software-related services with the license and essential services, for example, PCS and training. Consistent with the basic principles of SOP 97-2, an assessment of which elements should be accounted for under contract accounting and which elements should be separately accounted for must be completed. This is supported by footnote 4 to paragraph 7 of SOP 97-2, which states "if a software arrangement includes services that meet the criteria discussed in paragraph 65 of this SOP, those services should be accounted for separately." The result is that the arrangement fee should be allocated between the non-essential services and the remaining elements using VSOE of fair value for the non-essential services via the residual method (assuming that VSOE of fair value does not exist for the remaining elements). Factors that may indicate that the service element is essential to the functionality of the other elements of an arrangement include the following: The software is not an off-the-shelf product. If the software is never licensed without services, it may be an indication that it is core software. The vendor always provides the services with the software. If the vendor always includes the services as part of the licensing arrangement and never offers the software without the services, this suggests that the service element is essential to the functionality of the software. Building complex interfaces. If complex interfaces must be built between the software and the customer's existing systems, these integration services would likely be essential to the software working as intended. The services include significant alterations of the features and functionality of the software. The feature and function changes are likely to indicate that the licensed software is not an off-the-shelf product. The timing of payments for the software coincides with the performance of the services. Payments which include amounts pertaining to the software license and which are spread over the course of delivering the services often suggest that the customer is relying on the service element of the arrangement. Milestones or acceptance criteria affect the realizability of the software license fee. Payment terms that are tied to milestones or to customer-acceptance clauses would suggest that the service element is essential to the functionality of the software. The customer views the services of the vendor as a key differentiating factor in selecting the vendor's software. If a customer believes that the vendor's services provide it with the only means to meeting its objectives, the services may be essential in the eyes of the customer. The final product that is delivered to the customer contains a significant amount of new code. If the number of lines of code that is added to the core software is substantial, the service element may be essential. A critical factor in determining whether services are essential to the functionality of any other element of the software arrangement is whether the software is considered core software or off-the-shelf software. SOP 97-2 defines core software as an inventory of software that vendors use in creating other software. www.pwcrevrec.com 143

Core software is not delivered as is, because customers cannot use it unless it is customized to meet system objectives or customer specifications. SOP 97-2 defines off-the-shelf software as software marketed as a stock item that customers could use with little or no customization. Arrangements involving a core software product generally do not qualify for separate accounting because the services are considered essential to the functionality of the software, based on the definition of core software described above. If, to meet the customer's purpose, the arrangement includes significant modifications or additions to the software, the software should be considered core software. Software that is considered off-the-shelf may be accounted for separately from services. Software may be considered off-the-shelf only if (1) insignificant changes (or no changes) are made to the underlying code and (2) the software can be used by the customer for the customer's purposes upon installation. The customer's actual use of the software is not required for it to be determined that the customer could use the software off the shelf. In addition to not being essential to the functionality of any other element in the transaction, services that qualify for separate accounting are always separately described in the contract and have one or more of the following characteristics: The services are available through other vendors. Services that are available through other vendors indicate that the customer's decision to license the software did not depend on the vendor's ability to provide the services. The services do not carry a significant degree of risk or unique acceptance criteria. Services that are not complex and for which there are no customer-specific acceptance or performance criteria indicate that the customer's acceptance of the software product did not depend on the successful completion of the services. The software vendor is an experienced provider of the services. Services that are performed routinely or that the vendor has performed with ease in the past indicate that the risk that the customer will not accept the product is low. The vendor is primarily providing implementation services. Such services as implementation planning, loading the software, training customer personnel, data conversion, building simple interfaces, running test data, and assisting in the development and documentation of procedures are generally value-added services that are not required for the customer to use the product but, rather, enhance the benefits that the software can bring to the customer. Customer personnel are dedicated to participating in the services that are performed. Customer involvement in the services indicates that the customer is sharing the risk that the services will not meet its needs. Arrangements in which the customer takes primary responsibility for the required services (i.e., the customer controls the performance of the services but turns to vendor personnel for their experience with the product or to augment its staff) suggest that the services provided by the vendor are incidental to the product. Observation: For a number of reasons, software vendors may perform all of the required implementation services themselves for their software license sales (i.e., no other third-party vendors or situations where the enduser customer performs the implementation themselves). Depending on the nature of the services involved and the specific facts, these situations may require contract accounting for the entire arrangement. As software vendors grow and their products mature, the need for them to perform all of the implementation services may begin to diminish. In order to transition from a contract accounting model (SOP 81-1) to a more traditional software revenue recognition model (i.e., SOP 97-2 license revenue upon delivery and services as performed, assuming all other revenue recognition criteria are met), the software vendor must first demonstrate over time that a meaningful number of implementations (at least 10-20%) are being performed by others (i.e., resellers, third-party consulting firms, the actual end-user customer, etc.). 144 PricewaterhouseCoopers LLP

As noted earlier, an analysis of whether contract accounting should be followed must comprehend how important the customization services are to the functionality of the software in the eyes of the customer. Paragraph 74 of SOP 97-2 provides some parameters for this analysis. It states, If an arrangement to deliver software or a software system, either alone or together with other products or services, requires significant production, modification, or customization of software, the service element does not meet the criteria for separate accounting set forth in paragraph 65. The entire arrangement should be accounted for in conformity with ARB No. 45, using the relevant guidance in SOP 81-1 except for services which meet the separability criteria in paragraph 65 of SOP 97-2. This acknowledges that the licensed software, without the contemplated services, does not fulfill the customer's expectations. SOP 97-2 does not provide specific guidance on how to interpret the term significant in paragraph 74, but instead refers readers to guidance provided in paragraph 14 of SOP 81-1. Paragraph 14 of SOP 81-1 states the following: Contracts not covered...include...sales by a manufacturer of goods produced in a standard manufacturing operation, even if produced to buyer's specifications, and sold in the ordinary course of business through the manufacturer's regular marketing channels if such sales are normally recognized as revenue in accordance with the realization principle for sales of products and if their costs are accounted for in accordance with generally accepted principles of inventory costing. Observation: The provisions of SOP 81-1 (contract accounting) cannot be used to avoid the delivery requirements under SOP 97-2 for situations where a software license arrangement includes a specified future deliverable (i.e., specified future product or specified upgrade or enhancement). In these situations, as discussed in Chapter 5, the VSOE of fair value of the future deliverable must be deferred if such VSOE is available. The third criteria which needs to be met to account for services separately from the related license fee is that the services must be described in the contract such that the total price of the arrangement would be expected to vary as a result of the inclusion or exclusion of the services. In other words, the services must be of value from the customer's perspective. Typically, if the service is an item that the customer bargained for inclusion in the arrangement or it is sold separately, it is considered a helpful fact in meeting this criterion. If the arrangement includes services that meet all three of the criteria for separate accounting, revenue should be allocated among the service and software elements of the contracts based on VSOE of fair value. Chapter 3 discusses the determination of VSOE of fair value in detail. Specifically for services, VSOE of fair value can be determined in a number of ways, including the following (when the element is sold separately): Additional training sessions purchased separately by existing customers; Implementation services sold separately to existing customers related to a new release of a vendor's software product that is included as part of PCS (i.e., the implementation services and new software release are not sold together); or Other add-on services (e.g., customer initially plans to do the implementation themselves, but subsequently decides to hire the software vendor to perform the services or customer initially hires the software vendor to only do project management work on the implementation, but then subsequently decides to hire the software vendor to also perform the date conversion, etc.). Revenue allocated to the service element(s) should be recognized as services are performed or, if no pattern of performance is discernable, recognized on a straight-line basis over the period during which the services are performed. If the services do not meet the criteria for separate accounting, contract accounting must be applied to both the software and service elements, except as discussed in below. www.pwcrevrec.com 145

If the arrangement includes services that do not meet all three of the criteria for separate accounting ("SOP 81-1 services") as well as services that do meet the criteria for separate accounting ("SOP 97-2 services"), then EITF 00-21 Revenue Arrangements with Multiple Deliverables must be applied to separate and allocate the consideration among the deliverables. Assuming that the criteria set forth in EITF 00-21 are met for the SOP 81-1 services and the SOP 97-2 services, then these services would be accounted for separately under the relevant guidance. However, assuming that the criteria in EITF 00-21 are not met for the SOP 81-1 services and the SOP 97-2 services, then the entire arrangement is considered to be a single unit of accounting and accounted for by applying the guidance in paragraph 12 of SOP 97-2, which provides for the deferral of the arrangement fee until all elements have been delivered except for PCS at which point the arrangement fee begins to be recognized over the remaining PCS period. In some situations: The software arrangements require a significant amount of service to be performed by the software vendor's technical development staff who are to work under the direction of the customer, albeit with no deliverable in terms of a specified product. The nature of the software license and how the customer would obtain economic benefits from its license rights being acquired necessitated that the customer integrate the licensed software into its own intellectual property. The fair value of the amount of time that is to be provided by the software vendor's development staff is significant relative to the contractually stipulated portion of the arrangement's total fee assigned to the software license. In other words, the services are not simple data transfer and loading or installation activities that are done repeatedly. As a result, we conclude there is a presumption (and there was no objective evidence available to rebut that presumption) that the utilization of those services would result in significant production, modification or customization of software. To conclude otherwise would have suggested that the customer would demand the right to utilize and direct the efforts of software developers in a manner that would be wholly inconsistent with (1) the skill set of the people, and (2) the customer's motivation in negotiating for and obtaining the rights to the benefits of those people's efforts and obligating itself to pay for those efforts (notwithstanding the fact that the payment obligation was executory in nature). Even if a determination is reached that the services are not expected to result in significant production, modification or customization of the software, it may well be that the services are essential to the functionality of the software from the customer's perspective. That is a circumstance that also requires the application of contract accounting pursuant to SOP 97-2 paragraph 65. Observation: When dealing with other than shrink wrap software or long-standing products that have been installed many times in a wide variety of settings and there is a significant level of services being provided, the need to account for the entire arrangement under contract accounting is a distinct possibility. Questions and Answers Appropriateness of accounting for services separately The Vendor and the Customer enter into an arrangement on June 27, X1 pertaining to software Product J. Pursuant to the terms of the arrangement, a fully functional version of Product J was delivered on June 30, X1. The arrangement included 180 days of consulting services. The Vendor's standard 146 PricewaterhouseCoopers LLP

arrangements include 30 days of consulting services. The Vendor has never sold the consulting services separately. The purpose of the consulting work is to develop complex interfaces so that Product J can operate with the Customer's legacy systems. No other services are included in the arrangement. Question: Should the Vendor account for the Product J software license and the consulting services separately in this arrangement? Answer: Based on the facts of this arrangement, the consulting services would not meet the criteria for separate accounting that are outlined in SOP 97-2 paragraph 65, as the services clearly impact the functionality of the software (i.e., develop complex interfaces). As such, contract accounting for the total fees under the arrangement would be appropriate. Furthermore, note that since the Vendor does not sell these services separately, it most likely would not have VSOE of the fair value for the separate elements and thus would fail that criterion as well. 9.2 Applying contract accounting If a vendor selling a software license with services concludes that all three of the criteria required to account for the services separately from the license have not been met (or that the arrangement involves significant production, modification or customization of software), then contract accounting is appropriate for all fees under the contract (except PCS, assuming there is VSOE for that element see discussion later in this chapter). SOP 97-2 paragraphs 74 to 91 provide guidance with regards to applying contract accounting for software arrangements and require that revenue be recognized in accordance with Accounting Research Bulletin No. 45 (ARB 45), Long-Term Construction-Type Contracts, and with the relevant guidance provided by SOP 81-1. ARB 45 and SOP 81-1 outline two different methods of accounting for contracts: (1) the percentage-of-completion method and (2) the completed-contract method. Paragraph 15 of ARB 45 provides the following guidance on determining which method is the most appropriate. It states, The committee believes that, in general, when estimates of costs to complete and extent of progress toward completion of long-term contracts are reasonably dependable, the percentage-of-completion method is preferable. When lack of dependable estimates or inherent hazards cause forecasts to be doubtful, the completed-contract method is preferable. Paragraph 24 of SOP 81-1 states: For entities engaged on a continuing basis in the production and delivery of goods or services under contractual arrangements and for whom contracting represents a significant part of their operations, the presumption is that they have the ability to make estimates that are sufficiently dependable to justify the use of the percentage-of-completion method of accounting. SOP 81-1 81-1 goes on to state, in paragraph 25: Accordingly, the division believes that entities with significant contracting operations generally have the ability to produce reasonably dependable estimates and that for such entities the percentage-ofcompletion method of accounting is preferable in most circumstances. An entity using the percentage-ofcompletion method as its basic accounting policy should use the completed-contract method for a single contract or a group of contracts for which reasonably dependable estimates cannot be made or for which inherent hazards make estimates doubtful. Such a departure from the basic policy should be disclosed. Based on the above guidance, the percentage-of-completion method is the preferred methodology and should be used in most situations. The completed-contract method should be used in unique situations only and should not be viewed as an alternative to applying the percentage-of-completion method. Regardless of the method used, when estimates of total contract revenue and cost indicate that a loss will be incurred, the loss should be accrued in that period. Also, even reasonably dependable estimates may www.pwcrevrec.com 147

need to be revised, regardless of whether or not the scope of the project has changed. According to Accounting Principles Board Opinion No. 20 (APB 20), Accounting Changes, such revisions in estimates are considered changes in accounting estimates and should be accounted for during the period in which the estimate is revised. Generally, using the percentage-of-completion method for contracts of a short duration (e.g., for public companies, those that do not extend significantly over a quarterly reporting period) is less practical, due to the administrative requirements of tracking and estimating progress toward completion. Revenue for contracts with a short duration (subject to management's judgment) should generally be accounted for by the completed-contract method in circumstances in which the financial position and results of operations would not vary materially from that which would be derived from the percentage-of-completion method. Under the percentage-of-completion method, progress towards completion can be measured by input measures (e.g., labor hours incurred) or output measures (e.g., contract milestones), whichever provides the most reliable and meaningful measure that is available for determining a project's progress toward completion. The preferred approach is the use of an output method, however, the practical application is difficult given that output measures generally cannot be reliably measured. As stipulated by paragraph 51 of SOP 81-1, the method that is selected should be periodically reviewed and confirmed by alternative measures. SOP 97-2 provides guidance on how to apply input and output measurement methods when the percentage-of-completion method is being used. An input measurement method takes stock of the amount of effort that has been expended under a contract. Examples would include methods that are based on costs and/or efforts expended. An output measurement method draws on the results that are achieved under a contract. Examples would include methods that are based on units produced and delivered, substantive contract milestones (which may be different than payment milestones), and added value. The method that is used must best approximate the measurement of the degree to which each element of a contract has been completed. An input measurement method may be used for the service portion of the contract, and an output method used for the off-the-shelf software portion, assuming that the contract can be segmented. Items that are not specifically produced for the contract, such as off-the-shelf hardware or software that is purchased from a third party should not be included in the measurement of the contract's progress toward completion until the installation of the elements is completed, if such an inclusion would tend to overstate the percentage of completion that might otherwise be determined. The cost of core software should be included in the measurement of the contract's progress toward completion as the software is customized. Observation: In applying percentage-of-completion contract accounting to software arrangements, it is our experience that progress to completion usually is most appropriately measured by inputs (generally labor hours). Despite the discussion about the use of output methods in SOP 97-2, we have found that it is generally difficult to sustain a position that sufficient evidence exists to show that progress to completion can be reliably measured by output milestones in a software arrangement. SOP 81-1, paragraphs 43 through 51 and SOP 97-2, paragraphs 78 through 91 discuss the considerations involved in selecting the method by which progress to completion is measured. As a practical matter, many companies that apply contract accounting for their services include a hold back mechanism in their percentage-complete calculations. This approach provides a reserve for unexpected project delays and extensions. If consistently applied, this methodology has been accepted in practice as part of the estimation process. Inherent in applying contract accounting under SOP 81-1 is that not only are the input measures estimated to derive the percentage complete, but the total revenues to be derived from the contract may also be estimated. The estimated percentage complete is then applied against these estimated total revenues to derive the revenue to be recognized through the current accounting period. It is not 148 PricewaterhouseCoopers LLP

uncommon for the total fees contemplated in the contract to be adjusted subsequently, up to reflect expanded scope of services (referred to as change orders), or down to resolve disputes about the work performed or value received (referred to as claims). Depending on whether the costs attributable to a change order are probable of being recovered, such costs will either be treated as costs of the contract or deferred, as discussed in paragraph 62 of SOP 81-1. Change orders that are in dispute or are unapproved should be evaluated as claims. If a vendor requests incremental fees for claims, such fees should only be included in the total contract fee if it is probable that the claim will result in additional contract revenue and the amount can be reliably estimated. Even if already billed, reductions of the total fees under the arrangements should be recorded so as to reduce revenues and should not be treated as bad debts. Only write-offs of receivables as a result of a customer becoming not creditworthy (i.e., an inability to pay) should be treated as bad debt expenses. Observation: Use of the percentage-of-completion method of contract accounting requires that the company be able to reasonably estimate total costs. There are three approaches to applying percentage of completion accounting discussed in paragraph 25 of SOP 81-1. The commonly applied approach is a direct calculation of percent complete (paragraph 25(a)). However, there are circumstances in which estimates can be made but the overall profitability can only be known in a range (often this is highlighted by profitability estimates that change period to period). In this circumstance, margins should be recorded assuming profitability at the low end of the range as indicated in paragraph 25(b). This is consistent with the hold-back contingency discussed above. That necessitates (1) the scope of the services be adequately defined and of a nature that permits costs to be reasonably estimable, and (2) an accounting system that accurately captures costs incurred. Where services are not being provided on a time and material basis and the nature of services are those that lead to the production, modification or customization of software, the use of the zero gross profit approach (paragraph 25c of SOP 81-1) is sometimes appropriate, at least in the early stages of the contract. Under SOP 81-1, there are certain situations in which a vendor may segment a contract into discrete projects in order to account for each project as a separate profit center (i.e., separate percentage-ofcompletion calculations are done for each contract segment). Paragraphs 76 and 77 of SOP 97-2 provide direction on when segmentation of an arrangement into separate profit centers is appropriate. These parameters are consistent with those outlined in SOP 81-1. The general criteria for segmenting contractual elements are set forth in paragraphs 39 through 42 of SOP 81-1 and should be followed for software arrangements. The SOP 81-1 criteria require that: each individual component of the contract be available on a separate basis (the customer can accept the contract on an aggregate or individual-component basis) and that, functionally, those components are able to stand alone; the aggregate price of the components approximates the aggregate contract price; the terms of the contract clearly call for separable elements, and those elements are negotiated separately on a routine basis; the market assigns different margins to separate components; there is a stable history of revenue streams for individual components that are sold separately (particularly for those segments with a margin higher than that earned on the overall contract); the excess price of the sum of individual segments over the aggregate contract price is clearly attributable to cost savings that are incidental to combined performance; and the similarity (1) between the services and prices in the contract and (2) between the customer and other customers should be documented and verifiable. Observation: Software companies typically have significant difficulty meeting these criteria for segmentation, especially the criterion that requires individual components of the contract to be available to the buyer on a www.pwcrevrec.com 149

separately priced, stand-alone basis. Often, hardware vendors and other vendors will preclude software companies from separately selling the hardware or third-party service component of a system, thus preventing the software company from negotiating the elements separately. Similar to accounting for multiple element arrangements under SOP 97-2, another challenge that software vendors using contract accounting must address is the appropriate accounting for several contracts with the same customer that are entered into within the same, narrow time frame. This situation tends to be more prevalent with core software because customers often decide to add another module, feature or customization prior to the completion of the original work. The principal challenge relates to ascertaining when a series of contracts should be accounted for as individual contracts or aggregated into one overall arrangement. If a contract is accounted for individually, additional contracts that are entered into at later dates may be considered new contracts or extensions/modifications of the original contract, as discussed in SOP 81-1. We believe that the AICPA's guidance established in the Q&As (TPA 5100.39) is relevant in an assessment of how a series of contracts should be accounted for under both SOP 97-2 and SOP 81-1. This guidance is discussed further in Chapter 3. In addition, see similar discussion in paragraphs 35 through 38 of SOP 81-1 regarding combining contracts. In the context of services arrangements under contract accounting, subsequently entered contractual arrangements, which extend the scope of the original services, would be considered all as one arrangement (i.e., one percentage-of completion computation) if the original project is not 100% complete and paid in full. Observation: An additional issue often arises when the contract accounting that is being followed impacts whether the revenue will be classified as that which is generated by license fees or by services. The classification is considered important because a vendor may receive a greater corporate valuation by an analyst or investment banker based on different revenue multiples that may be applied to each revenue type in valuing the company. Where available, VSOE should be used to allocate revenue for classification purposes. However, vendors that follow contract accounting for their arrangements often do not license software without services. Because the VSOE criteria of SOP 97-2 require that each element be sold separately, VSOE of fair value for the licenses may not exist when contract accounting is being followed. In these situations, practice has established that VSOE for the services element is applied to the revenue classification for that element and the residual portion of the total fees is allocated to the license classification. If VSOE of fair value does not exist for either element, then it may be difficult for a vendor to justify reflecting the licensing portion of its revenue separately in its income statement, even though the contractual arrangement may specify a fee for the license that is separate from the service fee. However, the SEC does not object to the presentation of product and service revenue separately in the income statement, as long as a reasonable methodology is applied on a consistent basis to determine the allocation. For further discussion for this topic, see Chapter 3, section 3.7. Questions and Answers Percentage-of-completion versus completed-contract accounting reasonably dependable estimates The Vendor and the Customer enter into an arrangement on January 1, X1 to provide software and consulting services that involve the development of complex interfaces between the Vendor's software and the Customer's existing systems. The fee for the arrangement is $600,000, and the Vendor expects to incur $240,000 in costs over the next twelve months, as the services are performed. Assume that labor hours are incurred ratably over the twelvemonth period. Input measures (costs) are considered more objective than output measures. Question: Assuming that the Vendor is able to make reasonably dependable estimates of the costs that are involved in fulfilling the terms of the contract, what accounting method would be applied to the arrangement? 150 PricewaterhouseCoopers LLP

Answer: Under the percentage-of-completion method of contract accounting, the revenue would be recognized and the related costs expensed as progress towards the completion of the project (that is specified by the contract) is made. In this example, the Vendor would recognize $50,000 in revenue and $20,000 in expenses each month, until the services are completed (December 31, X1), irrespective of when payments are made. Percentage-of-completion versus completed-contract accounting no reasonably dependable estimates Assume that the original facts in the example above pertain here as well, and also assume that the Vendor has never provided these services before and cannot produce reliable estimates of their cost. Question: Assuming that the Vendor is not able to make reasonably dependable estimates of the costs that are involved in fulfilling the terms of the contract, what would the accounting be for the arrangement? Answer: In this situation, the completed-contract method would be the appropriate method. Under the completedcontract method of contract accounting, no revenue is recognized until the contract is complete which, in this example, is on December 31, X1. In order to properly match revenue with expenses, the Vendor will capitalize the costs of the arrangement on the balance sheet until the arrangement is completed, at which time the costs will be recorded as expenses. Accordingly, the Vendor would defer $20,000 per month until December 31, X1, at which time it would (1) record $600,000 as revenue and (2) expense the $240,000 that had been recorded as a deferred cost. If at any time during the contact a loss would have been anticipated, the full amount of the loss should be accrued at that point. Input method vs. output method to measure the percentage-of-completion A Vendor sells its software in modules. The main software consists of a general ledger module to which a customer can add other modules such as inventory, financial reporting, payroll, etc. The Vendor enters into an arrangement on August 1, 20x1 with a Customer to license the general ledger and reporting modules. The sale includes installation and customization services that will add additional functionality to both the general ledger and the reporting modules. The total fees for the arrangement are $150,000, which includes a 25% discount on both the license and the services. The Vendor has a history of providing modifications to its software and making accurate estimates of the hours required to complete the tasks. The Vendor intends to recognize revenues for the license fee and services in accordance with SOP 81-1 (i.e., to not separate the elements, since the modifications are essential to the intended functionality of the modules) and has estimated that the services will require 100 days of work consisting of 60 days of modifications to the general ledger module and 40 days for the reporting module customization. The services will be tracked on a time-incurred basis and any work incurred beyond the initial estimate of 100 days will be billed to the Customer at a rate of $1,200 per day. Billings per the agreement are to consist of $50,000 due at the time software licenses are delivered, $80,000 upon completion of the modifications to the general ledger module and $20,000 at the completion of work on the reporting module. Question: Should the Vendor select input or output measures for measuring the percentage of the work complete in accordance with SOP 81-1? www.pwcrevrec.com 151

Answer: The selection of input measures vs. output measures for measuring the percentage-of-completion should be determined by identifying which method provides the most reliable and meaningful measure that is available for determining the project's progress towards completion. The most identifiable input measure in this situation is the hours incurred towards completion and the most identifiable output measure is the successful modification and installation of each module. As the input measure contains more points of reference (i.e., 100 days) than the output measure (two modules), the input measure of time incurred would be considered the more appropriate method under which to measure the percentage-of-completion in this situation. Classification of license vs. services Assume the original facts from above and, furthermore, the Vendor has not established VSOE for the license. Question: How should the Vendor classify the payments made in its statement of operations? Answer: Although revenue recognition for this contract is being measured in accordance with SOP 81-1, the Vendor is able to apply the VSOE provisions of SOP 97-2. As additional services are to be provided at a rate of $1,200 per day, which is consistent with the Vendor's pricing practices and industry norms and such rate has substance, the Vendor is considered to have established VSOE for the services for the purpose of allocating the contract between license and service fees on the face of its statement of operations. Therefore, based on the 100 days estimated to complete the services, $120,000 (80%) of the total fee should be allocated to services and the remaining $30,000 (20%) to the license. Based on the percentage-of completion for the entire arrangement at the end of each reporting period, these percentages (80%/20%) would be used to classify revenue recognized in the statement of operations. Note that this residual method approach has the effect of driving the entire discount on the arrangement into the license revenue component. Amendments Assuming the original facts from above, the Vendor is midway through the software customizations when the Customer decides to add the payroll module. Adding this module as specified by the Customer will require 20 additional days of modification and installation work. The Vendor and Customer enter into a written amendment to the original agreement to provide the module for $30,000 and the services for $24,000. Question: Should the Vendor account for the additional work as a separate contract or as an addition to the existing contract? Answer: The facts provided above would support accounting for this contract separately because: The Customer did not negotiate for the additional module and services in close proximity to the time of entering into the original agreement; The individual component, in this case the payroll module, is available on a separate basis; and 152 PricewaterhouseCoopers LLP

The amount charged is similar to the price the Vendor has charged others for the module and installation/customization work. Treatment for disputed amounts Assuming the same facts as above, the Vendor exceeds its estimate to complete the general ledger module by 10 days and issues the Customer an additional bill for $12,000 (recognizing revenue for this amount). In the next accounting period, the Customer disputes the bill with the Vendor and they agree to an extra payment of $8,000 instead of the $12,000 the Vendor had billed. The Vendor is considering either reducing revenue or applying the amount to bad debt expense to account for the $4,000 difference. Question: How should the Vendor account for the $4,000 difference? Answer: In this situation, the Vendor and Customer have agreed to adjust the total fees for services that have been provided and thus, the Vendor's adjustment should impact its revenues/margin, not be treated as a bad debt expense. The $4,000 should be applied as a reduction of the Vendor's service revenue in the period when the adjustment is granted. Bad debt expense should only represent issues related to the inability to pay, not an unwillingness to pay. 9.3 Interaction of SOP 97-2, SOP 81-1 and SAB 104 Although SOP 97-2 (1) addresses situations in which contract accounting applies and (2) requires treatment in conformity with SOP 81-1, it does not provide any specific guidance on the interaction of the two SOPs. Thus, for an arrangement that has followed the guidance of SOP 81-1, it is uncertain whether the concepts and provisions of SOP 97-2 should be applied. Although SOP 97-2 does not specifically address this issue, we believe that many of the same factors on which the guidance in SOP 97-2 is based are required to be considered in the application of SOP 81-1. The issuance of SAB 104, although not directly impacting SOP 97-2 and SOP 81-1, has influenced some issues and interpretations common to all three pieces of literature, including what constitutes evidence of an arrangement and acceptance. Some of the issues related to these standards that often cause confusion among software vendors include: separation and allocation; evidence of arrangement and collectibility; customer-acceptance clauses; PCS; extended payment terms; and NRE arrangements that include subsequent manufacturing. 9.3.1 Separation and allocation An arrangement may include significant production, modification, or customization of licensed software, but may also include non-software deliverables. A question arises whether the non-software deliverables should be part of the arrangement within the scope of SOP 81-1. In such situations, EITF 00-21 should be applied to determine whether the non-software deliverables can be separated from the software deliverables and thus the related allocated fee be attributed to revenue following the relevant guidance. Additionally, consideration may need to be given to EITF 03-5 and EITF 00-2. www.pwcrevrec.com 153

9.3.2 Evidence of arrangement and collectibility SOP 81-1 directly addresses the fundamental revenue recognition criteria of delivery (recognition of the delivery of services over time) and of fees being fixed or determinable (requirements to estimate total revenues to be received in applying the percentage complete). The remaining fundamental revenue recognition criteria set forth in SOP 97-2 and SAB 101, evidence of arrangement and collectibility, are not as clearly addressed in SOP 81-1, but still apply to contract accounting. Prior to commencing recognition of revenue under contract accounting, the vendor should have assessed and concluded that collectibility was reasonably assured. In this regard, the vendor should document its standard practices for completing this assessment, so that the satisfaction of this criteria is evident. Subsequent write-offs of receivables where no credit checks were performed at the outset may suggest that revenue should never have been recognized in the first place (as opposed to revenue recognized, later offset by a bad debt expense classified elsewhere in the income statement). A presumption exists that the collectibility criteria was not met (and revenue should not have been recognized) in situations where revenue and bad debt expense for the same services are recognized in the same accounting period. If the vendor does not have evidence of arrangement consistent with its normal business practice, then it should not commence recognition of revenue under contract accounting. If it is the vendor's practice that both parties sign the contract (as is almost always the case in services arrangements), then the contract must be signed by both parties prior to the end of the accounting period to recognize any revenue in that period. Backdating of agreements is not acceptable. Observation: To the extent both parties do not sign a contract until shortly after the end of a period, but costs were incurred by the vendor specifically for this arrangement prior to period-end, the costs incurred may be deferred at period-end. SOP 81-1 allows for precontract costs to be deferred, depending on the probability of recovery of the costs. Paragraph 75 of SOP 81-1 provides a list of types of contract costs and how each type should be accounted for. Many software vendors that provide significant consulting services will likely encounter situations where it makes business sense to commence work for a customer prior to execution of the standard documents. Because the evidence of an arrangement criterion is not met pursuant to the previous paragraph, revenue should not be recognized until such contract is in place. However, many vendors have an additional business practice in such situations where a simplified, interim agreement is struck between the parties which provides that the vendor is engaged to render services on a time-and-materials basis (often up to a set limit), and the customer commits to pay accordingly. If the vendor has established this evidence of arrangement practice, recognition of revenues on the time-and-materials basis may be appropriate, once both parties execute the interim agreement. 9.3.3 Impact of customer-acceptance clauses As noted earlier, SOP 81-1 states that a determination of the preferable accounting method depends on a vendor's ability to make reasonably dependable estimates. However, paragraph 23 of SOP 81-1 also requires that as a condition to using the percentage-of completion method, it must be anticipated that both the vendor and the buyer will satisfy their obligations under the contract. Presumably, this would require that customer acceptance not be uncertain at the outset of an arrangement. In determining whether acceptance is uncertain, a vendor may want to consider the following factors (among other facts): The vendor's history regarding similar arrangements. If the vendor has a history of successfully meeting acceptance criteria in its contracts, acceptance may be reasonably assured. 154 PricewaterhouseCoopers LLP

The customer's participation in the endeavor. Generally, the more involved the customer is in the arrangement, the less likely it is that acceptance will not be achieved. The nature of the software and the existence of other service providers. If the software is mission-critical and there are no other providers of a similar software, the economic penalty that the customer will face if it does not accept the software may be so significant that the customer's acceptance is reasonably assured. The payment terms. If the payment terms are weighted in favor of acceptance or the other payments are subject to a refund, this may indicate that acceptance is not perfunctory. Observation: All of the facts and circumstances surrounding the arrangement should be evaluated when a determination is being made of whether or not an acceptance clause impacts the vendor's ability to use the percentage-of-completion method. Customer-acceptance clauses should be of concern to vendors, but in some cases they may be considered perfunctory and each situation must be evaluated. The guidance in TPA 5100.67 on customer acceptance and software revenue recognition should also be considered, as appropriate. 9.3.4 Impact of PCS and other services SOP 97-2 addresses the accounting for services in arrangements that include both software and services. Such arrangements may also include future PCS that will be supplied following the fulfillment of the terms of the contract and for which there will be no additional charge. If the service element meets the criteria for separate accounting that are cited in paragraph 65 of SOP 97-2, services may be carved out of the contract accounting in certain circumstances (see footnote 4 to paragraph 7 of SOP 97-2). SOP 97-2 does not address circumstances in which PCS is provided subsequent to the completion of the production, modification, or customization of the software. According to the criteria that SOP 97-2 cites for multiple-element arrangements, logic and practice dictate that if VSOE of the fair value of the PCS exists, the PCS should be unbundled from the total arrangement fee. The fee allocated to the PCS arrangement should be (1) recognized over the PCS period, beginning upon the completion of the services that are being accounted for pursuant to SOP 81-1 and (2) excluded from contract revenue that is being recorded under contract accounting. As discussed in Chapter 3, this issue was addressed by the AICPA in TPA 5100.49. This TPA states that if the software vendor has VSOE of fair value of the PCS, then PCS should be accounted for separately from the balance of the arrangement that is being accounted for under contract accounting. 9.3.5 Extended payment terms Payments for services delivered over time and subject to contract accounting typically are spaced out over the term of the project and are payable upon reaching certain milestones along the way. In this fashion, payments often parallel when the revenue is recognized. Although the payments usually are spread out over time, the concepts and risks of extended payment terms still apply to services arrangements under contract accounting. If payment terms are allowed which extend the payments beyond when the services are rendered, application of contract accounting results in the recognition of revenue under percentage completion before such amounts are billable, with the offsetting amount carried in a balance sheet holding account often termed either Unbilled receivables or Costs and earnings in excess of billings on uncompleted contracts. This scenario increases the potential that the customer may dispute the services rendered and refuse to pay, or that concessions will be made in the contract fee or the total work to be performed, even though revenue has already been recognized. Accordingly, unless the vendor has a proven track record of collecting such unbilled receivable amounts, the estimates of total revenue under the contract which are used in the current percentage-complete computations should consider excluding amounts on extended payment terms. www.pwcrevrec.com 155

9.3.6 NRE arrangements that include subsequent manufacturing Certain software vendors enter into non-recurring engineering (NRE) arrangements with customers that include a follow-on manufacturing arrangement. These arrangements may involve customization of software to a circuit board or other manufactured product to which the software is not considered incidental. The software vendor also will often be the manufacturer of the board. Payments consist of amounts due during the NRE work based either on milestones or scheduled payments. Payments for boards customized are on a per board basis and are typically greater than amounts charged for a standard product due to the lower quantity being produced. The customer is committed to purchase a minimum number of the modified boards over a multi-year period. The vendor retains all rights to the modified board and the customer does not have the right to take the modified board to another board manufacturer or to manufacture the boards themselves. The software vendor is not obligated to provide upgrades or enhancements. Any upgrades or enhancements desired by the customer would be at the customer's request and the work would result in a separate agreement. In these situations, the arrangement is not eligible for multiple-element accounting. The NRE and followon manufacturing cannot be unbundled unless there is persuasive evidence that the NRE activity is a separate earnings process from both the vendor and customer's perspective (e.g., whether the manufacturing process is essential to the functionality of the NRE, for example, could the customer have taken the NRE results and gone to a different enterprise for the manufacturing, or did the customer not get independent rights to all the core technology reflected in the output of the NRE). The revenue and costs of the NRE arrangement should be deferred and recognized based on the manufacturing agreement. The arrangement is not considered eligible for recognition on a percentage-ofcompletion basis (in this case on a units delivered basis) until the product begins delivery. In essence, the payment for the NRE is considered an up-front payment for which revenue recognition is generally prohibited as clarified in SAB 104. Questions and Answers Accounting for software arrangements with research and development and follow-on manufacturing A Vendor that provides boards containing non-incidental software for a telecommunications company is asked to modify the board's software in an attempt to develop a new more advanced product. Upon completion of the software development effort, the Vendor will provide the Customer with at least 400 boards containing the new software. For each board delivered, the Customer will pay $1,000 per board. The Customer is committed to purchase at least 400 boards over a three-year period. An up-front payment of $1,000,000 is provided to fund the research and development effort. No VSOE exists for either the product or the research. The research and development will be the property of the Vendor and the Customer will not have rights to manufacture the boards (i.e., the Vendor has exclusive manufacturing rights). The contract is signed on January 1, X1. The development work is completed on December 31, X1, 300 units of the product are delivered on January 31, X2, and 100 units on January 31, X3. Question: Does the arrangement qualify for separate accounting for the development and manufacturing efforts? How should the Vendor account for the arrangement? Answer: As the Customer in this situation gets no benefit from the research and development service unless they ultimately receive the boards, the research and development service is not considered a separate earnings process from the Customer's perspective and therefore does not qualify for unbundling. Therefore the $1,000,000 and the cost incurred for the research and development in X1 is deferred. The 156 PricewaterhouseCoopers LLP

$1,000,000 should be combined with the total minimum payments of $400,000 (400 x $1,000) to be received from the manufacturing effort and recognized at a rate of $3,500 ($1,400,000 divided by 400 units) per unit resulting in $1,050,000 ($3,500 x 300 units delivered) of revenue in X2 and $350,000 ($3,500 x 100 units delivered) of revenue in X3. 9.4 Accounting for installation services There are many issues surrounding installation services that may impact revenue recognition for both hardware and software vendors. As noted elsewhere in this chapter, a vendor must evaluate installation services to determine whether they can be accounted for separately. The software vendor must consider the guidance provided in SOP 97-2 when determining the appropriate accounting for an arrangement. In the case of hardware vendors, situations may arise in which the software would not be considered incidental to the hardware and thus, the guidance in SOP 97-2 and the software revenue recognition rules should be applied. In practice, installation often may occur simultaneous to the delivery of a product when an arrangement has payment terms that require that payment be made based on the delivery date. However, in many cases, installation might not occur simultaneous to the delivery of the product, and thus, for those cases that fall under the provisions of SOP 97-2, the practice of recognizing revenue upon the delivery of a product may need to be evaluated in light of the delivery criterion in SOP 97-2. Under SOP 97-2, installation is considered a service; therefore, the revenue-allocation provisions are applicable regardless of whether the installation is separately priced in the arrangement. In a multipleelement arrangement, installation services must be evaluated to determine whether VSOE of fair value exists and, thus, whether the vendor should account for the total fee based on the installation element. Because (1) the completion of the installation may require the participation of the vendor and (2) in practice, installation often takes place at a time other than when the product is delivered, installation services are permitted to be sold only when a product is also licensed; therefore, those services are never sold separately. Accordingly, the VSOE requirements of SOP 97-2 would not be met. See additional discussion on this matter in the examples below. When installation occurs after delivery and the vendor is able to establish VSOE for PCS, the question arose as to when the fee allocated to the PCS arrangement should begin to be recognized as revenue. This issue was addressed by the AICPA in TPA 5100.44. The deciding factor for the start date of the PCS was established to be when the customer is eligible to begin to receive any upgrades/enhancements released by the vendor during the delivery/installation period. For example, a vendor enters into an arrangement to deliver its software and provide PCS in a project that involves significant installation. The software will be deployed in stages while the PCS period per the agreement is stated to begin six months after the delivery of the software. If the vendor has a history of providing its customers with the services normally associated with PCS prior to the agreed upon start date, the PCS period would be deemed to commence upon initial delivery of the software. Questions and Answers Installation occurs simultaneous with delivery The Vendor sells computer equipment and software that provide machine vision in manufacturing processes. The products are sold to end users, and the Vendor generally installs the products upon their delivery at the Customer's site. Installation is routine and completed within one to two hours after the product has been delivered. Installation is not separately stated in the arrangement with the Customer, but is a condition to customer acceptance, for which there is no evidence that any uncertainty exists. www.pwcrevrec.com 157

Question: Is installation a service element to which the revenue-allocation provisions of SOP 97-2 must be applied? Answer: In many situations, the installation of a product may not be significant enough to be separately stated in arrangements with customers. This is generally the case when (1) the product is delivered and installed simultaneously and (2) the installation process (a) is the same for all deliveries of the same product and (b) is routine. As illustrated above, we believe that in these situations installation is not a separately offered service element of the transaction and, therefore, the revenue-allocation provisions of SOP 97-2 are not applicable. The total fee for the product should be recognized upon the delivery of the product, assuming that all of the other criteria for revenue recognition have been met. Installation does not occur simultaneous with delivery and VSOE does not exist The Vendor licenses a software product that enables customers to conduct videoconferences with other sites. Under the terms of the arrangement, the Vendor licenses the software, performs the installation, and provides an annual maintenance contract for $75,000. The Vendor delivers the product to the Customer and schedules an installation date at the Customer's convenience. Installation services are significant, vary from customer to customer (because of the complexities associated with phone lines and network infrastructures), and are never sold separately. Therefore, VSOE of fair value does not exist for the installation services. However, VSOE of the fair value of the software product and the PCS arrangement is $40,000 and $10,000, respectively. The Vendor has never had a customer not accept a product once it has been delivered. Question: Can the Vendor recognize the fees that are allocated to the software product when that product has been delivered, as there is no uncertainty about the acceptance of the product and VSOE of fair value exists for two of the three elements? Answer: It is not likely that the services described in the above example will involve significant production, modification, or customization of the software. Furthermore, the only undelivered element is the installation service. However, since VSOE of fair value does not exist for the installation services (i.e., the installation services are never sold separately ), the allocated fees associated with the software product and the installation services should be recognized as revenue as the installation services are performed or, if no pattern of performance is discernible, the fee should be recognized on a straight-line basis over the period during which the installation services are performed. Installation services for a fixed fee The Vendor sells Product A (a hardware product that includes firmware ) to the Customer for $2,000,000. The software in Product A has been deemed significant, and thus the Vendor applies the criteria of SOP 97-2 to determine revenue recognition. As part of the same arrangement, the Vendor also is to provide installation services for a fixed fee of $10,000. The Vendor has VSOE of the fair value for Product A ($2,000,000), as there have been many sales of Product A without installation services included. However, the Vendor never performs installation services without selling Product A; consequently, installation services are never sold separately. Installation is not essential to the functionality of Product A, and customer acceptance is not contingent on installation. 158 PricewaterhouseCoopers LLP

Question: Must the Vendor defer the recognition of all revenue on the sale of Product A and, instead, recognize the revenue over the installation period, because the installation services have never been sold separately? Answer: A literal reading of SOP 97-2 would lead to a conclusion that revenue could not be recognized on the delivery date of Product A; instead, revenue from Product A would be deferred and recognized ratably over the installation period. However, we believe that for situations in which the installation services are not essential to the functionality of the software and vendors have, in recent periods, charged customers an hourly rate or fixed fee for separately sold similar professional service for either software products or hardware products (when the software is not considered incidental) these rates may be used as a surrogate for VSOE. Regarding the above example, assume that the Vendor had previously separately sold similar professional services for $50 per hour and that the installations normally took 200 hours to complete. We believe that the Vendor could reasonably determine that the revenue is recognizable upon the delivery of Product A by comparing the value of fees ($10,000) as determined based on historical hourly rates for separately sold similar professional services ($50 per hour x 200 hours) to the new arrangement's fixed fee of $10,000. The Vendor would then recognize $2,000,000 of revenue upon the delivery of the product and $10,000 during the installation period. If a discount existed in this arrangement, the Vendor would allocate the discount to the two elements when allocating the fee, as VSOE of fair value would be considered to exist for all elements. If the Vendor did not have VSOE of fair value of the software, using the residual method the full, undiscounted VSOE of fair value of the services would be deferred and recognized as the services are performed with any residual arrangement fees being recognized upon delivery of the software. www.pwcrevrec.com 159

Chapter 10: Hosting Arrangements including Softwareas-a-Service (SaaS) 10.0 Overview New service delivery models are changing the way enterprises buy, manage and upgrade their information technology needs. These models, although similar, come in a variety of arrangements, including Application Service Providers ("ASPs"), Software-as-a-Service ("SaaS"), and Business Process Outsourcing ("BPO") and have emerged as opportunities for buyers of IT functionality. Generically, we'll refer to these models as hosting services. Under certain business arrangements, a software vendor will not actually deliver a software product to a customer for installation on the customer's in-house systems. Rather it will make the software available to the customer through a hosting arrangement. In this case, the vendor will install and run the software application on either its own or a third-party's servers, giving customers access to the application via the Internet or a dedicated line. Historically, ASPs have been an example of this sort of service offering. While many ASPs offered their own specific software solutions, others have acted as a service bureau providing customers access to third-party software. SaaS is a newer software delivery method that provides access to software which functions remotely as a Web-based service. SaaS allows organizations to access business functionality at a cost typically less than paying for licensed applications since SaaS pricing is often based on a usage fee per session, per transaction or per month. Many SaaS vendors offer access to software that is less customized, or more portable, than earlier ASP solutions. Finally, most often the ASP customer has license rights to software (even though they do not take possession of it), while in a SaaS arrangement the customer has no rights to take the intellectual property. BPO is a form of outsourcing which involves the contracting of the operations and responsibilities of a specific business function to a third-party service provider. BPO is often divided into two categories: back office outsourcing, which includes internal business functions such as billing or purchasing, and front office outsourcing, which includes customer-related services such as marketing or tech support. BPO that is contracted outside a company's own country is sometimes called offshore outsourcing. BPO that is contracted to a company's neighboring country is sometimes called nearshore outsourcing. Use of a BPO as opposed to an ASP usually means that a certain amount of risk is transferred to the company that is running the process elements on behalf of the outsourcer. A typical BPO arrangement includes the software, the process management, and the people to operate the service, while a typical ASP model includes only the provision of access to functionalities and features provided or 'served up' through the use of software, usually via web browser to the customer. These arrangements mean that the end user does not have to provide its own hardware system capacity to run the software or maintain the application on its servers. This enables them to reduce the level of inhouse IT resources required. Generally, these models also eliminate the large, up-front license fees that are common in a perpetual license model and allow the end user to pay for the value it receives over a longer period of time. From a vendor perspective, a growing number of software vendors are adopting value-based pricing models that focus on customer demand and value perception. More vendors are moving from the established practice of selling perpetual licenses for packaged software to newer approaches that include SaaS. In many cases, this eliminates up-front license fees and IT investment for the customer, allowing them to pay for their IT fulfillment over time. Economic and market factors contributing to this change 160 PricewaterhouseCoopers LLP

include constrained IT budgets and increased focus on return on investment for specific technologies. The transition to value-based pricing is also attributable to a number of technology developments that have changed the way in which software is designed and delivered. Generally, a SaaS arrangement consists of the following deliverables: the right to use the software rights to use upgrades or enhancements data back-up or recovery the hosting service; and other services, including professional services such as training and implementation Software delivered as a service - wherein the customer does not acquire a license to run on its own systems but, instead, is limited to accessing the software from the systems of a vendor under a hosting arrangement - is considered a service, not a product delivery. As discussed later in this chapter, software delivered as a service is accounted for under literature that is applicable to service providers, rather than SOP 97-2. Hosting arrangements may or may not include a license right to the software and the customer may or may not have an option to take delivery of the software either during or at the end of the hosting period. This chapter will discuss the following in regards to ASPs, SaaS, and BPO, collectively referred to as hosting arrangements: 10.1 Applicability of SOP 97-2 to hosting arrangements 10.1.1 Significant penalty 10.2 Revenue recognition guidance for hosting arrangements falling outside of SOP 97-2 10.2.1 Set-up services 10.3 Hosting arrangements and other considerations 10.3.1 Professional services 10.3.2 Specified enhancements and upgrades 10.3.3 Service level agreements 10.3.4 Contingent revenues 10.3.5 Inconsequential or perfunctory deliverables 10.4 Accounts receivable and bad debt considerations 10.5 Cost considerations 10.5.1 Cost associated with up-front services 10.5.2 Capitalization of development costs 10.5.3 Transition from a hosted to a license model and vice-versa 10.1 Applicability of SOP 97-2 to hosting arrangements The EITF was tasked with assessing the applicability of SOP 97-2 to hosting arrangements and considering how the vendor's hosting obligation would impact revenue recognition. This discussion resulted in the issuance of EITF 00-03, Application of AICPA Statement of Position 97-2 to Arrangements That Include the Right to Use Software Stored on Another Entity's Hardware. Under this Issue, the Task Force reached a consensus that a hosting arrangement is within the scope of SOP 97-2 if: the customer has the contractual right to take possession of the software at any time during the hosting period without significant penalty; and it is feasible for the customer to either run the software on its own hardware or contract with another party unrelated to the vendor to host the software without significant penalty. www.pwcrevrec.com 161

Accordingly, SOP 97-2 applies only to those hosting arrangements in which the transactions satisfy the aforementioned criteria. This would allow the vendor the ability to recognize that portion of the fee attributable to the license on delivery, while that portion of the fee related to the hosting element would be recognized as the service is provided, assuming all other revenue recognition criteria have been met. Arrangements which permit the customer to take possession of the software only under conditions that are outside the customer's control generally do not satisfy the first criterion above. Those arrangements that do not satisfy both criteria are service contracts and would be recorded following guidance appropriate to deliverables in the arrangement (i.e., EITF 00-21, SAB 104, SOP 81-1 or others). 10.1.1 Significant penalty There are two distinct concepts to the term "significant penalty" used in EITF 00-03. These are: that the user can take delivery of the software without incurring significant monetary cost; and that the end user would be able to use the software separately without a significant diminution in utility or value. The determination of what constitutes a significant penalty is based on facts and circumstances. Within existing literature, there is no definition of a significant penalty; hence such an evaluation requires significant judgment. A significant penalty would generally exist if significant direct and incremental costs are incurred in connection with cancelling the hosting arrangement or deploying the software on the customer's hardware or that of a third-party, or if there is a significant decrease in utility or value of the software as a result of the customer taking possession. Examples of direct and incremental costs include forfeited hosting fees, termination fees or penalties incurred to cancel the hosting arrangement, and unusually significant expenditures (e.g., capital or other costs) incurred to deploy the software on the customer's hardware or on that of a third-party. The mere existence of "costs" in connection with taking possession of the software would not, by itself, result in a significant penalty. These would include the typical costs associated with hardware requirements for an entity to host an application itself. Instead, direct and incremental costs should be evaluated to determine whether they are significant, which generally would be in comparison to the value of the overall arrangement. Indicators of a significant penalty include, but are not limited to, the following: It is cost prohibitive for the customer to purchase the required hardware to use the software or the cost to acquire the required hardware is significant when compared to the value of the overall arrangement; Specialized hardware is required to use the software and the hardware can not be purchased separately; There are no third parties that are able to provide hosting for the hardware required to use the software; Cancellation of the hosting arrangement would require forfeiture of the remaining hosting fee and the amount is significant in relation to the value of the overall arrangement; Cancellation of the hosting arrangement requires the customer to pay a termination fee to the vendor and the amount is significant in relation to the value of the overall arrangement; The customer's right to receive upgrades is terminated upon taking possession of the software and such upgrades are important; and There is a significant decrease in the customer's utility of the software if the software is not hosted by the vendor. Observation: It is good practice for a software vendor to establish, and consistently apply, an accounting policy to determine what constitutes a significant penalty. 162 PricewaterhouseCoopers LLP

If the vendor is unable to demonstrate that the end user can meet both of the criteria of EITF 00-3, it will not be able to utilize SOP 97-2 for purposes of revenue recognition for these hosting arrangements. In order to support its revenue recognition policy, the vendor may wish to obtain written representation from the end user that it is able to meet both of these conditions. If the vendor is able to demonstrate that the software element is within the scope of SOP 97-2, all of the SOP's requirements for recognizing revenue, including VSOE of fair value of the various elements in the contract and the requirement that the fee allocated to the software element not be subject to forfeiture, refund, or other concession, must be met in order to recognize revenue upon delivery for the portion of the fee allocated to the software element. For purposes of revenue recognition, in hosting arrangements where the customer has the option to take possession of the software but has chosen not to, delivery of the software is deemed to occur when the customer has the ability to take immediate possession of the software. Questions and Answers No significant penalty on delivery A Vendor enters into a contractual arrangement that grants a perpetual software license to an end user for an initial non-refundable payment of $100,000. Although the end user has the ability to take delivery of the software without incurring significant cost and could use it separately without impairing its utility or value, it initially chooses to have the Vendor host the software. No separate fee is charged for the hosting services for the first year and the agreement allows for the hosting arrangement to be renewed for a second year at a rate of $20,000. During the hosting period, the Vendor provides when-and-if available software updates and technical support. The $100,000 fee is considered to be fixed, there is a contract signed by both parties and collectability is considered reasonably assured. Question: How should the Vendor recognize revenue for this contract? Answer: The arrangement contains two elements - the perpetual license and the first year hosting service. Assuming the renewal rate on the hosting services is substantive (i.e., creates VSOE of fair value), we would allocate $20,000 of the initial $100,000 fee to the hosting services and the residual amount ($80,000) could be assigned to the perpetual license. Thus, the Vendor would be able to recognize $80,000 of license revenue at the time the Customer has the ability to take immediate possession of the software and would recognize the remaining $20,000 as hosting service revenue ratably over the twelve months (recognized on a daily basis) for which hosting services are provided. Significant penalty on delivery Consider the original fact set as presented in the example above; however, by installing and running the software on its own system, the end user loses certain of the software's functionality and the time to process a transaction increases significantly. Question: How should the Vendor now recognize revenue for this contract? Answer: It would appear that as a result of taking delivery of the software, the end user has seen a significant decrease in its utility. Consequently, we believe that most customers would view this as a significant penalty to taking delivery of the software. Therefore, the Vendor would not be subject to SOP 97-2 for purposes of revenue recognition and would need to consider alternative revenue recognition guidance discussed in Section 2 below. www.pwcrevrec.com 163

Termination of hosting arrangement Consider the original fact set as presented in the first example above; however, the end user terminates the hosting arrangement after nine months and installs the software on its own systems. Question: How would the answer change? Answer: The two elements would still be separated, with the $80,000 being recognized up-front and the $20,000 being recognized ratably. However, at the end of month nine, the Vendor would be able to recognize the unrecognized balance of $5,000, since there would be no further obligation for the Vendor to provide hosting services in the future and the fees are nonrefundable. Customer can access software under limited conditions A Vendor contracts with Customer A to provide a software application that will enable Customer A's clients to process information. As is the case with most of the Vendor's other normal hosting arrangements, the software application in this arrangement will reside on the Vendor's servers. The Vendor notes that while it may be feasible for Customer A to take possession of the software and run the software on its server, the contract stipulates that Customer A shall only have the right to take possession of the software in the following circumstances: an uncured material breach of contract by the Vendor; an involuntary or voluntary filing for bankruptcy by the Vendor; or assignment by the Vendor of the agreement to a competitor of Customer A. Question: Would the vendor be subject to SOP 97-2 for purposes of revenue recognition? Answer: In this fact pattern, Customer A is prohibited from taking possession of the software until the Vendor triggers one of the three criteria. Therefore, as the customer does not have the contractual right to take possession of the software at any time during the hosting period, SOP 97-2 should not be applied to this arrangement. Rather the entire arrangement (both the software and the hosting elements) would be accounted for as a service agreement under other GAAP as discussed in section 10.2. Bundled time-based license and hosting service A Vendor sells a web-based software application that allows a Customer to purchase goods from various suppliers through one point of online order entry. The Vendor offers a three year time-based license which allows the Customer to take possession of the web-based software application to run it on the Customer's own server for an up-front fee of $100,000. The arrangement includes one year of hosting and maintenance for no charge. The up-front fee is for modifying the software so that it will work on the Customers' server, and the modifications are done even if the Customer elects to have the application hosted by the Vendor. The customer must pay a $20,000 annual maintenance fee to renew the right to use the web-based software application in a hosted environment for years two and three. However, even if the Customer takes possession of the software, the Customer must pay the $20,000 annual maintenance fee in order to use the web-based software application longer than the first year. In addition, the Vendor does not sell the maintenance or hosting services separately and the same pricing structure is offered to all customers. 164 PricewaterhouseCoopers LLP

Question: How should revenue be recognized? Answer: As discussed earlier, contracts where a customer can take possession of the software without significant penalty and feasibly run the software on its own hardware or contract with another party unrelated to the vendor to host the software should be accounted for using SOP 97-2, which requires separation and allocation of the total arrangement consideration amongst the multiple elements based on VSOE of fair value. VSOE of fair value does not exist for the annual maintenance service as it is not sold on a standalone basis (i.e., there is no separate renewal rate for PCS). As noted in Chapter 3, a substantive renewal rate for PCS can be used to support VSOE, however, this is not applicable as the Customer must renew the maintenance service to retain the right to use the software. This payment constitutes both the renewal of the license and maintenance services and therefore does not represent the VSOE of fair value for the maintenance services on a standalone basis. By reference to TPA 5100.53, the upfront fee should be recognized ratably over the term of the agreement. The initial one year period and each subsequent renewal period represent a time-based license with coterminous PCS. Pursuant to paragraph 58 of SOP 97-2, since VSOE of fair value does not exist for the PCS and the only undelivered element is PCS, the entire arrangement should be recognized ratably over the contractual PCS term of one year. The up-front fee of $100,000 received in year one would represent a premium over any other year (that is, the years being renewed are at a discount). If the discount is deemed significant and incremental, the premium would be deferred and recognized over the expected discount period. Consideration was given to whether the contract contained a significant incremental discount, as discussed in TPA 5100.50. It was determined not to be a significant incremental discount as the same pricing structure is offered to all customers (i.e., the discount is not incremental to the range of discounts typically given in comparable transactions). Application of this model, in this fact pattern, results in the up-front fee being recognized ratably over the first year of the contractual term. The annual maintenance fee would be recognized over the related future annual service period, if renewed. 10.2 Revenue recognition guidance for hosting arrangements falling outside of SOP 97-2 If a hosting arrangement fails to meet the requirements of EITF 00-03 then the arrangement is not considered to have a software element and therefore is outside of the scope of SOP 97-2. Unlike software license arrangements, there has been no specific authoritative GAAP established for hosting arrangements that do not deliver or license software. The hosting arrangement, which would follow a services accounting model, would be accounted for in accordance with the guidance contained in SAB 104, after considering the separation and allocation guidance of EITF 00-21. Although non-public companies are not subject to the SAB through direct regulation, its rules provide an indication of best practice in the area of revenue recognition. SAB 104 requires the same four basic criteria for revenue recognition as SOP 97-2: Persuasive evidence of an arrangement exists; Delivery has occurred or services have been rendered; The vendor's price to the buyer is fixed or determinable; and Collectibility is reasonably assured. www.pwcrevrec.com 165

The simplest form of a hosted software agreement will typically have two distinct components to its revenue stream - an up-front payment to cover the set-up and an ongoing periodic charge to cover hosting. An up-front fee can take the form of either a payment for initial set-up services or a license fee received at the inception of an arrangement. It is also possible that additional services may be made available under the arrangement - for example training, consulting, enhancements, and support (PCS). Accounting for these more complex multiple-element agreements is discussed later in Section 10.3 of this chapter. 10.2.1 Set-up services For hosted arrangements outside the scope of SOP 97-2 with an up-front payment and charges for ongoing service, the vendor will first need to apply EITF 00-21 to determine whether it can account for these elements as separate units of accounting. EITF 00-21 requires the following conditions to be satisfied in order for a delivered element to be separated from undelivered elements for accounting: the delivered service has value to the customer on a standalone basis; there is objective and reliable evidence of fair value of the undelivered service(s); if the arrangement includes a general right of return relative to the delivered service, the performance of the undelivered service is considered probable and substantially in the control of the vendor. The standard of "objective and reliable evidence" refers to VSOE of fair value as prescribed by SOP 97-2 in all cases in which it is available. However, EITF 00-21 under its concept of verifiable objective evidence allows more latitude. Under EITF 00-21, third-party evidence of fair value (for example, prices of the vendor's or any competitor's largely interchangeable products or services in sales to similarly situated customers) is acceptable if VSOE of fair value is not available. If the above conditions are satisfied, the vendor should allocate the arrangement consideration to each of the elements based upon their respective relative fair values, or, using the residual method, if verifiable objective evidence exists for the undelivered units of accounting but not for the delivered units. With respect to the initial up-front fee (either license or set-up), the vendor would then need to follow the guidance in the interpretive response to SAB 104 relating to nonrefundable up-front fees. This states that unless the up-front fee is in exchange for products delivered or services performed that represent the culmination of a separate earnings process, the deferral of revenue is appropriate. Observation: As noted in SAB 104, the SEC Staff believes that the vendor activities associated with an up-front fee, even if considered to be a deliverable to be evaluated under EITF 00-21, will rarely provide value to the customer on a stand-alone basis. The deferred revenue would then be recognized ratably (on a daily basis) over the longer of the term of the arrangement or the expected period of the customer relationship. Although the Staff does not specifically define a "separate earnings process," it does provide some insights as to what normally would not be considered separate, as follows: The up-front payments are negotiated in conjunction with the pricing of the other elements; The customer would ascribe a lower value, or no value, to the up-front activity in the absence of the performance of the other elements in the arrangement; and The vendor often does not sell the initial right or activities separately. Since we believe that all of the above points generally would apply to a hosted software solution, a separate earnings process is not considered to have occurred, and therefore the arrangement fee typically should be deferred and recognized ratably. 166 PricewaterhouseCoopers LLP

An acceptable accounting method is found SAB 104, footnote 39, which states that the vendor should not assume that the life of the initial contract is the appropriate period for revenue recognition for an up-front fee. If the relationship with the customer is expected to extend beyond the initial term (anticipated renewals) and the customer continues to benefit from the payment of the up-front fee, the up-front fee should be recognized over a longer period. Early-stage companies, by definition, will have a limited operating history and, therefore, have limited data with respect to customer relationship periods. Such companies may have difficulty ascertaining the period over which to amortize the up-front fee. Even in those situations, the company should not default to recognizing the up-front fee over the initial contract term; rather the vendor should look to other data to determine the expected life of the customer relationship. Factors that could be considered in developing estimates of average customer relationship periods include the following: Historical data; Expected renewal rates; Expected period over which the customer could reasonably be expected to recover and earn a reasonable return on the up-front fee; Budgets; Marketing studies; Data used to set the pricing terms of the arrangement; Discussions with customers, either in the process of negotiating the arrangement or subsequent to negotiations; and Industry data, particularly if substitutes for the software are readily available in the marketplace. Under the guidance of SAB 104, the vendor may not be required to amortize an up-front fee over the customer relationship period if the initial contract period is substantive and the customer does not continue to benefit from payment of the up-front fees during future renewal periods. Indications that the initial contract period is not substantive would include: initial period is shorter than the period that customers generally renew the service; initial period is shorter than the renewal period stated in the contract; or renewal fees are significantly discounted, or fees related to other elements are so significant in relation to the overall arrangement, such that the customer is compelled to renew the hosting service, in light of the up-front cost of set-up and other professional services. If the vendor determines that the initial contractual hosting period is not substantive, an estimate of the renewal periods will be required. Revenue would then be recognized over the total of the initial period plus the estimated renewal periods. Questions and Answers Up-front fees - advance payment for future services A Customer enters into a license agreement with a Vendor for access to its software functionality for an up-front payment of $20,000. It is not possible for the Customer to take delivery of the software. The license has a term of five years and the Customer signs a one-year hosting agreement that's renewable for $6,000, which represents verifiable objective evidence of fair value of annual hosting. It would have been possible for the Customer to enter into a shorter-term license at a lower cost. Question: How much revenue should the Vendor recognize in the first year of the arrangement? www.pwcrevrec.com 167

Answer: Although the Customer has only entered into a one-year hosting contract, it has paid the Vendor for a five-year license. This would suggest that it has an intention of continuing to use the software after the expiration of the initial hosting agreement. Thus, the up-front fee should be recognized ratably over the estimated renewal periods. In this case, the license term of five years appears to be the best estimate of the hosting period. As such, license revenue of $4,000 ($20,000 5 years) and hosting revenue of $6,000 should be recognized in the first year. Observation: For a hosted arrangement recognized under SAB 104, revenue recognition should not commence until the customer has the ability to use the hosted application as intended, which generally would be at the point where the set-up activities are complete. Furthermore, the SEC staff has stated that in a licensing arrangement, delivery does not occur for revenue recognition purposes until the license period begins. Accordingly, if a hosted application has been made available to the customer (i.e. set-up is complete) but the contractual start date for the hosting application has not yet been reached, no revenue can be recognized until the hosted application's contractual start date. The underlying logic for this is that the customer does not have a legal right to use the application until that date. Similarly, but conversely, if the legal term of a hosted license arrangement has commenced but the set-up is not complete, revenue recognition should not commence until the application is available for use by the customer. Up-front fees - customer does not renew hosting arrangement Assume the original fact set as presented in the previous example; however, at the end of the first year, the Customer does not renew the hosting arrangement. Question: How should revenue be recognized at the end of year one? Answer: If the Vendor were able to represent that the Customer has no further intention to use the software and is not going to initiate a new hosting contract before the five-year license term has expired, then it would be able to recognize the balance of the deferred revenue at that point ($16,000). However, if there is any possibility that the Vendor may be required to provide access to the software again in the future, the amortization should continue on a ratable (daily) basis. Training solutions - ratable vs. non-ratable revenue recognition A Vendor that provides its training solutions via a SaaS model enters into a license with a Customer to make its software available for up to ten separate training sessions in a twelve month period. The Customer is required to pay an up-front configuration fee of $8,000 and a yearly hosting fee of $12,000. The Customer cannot take possession of the software, the training material will be out-of-date at the end of the one year term and there will be no benefit of the set-up work in future years. The customer has no right to a refund of fees if fewer than ten sessions are used. Question: How should revenue be recognized in this scenario? Answer: The appropriate recognition guidance is in SAB 104 and CON 5. The provision of the configuration service does not represent a separate earnings process and the associated fee does not represent an advance payment for training services beyond the initial 12 month period. Therefore, the up-front fee should be combined with the hosting fee and recognized over the initial contractual term of the hosting arrangement. The total revenue to be earned from the contract is $20,000. As the software will be used for only ten distinct training sessions, $2,000 of revenue should be recognized on the date of each 168 PricewaterhouseCoopers LLP

training session. Only at the end of the twelve-month period would the Vendor be able to recognize the balance of the deferred revenue for any unused training sessions, so long as there is no future obligation to the Customer which should be supported by a history of not providing the service after the contract's expiration. Observation: An acceptable alternative revenue recognition model would be proportional revenue recognition based on expected "breakage" (i.e. if the customer doesn't use all 10 training sessions in the twelve-month period, revenue could be recognized in proportion to the number of training classes that are expected to be used) as the Customer consumes training sessions, provided that the Vendor has sufficient history that validates the typical consumption of training by customers. It would not be appropriate to recognize breakage at inception of the arrangement (i.e. recognize revenue upfront associated with the training sessions that the Vendor estimates the Customer won't use). Another acceptable alternative model would be to recognize revenue ratably over the 12 months, recognizing that the effort (earnings process) for the Vendor is incurred evenly over the period to make the training software available for use. Such an approach would be preferable in situations where the Vendor cannot determine the pattern of usage. 10.3 Hosting arrangements and other considerations A hosted software arrangement may, in addition to the up-front fee and hosting, include other deliverables such as professional services (training, implementation and/or other consulting), ongoing support, and upgrades and enhancements. Where an arrangement includes a number of separate deliverables, the principles of EITF 00-21 continue to apply. As noted in section 10.2.1 above, the vendor will need to determine whether it can account for each element as a separate unit of accounting and then allocate the arrangement consideration to each of the elements based upon their respective relative fair values. If the vendor does not have objective evidence of fair value for the delivered element, but has objective evidence of fair value for all undelivered elements, it may apply the residual method to allocate fee to the delivered item if that delivered service has stand-alone value to the customer. In this section, we consider the following additional matters: Professional services Specified enhancements and upgrades Service level standards and refund clauses Contingent revenues Inconsequential or perfunctory deliverables 10.3.1 Professional services For the purpose of this discussion, we are referring to the common situation in which professional services that are performed at the outset of the arrangement (before the customer can use the hosted technology) or completed early in the hosting term. In considering the EITF 00-21 criteria noted in section 10.2.1 above, a vendor needs to evaluate whether the professional services have value on a stand-alone basis to the customer. Factors that would need to be considered include, but are not limited to, the following: the length of time between the access and use of the hosted service by the customer and the provision of the professional services; the separate sale of such services by the vendor, or another vendor (i.e. without hosted services); the uniqueness of the professional services (i.e. can another vendor provide the services); www.pwcrevrec.com 169

whether the professional services are a unique request by the customer (e.g. will this result in customer-specific functionalities that no other customer has); and the similarity between initial set-up services and the additional professional services (i.e. is the vendor providing services that are analogous to set-up services despite the length of time that has elapsed since the initial customer account provisioning). In practice, there are a number of potential revenue recognition scenarios which could arise when professional services are included in a hosting arrangement. Two outcomes which may be appropriate based on application of EITF 00-21 to the specific circumstances are described below: 1. In exchange for a non-refundable fee of $1,000, the Vendor is required to perform account set-up to enable the Customer's access to the hosting environment. The Vendor also charges a $9,000 non-refundable fee to perform professional services that last through the first month of a one-year hosting contract. Assume the professional services are commonly sold on a stand-alone basis and the Vendor has objective and reliable evidence of fair value for hosting services. Account setup services are never sold on a stand-alone basis. If stand-alone value is established and the other criteria of EITF 00-21 are satisfied to treat the professional services as a separate unit of accounting (verifiable objective evidence of fair value for the hosting service and non-substantive refund provisions), then fees allocable to the professional services should be recognized as they are performed. 2. Assume the same facts as in (1), but the Vendor does not have objective and reliable evidence of fair value for the professional services or the professional services do not have stand-alone value to the customer. If the Vendor concludes that the additional professional services do not represent a separate unit of accounting (e.g., the services are akin to initial set-up services prior to initial account provisioning) then, upon completion of the professional services, the Vendor should combine the professional services fee with the set-up fee and recognize the combined amount over the longer of the remaining contractual term or the customer relationship period. This is assuming the fair value of any undelivered element (e.g. periodic hosting services) is known at the time the professional services are complete. See our discussion of upfront set-up fees in section 10.2 above. Observation: Another potential scenario could include only two undelivered service elements, for example, professional services delivered over a short period of time in the early portion of the hosting term and hosting services delivered over the full term of the contract. Assuming the shorter service has standalone value to the customer and verifiable objective evidence of fair value exists for the longer service, one acceptable accounting model would have the vendor defer the fair value of the service element to be delivered over the longer period of time (which would be recognized as hosting is provided) while the residual of the arrangement consideration would be recognized over the shorter period of performance of the professional services. Importantly, application of this approach should result in any discount embedded in the arrangement being recognized over the shortest period of performance thus preventing front-loading of revenue. It is often the case that subsequent to the initial installation, a customer will negotiate for additional deliverables under a new arrangement, for example, additional enhancements or customizations, hosting of other related or unrelated products and consulting services. Such deliverables negotiated and committed to subsequent to the commencement of the initial service would be subject to the same separate earnings event criteria used in assessing when revenue should be recognized. Reference should be made to TPA 5100.39. If these additional deliverables are determined to not represent a separate earnings process, any revenue arising from the subsequent arrangement would be combined with the original arrangement's fees and recognized based on the guidance that is applicable to the combined arrangement; i.e., the newly negotiated services would be viewed as an amendment to the pre-existing arrangement. Refer to Chapter 3 in this monograph for guidance regarding combining contracts. 170 PricewaterhouseCoopers LLP

10.3.2 Specified enhancements and upgrades It is possible that a vendor may commit to delivering certain specified upgrades and enhancements to the hosted software. SAB 104 does not specifically provide guidance on accounting for such obligations. However, as the vendor has promised to provide specified upgrades, enhancements, or other deliverables in a manner that is deemed to represent a substantive commitment, we believe the obligation should be treated as a separate deliverable in a multiple-element arrangement. This treatment is further supported by the belief that a sale involving a specified upgrade or enhancement would not have been made (or the customer would have paid a lower price) absent such a provision. Generally, it will be difficult for a seller to unbundle a specified upgrade or enhancement, as the fair value of the upgrade or enhancement is typically difficult to establish. The threshold for establishing evidence of fair value in arrangements subject to EITF 00-21 is lower than the VSOE standard in SOP 97-2, as EITF 00-21 only requires verifiable objective evidence of fair value for use in unbundling a multiple-element arrangement. This means that prices charged by third parties or the vendor in sales of substantially interchangeable upgrades or enhancements may be used. Nonetheless, verifiable objective evidence frequently does not exist for upgrades and enhancements. Refer to Chapter 5 for further discussion around specified enhancements and upgrades. 10.3.3 Service level agreements Hosting vendors regularly enter into service level arrangements ("SLA") that guarantee availability of the hosted application (e.g., 99% uptime, etc.). SLAs generally include penalty clauses that allow a customer to receive a refund of part of the hosting fee if the vendor breaches any of the terms of the SLA. The critical accounting concern surrounding SLAs is whether they represent a warranty, or a contingent fee based on a specific refund right, considering the specific terms and circumstances of the arrangement. The nature of the SLA will affect the revenue recognition of the overall arrangement. The substance of an SLA might represent a penalty payment made by the customer to the vendor (e.g. a percentage of the prior month's hosting fee is refunded to the customer if contractually agreed upon uptime requirements are not met) or could be a refund of fees (e.g. a 30 day money back guarantee whereby the vendor will refund the entire up-front purchase price at the discretion of the customer). Some guidance to consider when evaluating SLAs includes but is not limited to: SAB 104, FAS 5, SOP 97-2, EITF 00-21, and EITF 01-9. The scope of FAS 48 explicitly excludes arrangements for delivering services; revenue usually should not be recognized in earnings based on an assessment of the probability that significant, but unfulfilled, terms of a contract will be fulfilled at some point in the future. The SEC staff acknowledged in SAB 104 that in limited circumstances, it could be appropriate to apply FAS 48 for a general refund right in a service arrangement. SAB 104 states that the SEC staff believe that the recognition of refundable fees, net of estimated refunds, as earned revenue over the agreement's term would be appropriate if all of the following criteria have been met: The estimates of terminations or cancellations and refunded revenues are being made for a large pool of homogeneous items (e.g., membership or other service transactions with the same characteristics such as terms, periods, class of customers, nature of service, etc.); Reliable estimates of the expected refunds can be made on a timely basis without experiencing material variances in the estimated number of refunds or their absolute effect to the financial statements. Deferring revenue based on the upper-end of a wide range of potential return rates is not appropriate; There is a sufficient company-specific historical basis upon which to estimate the refunds, and the company believes that such historical experience is predictive of future events; and The amount of the service fee specified in the agreement at the outset of the arrangement is fixed, other than the customer's right to request a refund. www.pwcrevrec.com 171

Generally the use of FAS 48 is appropriate in scenarios where these criteria are met and it is at the discretion of the customer to cancel service and obtain a refund of the purchase price paid. Typically, SLA features in a hosting arrangement will not qualify for this application of FAS 48, as the SLA relates to a specific, objective refund right and not a general cancellation right. Frequently, judgment is required to assess whether the payments a vendor incurs in connection with an SLA are akin to warranty costs, (in substance, a contingent loss recorded pursuant to FAS 5) or a specific refund right tied to vendor performance, which results in contingent fees that cannot be recognized until the contingency lapses. Factors to consider when evaluating SLA terms to determine the appropriate accounting model include, but are not limited to, the following: Is the SLA simply a standard warranty and subject to the guidance in FAS 5? Do SLA terms provide any incremental benefits beyond what the customer is already entitled to pursuant to the standard warranty? Are the SLA penalty clauses economically substantive? Does the company have a history of paying penalties on the specific or similar products? Are the SLA penalties in substance a refund of the sales price of the product? Has the guidance in EITF 01-9 been considered? Is the SLA a separate services arrangement in a multiple element arrangement under EITF 00-21? Is the SLA in essence PCS? It is important to fully understand the economics of the SLA. The accounting model or guidance applied will depend on the specific facts and circumstances. 10.3.4 Contingent revenues There are occasions where a vendor will enter into an arrangement to make software available to a customer for a stated period of time. The monthly fee that the vendor receives for providing these services is calculated as a fixed percentage of the value of the transactions that the customer processes using the software, or as a fixed fee per transaction. Thus, each month's fee is contingent upon the outcome of events occurring within that month, and such events are: not within the control of the vendor; and not directly tied to the vendor's provision of service. To recognize revenue as the contingency lapses in each period, the vendor should demonstrate that an earnings process was completed. Generally, the recognition of revenue should coincide with the transfer of value to the customer. The nature of the arrangements may vary, but the vendor should assess which of following two approaches is appropriate: 1. The interpretive response to SAB 104, Question 8 indicates that contingent revenue should be recorded in the period the contingency is resolved. Although this question specifically addressed contingent rent, the SEC staff has confirmed that this guidance could be extended to other similar contingent-income arrangements. For example, a vendor may agree to host an application that a bank will use to send and receive electronic funds transfers, in exchange for a fee collected on each transfer the application sends or receives. The customer derives value from each transaction the application has processed, as the transaction is completed, which is an important indicator that the fee has been earned. 2. Looking to the language in the interpretive responses to SAB 104 Questions 5 and 6 that requires the deferral of revenue over service periods, some have argued that because the service obligation and payment of fees span an extended period, each incremental fee is equivalent to an up-front payment that should be recognized over the entire contract period. For example, consider a year-long hosting arrangement in which the vendor agrees to host an application that 172 PricewaterhouseCoopers LLP

is used by a bank to send and receive electronic funds transfers. Each transfer takes precisely the same amount of time, computing capacity, and network bandwidth. However, the vendor will be paid a fraction of the dollar value which the bank transfers in each transaction. There may be insufficient correlation between the earnings process (i.e., completing a transfer) and the amount collected by the vendor in any month. In that case, only one-twelfth of the indicated annual fee that is calculated at the end of the first month would be recognized as revenue, with the remaining balance deferred and spread over the remainder of the year. 10.3.5 Inconsequential or perfunctory deliverables The SEC Staff has stated that in order to establish that delivery has occurred and recognize revenue in respect of a product or a service, a vendor should have substantially completed or fulfilled the terms specified in the arrangement. For an obligation to be considered substantially complete, only inconsequential or perfunctory actions may remain to be completed. Further, the vendor must have a demonstrated history of successfully completing the remaining tasks in a timely manner. In SAB 104, the SEC Staff provides further guidance for use in determining whether a remaining performance obligation can be deemed inconsequential or perfunctory. If the undelivered element is essential to the functionality of the delivered products or services or if failure to complete the activities would result in the customer receiving a right to a full or partial refund or to reject the products delivered or services performed to date, then it would not be possible to establish that the element was inconsequential, and accordingly, revenue would be deferred. If an arrangement does not specifically include such a right, but the vendor has a historical pattern of granting such rights, consideration should be given to the historical practice. In addition to the refund right, the following factors may indicate that a remaining performance obligation is substantive rather than inconsequential or perfunctory: The vendor does not have a demonstrated history of completing the remaining tasks in a timely manner and reliably estimating their costs. The cost or time to perform the remaining obligations for similar contracts historically has varied significantly from one instance to another. The skills or equipment required to complete the remaining activity are specialized or are not readily available in the marketplace. The cost of completing the obligation, or the fair value of that obligation, is more than insignificant in relation to such items as the contract fee, gross profit, and operating income. The period before the remaining obligation will be extinguished is lengthy. Vendors should consider whether reasonably possible variations in the period to complete performance affect the certainty that the remaining obligations will be completed successfully and on budget. The timing of payment of a portion of the sales price is coincident with completing performance of the remaining activity. If an outstanding deliverable is not deemed perfunctory or inconsequential, it should be evaluated using the criteria in section 10.2.1 to determine whether it represents a separate unit of account. Questions and Answers Bundled hardware and hosting services A Vendor enters into an arrangement with the Customer whereby the Vendor will provide the Customer access to its software via a hosting service, set up the customer profile and sell the necessary hardware to the Customer to interface with the hosted software. The Customer has no option to take possession of the software. The Vendor receives a set-up fee, purchase consideration for the hardware and a recurring www.pwcrevrec.com 173

monthly service fee, for which the Vendor has established fair value. The hardware is sourced from various manufacturers and is not specific to the Vendor. The Customer could provide previously purchased hardware or could use the newly acquired hardware for other data processing operations. The Vendor concludes that none of the deliverables in this arrangement are in the scope of SOP 97-2. Question: Does the sale of the hardware product qualify as a separate unit of account in the transaction? Answer: Yes. Due to the fact that the hardware product could be sourced independently from a third-party vendor and could also be used for services provided by another vendor, the hardware appears to have standalone value to the Customer and objective evidence of fair value presumably exists for the recurring service. This would permit the Vendor to recognize the fee allocated to the hardware upon delivery, assuming all other revenue recognition criteria are met. Set-up activities not perfunctory A Vendor enters into an agreement with the Customer whereby the Vendor will host its proprietary application at its existing data center for a period of five years. The application requires an initial set-up effort, consisting of creating certain routine interfaces, configuring the Vendor's application to suit Customer characteristics and establishing the necessary access processes. The initial set-up services are unique to the Vendor and could not be performed by other service providers. Thereafter, the application will be automated without significant interaction by the Vendor. The agreement comprises a set-up fee of $350,000 for the initial set-up services and a monthly service fee of $11,000. The monthly service fee is supportable as fair value as the Vendor sells its services at similar rates upon renewals. Question: How should the Vendor account for this transaction? Answer: Provided all other revenue recognition criteria are met, service revenue should be recognized on a straight-line basis, unless evidence suggests that the revenue is earned or obligations are fulfilled in a different pattern. Recognition of the ongoing application services on a straight-line basis should span the contractual term of the arrangement, beginning upon completion of the set-up when the Customer can use the service as intended. In this transaction, the Customer contracted for the ongoing hosting service, not for the set-up activities. We believe that the set-up activities do not represent an insignificant or perfunctory process because the Customer cannot use the hosting service without the Vendor delivering the set-up services and because the fees associated with completing the obligation is more than insignificant in relation to the overall arrangement fee. Observation: The set-up fees are 35% of the total committed fees. Accordingly, the set-up fees should be recognized over the longer of the contractual term or the expected customer relationship period (note that in this case, given the five year commitment for the monthly service, the expected customer relationship may be the same).in addition, it would not be appropriate to recognize revenue in proportion to the costs incurred because the set-up costs incurred bear no direct relationship to the pattern in which value is provided to the customer. Training services not perfunctory Consider the fact set as set out in the previous example above; however, the Vendor is also obligated to provide the Customer with training in use of the application over a period of several days for an additional fee. 174 PricewaterhouseCoopers LLP

Question: Could this training service be deemed perfunctory or inconsequential and, therefore, not considered an element of the arrangement? Answer: Generally, no. In order for an obligation to be considered perfunctory or inconsequential, the failure to perform such an obligation could not result in the Customer's receiving even a partial refund of the agreed-upon price. As a result, we believe it is unlikely that any obligation that is specified in an agreement, such as an installation or training obligation, would be considered perfunctory or inconsequential. The Vendor may wish to obtain a legal opinion before concluding that the Customer would have no claim for any refund, specific performance, or other concession in the event that such obligations were not fulfilled. If a deliverable is not deemed perfunctory or inconsequential, it should be evaluated to determine whether it is a separate unit of account in the multiple-element arrangement. 10.4 Accounts receivable and bad debt considerations Vendors that recognize revenue in accordance with SOP 97-2 typically recognize software license fees at the time of delivery, given that they have evidence of an arrangement, fixed or determinable fees and collection is reasonably assured at the time the sale is made. If in a reporting period subsequent to when the revenue was recognized, it is determined that the receivable is not collectible (for example, a customer with a good credit report at the time of the sale suffers an unforeseen catastrophic loss), the related receivable would be reserved or written off to bad debt expense. Revenue recognition in the prior period is not revisited or restated for events that could not have been foreseen at the time the original judgments were made. When revenue is recognized ratably, either under SOP 97-2 or SAB 104, the vendor needs to regularly assess its ability to collect the related receivables and if it is determined that collection is no longer probable, ratable revenue recognition should cease at that time. Revenue would then only be recognized as the payments are considered collectible (which may in fact be when the cash is received). There would be no need to establish an allowance for doubtful accounts in excess of the revenue recognized up to that point less any cash received, as any remaining receivable would be offset by the amount of remaining deferred revenue. Questions and Answers Ratable recognition and bad debt situations Two vendors each make a $365,000 sale to their respective customers on March 26, X1. Vendor A sells a software license in accordance with SOP 97-2. Vendor B enters into an arrangement with its customer to host the software (assume set-up takes only one day), for which the customer cannot take delivery of the software without significant penalty, for a period of one year. Vendor B bills its customers at the end of each month. Each Vendor did a credit check on their respective customer and established that collection of the related receivable was reasonably assured on March 26, X1. Vendor A and B have no other customers and report revenue on April 15th for the quarter end March 31, X1 of $365,000 (product revenue) and $5,000 (service revenue), respectively, and both Vendors filed their 10-Qs with the SEC on that date. On April 20th Vendor A's customer unexpectedly loses its factory and it is determined that it is now unlikely that they will be able to make any payment related to their $365,000 receivable. Vendor A's customer supplied Vendor B's customer with a crucial component of its product and therefore Vendor B determines that it is also unlikely to be able to collect its $365,000 fee. www.pwcrevrec.com 175

Question: Was it an error for Vendor A or B to recognize revenue in Q1? How much revenue should Vendor A and B report during Q2 related to their respective customers? What entry should each vendor make to record the doubtful receivables on April 20, X1? Answer: Neither Vendor A or B should restate their Q1 earnings as both properly determined that the collection of the related receivable was reasonably assured at the date of sale. As Vendor A properly recorded the entire revenue of $365,000 during Q1, no revenue would be recorded or reversed during Q2. However, Vendor A would record an allowance for the doubtful account in the amount of $365,000 and a corresponding entry of $365,000 to bad debt expense in the income statement. Therefore Vendor A would show a profit of $365,000 in Q1 and a loss of $365,000 in Q2 (ignoring all other expense items and taxes). Vendor B provided services for 19 days in Q2 prior to establishing that collection of the related receivable was doubtful, however, as Vendor B bills its customers at the end of the month, no revenue would be reported in Q2 for these 19 days. Therefore, Vendor B would cease revenue recognition and record an allowance for the doubtful account in the amount of $5,000 and a corresponding entry of $5,000 to bad debt expense on the profit and loss statement. No additional reserve is needed for the remaining receivable of $360,000 as it has not been recognized on the profit and loss statement. If Vendor B decides to write off the related receivable, Vendor B would accomplish this by also writing-off the related deferred revenue. Therefore, Vendor B would show a profit of $5,000 in Q1 and a loss of $5,000 in Q2 (ignoring all other expense items and taxes). 10.5 Cost considerations 10.5.1 Cost associated with up-front services There is limited authoritative guidance on the treatment of costs associated with revenue generating transactions. Vendors often incur costs to acquire a customer or to set-up a customer to use their software product or service before recognition of revenue begins. When revenue is deferred as a result of not meeting all the recognition criteria, companies often assert that they should be allowed to defer the related costs due to the matching principle. The matching principle should not be relied upon solely to justify cost deferral as this could question the quality of the asset and the quality of earnings. It is clear that the revenue recognition and cost recognition models do not always align and they often result in very different recognition patterns. Certain types of costs incurred prior to revenue recognition may be capitalized if they meet the definition of an asset under the principles provided by CON 6. Pursuant to CON 6, par. 25, assets are "probable future economic benefits obtained or controlled by a particular entity as a result of past transactions or events." CON 6 continues on to state that "An asset has three essential characteristics: (a) it embodies a probable future benefit that involves a capacity, singly or in combination with other assets, to contribute directly or indirectly to future net cash inflows, (b) a particular entity can obtain the benefit and control others' access to it, and (c) the transaction or other event giving rise to the entity's right to or control of the benefit has already occurred." 176 PricewaterhouseCoopers LLP

Customer set-up costs related to revenue generating transactions are not included within the scope of any authoritative literature, however, the SEC Staff believes that the capitalization of certain contract acquisition and origination costs may be appropriate. More detailed guidance is provided in SAB 104. It should be noted that the customer set-up costs referred to above are different from the start-up costs as covered by EITF 98-5, Reporting on the Costs of Start-Up Activities. Although the SEC Staff does not provide a definition of the types of costs that could be capitalized under this guidance, it states that "although the facts of a particular situation should be analyzed closely to capture those costs that are truly direct and incremental, the Staff generally would not object to an accounting policy that results in the capitalization of costs in accordance with paragraph 6(a) and (b) of SFAS No. 91, Accounting for Nonrefundable Fees and Costs Associated with Originating or Acquiring Loans and Initial Direct Costs of Leases or FTB 90-1, Accounting for Separately Priced Extended Warranty and Product Maintenance Contracts." Public registrants should disclose their policies for determining which costs to capitalize as contract acquisition and origination costs. Although this guidance does not specifically address the sort of installation costs that would be incurred by a hosting vendor, it does provide guidelines for the application of the concept of incremental costs to specific situations. Depending on which analogy a company uses for its deferral policy, direct and incremental sales commissions (related only to the revenues being deferred) may also qualify for deferral and amortization. By analogy to FAS No. 91, the costs that a software vendor would be able to capitalize would be the costs incurred to generate the initial sale to a customer which: result directly from and are essential to that sale; and would not have been incurred by the vendor had that sale transaction not occurred. Under FTB 90-1, only those costs that are directly related to the acquisition of a contract and that would have not been incurred but for the acquisition of that contract (incremental direct costs) should be deferred. All other costs, such as costs of services performed under the contract, general and administrative expenses, advertising expenses, and costs associated with the negotiation of a contract that is not consummated, should be charged to expense as incurred. Whichever basis (FAS No. 91 or FTB 90-1) a vendor chooses to adopt to quantify the costs to capitalize, it must ensure that it does not capitalize costs in excess of the revenues that are reasonably assured - to do so would create an asset on the balance sheet that would not be recoverable from a third party. Any incremental contract acquisition costs and set-up costs which have been capitalized should be amortized using the same time period and same method (i.e., straight-line, etc.) as is being used to recognize the related revenue. The costs should be recognized in accordance with the nature of the benefit provided (e.g. cost of sales, sales and marketing or general and administrative). Any deferred costs should be periodically assessed for impairment. 10.5.2 Capitalization of development costs Once it is determined what revenue recognition guidance applies to a transaction, the next hurdle is to determine what literature applies to any software development costs to be capitalized, FAS 86 or SOP 98-1. When discussing the issues in EITF Issue No. 00-03, the Task Force observed that if the vendor sells, leases, or licenses software that is within the scope of SOP 97-2, then the development costs of such software should be accounted for in accordance with FAS 86. www.pwcrevrec.com 177

Conversely, if the vendor never sells, leases or licenses the software and therefore its arrangements are not within the scope of SOP 97-2, then the software is being utilized to provide services and the development costs of the software should be accounted for in accordance with SOP 98-1. However, if during such software's development or modification, the vendor develops a substantive plan to sell, lease or otherwise market the software externally, the development costs of the software should be accounted for in accordance with FAS 86. Observation: There may be cases where the software development occurs prior to all the contract terms being developed. Accordingly, EITF 00-03 will force companies to make an assessment of its plan to market the software prior to completion of the software. Development that relates to software where a "substantive plan to market" exists should be capitalized in accordance with FAS 86. This "substantive plan to market" will need to be evaluated as to whether the arrangements will be within the scope of SOP 97-2 based on the criteria outlined in EITF 00-03. Where the plan is to transfer a software license to the buyer, FAS 86 applies. Where the plan is to market the software through only service transactions, SOP 98-1 applies. If the vendor's plan includes both licensing software and entering into service arrangements, FAS 86 applies. Since the method of determining when expense capitalization begins under the two models (FAS 86 or SOP 98-1) is different, the revenue recognition rules being followed will influence the amount of capitalized software development costs being carried on the balance sheet. A company following SOP 98-1 will generally commence capitalizing development costs at an earlier stage of the product's development cycle and, hence, have a higher resultant amount to capitalize and ultimately amortize. 10.5.3 Transition from a hosted to a license model and vice-versa Under SOP 98-1, if, after the development of internal-use software is completed, a vendor decides to market the software, proceeds received from the license of the computer software, net of direct incremental costs of marketing, such as commissions, software reproduction costs, warranty and service obligations and installation costs, should be applied against the carrying amount of the capitalized software development costs. No revenue should be recognized until aggregate net proceeds from licenses and amortization have reduced the carrying amount of the internal use software on the balance sheet to zero. Subsequent proceeds should be recognized in revenue as earned. This is similar to the treatment of certain funded software development arrangements as discussed in Chapter 8. If, during the development of internal-use software, a vendor decides to market the software to others, the entity should follow FAS 86. Amounts previously capitalized under SOP 98-1 should be evaluated at each balance sheet date in accordance with paragraph 10 of FAS 86. Capitalized software development costs should be amortized in accordance with paragraph 8 of FAS 86. A pattern of deciding to market internal-use software during its development creates a rebuttable presumption that any software developed by that vendor is intended for sale, lease, or other marketing, and thus is subject to the guidance in FAS 86 from the commencement of development. If a vendor historically has sold, leased or licensed its software and it decides to transition to a hosted model where revenue is recognized under SAB 104, the vendor should evaluate whether additional development costs incurred are in the scope of FAS 86 or SOP 98-1. Questions and Answers No intention to market development application for external use 178 PricewaterhouseCoopers LLP

A Vendor is developing a new product for future release. This product is to be made available as a hosted solution with no intention that it would be deliverable to third parties. The Vendor does not have a history of subsequently marketing hosted applications for external license. Question: How should the costs incurred in developing the application be accounted for? Answer: As there is no intention that the software being developed would be sold, leased or licensed in an arrangement within the scope of SOP 97-2 (i.e., no delivery will occur), the accounting would follow the guidance within SOP 98-1. Thus, all costs incurred in the "application development phase" should be capitalized. History of marketing development applications for external use Assume the fact set as presented in the example above; however, the Vendor has a history of subsequently making its hosted software solutions available for delivery. Question: How should the costs incurred in developing the application be accounted for? Answer: In this case, there is the presumption that the software will ultimately be made available for sale, lease or other marketing. Consequently, the Vendor should utilize the accounting principles of FAS 86 to account for the development costs unless it is able to provide evidence to rebut that presumption. Change in use of development application Assume the fact set as presented in the first example above; however, the Vendor has completed development of the product and capitalized $500,000 of software development costs under SOP 98-1, which will be amortized at a rate of $125,000 per year during each of the next four years. On June 30, X1, management decided that the software would be licensed for external sale. At that date, the software is available for third-party use as a hosted solution. On June 30, X2, the Vendor receives cash of $400,000 from the sale of a software license. Question: How would this impact the accounting for revenue and development costs? Answer: Subsequent to June 30, X1, future development costs should be accounted for in accordance with FAS 86 following the Vendor's decision to make the software available for third-party delivery. For the year ended June 30, X1, amortization of $125,000 should be charged against the capitalized software development costs, leaving a net book value of $375,000 on the Vendor's balance sheet. The cash received from third-party sales would first need to be applied against the carrying amount of the related capitalized software development costs - therefore, $375,000 of the X2 revenue would be netted against the carrying value of the capitalized development costs remaining on the balance sheet with the remaining $25,000 being recognized as revenue. Observation: Amortization of any costs capitalized according to FAS 86 would be amortized based on the pattern of expected benefit, which in most cases would not be a straight-line pattern. www.pwcrevrec.com 179

Chapter 11: Tax Considerations 11.0 Overview Tax considerations can add another level of complexity for software companies, especially for those doing business both across the United States and internationally. As tax rules and regulations continue to change and evolve across the various jurisdictions (e.g., federal, state and international), appropriate tax experts should be consulted as necessary. The complexities of GAAP software revenue recognition are further compounded by an overlay of the tax rules. It is important to understand a few general tax principles before delving into the specific tax rules related to software revenue recognition. First, the form of the software contract will generally be controlling - both as to its allocation of value amongst elements (if any) and to the substantive terms and conditions. In the event that GAAP has modified or discounted the contractual allocation of value and reallocated amounts - it will usually be necessary for tax purposes to reconstruct the revenues pursuant to the contract. This often results in no deferral or different deferral for income tax purposes. Second, the timing and character of revenue recognition for tax purposes again will be tied to a determination of whether the value has been received specifically for goods or for services. The fact that GAAP may have mandated the coupling of certain or all elements will not be controlling- again the terms and conditions of the contract will generally control and a remeasurement for tax purposes is probably required. For instance, a common issue is that of maintenance - if it has been bundled within the primary license - it is often, nonetheless, unbundled for GAAP purposes. The tax rules do not necessarily follow that treatment as discussed further in this chapter. Third, normally the taxpayer is precluded from asserting a tax position that is arrived at by concluding the substance of a transaction over its form. It is not impossible, but it certainly requires a complete understanding of the risks of following such a course. For example, there are areas of the tax rules that follow substance over form as discussed in the international section of this chapter. Ultimately, success of such an approach is based on the unique facts and circumstances of the transaction and the taxpayer. Observation: Note that later in the international section of this chapter we discuss the regulations under Section 861, which provides guidance for determining the income from software transactions. Although the regulations by terms don't apply to the federal tax area and are specifically limited in their application to certain international rules, we can look to them as an overall set of principles. Software revenue recognition is one of the most difficult and unsettled areas and this provides some look into how the IRS may view the characterization of software transactions. This chapter will provide an overview of the following tax considerations: 1.1 Federal income tax matters 11.1.1 Software revenue recognition for tax purposes 11.1.2 Deferral of revenue 11.1.3 Sale of goods 11.1.4 Sale of services (including PCS) 11.1.5 Other considerations 11.1.6 Common differences in revenue recognition between tax and financial reporting 11.1.7 Changes in accounting method rules 11.2 State income tax matters 11.2.1 Income tax considerations 11.2.1 Nexus 11.2.1 Apportionment 180 PricewaterhouseCoopers LLP

11.3 Sales and use tax considerations for software 11.3.1 Nexus 11.3.2 Prewritten computer program 11.3.3 Custom computer program 11.3.4 Custom modifications 11.3.5 Customized computer program 11.3.6 Software maintenance agreements 11.3.7 Consulting services 11.3.8 Software training services 11.3.9 Hosting arrangements, including Software-as-a-Service 11.4 International tax matters 11.4.1 Cross-border software transactions: characterization and source 11.4.2 Characterization of software transactions 11.4.3 Transfer of a copyright right 11.4.4 Transfer of a copyrighted article 11.4.5 Provision of services 11.4.6 Provision of know-how 11.4.7 Transfer of a copyright right: sale vs. license 11.4.8 Transfer of a copyrighted article: sale vs. lease 11.4.9 Forms and labels 11.4.10 Means of transfer 11.4.11 Hybrid transactions 11.4.12 General sourcing rules 11.4.13 Copyright rights 11.4.14 Copyrighted articles 11.4.15 Services and know-how 11.4.16 Withholding taxes 11.4.17 Extraterritorial income 11.4.18 Domestic manufacturing deduction 11.4.19 Income from foreign corporations 11.1 Federal income tax matters 11.1.1 Software revenue recognition for tax purposes The rules for software revenue recognition for tax purposes are very different from those under GAAP. As a general rule, revenue is recognized when two tests are met: (1) all events have occurred to fix the right to the revenue and (2) the amount of the revenue can be determined with reasonable accuracy. The first of these tests, sometimes referred to as the "all events test", is met at the earlier of the following three events; (1) payment is earned through performance, (2) payment is due to the taxpayer, or (3) payment is received by the taxpayer. In the case of the sale of goods, income is "earned through performance" generally at the time of shipment, delivery or acceptance, or when title passes, depending on the terms of the contract. In the case of services, income is "earned through performance" as services are provided. As indicated above, if payment is received earlier, income is includible at that time; however, as will be discussed below, there are specific exceptions to the rule that income is includible when cash is received. Based on the above discussion, revenue recognition for tax purposes sometimes occurs prior to revenue recognition under SOP 97-2; thus income may be accelerated for tax purposes. 11.1.2 Deferral of revenue As discussed above, a taxpayer would generally recognize income upon receipt of an advance payment. There are two significant exceptions to this general rule. First, advance payments for goods may generally be deferred until the earlier of (1) the time when, for tax purposes, income has been earned through performance, or (2) the time that the revenue is recognized under GAAP. Second, under a www.pwcrevrec.com 181

revenue procedure issued in 2004, a broad range of advance payments (including advance payments for services, for the sale of goods, for the use of intellectual property, and for the sale, lease, or license of computer software) are includible at the earlier of when includible under GAAP or in the tax year following receipt. Under SOP 97-2, different revenue recognition rules exist for shrink-wrapped or off-the-shelf software, which is classified as a good, and for software that requires significant modification or customization, which is usually classified as a service. Likewise, for income tax purposes, revenue from the sale of goods is subject to different deferral rules than service revenue. These deferral rules are discussed in detail in the following sections. Note that for all of the advance payment rules discussed below, the term "advance payment" includes both amounts received and amounts due and payable. 11.1.3 Sale of goods Pursuant to Treasury Regulation 1.451-5, advance payments for the sale of goods may be deferred and recognized as revenue at the same time for tax purposes as they are for financial reporting purposes, subject to the following limitations. First, deferral cannot be for a period longer than the time at which revenue has been earned through performance for tax purposes. For example, if a taxpayer treats revenue as earned for tax purposes at the time of shipment, but under GAAP revenue recognition is at a later time, deferral for tax purposes ends at shipment. Second, Treasury Regulation 1.451-5(c) provides a two year limit on deferral in certain circumstances. This regulation applies when the taxpayer has received substantial advance payments (defined further below) and, at the end of the year in which the advance payment is received, has goods on hand of similar kind and in sufficient quantity to satisfy the agreement pursuant to which it received the advance payment. This regulation provides that advance payments for the sale of inventoriable goods may be deferred until the end of the second taxable period beyond the period in which the taxpayer receives substantial advance payments (but no later than is recognized for financial reporting purposes). Observation: For example, assume a taxpayer receives substantial advance payments in year one for an item to be delivered in year four. If the taxpayer recognizes any amounts as income for financial reporting purposes before year three, those amounts must be recognized as income for tax purposes in the same tax year as they were recognized for financial reporting purposes. Any portion of the advance payment not yet recognized as income must be recognized in year three. For purposes of the two-year limitation on deferral discussed above, a taxpayer receives substantial advance payments when the total of advance payments received equals or exceeds the total expected costs and expenditures associated with the contract. Thus if total installment payments received (such as progress payments) equal or exceed the expected cost of the goods associated with the contract in the second year of the contract, substantial advance payments have been received and must be recognized within the following two tax years (by the fourth year of the contract). If additional advance payments are received in the third year of the contract, such payments must also be recognized no later than the fourth year of the contract (i.e., within two tax years of when substantial advance payments have been received). Any payments received after the third year of the contract may not be deferred. If the taxpayer is subject to the rule requiring that advance payments be recognized by, at the latest, the second taxable year after the taxable year in which substantial advance payments are received, the associated costs of goods sold relating to advance payments required to be taxed in that taxable year are recovered in that taxable year. This can have added relevancy to software companies, as most off-the-shelf software has very little cost and accordingly advance payments can quickly equal or exceed the total expected costs associated with the transaction. The deferral rules for advance payments for goods provide that advance payments for services integral to the sale of goods are deferred as if the advance payments were for the goods themselves. This rule only pertains to the sale of complete software programs that are sold in the ordinary course of the taxpayer's 182 PricewaterhouseCoopers LLP

business. Services integral to the sale of goods may include installation and integration of the software, as long as these services relate to software that is sold by the taxpayer. If ancillary services sold are not integral to the sale of goods, but account for less than five percent of the value of the entire contract, revenue from these services may also be deferred. If the contract includes services that are neither integral to the sale of goods nor less than five percent of the value of the entire contract, the advance payment must be segregated. The portion of the advance payment related to the sale of goods will be deferred under Regulation 1.451-5 and the portion related to service revenue will be subject to the service revenue rules discussed below. The relative values for the goods and services will often be known because in order to establish vendor specific objective evidence of fair value, goods and services are frequently priced independently and are separately available for sale. In Technical Advice Memorandum 9231002 ("TAM 9231002"), the IRS applied Regulation 1.451-5 to software maintenance agreements for off-the-shelf software. The taxpayer entered into nontransferable, nonexclusive license agreements to use its software for a perpetual term, while maintaining all intellectual property rights. The taxpayer also offered extended maintenance agreements to its customers, which granted them the same licensing rights to all future updates, cyclical releases, and rewrites of the software for the duration of the agreement. Such maintenance agreements could be extended year after year. Finally, customers paid for the maintenance agreement at the time they entered into the contract. The IRS first found that shrink-wrapped or off-the-shelf software is a good for tax purposes. Second, it found that revenue from the license agreements should be treated as revenue from the sale of goods as defined in Regulation 1.451-5. The rationale was that whether the payments were classified as royalties, licenses, or subscriptions, such payments were for the right to use a specific product ordinarily distributed in the course of the taxpayer's business. Third, the IRS applied the same reasoning to the extended maintenance agreements, and found the payments received for future updates, etc. were advance payments for the future sale of goods. Finally, the IRS stated that off-the-shelf software and the updates, cyclical releases, and rewrites associated with related maintenance agreements are inventoriable goods, and as such, advance payments for such software and maintenance agreements are subject to the deferral rules of Regulation 1.451-5 and the inventoriable goods exception in 1.451-5(c). Some believe the IRS misapplied the inventoriable goods exception in this ruling. While advance payments can be received for maintenance agreements it is unlikely that software companies will have these goods on hand by the end of the tax year in which the advance payment is received, failing to meet the exception under 1.451-5(c) and falling under the normal deferral rules of 1.451-5 (i.e., not subject to the two year limitation on deferral). TAM 9231002 applied only to maintenance agreements related to off-the-shelf software. Further, the maintenance agreement only included future updates, cyclical releases, and rewrites of the software, and did not include customized software solutions. 11.1.4 Sale of services (including PCS) Revenue Procedure 2004-34 allows the deferral of advance payments received for the performance of services. Although such revenue is generally recognized over the service period as the services are performed for financial reporting purposes, Revenue Procedure 2004-34 allows the taxpayer to defer the recognition of some or all of the revenue received for services into the taxable year following the taxable year in which the payment is received. Specifically, the advance payments must be reported in income in the year of receipt to the extent reported in income in that year under GAAP, and any remaining amount must be reported in the following year, regardless of whether the services are performed after the tax year in which revenue is recognized. Revenue Procedure 2004-34 applies to more than advance payments for services. It also applies to advance payments for goods, for the use of intangible property, and for the sale, lease, or license of software. For financial reporting purposes, unspecified enhancements/upgrades are considered Post Contract Customer Support, or PCS. These arrangements are subscriptions, which are recognized pro rata over the course of the contract for financial reporting purposes. For tax purposes, subscriptions fall under the www.pwcrevrec.com 183

same service rules discussed above; if any portion of the service revenue will be earned more than one taxable year after the end of the taxable year of the transaction, the remaining amount of subscription revenue must be recognized in the year after the advance payment is received. Contracts for unspecified upgrades and new releases must be kept distinct from contracts for cyclical updates and specified upgrades because they fall outside the scope of maintenance agreements that qualify as goods under Regulation 1.451-5. If the taxpayer sells renewable one-year subscriptions, the revenue from such transactions typically may be recognized consistent with that for financial reporting purposes (i.e., ratably over one year). Observation: Note the difference for tax purposes between a PCS subscription and a maintenance agreement as discussed above. The maintenance contract is treated as the recurring sale of goods, and as such, may be deferred for up to two (or arguably more) taxable years after the date of the transaction. A PCS subscription, on the other hand, may only be deferred until the following taxable period. The determining factor is whether the customer bargained for specific software upgrades, or whether the contract does not identify what will be provided. If the taxpayer purchases software and part of the package includes such a subscription, the value of the subscription must be separately identified. The above tax rules related to services can also result in hosting set-up fees being recognized for tax purposes in advance of when they are recognized for book purposes (i.e., typically deferred and recognized ratably over the estimated customer relationship period see Chapter 10). 11.1.5 Other considerations As discussed in Chapter 2, to the extent a software arrangement is determined to have extended payment terms, revenue for financial reporting purposes may have to be recognized as payments become due. Because the product has been delivered, and the right to payment is fixed and determinable, for tax purposes this revenue must either be recognized or deferred under the preceding rules. If the right to receive payment is conditioned upon a certain event, such as approval by a third party or achieving a sales goal, the all events test is not satisfied until the condition is met. The condition simply becomes another requirement to satisfy the all events test. If the taxpayer ceases to exist or liability to provide services otherwise ends, any revenue previously deferred is immediately recognized. 11.1.6 Common differences in revenue recognition between tax and financial reporting If it is unlikely that a receivable will be collected, or if the taxpayer may not accurately estimate the collectibility of receivables, revenue may be subject to specific deferral rules for financial reporting purposes. For tax purposes, revenue should generally be recognized when the all events test is met, as discussed above. Deductions for uncollectible accounts are only granted when the specific account receivable is written off. Under GAAP, the taxpayer will generally recognize revenue upon delivery (assuming all other revenue recognition criteria are met) unless there is significant uncertainty regarding customer acceptance. If such uncertainty exists, revenue would be deferred and recognized upon acceptance. For tax purposes, income may be recognized on shipment, delivery or acceptance, or when title passes, whichever is first recognized for financial reporting purposes. This is generally true whether the taxpayer sells the software or a license agreement that is treated as a sale for tax purposes, especially if there are no obligations other than the provision of software. If an advance payment is made, the taxpayer must determine whether the product is a good or service, and follow the rules discussed above. If no advance payment is 184 PricewaterhouseCoopers LLP

made, and the license is for more than one year, for tax purposes revenue for the entire license agreement is recognized upon delivery, if the license is treated as a sale for tax purposes; if the license is treated as a license for tax purposes, revenue is recognized over the period when the software is used. If the taxpayer has obligations in addition to the provision of software, revenue for book purposes may be recognized in a number of different ways depending on the facts and circumstances (e.g., a portion on delivery, revenue may be recognized using contract accounting or it may be fully deferred until all vendor obligations are delivered). For tax purposes, revenue will be recognized as soon as the all events test has been satisfied, or under the deferral rules discussed above. If the obligations are significant, revenue may be deferred for tax purposes until the taxpayer substantially performs such obligations, but generally not later than the time the revenue is recognized for book purposes. If the taxpayer's customer has the right to return software to the taxpayer, revenue may need to be deferred for book purposes (as discussed in Chapter 4). For tax purposes, the right of return does not allow the taxpayer to defer income, nor are reserves for returns allowed. The taxpayer generally gets a deduction (or a reduction in income) only for actual returns. Observation: As discussed in the sections above, revenue for tax purposes is generally recognized no later than at the point when revenue is recognized for book purposes. In addition, in certain situations revenue for tax purposes can be recognized in advance of when it is recognized for book purposes. Awareness of this is especially important for growing software companies that are approaching or have just achieved profitability. 11.1.7 Changes in accounting method rules It is important to note that even if a taxpayer is using an incorrect method to recognize revenue for tax purposes, the taxpayer must continue to use that incorrect method until it applies for a change in accounting method under the appropriate procedures. Changes to or from the deferral procedures of Regulation 1.451-5 are made under the standard accounting method change procedures (as contained in Revenue Procedure 97-27). Changes to or from the deferral procedures of Revenue Procedure 2004-34 are generally made under the automatic method change procedures (Revenue Procedure 2008-52). If the taxpayer changes its revenue recognition method without permission, or continues to use the incorrect method, then the taxpayer may be subject to an adjustment of taxable income by the IRS, with interest and possible penalties. Observation: For example, if a taxpayer has established an accounting method for tax purposes of recognizing revenue from the sale of goods in the period in which advance payments are received, the taxpayer would have to apply for a change in accounting method to apply the deferral rule under Regulation 1.451-5. 11.2 State income tax matters 11.2.1 Income tax considerations In addition to federal tax consequences, state tax laws are important considerations for the taxpayer. Those considerations include state income, franchise, gross receipts, margin, commercial activity, sales and use, and property taxes, as well as taxes imposed at the local level. The discussions below focus on state income and sales and use tax considerations. In general, states follow federal tax rules with respect to the determination and timing of income recognition; however, state income taxes offer unique challenges in the area of nexus and apportionment. www.pwcrevrec.com 185

11.2.2 Nexus In most instances, before a state can impose a tax on a taxpayer there must be some connection or nexus between the taxpayer and the taxing jurisdiction. Nexus is generally defined as the requisite connection that must exist between an entity and a jurisdiction for a jurisdiction to have authority to impose a tax. It is unconstitutional for a state to impose a tax on a taxpayer that does not have nexus with the state. Nexus standards generally differ based on the tax at issue. The Due Process Clause and Commerce Clause of the U.S. Constitution limit a state's authority to tax interstate commerce. In general, the Due Process Clause limits a state's authority to impose a tax to the extent such imposition would deprive a person... of property, without due process of law. The Commerce Clause generally limits a state's authority to impose tax by requiring that a taxpayer have substantial nexus with the taxing state, which is generally understood to mean more than a de minimus physical presence in the taxing state. In general, federal law (P.L. 86-272) limits a state's ability to impose an income-based tax to the extent a taxpayer limits its activity in the state to mere solicitation for the sale of tangible personal property, where the orders are approved outside the state, and, if approved, are filled and delivered from a stock of goods located outside the state. While such activities create constitutional nexus, the public law protects taxpayers that limit their activity in accordance with the strict criteria specified in the law; that is, mere solicitation, sales of tangible personal property, orders approved and filled outside the state, While taxpayers often treat transactions with respect to canned software as the sale of tangible personal property, and transactions with respect to custom software as the sale of intangible personal property or a service, the underlying contracts generally refer to both transactions as the license of software. Accordingly, such transactions may not fall within the protections of P.L. 86-272. Absent such protection, a licensor may have an obligation to file income tax returns in any state in which it licenses its software. Observation: In addition to concerns regarding the lack of protections from licensing activities, software companies may also conduct training, consulting, software upgrades, and related activities that may take them out of the protections of P.L. 86-272, and create a filing obligation for the entity that performs such activities. 11.2.3 Apportionment In addition to concerns regarding income tax nexus, taxpayers also face the challenge of determining how to apportion income among the states in which they operate. As noted above, canned and custom software is generally treated as tangible personal property, and intangible personal property or services, respectively. Such classification is based on the way canned and custom software is generally classified in various state sales and use tax statutes, rather than based on any clear guidance in state income tax statutes. Interestingly, tangible personal property is generally defined as property, other than real property, that can be weighed, touched, seen, felt, tasted or otherwise perceptible to the senses. Because software, in and of itself, is not tangible, states have amended their sales and use tax statutes to include canned software within the definition of tangible personal property. In general, states have not made similar changes to their income tax statutes or regulations. Where the license of canned software is treated as the sale of tangible personal property, a taxpayer will need to understand state specific rules with respect to the sourcing of sales of tangible personal property for income tax apportionment purposes. In general, sales of tangible personal property are sourced on a destination basis; i.e., included in the numerator of sales factor apportionment formula of the state into which the property is delivered. That said, taxpayers need to be aware of state-specific rules that require sales factor throwback when the seller is not taxable in the destination state. In general, the throwback 186 PricewaterhouseCoopers LLP

rule requires that receipts from the sale of tangible personal property be included in the numerator of the sales factor formula in the state from which the product is shipped, rather than in the state to which the product is shipped, if the seller does not have a taxable nexus in the destination state. In contrast, sales of services, which may include the license of custom software as well as software customization services and certain support and maintenance services, are generally sourced on an income producing activity basis; i.e., included in the numerator of the sales factor apportionment formula of the state in which the greater or greatest costs of performance associated with generating the service revenue were incurred. However, a growing number of states are moving to a market-based approach for sourcing service receipts, which sources receipts from the sale of services to the customer's location rather than based on where the seller incurred the costs of sale. The concern regarding the proper treatment of software for apportionment purposes is not limited to the sales factor. In general, states use some combination of a three-factor formula (i.e., property, payroll and sales) to apportion the income of a multistate corporation. In addition, most state apportionment factors limit the property factor to tangible personal property and specifically exclude intangible property from the factor. To the extent an entity is deemed to be licensing an intangible product, rather than selling a tangible product, one could argue that the value of its license agreements, which significantly contribute to the creation of income (much like a manufacturer's plant and equipment), should be included in the property factor to avoid distortion. Observation: Each state's income tax treatment of software is different and must be evaluated separately. The above discussion only scratches the surface of the complexities that software companies face in determining the proper income tax treatment of software. An extensive analysis of state-specific rules is required to ensure a correct understanding of the income tax rules applicable to software in any state. 11.3 Sales and use tax considerations for software States generally impose sales and use tax on the retail sale of tangible personal property and enumerated services. A sale at retail is usually defined as any sale or lease of tangible personal property and enumerated services, other than for resale, in the regular course of business. Additionally, states typically define a sale to be an exchange of tangible personal property or certain services for some form of consideration. Tangible personal property is generally defined as property, other than real property, that can be weighed, touched, seen, felt, tasted or otherwise perceptible to the senses. Therefore, when a company makes a sale or lease of tangible personal property to an end user for consideration, sales or use tax is usually triggered. Because software in and of itself is not tangible, most states have modified their statutes or regulations to specifically include the sale or license of prewritten (shrink-wrapped, offthe-shelf or canned) computer software in the definition of tangible personal property subject to tax. In contrast, the sale or license of custom software and separately stated charges to modify software are treated as a service and taxed only where specifically enumerated in the statute. 11.3.1 Nexus In most instances, before a state can constitutionally impose a tax on a taxpayer there must be some connection or nexus between the taxpayer and the taxing jurisdiction. Nexus is generally defined as the requisite connection that must exist between an entity and a jurisdiction for a jurisdiction to have authority to impose a tax. It is unconstitutional for a state to impose a tax on a taxpayer that does not have nexus with the state. Nexus standards generally differ based on the tax at issue. As noted above, P.L. 86-272 limits a state's ability to impose an income based tax where the taxpayer limits its activities to those specified in the public law. P.L. 86-272 does not apply in the context of sales and use taxes. Rather, for www.pwcrevrec.com 187

sales and use tax purposes, substantial nexus must be established under the Commerce Clause for a state to require a taxpayer to register as a vendor and to collect and remit tax. Substantial nexus requires, at a minimum, that a taxpayer have some physical presence in the state. There is no bright-line test for determining what degree of physical presence is required for purposes of substantial nexus ; however, it must be more than a de minimis level of physical presence. Certain activities, such as having an office or employees in the state, or having employees or independent contractors soliciting sales in the state on a regular and recurring basis, or having property in a state, will establish substantial nexus. Once nexus is established, a company will be required to collect sales tax on the retail sale of taxable items shipped or delivered into the state, and on services provided in the state, to the extent taxable, where nexus was established. Software companies should be sensitive to the fact that the sourcing rules for income tax apportionment purposes may differ significantly from the sourcing rules that apply for sales and use tax purposes. Accordingly, while the sale of a canned program may be included in the numerator of the origin-state income tax sales factor apportionment formula (e.g., as a result of the throwback rule), a taxpayer may still be required to collect the destination state's sales and use tax if the product is delivered in that state. Similarly, sales of custom software and computer services may be subject to tax in the purchaser's state, even though a greater or the greatest percentage of costs associated with the sale were incurred in the software company's home state office. One unique consideration a software company must consider in determining the proper amount of tax to collect is whether the sale/license of its products, to the extent subject to tax (e.g., as tangible personal property), will be used in more than one location by the purchaser/licensee. If so, then the software company may need to obtain a multiple points of use exemption certificate from the purchaser/licensee or collect tax on the full sales price, where appropriate. The exemption certificate will generally shift the tax remittance obligation from the software company to the purchaser/licensee, who will be responsible to determine the level of usage in and amount of tax owed to each state, based on a reasonable, but consistent and uniform, method of apportionment supported by the purchaser's/licensee's books and records. 11.3.2 Prewritten computer program Prewritten computer software is often defined to be a computer program that is held or exists for general or repeated sale or lease. The term encompasses software that is ready for immediate sale and use, which does not need additional modifications, and also includes computer programs developed for inhouse use that are subsequently offered for repeated sale or lease. Prewritten computer programs are also referred to as shrink-wrapped. It is important, however, to understand how each state defines prewritten software programs. Generally, prewritten computer programs are transferred to a customer via storage media such as a disk, tape, or CD. However, prewritten computer programs can also be transferred via remote telecommunications or electronic media such as the Internet or as a file attached to an e-mail transmission. Most states include prewritten computer software in their definitions of tangible personal property. Therefore, the majority of states impose sales or use tax on the retail sale of prewritten computer programs. However, the method of delivery will sometimes affect the taxable nature of the transaction. For example, California Sales and Use Tax Regulation Sec. 1502 specifically exempts from the tax prewritten computer software when it is delivered by remote telecommunications (assuming certain other restrictions are met). However, New York Code Sec. 1101 (b)(6) clearly states that a prewritten computer program retains its character as tangible personal property even if it is conveyed by electronic means. As of January 2008, 16 states do not impose sales or use tax on the electronic transmission of software. 188 PricewaterhouseCoopers LLP

Observation: To avail itself of the exemptions related to electronic delivery, the seller must observe and comply with each state's associated rules and regulations related to distribution of associated materials such as training manuals, back-up discs, or other documentation. 11.3.3 Custom computer program Custom computer programs are generally computer software programs written or prepared to the special order of a customer and not held for repeated sale or lease. Many states include separately stated charges for custom modifications to prewritten computer programs in the selling price of a custom computer program and tax such charges in the same manner as the custom computer program. Most states will treat the sale of a custom computer program as the sale of a service, which would not be subject to tax unless specifically enumerated in the taxing statute. 11.3.4 Custom modifications Custom modifications are generally defined to be alterations or additions to prewritten computer programs that are prepared to the special order of an individual customer. Custom modifications can include configuration services and the writing of additional lines of code. Some states will reclassify prewritten computer software to custom computer software depending upon the amount of custom modifications made to the original program. Most states will not impose tax on custom modification charges provided that the charges are contracted for separately from the sale of the original computer program and are separately stated on the invoice of sale. 11.3.5 Customized computer program A customized computer program is defined to be a significantly altered prewritten computer program that has been modified to meet the specific needs of an individual customer. Alterations or additions to a prewritten computer program that are prepared to the special order of an individual customer are generally defined as custom modifications. Custom modifications can include configuration services and the writing of additional lines of code. Some states will reclassify prewritten computer software as custom computer software depending on the amount of custom modifications made to the original program. Each state will determine the amount of modifications necessary to reclassify a prewritten computer program to a customized computer program. The general rule for reclassifying prewritten computer programs into custom computer programs is that more than fifty percent (50%) of the code is changed or that the cost of the customization service exceeds fifty percent (50%) of the original software license price. However, this rule varies by state and should only be used as a guideline. Observation: Not all states will reclassify the sale of a prewritten computer program to a customized computer program even though significant modification services are performed. Some states will only exempt separately stated custom modification charges. www.pwcrevrec.com 189

11.3.6 Software maintenance agreements Software maintenance agreements are either sold as a mandatory part of a software license agreement or at the option of the customer. Mandatory software maintenance agreements are included with the sale of a software program and, as a condition of the sale, the customer is required to purchase the agreement. Optional software maintenance agreements are purchased at the option of the customer and are generally contracted for under an agreement that is separate and distinct from the sale of the software. Software maintenance agreements most commonly include telephone support, upgrades, bug fixes or error corrections. Mandatory software maintenance agreements will generally take on the same tax application as the original software license transaction. The taxability of optional software maintenance agreements, however, is contingent upon how sales/use tax is imposed in each state. Telephone support services are not taxable in most states. Most states will impose sales or use tax on optional software maintenance agreements if the maintenance contract includes software upgrades, bug fixes or error corrections. The theory behind the application of tax is that all purchasers of the software who have purchased the maintenance agreement will receive the same updates, bug fixes or error corrections. These pieces of software are deemed by most states to be additional sales of canned software. Since the telephone support and the upgrades, bug fixes or error corrections are sold for a single price in one contract, the entire contract is taxable because pieces of canned software are included in the agreement. Observation: The method of delivery will also affect the taxability of maintenance agreements in those states that do not tax the electronic delivery of software. Software companies that can deliver software and software updates, bug fixes and error fixes electronically have a competitive advantage in states that do not tax electronic delivery. 11.3.7 Consulting services Consulting services consist of additional bundled activities that can be contracted for separately from the sale of the computer program. These services are usually sold for one price and often include installation, systems analysis, planning and technical consulting. Although individual elements of the contract may be exempt if separately stated on a bill or invoice, one taxable element will often cause the entire consulting contract to be taxable if it is part of a lump-sum transaction. The service that usually causes the contract to become taxable is installation. Several states specifically tax installation services. Additionally, some states tax general data processing and computer services. Systems analysis, planning and technical consulting will sometimes be included in the definition of data processing and computer services. Therefore, software companies should review the sales and use tax laws in states where consulting services are sold and the company has nexus. 11.3.8 Software training services Software training services generally consist of specific instruction regarding the use and operation of the software program sold. Training services can be contracted for as a separate and distinct sale from the license agreement. Training is usually performed at the site of the customer and often includes the provision of manuals and other documentation. Training manuals and documentation are separate from any software documentation transferred pursuant to the sale of a computer program, and they are usually an inconsequential element of the total cost of providing the training services. Separately stated charges for training manuals and documentation are generally subject to sales/use tax. Most states do not impose sales or use tax on separately contracted for and stated training services. 190 PricewaterhouseCoopers LLP

11.3.9 Hosting arrangements, including Software-as-a-Service In these arrangements, service providers sell the right to access and use through the Internet application software. The software is resident on the service provider's server and neither title nor possession of the software transfers to the customer. The customer is charged a fee for accessing the software via the Internet. The service provider typically does not provide Internet access to the customer. The customer must have already acquired Internet access from another vendor to gain access to the computer program. As noted in Chapter 10, these arrangements are becoming more widely used by smaller companies with limited information technology budgets, as well as larger companies that utilize hosted products as a cost-saving information technology alternative. Most states will not impose sales or use tax on the fee for accessing software over the Internet because no transfer of property takes place. However, states that currently charge sales or use tax on data processing, computer services, or Internet access charges may impose the same taxes on fees for accessing the software. Observation: Just like state income tax, the sales and use tax treatment of software and ancillary services is complex and varies by state. Therefore, each state must be evaluated separately to ensure a complete understanding of a specific state's treatment of software for sales and use tax purposes. 11.4 International tax matters 11.4.1 Cross-border software transactions: characterization and source From a U.S. perspective, taxpayers will characterize the income from cross-border transactions involving software in one of five ways: a sale; a license; a lease; the provision of services; or the provision of knowhow. That characterization determines how the U.S. tax rules source the income; specifically is the income from U.S. or foreign sources? Observation: A U.S. company is generally taxed on its worldwide income. Therefore, income earned from certain foreign operations may be taxed in the U.S. and in the foreign jurisdiction where the income is generated. This results in potential double taxation. The U.S. tax rules provide a credit mechanism for taxpayers to mitigate the effects of double taxation. A U.S. taxpayer may be able to reduce its U.S. tax liability by claiming a tax credit for all or some of the tax paid to the foreign taxing jurisdiction. The ability to claim a foreign tax credit may be limited depending on a U.S. company's allocation of income from U.S. and foreign sources. Generally, a U.S. taxpayer may claim foreign tax credits only to the extent such U.S. taxpayer has net foreign source income. Taxpayers should also note that calculating foreign source income may be performed on a consolidated basis. To the extent U.S. companies earn income from software transactions that are subject to tax both in the U.S. and elsewhere, determining the source of the revenue is important in determining how much U.S. tax the U.S. company ultimately will pay. www.pwcrevrec.com 191

11.4.2 Characterization of software transactions For purposes of international computer software transactions, Treasury Regulation 1.861-18 broadly defines a computer program as a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result. In addition, a computer program also includes any media, user manuals, documentation, databases or similar items that are incidental to the operation of the computer program. This discussion is based upon the rules for classifying software transactions contained in Regulation 1.861-18. Observation: For U.S. federal income tax purposes it is important to distinguish the use of the characterization rules under Treasury Regulation 1.861-18, from the timing rules prescribed in Treasury Regulation 1.451-5 and Revenue Procedure 2004-34. The rules under Treasury Regulation 1.861-18 determine whether the income is from U.S. or foreign sources. The rules under Treasury Regulation 1.451-5 and Revenue Procedure 2004-34 determine the tax period in which advance payments from sales of inventoriable goods and sales of services, respectively, are recognized. Also, note that Treasury Regulation 1.861-18 offers specific guidance with respect to and is specific to software transactions. However, Revenue Procedure 2004-34 does include several examples covering advance payments for licensing software and for providing customer support. In general, the revenue from the transfer of a computer program can be segregated into one of four different categories: A transfer of a copyright right in the computer program (e.g., the license granted to a distributor to reproduce unlimited copies of the software and sell them to the general public); A transfer of a copyrighted article (e.g., the sale of an off-the-shelf computer program, without the right to make any or more than a de minimus number of additional copies); The provision of services for the development or modification of a computer program (e.g., the writing of a source code according to the technical specifications provided by the beneficiary of the software); or The provision of know-how relating to computer programming techniques. 11.4.3 Transfer of a copyright right The transfer of a computer program is treated as the transfer of a copyright right only if one or more of the following rights is transferred: The right to make copies of the computer program for purposes of distribution to the public; The right to prepare derivative computer programs based upon the copyrighted computer program; The right to make a public performance of the computer program; or The right to publicly display the computer program. 11.4.4 Transfer of a copyrighted article In contrast, a transfer of a computer program is categorized as a transfer of a copyrighted article if the transferee: Acquires a copy of a computer program; and Does not acquire more than a de minimus amount of any of the four copyright rights identified above. 192 PricewaterhouseCoopers LLP

11.4.5 Provision of services If the transaction involves the performance of services for the development or modification of the computer program, it will be classified as a provision of services. However, if the value of the services is minimal compared to the value of the copyright right or copyrighted article being transferred in one transaction, the services will not be treated as a separate transaction, but a part of the transfer of the copyright right or copyrighted article. For example, if the seller of a copyrighted article performs initial software installation or customization services, the services generally constitute part of the sales transaction. Note that this rule is specific for characterizing the transaction, and thus determining the source of income for U.S. tax purposes. To the extent an advance payment for services was received, the timing for the recognition of income related to those services may fall under either Treasury Regulation 1.451-5 or Revenue Procedure 2004-34, depending upon whether the goods were available without the purchasing of services. See section 11.1.4 above. 11.4.6 Provision of know-how The provision of information with respect to a computer program is characterized as a provision of knowhow if all of the following three elements are satisfied: The information transferred is related to computer programming techniques; The transaction is subject to restrictions preventing unauthorized disclosure; and The information is subject to trade secret protection. 11.4.7 Transfer of a copyright right: sale vs. license If the transaction is classified as a transfer of a copyright right, then a subsequent determination should be made as to whether it is a sale/exchange or a license of the copyright right. If there is a transfer of all substantial rights in the copyright, the transaction will be classified as a sale. A transaction that does not constitute a sale because not all substantial rights have been transferred will be classified as a license generating royalty income. For example, if the transferee is granted the right to reproduce and distribute software within a country, but the grant is on a non-exclusive basis, for less than the remaining life of the copyright, and does not permit sublicensing, the transaction will likely be classified as a license, not as a sale. 11.4.8 Transfer of a copyrighted article: sale vs. lease If the transfer of a computer program is classified as the transfer of a copyrighted article, then a subsequent determination must be made as to whether it is a sale/exchange or a lease of the copyrighted article. If the benefits and burdens of ownership have been transferred, the transaction will be classified as a sale. A transaction that does not constitute a sale because insufficient benefits and burdens of ownership have been transferred will be classified as a lease, generating rental income. For example, if the transaction involves a transfer that is contingent on the periodic payment of a fee, with no right to use the copyrighted article in perpetuity, the transaction is generally classified as a lease rather than a sale. 11.4.9 Forms and labels In evaluating the tax characterization of a software transaction, it is critical to understand that the labels and forms of a transaction, such as licensee and license are not determinative for purposes of classifying income from such a transaction. The substance, rather than the form, of a transaction will determine its classification. www.pwcrevrec.com 193

Observation: Generally, in classifying the income, the focus is on the intent and all facts and circumstances tests. For example, if the sum of the rentals paid over a short part of the expected useful life of the computer program approximates its purchase price and the lessee continues to use the software for the remainder of the estimated useful life for relatively nominal or token payments, the transaction would be likely to qualify as a sale, even though a passage of title is not expressly provided in the agreement. 11.4.10 Means of transfer For U.S. federal income tax purposes, the means of transferring a computer program, whether electronically or physically, is generally irrelevant for classification purposes. Accordingly, an electronic transfer of a computer program over the Internet or a transfer of a disk containing such computer program should be classified in the same manner. Observation: It is critical to realize that this broad generalization is with respect to the relevant U.S. tax rules. Other countries may determine that the means or transferring the program may be integral to classifying the nature of the program and therefore determining any related tax. Other countries are also not bound by the U.S. characterization. Their own rules will be applied to determine the taxation. If the U.S. has an income tax treaty with the other country, then the two jurisdictions may have agreed on the rules of characterization. 11.4.11 Hybrid transactions Computer program transactions are sourced according to the category in which they are placed. However, if a transaction consists of more than one category, each type of income is generally treated as a separate transaction, unless the transaction falls primarily into one category and involves only a de minimus transfer of other rights. 11.4.12 General sourcing rules After determining the character of a transaction, a U.S. company must then determine whether income and expenses derived from such transactions are from U.S. or foreign sources. 11.4.13 Copyright rights Income derived from the sale of a copyright right will be sourced according to the residence of the seller. Conversely, income characterized as a royalty arising from the license of copyright rights will generally be sourced where the rights are used. For example, if the copyright right is used in a foreign country, the license will generally generate foreign source royalty income. In general, a U.S. company prefers to earn foreign source income because foreign tax credits may only be utilized to the extent such U.S. company earns positive foreign source income. However, this benefit could be mitigated by additional withholding taxes imposed on royalty income in foreign jurisdictions. 11.4.14 Copyrighted articles The source of sales proceeds arising from the transfer of copyrighted articles (inventory) will depend on whether the taxpayer produced or purchased the inventory. Income from purchased inventory is sourced where title passes. Income from inventory produced by the taxpayer is sourced according to where the taxpayer produced the inventory and where title passes from the seller to the buyer. In essence, the revenue from the latter transaction is allocated to the production and to the sales activities. 194 PricewaterhouseCoopers LLP

Once the revenue is allocated to those specific activities (pursuant to formulaic instructions) the revenue is then sourced according to the rules specific to those activities. The revenue from production would generally be sourced to where the production took place. As discussed above, the revenue from the sale would generally be sourced according to where the property is located when the sale took place. Conversely, income generated from a lease of a copyrighted article will be sourced where the leased article is used. Observation: Passage of title is problematic for downloaded software because it is not clear where title passes. One way to mitigate such confusion is to stipulate by mutual agreement of the parties, in the contract, where and at what point title to the software transfers. See discussion on financial reporting issues related to delivery in Chapter 2. 11.4.15 Services and know-how The source of services income is the place where the service is performed. If services are performed both within and without the U.S., the services income will be allocated between U.S. and foreign sources. Determining the source of services income can become complicated when the income results from services performed via the Internet. The question then arises as to where the services are being performed at the customer's location or at the provider's location. This is an evolving area of international tax law; therefore companies (both in the U.S. and other jurisdictions) need to regularly review these rules. Income from the use of know-how is sourced to where the know-how is used. 11.4.16 Withholding taxes The U.S. will tax non-u.s. taxpayers on their income from U.S. sources. Moreover, U.S. taxpayers are usually taxed in foreign countries on their income from sources inside a particular country. Such tax is commonly assessed using a withholding mechanism. Most countries, including the U.S., require that the payor of income subtract and withhold from certain payments a specified amount of a payment and then submit that payment to the taxing authorities on behalf of the recipient, hence the term withholding. Withholding tax is most often applied to passive-type income including interest, royalties and dividend income. However, withholding tax can also be applied to services income as well as other income earned by a taxpayer not customarily subject to tax in the jurisdiction where the income was earned. In the U.S., royalties related to software transactions are subject to the withholding rules. The same is usually true for royalties paid from another country to a U.S. recipient as most other countries have similar mechanisms to collect tax. U.S. tax law imposes 30% tax on income earned from passive-type activities including royalty income. This means that when a U.S. payor makes a payment to a non-u.s. person, the U.S. payor withholds 30% of the payment and surrenders that amount to the U.S. government on behalf of the foreign payee. Fortunately, many countries, including the U.S., have income tax treaties with other countries. An income tax treaty between two countries will often specify a rate of withholding that is lower than the rate under the foreign jurisdiction's domestic tax law. A more challenging situation arises when different taxing jurisdictions characterize transactions differently. For example, a transaction characterized as generating sales income under U.S. law could be characterized as generating royalty income under Korean tax principles. This means the Korean payor will withhold a percentage of the payment to the U.S. company even though the U.S. does not view the income as royalty income. U.S. taxpayers may therefore be surprised when they receive an amount less than the total they were expecting. This is just one scenario in which the sourcing rules discussed above become relevant. www.pwcrevrec.com 195

To the extent the U.S. company pays tax in a foreign jurisdiction related to income generated from software transactions, the U.S. company may claim a foreign tax credit against its U.S. tax liability for the amount of the foreign income tax paid, subject to various limitations. For example, a U.S. company generally may only claim foreign tax credits on 35% of its net foreign source income in a particular year. To the extent, the U.S. company does not generate enough foreign source income, such credits may not be utilized in that year. This result can typically occur in cases where the foreign jurisdiction taxes income at a rate above the U.S. statutory rate of 35% or where a foreign jurisdiction taxes income of a U.S. company which is characterized as U.S. source income under U.S. tax rules. Any unused credits, however, may be carried forward to future years when the U.S. company has sufficient foreign source income. Currently, foreign tax credits have a ten year carryover period. In addition, foreign countries may impose withholding taxes on the payment of certain types of income to U.S. persons. To the extent the U.S. company is limited in its use of its foreign tax credits, such taxes would be an additional cost to the Company. Observation: The U.S. has a number of complex rules that limit the amount of foreign tax credits that U.S. corporations can claim. This is based upon a U.S. corporation's foreign income after an allocation of expenses incurred in the U.S. related to generating that income. Therefore, as discussed above, U.S. companies cannot assume that simply because they are paying foreign income tax that the foreign income tax can be used as a credit against their U.S. income tax liability. 11.4.17 Extraterritorial income In the fall of 2000, the U.S. enacted the FSC Repeal and Extraterritorial Income Act of 2000. The Extraterritorial Income regime ( ETI ) replaced the Foreign Sales Corporation regime ( FSC ) with the hope that the ETI regime would pass muster by the World Trade Organization ("WTO"), which had previously ruled that the FSC regime was an illegal export subsidy. The WTO eventually ruled that the ETI regime was also an illegal export subsidy and Congress repealed the ETI regime in 2004. Notwithstanding, various transition and binding contract rules apply and thus U.S. taxpayers may still have transactions generating income currently that qualify for ETI benefits. Broadly speaking, under the ETI rules, taxpayers are allowed to exclude from taxable income a portion of their gross income related to export sales. This exclusion is only allowed to the extent the taxpayer performs certain specifically prescribed sales and administrative activities outside the U.S. An export sale is one where the property is: held primarily for sale, lease or rental in the ordinary course of a trade or business for direct use, consumption or disposition outside the U.S.; not more than 50% of the fair market value of the property can be attributable to articles manufactured, produced, grown or extracted outside the U.S.; and the property can be manufactured, produced, grown or extracted within or outside the U.S. (see below). However, property manufactured outside the U.S. qualifies only if manufactured by a: domestic corporation; a U.S. citizen or resident; a foreign corporation that makes a special election under the ETI rules to be treated as a domestic corporation; or a pass-through entity where all of the partners are one of the above. 196 PricewaterhouseCoopers LLP

The ETI rules generally exclude intellectual property from qualifying as export property, however, there is an exception for license revenue from software. The qualification of software gross income as ETI is dependent upon the U.S. characterization of the income. Broadly, transfers of a copyright right via a royalty and transfers of a copyrighted article via a license qualify as ETI. However, services and transfers of know-how generally do not qualify as ETI. To qualify for the ETI exclusion, the taxpayer must meet all the ETI requirements. 11.4.18 Domestic manufacturing deduction The domestic production activities deduction (more commonly known as the "Section 199 Deduction") was enacted by Congress in 2004. The Section 199 deduction is available to all taxpayers actively engaged in qualifying business activities. Subject to a W-2 wage limitation, the Section 199 Deduction is computed as a percentage of the lesser of taxable income or qualified production activities income ("QPAI"), phased in at three percent in 2005 and 2006, six percent in 2007 through 2009, and nine percent in 2010 and thereafter. In general, a taxpayer's QPAI is equal to its domestic production gross receipts ("DPGR") less the sum of the cost of goods sold allocable to such receipts, and other expenses, losses, or deductions that are properly allocable to such receipts. DPGR includes, inter alia, gross receipts derived from any lease, rental, license, sale, exchange, or other disposition of computer software that was manufactured or produced by the taxpayer in whole or in significant part within the United States. Computer software is defined as any program or routine or any sequence of machine-readable code that is designed to cause a computer to perform a desired function or set of functions, and the documentation required to describe and maintain that program or routine. It also includes any "incidental and ancillary rights" that are necessary to effect the acquisition of the title to, the ownership of, or the right to use the computer software, and that are used only in connection with that specific computer software. Note that gross receipts of the taxpayer derived from software that is leased, licensed, or rented by the taxpayer for use by any related person is excluded from DPGR, unless the property is reproduced and sold, exchanged, leased, rented, or sublicensed to an unrelated person for the ultimate use of the unrelated person. Gross receipts derived from the online use of software, i.e., providing customers access to computer software for the customers' direct use while connected to the Internet or any other public or private communications network, generally is not DPGR. Such gross receipts may be treated as DPGR, however, if one of two safe harbor rules applies. First, gross receipts derived from the online use of software may be treated as DPGR if software that has only "minor or immaterial differences" from the online software may also be purchased on a tangible medium (e.g., CD) or by download from the Internet. Under the second safe-harbor, gross receipts derived from the online use of software may be treated as DPGR if "another person" derives on a regular and ongoing basis in its business gross receipts from the lease, rental, license, sale, exchange, or other disposition of "substantially identical" software to its customers affixed to a tangible medium or by download from the Internet. 81 DPGR generally does not include gross receipts derived from the performance of services. Thus, gross receipts derived from customer and technical support, telephone and other telecommunication services, online services (such as Internet access services, online banking services, providing access to online electronic books, newspapers, and journals), and other similar services do not constitute DPGR. One exception is that a taxpayer may include in DPGR the gross receipts it derives from services performed pursuant to a qualified computer software maintenance agreement (i.e., the embedded services rule). For this purpose, a qualified computer software maintenance agreement is an agreement provided in connection with the lease, rental, license, sale, exchange, or other disposition of computer software that entitles the customer to receive future updates, cyclical releases, rewrites of the underlying software, or customer support services for the computer software, where the agreement is provided in the normal course of the taxpayer's business, the price for the agreement is not separately stated, and the agreement is neither separately offered by the taxpayer nor separately bargained for with customers. This embedded services rule for qualified computer software maintenance agreements does not apply to online software. www.pwcrevrec.com 197

As a final note, taxpayers engage in transactions with related parties and often exchange payments pursuant to cost sharing arrangements, including certain "buy-in" payments in which participants make pre-existing intangible property such as software available for purposes of research. Further analysis would be required to determine whether the resulting gross receipts qualify as DPGR. For example, if the buy-in payment is characterized as a lease or license transaction, the gross receipts will not qualify as DPGR unless the taxpayer can establish that the software is licensed for reproduction, sale, exchange, lease, rental, or sublicense to an unrelated person for ultimate use of the unrelated person. Further, in this case, the gross receipts may need to be bifurcated into amounts that are relating to sublicensing to unrelated parties as well as amounts that relate to development performed by the related party licensee, the latter of which may not qualify as DPGR. 11.4.19 Income from foreign corporations As mentioned earlier, U.S. taxpayers are taxed on their worldwide income. In most cases, the income of a U.S. taxpayer does not include the income of foreign corporations in which the U.S. taxpayer owns stock until the foreign corporation pays a dividend to the U.S. owner. However, when a U.S.-owned foreign corporation earns certain types of "tainted income" including certain passive income, like royalties, that income may be taxable to the U.S. owners in the year when the foreign corporation earns the income, even if the foreign corporation has yet to pay a dividend. Under U.S. tax law, royalty and license income from software transactions may be characterized as passive income if the foreign corporation owned by the U.S. taxpayer is not actively involved in generating the royalty or license income. In such a case, there are two different sets of rules that may currently force the U.S. owner to include that income in its pool of U.S. taxable income: the Controlled Foreign Corporation ( CFC ) rules; and the Passive Foreign Investment Company ( PFIC ) rules. Congress designed these rules to prevent U.S. taxpayers from exporting revenue generating passive assets outside the U.S. The CFC rules If greater than 50% of the vote or value of the stock of a foreign corporation is owned, directly or indirectly by U.S. shareholders, as defined under U.S. tax rules, then that corporation is a CFC. In such a case, each U.S. shareholder that owns 10% or more of the voting stock of a CFC is taxed on its share of the CFC's passive income, called "Subpart F" income. (Caveat: U.S. shareholders may also be subject to tax on a CFC's "tainted" operating type income, so called "foreign base company sales income" and "foreign base company services income".) The PFIC rules A PFIC is any foreign corporation if, for any taxable year, 75% or more of its gross income is passive income or 50% or more of its assets produce, or are held to produce, passive income. In such a case, any U.S. taxpayer that is a shareholder in the PFIC must then make a decision. The U.S. shareholder must elect to be taxed on the income currently, defer taxation until the foreign corporation pays a dividend but then pay interest on the tax for all the years that deferral was chosen or, in the case of a PFIC with marketable shares, be taxed currently on the increase in the fair market value of the stock in the current year compared to the fair market value in earlier years. Observation: The application of these two regimes should not overlap -- if the CFC rules apply, the PFIC regime will generally not apply unless, for example, the CFC was created prior to 1998. These anti-deferral mechanisms, as they are commonly referred to, are complex and should be navigated with caution. When dealing with the revenue stream from software, it is critical to remember that simply because the revenue is earned by a foreign corporation, that revenue is not necessarily escaping the U.S. tax net. 198 PricewaterhouseCoopers LLP

Appendix A: Statement of Position 97-2, Software Revenue Recognition October 27, 1997 Paragraphs Note Introduction 1 Scope 2-3 Relationship to Other Pronouncements 4-5 Conclusions 6, 93 Basic Principles 7-14 Evidence of an Arrangement 15-17 Delivery 18-25 Customer Acceptance 20 Determining Delivery Multiple Copies of Software Products Versus Multiple Licenses 21 Delivery Other Than to the Customer 22 Delivery Agents 23 Authorization Codes 24-25 Fixed or Determinable Fees and Collectibility 26-33 Factors That Affect the Determination of Whether a Fee is Fixed or Determinable and Collectible 27-33 Multiple-Element Arrangements 34-73 Additional Software Deliverables and Rights to Exchange or Return Software 35-55 Postcontract Customer Support 56-62 Services 63-73 Contract Accounting 74-91 Effective Date and Transition 92 Basis for Conclusions 93-145 Background 93 Basic Principles 94-106 Delivery 107-109 Fixed or Determinable Fees and Collectibility 110-116 Multiple-Element Arrangements 117-132 Additional Software Deliverables and Rights to Exchange or Return Software 117-123 Postcontract Customer Support 124-125 Services 126-132 Contract Accounting 133-142 Distinguishing Transactions Accounted for Using Contract Accounting from Product Sales 137 Application of ARB No. 45 and SOP 81-1 138-142 Effective Date and Transition 143-144 Items Not Retained from SOP 91-1 145 Appendix A Examples of the Application of Certain Provisions of This Statement of Position 146 Appendix B Response to Comments Received 147 Appendix C Revenue Recognition on Software Arrangements 148 Glossary 149 Software Revenue Recognition A-1

Note Statements of Position (SOPs) on accounting issues present the conclusions of at least two-thirds of the Accounting Standards Executive Committee, which is the senior technical body of the Institute authorized to speak for the Institute in the areas of financial accounting and reporting. Statement on Auditing Standards No. 69, The Meaning of Present Fairly in Conformity With Generally Accepted Accounting Principles, identifies AICPA SOPs that have been cleared by the Financial Accounting Standards Board as sources of established accounting principles in category b of the hierarchy of generally accepted accounting principles that it establishes. AICPA members should consider the accounting principles in this SOP if a different accounting treatment of a transaction or event is not specified by a pronouncement covered by Rule 203 of the AICPA Code of Professional Conduct. In such circumstances, the accounting treatment specified by the SOP should be used, or the member should be prepared to justify a conclusion that another treatment better presents the substance of the transaction in the circumstances. An effective date provision of this SOP has been deferred by SOP 98-4, Deferral of the Effective Date of a Provision of SOP 97-2, Software Revenue Recognition. This SOP is effective March 31, 1998. If an enterprise had applied SOP 97-2 in an earlier period for financial statements or information already issued prior to the promulgation of this SOP, amounts reported in those financial statements or as part of that information may be restated to reflect the deferral of the effective date of the second sentence of paragraphs.10,.37,.41, and.57 of SOP 97-2 and the related examples noted in paragraph.03 of this SOP. SOP 97-2 is amended by SOP 98-9, Modification of SOP 97-2, Software Revenue Recognition, With Respect to Certain Transactions. The provisions of this SOP that extend the deferral of the application of certain passages of SOP 97-2 are effective December 15, 1998. All other provisions of this SOP are effective for transactions entered into in fiscal years beginning after March 15, 1999. Earlier adoption is permitted as of the beginning of fiscal years or interior periods for which financial statements or information has not been issued. Retroactive application of the provisions of this SOP is prohibited. Copyright 1997 by American Institute of Certified Public Accountants, Inc., New York, NY 10036-8775 All rights reserved. For information about the procedure for requesting permission to make copies of any part of this work, please call the AICPA Copyright Permissions Hotline at 201-938-3245. A Permissions Request Form for emailing requests is available at www.aicpa.org by clicking on the copyright notice on any page. Software Revenue Recognition A-2

Introduction.01 Statement of Position (SOP) 91-1, Software Revenue Recognition, was issued in 1991 to provide guidance on applying generally accepted accounting principles to software transactions and to narrow the range of revenue recognition practices that were in use before its issuance. Since the issuance of SOP 91-1, practice issues have been identified that the AICPA s Accounting Standards Executive Committee (AcSEC) believes are not addressed adequately in SOP 91-1. In addition, AcSEC believes some of the guidance in SOP 91-1 should be reconsidered. This SOP supersedes SOP 91-1. Scope.02 This SOP provides guidance on when revenue should be recognized and in what amounts for licensing, selling, leasing, or otherwise marketing computer software. fn 1 It should be applied to those activities by all entities that earn such revenue. It does not apply, however, to revenue earned on products or services containing software that is incidental fn 2 to the products or services as a whole..03 In connection with the licensing of an existing product, a vendor might offer a small discount (for example, a coupon or other form of offer for five percent off) on additional licenses of the licensed product or other products that exist at the time of the offer but are not part of the arrangement. Such marketing and promotional activities are not unique to software and are not included in the scope of this SOP. fn 3 Relationship to Other Pronouncements.04 If a lease of software includes property, plant, or equipment, the revenue attributable to the property, plant, or equipment should be accounted for in accordance with Financial Accounting Standards Board (FASB) Statement of Financial Accounting Standards No. 13, Accounting for Leases, and any revenue attributable to the software, including postcontract customer support (PCS), should be accounted for separately in conformity with the guidance set forth in this SOP. However, in conformity with paragraph.02, if the property, plant, or equipment contains software that is incidental to the property, plant, or equipment as a whole, the software should not be accounted for separately..05 A number of the requirements of this SOP are similar to or overlap those in certain pronouncements of the Accounting Principles Board (APB) or the FASB, such as FASB Statement No. 48, Revenue Recognition When Right of Return Exists. This SOP does not alter the requirements of any APB Opinion or FASB pronouncement. Conclusions.06 The following conclusions should be read in conjunction with the Basis for Conclusions section, beginning with paragraph.93 of this SOP, and the examples in Appendix A, Examples of the Application of Certain Provisions of this SOP [paragraph.146]. Basic Principles.07 Software arrangements range from those that provide a license for a single software product to those that, in addition to the delivery of software or a software system, require significant production, modification, or customization of software. If an arrangement to deliver software or a software system, either alone or together with other products or services, requires significant production, modification, or customization of software, the entire arrangement should be accounted for in conformity with Accounting Research Bulletin (ARB) No. 45, Long-Term Construction-Type Contracts, using the relevant guidance herein, and in SOP 81-1, Accounting for Performance of Construction-Type and Certain Production-Type Contracts [section 10,330]. fn 4 Software Revenue Recognition A-3

.08 If the arrangement does not require significant production, modification, or customization of software, revenue should be recognized when all of the following criteria are met: Persuasive evidence of an arrangement exists; Delivery has occurred; The vendor s fee is fixed or determinable; Collectibility is probable. fn 5.09 Software arrangements may provide licenses for multiple software deliverables (for example, software products, upgrades/enhancements, PCS, or services), which are termed multiple elements. A number of the elements may be described in the arrangement as being deliverable only on a when-and-if-available basis. When-and-if-available deliverables should be considered in determining whether an arrangement includes multiple elements. Accordingly, the requirements of this SOP with respect to arrangements that consist of multiple elements should be applied to all additional products and services specified in the arrangement, including those described as being deliverable only on a when-and-if-available basis..10 If an arrangement includes multiple elements, the fee should be allocated to the various elements based on vendor-specific objective evidence of fair value, regardless of any separate prices stated within the contract for each element. Vendor-specific objective evidence of fair value is limited to the following: The price charged when the same element is sold separately; For an element not yet being sold separately, the price is established by management having the relevant authority; it must be probable that the price, once established, will not change before the separate introduction of the element into the marketplace. The amount allocated to undelivered elements is not subject to later adjustment.fn6 However, if it becomes probable that the amount allocated to an undelivered element will result in a loss on that element of the arrangement, the loss should be recognized pursuant to FASB Statement No. 5, Accounting for Contingencies. When a vendor s pricing is based on multiple factors such as the number of products and the number of users, the amount allocated to the same element when sold separately must consider all the factors of the vendor s pricing structure..11 If a discount is offered in a multiple-element arrangement, a proportionate amount of that discount should be applied to each element included in the arrangement based on each element s fair value without regard to the discount. However, as discussed in paragraph.37, no portion of the discount should be allocated to any upgrade rights. Moreover, to the extent that a discount exists, the residual method described in paragraph.12 attributes that discount entirely to the delivered elements. [As amended, effective for transactions entered into in fiscal years beginning after March 15, 1999, by Statement of Position 98-9.].12 If sufficient vendor-specific objective evidence does not exist for the allocation of revenue to the various elements of the arrangement, all revenue from the arrangement should be deferred until the earlier of the point at which (a) such sufficient vendor-specific objective evidence does exist or (b) all elements of the arrangement have been delivered. The following exceptions to this guidance are provided. If the only undelivered element is PCS, the entire fee should be recognized ratably (see paragraphs.56 through.62). If the only undelivered element is services that do not involve significant production, modification, or customization of software (for example, training or installation), the entire fee should be recognized over the period during which the services are expected to be performed (see paragraphs.63 through.71). If the arrangement is in substance a subscription, the entire fee should be recognized ratably (see paragraphs.48 and.49). If the fee is based on the number of copies, the arrangement should be accounted for in conformity with paragraphs.43 through.47. Software Revenue Recognition A-4

There may be instances in which there is vendor-specific objective evidence of the fair values of all undelivered elements in an arrangement but vendor-specific objective evidence of fair value does not exist for one or more of the delivered elements in the arrangement. In such instances, the fee should be recognized using the residual method, provided that (a) all other applicable revenue recognition criteria in this SOP are met and (b) the fair value of all of the undelivered elements is less than the arrangement fee. Under the residual method, the arrangement fee is recognized as follows: (a) the total fair value of the undelivered elements, as indicated by vendorspecific objective evidence, is deferred and (b) the difference between the total arrangement fee and the amount deferred for the undelivered elements is recognized as revenue related to the delivered elements. [As amended, effective for transactions entered into in fiscal years beginning after March 15, 1999, by Statement of Position 98-9.].13 The portion of the fee allocated to an element should be recognized as revenue when the criteria in paragraph.08 of this SOP are met with respect to the element. In applying those criteria, the delivery of an element is considered not to have occurred if there are undelivered elements that are essential to the functionality of the delivered element, because the customer would not have the full use of the delivered element..14 No portion of the fee (including amounts otherwise allocated to delivered elements) meets the criterion of collectibility if the portion of the fee allocable to delivered elements is subject to forfeiture, refund, or other concession if any of the undelivered elements are not delivered. In order for the revenue related to an arrangement to be considered not subject to forfeiture, refund, or other concession, management must intend not to provide refunds or concessions that are not required under the provisions of the arrangement. All available evidence should be considered to determine whether the evidence persuasively indicates that the revenue is not subject to forfeiture, refund, or other concession. Although no single item of evidence may be persuasive, the following additional items should be considered: Acknowledgment in the arrangement of products not currently available or not to be delivered currently; Separate prices stipulated in the arrangement for each deliverable element; Default and damage provisions as defined in the arrangement; Enforceable payment obligations and due dates for the delivered elements that are not dependent on the delivery of the future deliverable elements, coupled with the intent of the vendor to enforce rights of payment; Installation and use of the delivered software; and Support services, such as telephone support, related to the delivered software being provided currently by the vendor. Regardless of the preceding, the vendor s historical pattern of making refunds or other concessions that were not required under the original provisions (contractual or other) of other arrangements should be considered more persuasive than terms included in the arrangement that indicate that no concessions are required. Evidence of an Arrangement.15 Practice varies with respect to the use of written contracts. Although a number of sectors of the industry rely upon signed contracts to document arrangements, other sectors of the industry that license software (notably the packaged software sector) do not. Software Revenue Recognition A-5

.16 If the vendor operates in a manner that does not rely on signed contracts to document the elements and obligations of an arrangement, the vendor should have other forms of evidence to document the transaction (for example, a purchase order from a third party or online authorization). If the vendor has a customary business practice of utilizing written contracts, evidence of the arrangement is provided only by a contract signed by both parties..17 Even if all other requirements set forth in this SOP for the recognition of revenue are met (including delivery), revenue should not be recognized on any element of the arrangement unless persuasive evidence of an arrangement exists. Delivery.18 The second criterion in paragraph.08 for revenue recognition is delivery. The principle of not recognizing revenue before delivery applies whether the customer is a user or a reseller. Except for arrangements in which the fee is a function of the number of copies, delivery is considered to have occurred upon the transfer of the product master or, if the product master is not to be delivered, upon the transfer of the first copy. For software that is delivered electronically, the delivery criterion of paragraph.08 is considered to have been met when the customer either (a) takes possession of the software via a download (that is, when the customer takes possession of the electronic data on its hardware), or (b) has been provided with access codes that allow the customer to take immediate possession of the software on its hardware pursuant to an agreement or purchase order for the software. In such cases, revenue should be recognized if the other criteria of paragraph.08 have been satisfied..19 Paragraphs.20 through.25 provide guidance on determining whether delivery is considered to have occurred in certain kinds of software transactions. Customer Acceptance.20 After delivery, if uncertainty exists about customer acceptance of the software, license revenue should not be recognized until acceptance occurs. Determining Delivery Multiple Copies of Software Products Versus Multiple Licenses.21 Arrangements to use multiple copies of a software product under site licenses with users and to market multiple copies of a software product under similar arrangements with resellers should be distinguished from arrangements to use or market multiple single licenses of the same software. In the former kind of arrangement, duplication is incidental to the arrangement and the delivery criterion is met upon the delivery of the first copy or product master. The vendor may be obligated to furnish up to a specified number of copies of the software, but only if the copies are requested by the user. The licensing fee is payable even if no additional copies are requested by the user or reseller. If the other criteria in this SOP for revenue recognition are met, revenue should be recognized upon delivery of the first copy or product master. The estimated costs of duplication should be accrued at that time. In the latter kind of arrangement, the licensing fee is a function of the number of copies delivered to, made by, or deployed by the user or reseller. Delivery occurs and revenue should be recognized as the copies are made by the user or sold by the reseller if the other criteria in this SOP for revenue recognition are met. Software Revenue Recognition A-6

Delivery Other Than to the Customer.22 Delivery should not be considered complete unless the destination to which the software is shipped is the customer s place of business or another site specified by the customer. In addition, if a customer specifies an intermediate site but a substantial portion of the fee is not payable until the delivery by the vendor to another site specified by the customer, revenue should not be recognized until the delivery is made to that other site. Delivery Agents.23 Vendors may engage agents, often referred to as fulfillment houses, to either duplicate and deliver or only deliver software products to customers. Revenue from transactions involving delivery agents should be recognized when the software is delivered to the customer. Transferring the fulfillment obligation to an agent of the vendor does not relieve the vendor of the responsibility for delivery. This is the case even if the vendor has no direct involvement in the actual delivery of the software product to the customer. Authorization Codes.24 In a number of software arrangements, vendors use authorization codes, commonly referred to as keys, to permit customer access to software that otherwise would be restricted. Keys are used in a variety of ways and may serve different purposes. For example, permanent keys may be used to control access to the software, or additional permanent keys may be necessary for the duplication of the software. Temporary keys may be used for the same purposes and also may be used to enhance the vendor s ability to collect payment or to control the use of software for demonstration purposes..25 In software arrangements involving the use of keys, delivery of a key is not necessarily required to satisfy the vendor s delivery responsibility. The software vendor should recognize revenue on delivery of the software if all other requirements for revenue recognition under this SOP and all of the following conditions are met. The customer has licensed the software and the vendor has delivered a version of the software that is fully functional except for the permanent key or the additional keys (if additional keys are used to control the reproduction of the software). The customer s obligation to pay for the software and the terms of payment, including the timing of payment, are not contingent on delivery of the permanent key or additional keys (if additional keys are used to control the reproduction of the software). The vendor will enforce and does not have a history of failing to enforce its right to collect payment under the terms of the original arrangement. In addition, if a temporary key is used to enhance the vendor s ability to collect payment, the delivery of additional keys, whether temporary or permanent, is not required to satisfy the vendor s delivery responsibility if (a) the above conditions are met and (b) the use of a temporary key in such circumstances is a customary practice of the vendor. Selective issuance of temporary keys might indicate that collectibility is not probable or that the software is being used only for demonstration purposes. Fixed or Determinable Fees and Collectibility.26 The other prerequisites in paragraph.08 for revenue recognition are that (a) the vendor s fee is fixed or determinable and (b) collectibility is probable. A software licensing fee is not fixed or determinable if the amount is based on the number of units distributed or copied, or the expected number of users of the product. Revenue recognition for variable-pricing arrangements is discussed in paragraphs.43 through.47 of this SOP. Additionally, if an arrangement includes (a) rights of return or (b) rights to refunds without return of the software, FASB Statement No. 48 requires that conditions that must be met in order for the vendor to recognize revenue include that the amount of future returns or refunds can be reasonably estimated. Software Revenue Recognition A-7

Factors That Affect the Determination of Whether a Fee is Fixed or Determinable and Collectible.27 A number of arrangements that call for fixed or determinable payments, including minimum royalties or license fees from resellers, specify a payment period that is short in relation to the period during which the customer is expected to use or market the related products. Other arrangements have payment terms that extend over a substantial portion of the period during which the customer is expected to use or market the related products. Because a product s continuing value may be reduced due to the subsequent introduction of enhanced products by the vendor or its competitors, the possibility that the vendor still may provide a refund or concession to a creditworthy customer to liquidate outstanding amounts due under the original terms of the arrangement increases as payment terms become longer..28 For the reason cited in paragraph.27 any extended payment terms in a software licensing arrangement may indicate that the fee is not fixed or determinable. Further, if payment of a significant portion of the software licensing fee is not due until after expiration of the license or more than twelve months after delivery, the licensing fee should be presumed not to be fixed or determinable. However, this presumption may be overcome by evidence that the vendor has a standard business practice of using long-term or installment contracts and a history of successfully collecting under the original payment terms without making concessions. In such a situation, a vendor should consider such fees fixed or determinable and should recognize revenue upon delivery of the software, provided all other conditions for revenue recognition in this SOP have been satisfied..29 If it cannot be concluded that a fee is fixed or determinable at the outset of an arrangement, revenue should be recognized as payments from customers become due (assuming all other conditions for revenue recognition in this SOP have been satisfied)..30 For reseller arrangements, the following factors also should be considered in evaluating whether the fixed or determinable fee and collectibility criteria for revenue recognition are met. Business practices, the reseller s operating history, competitive pressures, informal communications, or other factors indicate that payment is substantially contingent on the reseller s success in distributing individual units of the product. fn 7 Resellers are new, undercapitalized, or in financial difficulty and may not demonstrate an ability to honor a commitment to make fixed or determinable payments until they collect cash from their customers. Uncertainties about the potential number of copies to be sold by the reseller may indicate that the amount of future returns cannot be reasonably estimated on delivery; examples of such factors include the newness of the product or marketing channel, competitive products, or dependence on the market potential of another product offered (or anticipated to be offered) by the reseller. Distribution arrangements with resellers require the vendor to rebate or credit a portion of the original fee if the vendor subsequently reduces its price for a product and the reseller still has rights with respect to that product (sometimes referred to as price protection). If a vendor is unable to reasonably estimate future price changes in light of competitive conditions, or if significant uncertainties exist about the vendor s ability to maintain its price, the arrangement fee is not fixed or determinable. In such circumstances, revenue from the arrangement should be deferred until the vendor is able to reasonably estimate the effects of future price changes and the other conditions of this SOP have been satisfied. Software Revenue Recognition A-8

.31 Customer Cancellation Privileges. Fees from licenses cancelable by customers are neither fixed nor determinable until the cancellation privileges lapse. Fees from licenses with cancellation privileges expiring ratably over the license period are considered to become determinable ratably over the license period as the cancellation privileges lapse. In applying the provisions of this paragraph, obligations related to warranties for defective software, including warranties that are routine, short-term, and relatively minor, should be accounted for in conformity with FASB Statement No. 5. Additionally, short-term rights of return, such as thirty-day money-back guarantees, should not be considered cancellation privileges; the related returns should be accounted for in conformity with FASB Statement No. 48..32 Fiscal Funding Clauses. Fiscal funding clauses sometimes are found in software license arrangements in which the licensees are governmental units. Such clauses generally provide that the license is cancelable if the legislature or funding authority does not appropriate the funds necessary for the governmental unit to fulfill its obligations under the licensing arrangement..33 Consistent with FASB Technical Bulletin No. 79-10, Fiscal Funding Clauses in Lease Agreements, a software licensing arrangement with a governmental unit containing a fiscal funding clause should be evaluated to determine whether the uncertainty of a possible license arrangement cancellation is a remote contingency.fn8 If the likelihood is assessed as remote, the software licensing arrangement should be considered noncancelable. Such an assessment should include the factors discussed in paragraphs.27 and.28 of this SOP. If the likelihood is assessed as other than remote, the license should be considered cancelable, thus precluding revenue recognition. A fiscal funding clause with a customer other than a governmental unit that is required to include such a clause creates a contingency that precludes revenue recognition until the requirements of the clause and all other provisions of this SOP have been satisfied. Multiple-Element Arrangements.34 As discussed in paragraph.09, multiple-element arrangements to which contract accounting does not apply may include customer rights to any combination of additional software deliverables, services, or PCS. If contract accounting does not apply, individual elements in such arrangements should be accounted for in accordance with paragraphs.08 through.14. Paragraphs.35 through.73 provide guidance on the application of those paragraphs to multipleelement arrangements. Additional Software Deliverables and Rights to Exchange or Return Software.35 As part of a multiple-element arrangement, a vendor may agree to deliver software currently and to deliver additional software in the future. The additional deliverables may include upgrades/enhancements or additional software products. Additionally, a vendor may provide the customer with the right to exchange or return software, including the right to transfer software from one hardware platform or operating system to one or more other platforms or operating systems (a platform-transfer right)..36 Upgrades/enhancements. As part of a multiple-element arrangement, a vendor may agree to deliver software currently and provide the customer with an upgrade right for a specified upgrade/enhancement. The upgrade right may be evidenced by a specific agreement, commitment, or the vendor s established practice. (Rights to receive unspecified upgrades/enhancements on a when-and-if-available basis are PCS, as it has been redefined in this SOP.) The upgrade right should be accounted for as a separate element in accordance with paragraphs.08 through.14. Guidance on the application of those paragraphs to multiple-element software arrangements that include upgrade rights is given in paragraphs.37 and.38. Software Revenue Recognition A-9

.37 If a multiple-element arrangement includes an upgrade right, the fee should be allocated between the elements based on vendor-specific objective evidence of fair value. The fee allocated to the upgrade right is the price for the upgrade/enhancement that would be charged to existing users of the software product being updated. If the upgrade right is included in a multipleelement arrangement on which a discount has been offered (see paragraph.11), no portion of the discount should be allocated to the upgrade right. If sufficient vendor-specific evidence exists to reasonably estimate the percentage of customers that are not expected to exercise the upgrade right, the fee allocated to the upgrade right should be reduced to reflect that percentage. This estimated percentage should be reviewed periodically. The effect of any change in that percentage should be accounted for as a change in accounting estimate..38 The amount of the fee allocated to the upgrade right should be recognized as revenue when the conditions in paragraphs.08 through.14 are met. If sufficient vendor-specific objective evidence does not exist for the allocation of the fee to the upgrade right, revenue from the arrangement should be deferred until the earlier of the point at which (a) such sufficient vendorspecific objective evidence does exist or (b) all elements of the arrangement have been delivered..39 Additional Software Products. As part of a multiple-element arrangement, a vendor may agree to deliver software currently and deliver specified additional software products in the future. The rights to these additional products may be included either in the terms of a PCS arrangement or in a separate agreement. Even if the rights to the additional software products are included in a PCS arrangement, the revenue allocable to the additional software products should be accounted for separately from the PCS arrangement as an element of a multiple-element arrangement..40 Multiple-element arrangements that include rights to undelivered additional software products that are not subscriptions (see paragraphs.48 and.49) should be accounted for in accordance with paragraphs.08 through.14 of this SOP. Guidance on the application of those paragraphs to such arrangements is provided in paragraphs.41 through.47 below..41 The fee from the arrangement should be allocated among the products based on vendorspecific objective evidence of fair value. The allocation should be based on the relative sales prices (determined pursuant to paragraphs.10 and.11 of this SOP) of the products. If vendorspecific objective evidence of fair value does not exist, paragraph.12 of this SOP requires that all revenue from the arrangement be deferred until the earlier of the point at which (a) such sufficient vendor-specific objective evidence does exist or (b) all elements of the arrangement have been delivered. The fee allocated to the additional software products should not be reduced by the percentage of any customers that are not expected to exercise the right to receive additional software products..42 If the arrangement is based on a price per product (not a price per copy), the portion of the fee allocated to a product should be recognized as revenue when the product is delivered, assuming all other provisions of paragraphs.08 through.14 of this SOP are met..43 Some fixed fee license or reseller arrangements provide customers with the right to reproduce or obtain copies at a specified price per copy (rather than per product) of two or more software products up to the total amount of the fixed fee. A number of the products covered by the arrangement may not be deliverable or specified at the inception of the arrangement. Although the price per copy is fixed at the inception of the arrangement, an allocation of the arrangement fee to the individual products generally cannot be made, because the total revenue allocable to each software product is unknown and depends on the choices to be made by the customer and, sometimes, future development activity while the arrangement is in effect. Nevertheless, as discussed in paragraph.46 of this SOP, in certain situations, revenue can be allocated to the products that are undeliverable or not specified at the inception of the arrangement. Software Revenue Recognition A-10

.44 In arrangements in which no allocation can be made, until the first copy or product master of each product covered by the arrangement has been delivered to the customer assuming the provisions of paragraphs.08 through.14 of this SOP are met, revenue should be recognized as copies of delivered products either (a) are reproduced by the customer or (b) are furnished to the customer if the vendor is duplicating the software. Once the vendor has delivered the product master or the first copy of all products covered by the arrangement, any licensing fees not previously recognized should be recognized. (At that point, only duplication of the software is required to satisfy the vendor s delivery requirement. As discussed in paragraph.21 of this SOP, duplication of the software is incidental to the arrangement, and delivery is deemed to have occurred upon delivery of the product master or first copy.) When the arrangement terminates, the vendor should recognize any licensing fees not previously recognized..45 The revenue from the kind of arrangements discussed in paragraph.44 should not be recognized fully until at least one of the following conditions is met. Delivery is complete for all products covered by the arrangement. The aggregate revenue attributable to all copies of the software products delivered is equal to the fixed fee, provided that the vendor is not obligated to deliver additional software products under the arrangement..46 Nevertheless, certain arrangements that include products that are not deliverable at the inception impose a maximum number of copies of the undeliverable product(s) to which the customer is entitled. In such arrangements, a portion of the arrangement fee should be allocated to the undeliverable product(s). This allocation should be made assuming that the customer will elect to receive the maximum number of copies of the undeliverable product(s)..47 The revenue allocated to the delivered products should be recognized when the product master or first copy is delivered. If, during the term of the arrangement, the customer reproduces or receives enough copies of these delivered products so that revenue allocable to the delivered products exceeds the revenue previously recognized, such additional revenue should be recognized as the copies are reproduced or delivered. The revenue allocated to the undeliverable product(s) should be reduced by a corresponding amount..48 As part of a multiple-element arrangement with a user, a vendor may agree to deliver software currently and to deliver unspecified additional software products in the future (including unspecified platform transfer rights that do not qualify for exchange accounting as described in paragraphs.50 through.55). For example, the vendor may agree to deliver all new products to be introduced in a family of products over the next two years. These arrangements are similar to arrangements that include PCS in that future deliverables are unspecified. Nevertheless, they are distinguished from arrangements that include PCS because the future deliverables are products, not unspecified upgrades/enhancements..49 The software elements of the kinds of arrangements discussed in paragraph.48 should be accounted for as subscriptions. No allocation of revenue should be made among any of the software products, and all software product-related revenue from the arrangement should be recognized ratably over the term of the arrangement beginning with delivery of the first product. If the term of the arrangement is not stated, the revenue should be recognized ratably over the estimated economic life of the products covered by the arrangement, beginning with delivery of the first product. An intent on the part of the vendor not to develop new products during the term of the arrangement does not relieve the vendor of the requirement to recognize revenue ratably over the term of the arrangement, beginning with the delivery of the first product. Software Revenue Recognition A-11

.50 Rights to Exchange or Return Software. As part of an arrangement, a software vendor may provide the customer with the right to return software or to exchange software for products with no more than minimal differences in price, functionality, or features. The accounting for returns is significantly different from the accounting for exchanges. Although it is sometimes difficult to determine whether a transaction is a return or exchange of software, the fact that the software is not returned physically does not preclude accounting for the transaction as either an exchange or as a return. If the software is not returned physically and the customer contractually is entitled to continue to use the previously delivered software, the arrangement should be accounted for in the manner prescribed in the section herein entitled Additional Software Products (see paragraphs.39 through.49). If the software is not returned physically and the customer contractually is not entitled to continue to use the previously delivered software, the transaction should be accounted for either as a return or as an exchange, as discussed in the following paragraphs..51 If the rights discussed in the previous paragraph are offered to users (but not resellers), the exchanges are analogous to exchanges by ultimate customers of one item for another of the same kind, quality, and price... [that] are not considered returns described in footnote 3 of FASB Statement No. 48. Conversely, exchanges by users of software products for dissimilar software products or for similar software products with more than minimal differences in price, functionality, or features are considered returns, and revenue related to arrangements that provide users with the rights to make such exchanges should be accounted for in conformity with FASB Statement No. 48. If the other product(s) is not available at the time the initial product is delivered, there should be persuasive evidence that demonstrates there will be no more than minimal differences in price, features, or functionality among the products in order for the right to qualify as a right to exchange. Additionally, if the vendor expects to incur a significant amount of development costs related to the other product, the other product should be considered to have more than a minimal difference in functionality..52 As part of a multiple-element arrangement, a vendor may grant a user a platform-transfer right. Depending on the circumstances, the exercise of a platform-transfer right may represent an exchange, a return, or additional software products for accounting purposes. If the customer contractually is entitled to continue to use the software that was delivered originally (in addition to the software that is to be delivered for the new platform), the platform transfer right should be accounted for in the manner prescribed in the section herein entitled Additional Software Products (see paragraphs.39 through.49)..53 If, as part of a multiple-element arrangement, a vendor offers a user (not a reseller) a platform-transfer right, and the provisions of paragraphs.08 through.14 of this SOP are met, the revenue from the software license should be recognized upon the initial delivery of the software, and the exercise of the platform-transfer right should be treated as an exchange, if the platformtransfer right: Is for the same product (see paragraph.54); and Does not increase the number of copies or concurrent users of the software product available under the license arrangement..54 Products are considered to be the same product if there are no more than minimal differences among them in price, features, and functions, and if they are marketed as the same product, even though there may be differences arising from environmental variables such as operating systems, databases, user interfaces, and platform scales. Indicators of marketed as the same product include (a) the same product name (although version numbers may differ) and (b) a focus on the same features and functions. Software Revenue Recognition A-12

.55 As part of their standard sales terms or as a matter of practice, vendors may grant resellers the rights to exchange unsold software for other software (including software that runs on a different hardware platform or operating system). Because the reseller is not the ultimate customer (see paragraph.51), such exchanges, including those referred to as stock balancing arrangements, should be accounted for as returns. Arrangements that grant rights to make such exchanges should be accounted for in conformity with FASB Statement No. 48, even if the vendors require the resellers to purchase additional software to exercise the exchange rights. Postcontract Customer Support.56 Software arrangements may include the right to PCS. PCS includes the right to receive PCS services or unspecified upgrades/enhancements, or both, offered to users or resellers. A vendor may develop historical patterns of regularly providing all customers or certain kinds of customers with the services or unspecified upgrades/enhancements normally associated with PCS, or may anticipate doing so, even though there is no written contractual obligation or the stipulated PCS term commences at some date after delivery. In those situations, an implied PCS arrangement exists that commences upon product delivery. For purposes of applying the guidance in this SOP, PCS includes a vendor s expected performance based on such patterns, even if performance is entirely at the vendor s discretion and not pursuant to a formal agreement..57 If a multiple-element software arrangement includes explicit or implicit rights to PCS, the total fees from the arrangement should be allocated among the elements based on vendor-specific objective evidence of fair value, in conformity with paragraph.10. The fair value of the PCS should be determined by reference to the price the customer will be required to pay when it is sold separately (that is, the renewal rate). The portion of the fee allocated to PCS should be recognized as revenue ratably over the term of the PCS arrangement, because the PCS services are assumed to be provided ratably. However, revenue should be recognized over the period of the PCS arrangement in proportion to the amounts expected to be charged to expense for the PCS services rendered during the period if: Sufficient vendor-specific historical evidence exists demonstrating that costs to provide PCS are incurred on other than a straight-line basis. In making this determination, the vendor should take into consideration allocated portions of cost accounted for as research and development (R&D) costs and the amortization of costs related to the upgrade-enhancement capitalized in conformity with FASB Statement No. 86, Accounting for the Costs of Computer Software to Be Sold, Leased, or Otherwise Marketed. Such costs should be considered as part of the costs to provide PCS. The vendor believes that it is probable that the costs incurred in performing under the current arrangement will follow a similar pattern. Because the timing, frequency, and significance of unspecified upgrades/enhancements can vary considerably, the point at which unspecified upgrades/enhancements are expected to be delivered should not be used to support income recognition on other than a straight-line basis..58 If sufficient vendor-specific objective evidence does not exist to allocate the fee to the separate elements and the only undelivered element is PCS, the entire arrangement fee should be recognized ratably over (a) the contractual PCS period (for those arrangements with explicit rights to PCS) or (b) the period during which PCS is expected to be provided (for those arrangements with implicit rights to PCS)..59 PCS revenue may be recognized together with the initial licensing fee on delivery of the software if all of the following conditions are met. a. The PCS fee is included with the initial licensing fee. b. The PCS included with the initial license is for one year or less. c. The estimated cost of providing PCS during the arrangement is insignificant. d. Unspecified upgrades/enhancements offered during PCS arrangements historically have been and are expected to continue to be minimal and infrequent. Software Revenue Recognition A-13

If PCS revenue is recognized upon the delivery of the software, the vendor must accrue all estimated costs of providing the services, including upgrades/enhancements. Upgrades/ enhancements are not developed solely for distribution to PCS customers; revenues are expected to be earned from providing the enhancements to other customers as well. Therefore, costs should be allocated between PCS arrangements and other licenses..60 A determination that unspecified upgrades/enhancements offered during the PCS arrangement are expected to be minimal and infrequent should be evidenced by the patterns of minimal and infrequent unspecified upgrades/enhancements offered in previous PCS arrangements. A conclusion that unspecified upgrades/enhancements are expected to be minimal and infrequent should not be reached simply because unspecified upgrades/enhancements have been or are expected to be offered less frequently than on an annual basis. Regardless of the vendor s history of offering unspecified upgrades/enhancements to initial licensees, PCS should be accounted for separately from the initial licensing fee if the vendor expects to offer upgrades/enhancements that are greater than minimal or more than infrequent to the users or resellers of the licensed software during the PCS arrangement..61 Postdelivery Telephone Support at No Additional Charge. Postdelivery telephone support provided to users by the vendor at no additional charge should be accounted for as PCS, in conformity with this SOP, regardless of whether the support is provided explicitly under the licensing arrangement. Although such telephone support may be offered or available for periods exceeding one year, if the vendor has established a history of providing substantially all the telephone support within one year of the licensing or sale of the software, the PCS may be considered to have a term of one year or less in applying paragraph.59, item (b) of this SOP. Accordingly, revenue allocable to telephone support may be recognized together with the initial licensing fee on delivery of the software if all the conditions in paragraph.59 of this SOP are met. This provision applies only to telephone support provided at no additional charge. If revenue allocable to telephone support is recognized together with the licensing fee on delivery, the vendor should accrue the estimated cost of providing that support..62 PCS Granted by Resellers. An arrangement in which a vendor grants a reseller the right to provide unspecified upgrades/enhancements to the reseller s customers is an implied PCS arrangement between the vendor and the reseller, even if the vendor does not provide direct telephone support to the reseller s customers. If sufficient vendor-specific objective evidence does not exist to allocate the fee to the software and the PCS, revenue from both the licensing arrangement and the PCS should be recognized ratably over the period during which PCS is expected to be provided. Services.63 Certain arrangements include both software and service elements (other than PCS-related services). The services may include training, installation, or consulting. Consulting services often include implementation support, software design or development, or the customization or modification of the licensed software..64 If an arrangement includes such services, a determination must be made as to whether the service element can be accounted for separately as the services are performed. Paragraph.65 discusses the criteria that must be considered in making such a determination. If the nature of the services is such that the service element does not qualify for separate accounting as a service, contract accounting must be applied to both the software and service elements included in the arrangement. Paragraphs.74 through.91 of this SOP address the application of contract accounting to software arrangements. Software Revenue Recognition A-14

.65 In order to account separately for the service element of an arrangement that includes both software and services, sufficient vendor-specific objective evidence of fair value must exist to permit allocation of the revenue to the various elements of the arrangement (as discussed in paragraphs.10 and.12). Additionally, the services (a) must not be essential to the functionality of any other element of the transaction and (b) must be described in the contract such that the total price of the arrangement would be expected to vary as the result of the inclusion or exclusion of the services..66 If an arrangement includes services that meet the criteria of paragraph.65 for separate accounting, revenue should be allocated among the service and software elements of the contract. This allocation should be based on vendor-specific objective evidence of fair values. (Fair values are not necessarily the same as any separate prices stated for the separate elements of the arrangement.) Revenue allocated to the service element should be recognized as the services are performed or, if no pattern of performance is discernible, on a straight-line basis over the period during which the services are performed..67 If vendor-specific objective evidence of the fair value does not exist to allocate a portion of the fee to the service element, and the only undelivered element is services that do not involve significant production, modification, or customization of the software (for example, training or installation), the entire arrangement fee should be recognized as the services are performed. If no pattern of performance is discernible, the entire arrangement fee should be recognized on a straight-line basis over the period during which the services are performed..68 An important factor to consider in determining whether the services are essential to the functionality of any other element is whether the software included in the arrangement is considered core or off-the-shelf software. Core software is software that a vendor uses in creating other software. It is not sold as is because customers cannot use it unless it is customized to meet system objectives or customer specifications. Off-the-shelf software is software that is marketed as a stock item that can be used by customers with little or no customization..69 Software should be considered off-the-shelf software if it can be added to an arrangement with insignificant changes in the underlying code and it could be used by the customer for the customer s purposes upon installation. Actual use by the customer and performance of other elements of the arrangement is not required to demonstrate that the customer could use the software off-the-shelf. If significant modifications or additions to the off-the-shelf software are necessary to meet the customer s purpose (for example, changing or making additions to the software, or because it would not be usable in its off-the-shelf form in the customer s environment), the software should be considered core software for purposes of that arrangement. If the software that is included in the arrangement is not considered to be off-the-shelf software, or if significant modifications or additions to the off-the-shelf software are necessary to meet the customer s functionality, no element of the arrangement would qualify for accounting as a service, and contract accounting should be applied to both the software and service elements of the arrangement..70 Factors indicating that the service element is essential to the functionality of the other elements of the arrangement, and consequently should not be accounted for separately, include the following. The software is not off-the-shelf software. The services include significant alterations to the features and functionality of the off-theshelf software. Building complex interfaces is necessary for the vendor s software to be functional in the customer s environment. The timing of payments for the software is coincident with performance of the services. Milestones or customer-specific acceptance criteria affect the realizability of the softwarelicense fee. Software Revenue Recognition A-15

.71 Judgment is required in determining whether the obligation to provide services in addition to the delivery of software should be accounted for separately as a service element. Services that qualify for accounting as a service element of a software arrangement always are stated separately and have one or more of the following characteristics. The services are available from other vendors. The services do not carry a significant degree of risk or unique acceptance criteria. The software vendor is an experienced provider of the services. The vendor is providing primarily implementation services, such as implementation planning, loading of software, training of customer personnel, data conversion, building simple interfaces, running test data, and assisting in the development and documentation of procedures. Customer personnel are dedicated to participate in the services being performed..72 Funded Software-Development Arrangements. Software-development arrangements that are fully or partially funded by a party other than the vendor that is developing the software typically provide the funding party with some or all of the following benefits: Royalties payable to the funding party based solely on future sales of the product by the software vendor (that is, reverse royalties); Discounts on future purchases by the funding party of products produced under the arrangement; and A nonexclusive sublicense to the funding party, at no additional charge, for the use of any product developed (a prepaid or paid-up nonexclusive sublicense)..73 A funded software-development arrangement within the scope of FASB Statement No. 68, Research and Development Arrangements, should be accounted for in conformity with that Statement. If the technological feasibility of the computer software product pursuant to the provisions of FASB Statement No. 86 has been established before the arrangement has been entered into, FASB Statement No. 68 does not apply because the arrangement is not a research and development arrangement. Accounting for costs related to funded software-development arrangements is beyond the scope of this SOP. However, if capitalization of the softwaredevelopment costs commences pursuant to FASB Statement No. 86, any income from the funding party under a funded software-development arrangement should be credited first to the amount of the development costs capitalized. If the income from the funding party exceeds the amount of development costs capitalized, the excess should be deferred and credited against future amounts that subsequently qualify for capitalization. Any deferred amount remaining after the project is completed (that is, when the software is available for general release to customers and capitalization has ceased) should be credited to income. Contract Accounting.74 If an arrangement to deliver software or a software system, either alone or together with other products or services, requires significant production, modification, or customization of software, the service element does not meet the criteria for separate accounting set forth in paragraph.65. The entire arrangement should be accounted for in conformity with ARB No. 45, using the relevant guidance in SOP 81-1 [section 10,330]. Nevertheless, transactions that normally are accounted for as product sales should not be accounted for as long-term contracts merely to avoid the delivery requirements normally associated with product sales for revenue recognition..75 In applying contract accounting, the vendor must use either the percentage-of-completion method or the completed-contract method. The determination of the appropriate method should be made according to the recommendations in paragraphs 21 through 33 of SOP 81-1 [section 10,330.21 through.33]. Software Revenue Recognition A-16

.76 Segmentation. Software contracts may have discrete elements that meet the criteria for segmenting in paragraphs 39 through 42 of SOP 81-1 [section 10,330.39 through.42]. If a contract is segmented, each segment is treated as a separate profit center. Progress-tocompletion for each segment should be measured in conformity with paragraphs.78 through.80 of this SOP..77 Some vendors of arrangements that include software combined with services or hardware or both do not identify the elements separately and do not sell them separately because of agreements with their suppliers. Other vendors who are not restricted by such agreements nevertheless bid or negotiate software and other products and services together. Arrangements that do not meet the segmentation criteria in paragraph 40 of SOP 81-1 [section 10,330.40] are prohibited from being segmented, unless the vendor has a history of providing the software and other products and services to customers under separate arrangements and the arrangement meets the criteria in paragraph 41 of SOP 81-1 [section 10,330.41]..78 Measuring Progress-to-Completion Under the Percentage-of-Completion Method. Paragraph 46 of SOP 81-1 [section 10,330.46] describes the approaches to measuring progress on contracts (or segments thereof) under the percentage-of-completion method. Those approaches are grouped into input and output measures, as follows: Input measures are made in terms of efforts devoted to a contract. They include the methods based on costs and on efforts expended. Output measures are made in terms of results achieved. They include methods based on units produced, units delivered, contract milestones, and value-added. For contracts under which separate units of output are produced, progress can be measured on the basis of units of work completed. For software contracts, an example of an input measure is labor hours; an example of an output measure is arrangement milestones, such as the completion of specific program modules..79 If, as discussed in paragraph.76 of this SOP, a software contract includes a discrete element that meets the segmentation criteria of SOP 81-1 [section 10,330], the method chosen to measure progress-to-completion on the element should be the method that best approximates progress-to-completion. Progress-to-completion on separate elements of the same software arrangement may be measured by different methods. The software vendor should choose measurement methods consistently, however, so that it uses similar methods to measure progress-to-completion on similar elements..80 Output measures, such as value-added or arrangement milestones, may be used to measure progress-to-completion on software arrangements, but many companies use input measures because they are established more easily. As noted in paragraph 47 of SOP 81-1 [section 10,330.47], The use of either type of measure requires the exercise of judgment and the careful tailoring of the measure to the circumstances. Further, paragraph 51 of SOP 81-1 [section 10,330.51] states that: The acceptability of the results of input or output measures deemed to be appropriate to the circumstances should be periodically reviewed and confirmed by alternative measures that involve observation and inspection. For example, the results provided by the measure used to determine the extent of progress may be compared to the results of calculations based on physical observations by engineers, architects, or similarly qualified personnel. That type of review provides assurance somewhat similar to that provided for perpetual inventory records by periodic physical inventory counts..81 Input Measures. Input measures of progress-to-completion on arrangements are made in terms of efforts devoted to the arrangement and, for software arrangements, include methods based on costs, such as cost-to-cost measures, and on efforts expended, such as labor hours or labor dollars. Progress-to-completion is measured indirectly, based on an established or assumed relationship between units of input and productivity. A major advantage of input measures is that Software Revenue Recognition A-17

inputs expended are easily verifiable. A major disadvantage is that their relationship to progressto-completion may not hold if inefficiencies exist or if the incurrence of the input at a particular point does not indicate progress-to-completion..82 Costs incurred should be included in measuring progress-to-completion only to the extent that they relate to contract performance. Items not specifically produced for the arrangement, such as hardware purchased from third parties or off-the-shelf software, should not be included in the measurement of progress-to-completion..83 Labor hours often are chosen as the basis for measuring progress-to-completion, because they closely approximate the output of labor-intensive processes and often are established more easily than output measures. Core software requires labor-intensive customization. Therefore, labor hours provide a good measure of progress-to-completion on elements of software arrangements that involve the customization of core software..84 If the measurement of progress-to-completion is based primarily on costs, the contribution to that progress of hardware and software that were produced specifically for the arrangement may be measurable and recognizable before delivery to the user s site. For example, efforts to install, configure, and customize the software may occur at the vendor s site. The costs of such activities are measurable and recognizable at the time the activities are performed..85 Output Measures. Progress on arrangements that call for the production of identifiable units of output can be measured in terms of the value-added or milestones reached. Although progressto-completion based on output measures is measured directly from results achieved, thus providing a better approximation of progress than is provided by input measures, output measures may be somewhat unreliable because of the difficulties associated with establishing them..86 In order for the value-added to be verifiable, the vendor must identify elements or subcomponents of those elements. If output measures are neither known nor reasonably estimable, they should not be used to measure progress-to-completion..87 If value-added by off-the-shelf software is to be included in the measurement of progress-tocompletion, such software cannot require more than minor modifications and must be usable by the customer for the customer s purpose in the customer s environment. If more than minor modifications or additions to the off-the-shelf software are necessary to meet the functionality required under the arrangement terms, either by changing or making additions to the software, or because the software would not be usable by the customer in its off-the-shelf form for the customer s purpose in the customer s environment, it should be accounted for as core software..88 Value-added by the customization of core software should be included in the measurement of progress-to-completion of the customization and installation at the user s site. However, if the installation and customization processes are divided into separate output modules, the value of core software associated with the customization of a module should be included in the measurement of progress-to-completion when that module is completed..89 Contract milestones may be based on contractual project plans. Contractual provisions generally require the performance of specific tasks with the approval or acceptance by the customer; project plans generally schedule inspections in which the project s status is reviewed and approved by management. The completion of tasks that trigger such inspections are natural milestones because they are subject to relatively independent review as an intrinsic part of the project management process. Software Revenue Recognition A-18

.90 Considerations other than progress-to-completion affect the amounts that become billable at particular times under many arrangements. Accordingly, although the achievement of contract milestones may cause arrangement revenues to become billable under the arrangement, the amounts billable should be used to measure progress-to-completion only if such amounts indeed indicate such progress..91 The milestones that are selected to measure progress-to-completion should be part of the management review process. The percentage-of-completion designated for each milestone should be determined considering the experience of the vendor on similar projects. Effective Date and Transition.92 This SOP is effective for transactions entered into in fiscal years beginning after December 15, 1997. Earlier application is encouraged as of the beginning of fiscal years or interim periods for which financial statements or information have not been issued. Retroactive application of the provisions of this SOP is prohibited. [Note: An effective date provision of this SOP has been deferred by SOP 98-4. See section 10,740.]. The provisions of this Statement need not be applied to immaterial items. Background Basis for Conclusions.93 SOP 91-1 was issued in December 1991. AcSEC understands that certain provisions of that Statement are being applied inconsistently in practice and that various practice issues have arisen that were not addressed in SOP 91-1. As a result, AcSEC added a project to its agenda in March 1993 to interpret those provisions and provide additional guidance. The key issues identified at the outset of the project related to accounting for arrangements that provided for multiple deliverables (including PCS). The project began as an amendment to SOP 91-1. However, as deliberations progressed, AcSEC determined that it would be more appropriate to supersede SOP 91-1 to (a) amend the provisions in question and (b) incorporate AcSEC s conclusions on practice issues that had not been addressed in SOP 91-1. Basic Principles.94 Transfers of rights to software by licenses rather than by outright sales protect vendors from the unauthorized duplication of their products. Nevertheless, the rights transferred under software licenses are substantially the same as those expected to be transferred in sales of other kinds of products. AcSEC believes the legal distinction between a license and a sale should not cause revenue recognition on software products to differ from revenue recognition on the sale of other kinds of products..95 Arrangements to deliver software or a software system, either alone or together with other products, may include services. AcSEC believes that if those services entail significant production, modification, or customization of the software, such software before those alterations (even if already delivered) is not the product that has been purchased by the customer. Instead, the product purchased by the customer is the software that will result from the alterations. Accordingly, AcSEC concluded that arrangements that include services that entail significant production, modification, or customization of software are construction-type or production-type contracts, and should be accounted for in conformity with ARB No. 45 and SOP 81-1 [10,330]. AcSEC concluded that if the services do not entail significant production, modification, or customization of software, the service element should be accounted for as a separate element. Software Revenue Recognition A-19

.96 AcSEC believes that revenue generally should not be recognized until the element has been delivered. The recognition of revenue from product sales on delivery is consistent with paragraphs 83(b) and 84 of FASB Concepts Statement No. 5, Recognition and Measurement in Financial Statements of Business Enterprises. Paragraph 83(b) provides the following guidance for recognition of revenues: Revenues are not recognized until earned. An entity s revenue-earning activities involve delivering or producing goods, rendering services, or other activities that constitute its ongoing major or central operations, and revenues are considered to have been earned when the entity has substantially accomplished what it must do to be entitled to the benefits represented by the revenues. [Footnote omitted][emphasis added] Paragraph 84 states that in recognizing revenues and gains: [t]he two conditions [for revenue recognition] (being realized or realizable and being earned) are usually met by the time the product or merchandise is delivered...to customers, and revenues...are commonly recognized at time of sale (usually meaning delivery). [Emphasis added].97 SOP 91-1 did not address arrangements that included software that was deliverable only when-and-if-available. Implementation questions arose as to whether when-and-if-available terms created contingencies that could be disregarded in determining whether an arrangement consists of multiple elements. AcSEC believes that because the when-and-if-available deliverables are bargained for in arrangements, they are of value to the customer. Accordingly, AcSEC concluded that when-and-if-available deliverables should be considered in determining whether an arrangement consists of multiple elements. Thus, the requirements of this SOP with respect to arrangements that consist of multiple elements should be applied to all additional products and services specified in the arrangement, including those described as being deliverable only whenand-if-available..98 In SOP 91-1, the accounting for vendor obligations remaining after delivery of the software was dependent upon whether the obligation was significant or insignificant. However, these determinations were not being made in a consistent manner, leading to a diversity in practice. AcSEC believes that all obligations should be accounted for and that revenue from an arrangement should be allocated to each element of the arrangement, based on vendor-specific objective evidence of the fair values of the elements. Further, AcSEC concluded that revenue related to a particular element should not be recognized until the revenue recognition conditions in paragraphs.08 through.14 of this SOP are met, because the earnings process related to that particular element is not considered complete until that time..99 In paragraph.10 of this SOP, AcSEC concluded that the revenue from an arrangement should be allocated to the separate elements based on vendor-specific objective evidence of fair value, regardless of any separate prices stated in the contract for each element. AcSEC believes that separate prices stated in a contract may not represent fair value and, accordingly, might result in an unreasonable allocation of revenue. AcSEC believes that basing the allocation on fair values is consistent with the accounting for commingled revenue. An example is the following discussion in paragraph 12 of FASB Statement No. 45, Accounting for Franchise Fee Revenue: The franchise agreement ordinarily establishes a single initial franchise fee as consideration for the franchise rights and the initial services to be performed by the franchisor. Sometimes, however, the fee also may cover tangible property, such as signs, equipment, inventory, and land and building. In those circumstances, the portion of the fee applicable to the tangible assets shall be based on the fair value of the assets. Software Revenue Recognition A-20

.100 AcSEC considered allowing the use of surrogate prices such as competitor prices for similar products or industry averages to determine fair value. However, AcSEC believes that inherent differences exist between elements offered by different vendors. These inherent differences led AcSEC to conclude that only vendor-specific evidence of fair value can be considered sufficiently objective to allow the allocation of the revenue to the various elements of the arrangement..101 AcSEC believes that the best evidence of the fair value of an element is the price charged if that element is sold separately. Still, an arrangement may include elements that are not yet being sold separately. As discussed in the previous paragraph, because of inherent differences between the elements offered by different vendors, AcSEC concluded that companies should not use surrogate prices, such as competitor prices for similar products or industry averages, as evidence of the fair value for an element. AcSEC believes, however, that if a price for the element has been established by management having the relevant authority, such a price represents evidence of the fair value for that element. To meet the criterion of objectivity, it must be probable that the established price will not change before the introduction of the element to the marketplace. Thus, the internally established prices should be factual and not estimates. For this reason, AcSEC concluded that the allocations may not be adjusted subsequently..102 AcSEC is aware that the pricing structure of certain arrangements is not limited to the prices charged for the separate elements. Pricing may be based on many different factors or combinations thereof. For example, certain arrangements are priced based on a combination of (a) the prices of products to be licensed and (b) the number of users that will be granted access to the licensed products. In some of these arrangements, the vendor requires a minimum number of users..103 The products contained in such arrangements are not available to the customer at the prices charged in the arrangement unless the customer also pays for the minimum number of users. Therefore, the prices contained in the arrangement do not represent the prices charged for the product when sold separately. AcSEC believes that it would be inappropriate to determine the fair values of the products (as discussed in paragraph.10) without giving consideration to the impact of the user-based portion of the fee. For this reason, AcSEC concluded in paragraph.10 that when a vendor s pricing is based on multiple factors such as the number of products and the number of users, the price charged for the same element when sold separately must consider all factors of the vendor s pricing structure..104 Often, multiple element arrangements are sold at a discount rather than at the sum of the list prices for each element. If the amounts deferred for undelivered elements were based on list prices, the amount of revenue recognized for delivered elements would be understated. Accordingly, AcSEC concluded that relative sales prices should be used in determining the amount of revenue to be allocated to the elements of an arrangement..105 AcSEC believes that if an undelivered element is essential to the functionality of a delivered element, the customer does not have full use of the delivered element. Consequently, AcSEC concluded that delivery is considered not to have occurred in such situations..106 AcSEC believes that the earnings process with respect to delivered products is not complete if fees allocated to those products are subject to forfeiture, refund, or other concession if the vendor does not fulfill its delivery responsibilities. AcSEC believes that the potential concessions indicate the customer would not have licensed the delivered products without also licensing the undelivered products. Accordingly, AcSEC concluded that in order to recognize revenue, persuasive evidence should exist that fees allocated to delivered products are not subject to forfeiture, refund, or other concession. In determining the persuasiveness of the evidence, AcSEC believes that a vendor s history of making concessions that were not required by the provisions of an arrangement is more persuasive than terms included in the arrangement that indicate that no concessions are required. Software Revenue Recognition A-21

Delivery.107 In paragraph.18 of this SOP, AcSEC concluded that for software that is delivered electronically, the delivery criterion of paragraph.08 is deemed to have been met when the customer either (a) takes possession of the software via a download or (b) has been provided with access codes that allow the customer to take immediate possession of the software on its hardware pursuant to an agreement or purchase order for the software. AcSEC believes that the delivery criterion is met by use of access codes only when software is being delivered electronically..108 AcSEC believes that if the fee is not based on the number of copies to be delivered to or made or deployed by the customer, duplication of the software may be incidental to the arrangement. Paragraph.21 of this SOP describes circumstances (arrangements in which duplication is required only if additional copies are requested by the customer; arrangements in which the licensing fee is payable even if no additional copies are requested) that would lead to a conclusion that duplication is incidental to the arrangement. In other arrangements, vendors insist on duplicating the software to maintain quality control or to protect software transmitted by telecommunications. Others agree to duplicate the software as a matter of convenience to the customer..109 In arrangements in which duplication is considered incidental, AcSEC believes the vendor has fulfilled its delivery obligation as soon as the first copy or product master of the software has been delivered. Therefore, AcSEC concluded that in such instances, the vendor should not be precluded from recognizing revenue if the customer has not requested additional copies (particularly since the fee is payable regardless of whether such additional copies are requested by the customer). However, the estimated costs of duplicating the software should be accrued when the revenue is recognized. Fixed or Determinable Fees and Collectibility.110 In paragraphs.27 through.30, in the discussion of factors that affect the determination of whether a fee is fixed or determinable, AcSEC sought to clarify but not change similar provisions in SOP 91-1. In practice, some had interpreted those provisions to mean the following. Extended payment considerations could be overcome if customers were creditworthy. A fee could never be considered fixed or determinable if payment terms extended for more than twelve months after delivery..111 Others had interpreted these provisions to mean the following. If payment terms extended beyond customary terms but were twelve months or less, they were fixed or determinable. If payment terms exceeded twelve months, a vendor could recognize amounts due in the first twelve months as revenue at the time of the license. Additional revenue would be recognized based on the passage of time such that, at any point, any amounts due within one year would have been recognized as revenue (the rolling twelve months approach). Paragraphs.112 through.114 of this SOP: Explain that the concern with extended payment terms is technological obsolescence and similar factors, not customer creditworthiness. Describe circumstances in which the presumption that a fee is not fixed or determinable because of extended payment terms may be overcome. Confirm that any extended payment terms, even if for less than twelve months, must be assessed for their effects on the fixed or determinable aspects of the fee. Clarify that the rolling twelve months approach should not be used..112 AcSEC believes that, given the susceptibility of software to significant external factors (in particular, technological obsolescence), the likelihood of vendor refunds or concessions is greater in an arrangement with extended payment terms than in an arrangement without extended payment terms. This is true regardless of the creditworthiness of the customer. Because of this Software Revenue Recognition A-22

greater likelihood of refunds or concessions, AcSEC believes that any extended payment terms outside of a vendor s normal business practices may indicate that the fee is not fixed or determinable..113 In paragraph.28 of this SOP, AcSEC concluded that if payment of a significant portion of a licensing fee is not due until after the expiration of the license or more than twelve months after delivery, the fee should be presumed not to be fixed or determinable. This conclusion is based on AcSEC s belief that payment terms of such extended duration indicate that vendor refunds or concessions are more likely than not. AcSEC acknowledges that the one-year provision is arbitrary. However, AcSEC concluded that such a limitation is needed to provide greater comparability within the industry..114 In considering the rolling twelve months approach found in practice, AcSEC considered the guidance in Chapter 1A of ARB No. 43, Restatement and Revision of Accounting Research Bulletins, paragraph 1, which states that Profit is deemed to be realized when a sale in the ordinary course of business is effected, unless the circumstances are such that the collection of the sale price is not reasonably assured. Accordingly, if a fee is considered fixed or determinable, it should be recognized as revenue when the sale is affected. If not, AcSEC believes that it should be recognized as revenue as payments from customers become due..115 In paragraph.08 of this SOP, AcSEC concluded that collectibility must be probable before revenue may be recognized. This conclusion is based on paragraph 84g of FASB Concepts Statement No. 5, which reads: If collectibility of assets received for product, services, or other assets is doubtful, revenues and gains may be recognized on the basis of cash received..116 AcSEC notes that requiring collectibility enhances the verifiability of the other revenue recognition criteria of paragraph.08, as discussed below. Persuasive evidence of an arrangement AcSEC included this criterion in order to prevent revenue recognition on delivery of elements which, in fact, had not been ordered by a customer. AcSEC believes it is unlikely that a customer would pay for an element that had not been ordered. Therefore, AcSEC believes that requiring collectibility of a receivable related to the sale or license acts to verify that an arrangement does exist. Delivery AcSEC believes that until delivery of an element has occurred (including delivery of all other items essential to the functionality of the element in question), the customer has not received full use of the element ordered. A customer that has not received full use of the element ordered is likely to withhold payment or require a refund. Therefore, AcSEC believes that requiring collectibility of a receivable related to the sale or license acts to verify that the element has been delivered. Fixed or determinable fee Much of AcSEC s concern related to fixed or determinable fees relates to arrangements with extended payment terms. In the software industry, requiring collectibility of a receivable prior to revenue recognition is important because of the frequency with which upgrades, enhancements, or new versions are released. As discussed elsewhere in this SOP, in certain instances it may be difficult to determine which version of an element induced a customer to enter into an arrangement. By requiring collectibility, AcSEC sought to prevent revenue recognition on sales or licenses of an element in situations in which circumstances may prompt the vendor to make subsequent adjustments to the price of a customer s purchase or license of a subsequent version of that element. The likelihood that subsequent versions will be released is greater over the long term than over the short term. Therefore, concerns related to concessions increase in arrangements with extended payment terms. AcSEC notes that prohibiting revenue recognition in circumstances in which the price adjustments discussed above could occur serves to ensure that the portion of the Software Revenue Recognition A-23

fee allocated to each element is fixed or determinable. That is, if the price on a subsequent element cannot be adjusted for concessions, and the amount allocated to the initial element must be collected in full, neither amount is subject to adjustment. Therefore, AcSEC believes that requiring collectibility of a receivable related to the sale or license acts to verify that the fees are fixed or determinable. Multiple-Element Arrangements Additional Software Deliverables and Rights to Exchange or Return Software.117 Upgrades/enhancements. In paragraph.37 of this SOP, AcSEC concluded that the portion of the arrangement fee allocated to an upgrade right should be based on the price for the upgrade/enhancement that would be charged to existing users of the software product being updated. AcSEC believes that in arrangements that include upgrade rights, it may be difficult to determine which version of the software induced the customer to enter into the arrangement. For example, a customer licensing an existing version of the software may have done so to facilitate obtaining the updated version upon its introduction. To eliminate the possibility of allocating too much revenue to the delivered software (and thereby accelerating recognition), AcSEC concluded that the upgrade price (without the allocation of any discount on the arrangement) should be used to determine the amount to be deferred. The residual amount, if any, is considered to be the fair value of the original product..118 AcSEC believes that upgrades/enhancements do not necessarily contain improvements that all customers would desire. A customer may not exercise an upgrade right for various reasons, including any of the following: a. The benefits to be gained from the related upgrade/enhancement may not be important to that customer. b. The customer may not wish to learn new commands for what may be perceived by that customer as marginal improvements. c. The upgrade/enhancement would require more hardware functionality than the customer currently has. Consequently, AcSEC concluded that amounts allocated to upgrade rights should be reduced to reflect the percentage of customers not expected to exercise the upgrade right, based on vendorspecific evidence..119 Additional Software Products. As stated in paragraph.118, AcSEC believes that not all customers entitled to an upgrade/enhancement will exercise their upgrade rights. AcSEC believes, however, that it is probable that all customers will choose to receive additional software products. Consequently, AcSEC concluded that the fee allocated to additional software products should not be reduced by the percentage of any customers not expected to exercise the right to receive the additional products..120 Paragraphs.48 and.49 of this SOP discuss accounting for software arrangements in which vendors agree to deliver unspecified additional software products in the future. AcSEC concluded that such arrangements should be accounted for as subscriptions, and that the fee from the arrangement should be recognized ratably as revenue over the term of the arrangement. AcSEC notes that, because the vendor is obligated to deliver these items only if they become available during the term of the arrangement, in some situations, the delivery of additional products will not be required. AcSEC believes that because these items are unspecified, vendor-specific objective evidence of fair value of each unspecified additional product cannot exist. However, AcSEC believes that requiring the deferral of all revenue until the end of the arrangement is too onerous because of the following: a. All other revenue recognition conditions in paragraphs.08 through.14 of this SOP have been met. b. The additional software products in fact may never be delivered. Software Revenue Recognition A-24

However, AcSEC also was concerned that if revenue recognition were permitted to begin at the inception of the arrangement, revenue may be recognized too early, particularly in arrangements in which the first product was not delivered for some time after inception. Accordingly, AcSEC concluded that revenue from the arrangement should be recognized ratably over the term of the arrangement beginning with the delivery of the first product..121 Rights to Exchange or Return Software. AcSEC believes that the rights to exchange or return software (including platform transfer rights) are subject to the provisions of FASB Statement No. 48, even if the software is not returned physically. Accordingly, AcSEC concluded that the accounting for exchanges of software for products with no more than minimal differences in price, functionality, and features by users qualify for exchange accounting because, as discussed in footnote 3 to FASB Statement No. 48, (a) users are ultimate customers and (b) exchanges of software with no more than minimal differences in price, functionality, and features represent exchanges... of one item for another of the same kind, quality, and price. AcSEC concluded that because resellers are not ultimate customers, such exchanges by resellers should be considered returns..122 AcSEC reached similar conclusions related to certain platform-transfer rights. Additionally, AcSEC concluded that in situations in which customers are entitled to continue using the software that was originally delivered (in addition to the software that is to be delivered for the new platform), the customer has received additional software products, and the platform-transfer right should be accounted for as such. Other platform-transfer rights do not allow customers to continue to use the software on the original platform. Those platform-transfer rights should be accounted for as exchange rights or rights of return..123 It is possible that exchange rights may be granted for software that has not been developed for other platforms at the time revenue from the arrangement is recorded. AcSEC did not address the issue of whether such future development costs related to deliverable software, for which no further revenue will be received, should be capitalized pursuant to FASB Statement No. 86 because it was believed that such costs would not be significant. Accordingly, AcSEC concluded that in the event of significant development costs, the vendor would not be likely to be able to demonstrate persuasively that the future software would have similar pricing, features, and functionality, and would be marketed as the same product (that is, qualify as an exchange for accounting purposes). In that event, the vendor has granted a return right that must be accounted for pursuant to FASB Statement No. 48. Postcontract Customer Support.124 An obligation to perform PCS is incurred at the inception of a PCS arrangement and is discharged by delivering unspecified upgrades/enhancements, performing services, or both over the period of the PCS arrangement. The obligation also may be discharged by the passage of time. AcSEC concluded that because estimating the timing of expenditures under a PCS arrangement usually is not practicable, revenue from PCS generally should be recognized on a straight-line basis over the period of the PCS arrangement. However, AcSEC also concluded that if there is sufficient vendor-specific historical evidence that costs to provide the support are incurred on other than a straight-line basis, the vendor should recognize revenue in proportion to the amounts expected to be charged to the PCS services rendered during the period..125 SOP 91-1 required that revenue from both the PCS and the initial licensing fee be recognized ratably over the period of the PCS arrangement if no basis existed to derive separate prices for the PCS and the initial licensing fee. Diversity in practice arose as to what constituted a sufficient basis in arrangements involving vendors that did not have a basis to derive a separate price for the PCS. In this SOP, AcSEC has concluded that arrangement fees must be allocated to elements of the arrangement based on vendor-specific objective evidence of fair value. Because AcSEC determined that the evidence should be limited to that which is specific to the vendor, AcSEC believes that vendors that do not sell PCS separately have no basis on which to allocate fair values. AcSEC concluded that the total arrangement fee should be recognized in accordance Software Revenue Recognition A-25

with the provisions on recognition of PCS revenues. AcSEC also believes that, because a substantial portion of the arrangement fee typically is represented by the delivered software (rather than the performance of support), requiring the deferral of all revenues until the PCS obligation is fully satisfied would be too onerous. Accordingly, AcSEC concluded that, as discussed in the previous paragraph, the total arrangement fee generally should be recognized ratably over the period of the PCS arrangement. Services.126 Certain software arrangements include both a software element and an obligation to perform non-pcs services. SOP 91-1 provided guidance on the conditions that must be met in order to account for the obligation to provide services separately from the software component. AcSEC is aware that this guidance has been interpreted in varying ways, leading to a diversity in practice. During its deliberations on this SOP, AcSEC reached conclusions intended to clarify this issue, but did not redeliberate the other conclusions related to services that were included in SOP 91-1..127 AcSEC believes the service element should be accounted for separately if the following occur. a. All other revenue allocation provisions of this SOP are met. b.the services are not essential to the functionality of any other element in the arrangement. c. The service and product elements are stated separately such that the total price of the arrangement would vary as a result of inclusion or exclusion of the services. Accordingly, AcSEC concluded that a service element need not be priced separately in an agreement in order to account for the services separately. AcSEC believes that this conclusion represents the original intent of SOP 91-1, and wishes to clarify the language at this time..128 Paragraphs.129 through.132 of this SOP are carried forward from SOP 91-1 with certain editorial changes..129 Service Elements. Footnote 1 to paragraph 11 of SOP 81-1 [section 10,330.11, footnote 1] excludes service transactions from the scope of the SOP, as follows: This statement is not intended to apply to service transactions as defined in the FASB s October 23, 1978 Invitation to Comment, Accounting for Certain Service Transactions. However, it applies to separate contracts to provide services essential to the construction or production of tangible property, such as design... [and] engineering.....130 The previously mentioned Invitation to Comment, which was based on an AICPA-proposed SOP, was issued in 1978. The FASB later included service transactions as part of its project to develop general concepts for revenue recognition and measurement. The resulting FASB Concepts Statement No. 5, however, does not address service transactions in detail. Nevertheless, some of the concepts on service transactions developed in the Invitation to Comment are useful in accounting for certain software transactions..131 A service transaction is defined in paragraphs 7 and 8 of the Invitation to Comment as follows: A transaction between a seller and a purchaser in which, for a mutually agreed price, the seller performs... an act or acts... that do not alone produce a tangible commodity or product as the principal intended result... A service transaction may involve a tangible product that is sold or consumed as an incidental part of the transaction or is clearly identifiable as secondary or subordinate to the rendering of the service. The term service transaction is used in the same sense in this SOP but, as used in this SOP, does not apply to PCS. Items classified as tangible products in software service transactions generally should be limited to off-the-shelf software or hardware. Software Revenue Recognition A-26

.132 This SOP, like the Invitation to Comment, recommends the separation of such arrangements with discrete elements into their product and service elements. Paragraph 8(b) of the Invitation to Comment states the following: If the seller of a product offers a related service to purchasers of the product but separately states the service and product elements in such a manner that the total transaction price would vary as a result of the inclusion or exclusion of the service, the transaction consists of two components: a product transaction that should be accounted for separately as such and a service transaction.... Contract Accounting.133 SOP 91-1 included guidance on the application of contract accounting to software transactions. Questions arose as to whether output measures could be used to measure progress-to-completion if the amounts recorded would differ from those that would have been reported had input measures been used. During its deliberations of this SOP, AcSEC reached conclusions intended to clarify this issue, but did not redeliberate the other conclusions related to services that were included in SOP 91-1..134 AcSEC believes that the method chosen to measure progress-to-completion on an individual element of a contract should be the method that best approximates progress-to-completion on that element. Accordingly, AcSEC concluded that output measures may be used to measure progress-to-completion, provided that the use of output measures results in the method that best approximates progress-to-completion..135 Paragraphs.136 through.142 of this SOP are carried forward from SOP 91-1 with certain editorial changes..136 ARB No. 45 established the basic principles for measuring performance on contracts for the construction of facilities or the production of goods or the provision of related services with specifications provided by the customer. Those principles are supplemented by the guidance in SOP 81-1 [section 10,330]. Distinguishing Transactions Accounted for Using Contract Accounting From Product Sales.137 SOP 81-1 [section 10,330] suggests that transactions that normally are accounted for as product sales should not be accounted for using contract accounting merely to avoid the delivery requirements for revenue recognition normally associated with product sales. Paragraph 14 of SOP 81-1 [section 10,330.14] states the following: Contracts not covered... include... [s]ales by a manufacturer of goods produced in a standard manufacturing operation, even if produced to buyers specifications, and sold in the ordinary course of business through the manufacturer s regular marketing channels if such sales are normally recognized as revenue in accordance with the realization principle for sales of products and if their costs are accounted for in accordance with generally accepted principles of inventory costing. Software Revenue Recognition A-27

Application of ARB No. 45 and SOP 81-1.138 SOP 81-1 [section 10,330] provides guidance on the application of ARB No. 45 that applies to a broad range of contractual arrangements. Paragraph 1 of SOP 81-1 [section 10,330.01] describes contracts that are similar in nature to software arrangements, and paragraph 13 [section 10,330.13] includes the following kinds of contracts within the scope of that SOP: Contracts to design, develop, manufacture, or modify complex... electronic equipment to a buyer s specification or to provide services related to the performance of such contracts; and Contracts for services performed by... engineers... or engineering design firms..139 ARB No. 45 presumes that percentage-of-completion accounting should be used when the contractor is capable of making reasonable estimates. Paragraph 15 of ARB No. 45 states the following: [I]n general when estimates of costs to complete and extent of progress toward completion of long-term contracts are reasonably dependable, the percentage-of-completion method is preferable. When lack of dependable estimates or inherent hazards cause forecasts to be doubtful, the completed-contract method is preferable. Evidence to consider in assessing the presumption that the percentage-of-completion method of accounting should be used includes the technological risks and the reliability of cost estimates, as described in paragraphs 25, 26, 27, 32, and 33 of SOP 81-1 [section 10,330.25,.26,.27,.32, and.33]..140 Paragraph 24 of SOP 81-1 [section 10,330.24] specifies a further presumption that a contractor is capable of making reasonable estimates and states the following: [T]he presumption is that [entities]... have the ability to make estimates that are sufficiently dependable to justify the use of the percentage-of-completion method of accounting. Persuasive evidence to the contrary is necessary to overcome that presumption. [Footnote omitted].141 Although cost-to-cost measures may be verified easily, they tend to attribute excessive profit to the hardware elements of arrangements with combined software and hardware elements for contracts under which segmentation is not permitted. Although the hardware elements of such arrangements have high cost bases, they generally yield relatively low profit margins to vendors. Furthermore, if excessive revenue is attributed to the hardware element, revenue recognition on the arrangement becomes overly dependent on when that element is included in the measurement of progress-to-completion..142 For off-the-shelf software elements, the application of the cost-to-cost method produces the opposite effect. The book basis of the software tends to be low, because most of the costs associated with software development frequently are charged to expense when incurred in conformity with FASB Statement No. 86. Although the profit margins associated with software are generally higher than those for other elements of the arrangement, the application of cost-to-cost measures with a single profit margin for the entire arrangement would attribute little or no profit to the off-the-shelf software. Similarly, the application of the cost-to-cost method to arrangements that include core software, which also has a relatively low cost basis, would attribute a disproportionately small amount of profit to the software. Software Revenue Recognition A-28

Effective Date and Transition.143 AcSEC concluded that the provisions of this SOP should be applied prospectively and that retroactive application should be prohibited. AcSEC recognizes the benefits of comparable financial statements but is concerned that the application of the provisions of this SOP to contracts existing in prior periods would require a significant amount of judgment. The application of that judgment likely would be impacted by the hindsight a company would have, resulting in judgments based on information that did not exist at the time of the initial judgment but that would be called for if the SOP were to be applied retroactively..144 Additionally, AcSEC concluded that some entities would be required to incur large expenditures in determining restated amounts or the cumulative effect of adoption. AcSEC concluded that the cost of calculating such amounts likely would exceed the related benefit of that information. This SOP does not preclude an entity from disclosing in the notes to the financial statements the effect of initially applying this SOP if an entity believes it is practicable to do so. Items Not Retained From SOP 91-1.145 AcSEC believes that the guidance included in SOP 91-1 related to discounting receivables and the collectibility of receivables (discussed in paragraphs 56 and 78, respectively, of SOP 91-1) is not specific to the software industry and thus does not need to be retained in this SOP. Software Revenue Recognition A-29

Appendix A Examples of the Application of Certain Provisions of This Statement of Position.146 Scope Example 1 Facts: An automobile manufacturer installs software into an automobile model. This software is used solely in connection with operating the automobile and is not sold or marketed separately. Once installed, the software is not updated for new versions that the manufacturer subsequently develops. The automobile manufacturer s costs for the development of the software that are within the scope of FASB Statement No. 86, Accounting for the Costs of Computer Software to Be Sold, Leased, or Otherwise Marketed, and the production costs of such software are insignificant relative to the other development and production costs of the automobile. Applicability: The Statement of Position (SOP) is not applicable to such software because the software is deemed incidental to the product as a whole. Discussion: Although the software may be critical to the operations of the automobile, the software itself is not the focus of the marketing effort, nor is it what the customer perceives he or she is obtaining. The development and production costs of the software as a component of the cost of the automobile is incidental. Scope Example 2 Facts: An entity develops interactive training courses for sale or licensing to customers. These courses are delivered on a compact disc, which is loaded onto a customer s computer. The courses are developed such that, based on the responses received to a particular question, different questions are generated and content of the course material that is displayed is determined in a manner that directs the user s learning experience in a more focused way. The course developer s costs for the development of the software content are within the scope of FASB Statement No. 86 and are significant. The interactive nature of the courses is mentioned prominently in the marketing efforts. Applicability: The SOP is applicable because the software is not incidental to the product. Discussion: Although some might say that the product is educational services, the marketing of the product focuses on the software-reliant interactive features. In addition, the course developer incurs significant costs that are within the scope of FASB Statement No. 86. The nature of the relationship between the vendor and the customer is not one in which the customer would have a need for postcontract services. Consequently, the absence of PCS is not presumptive that software is incidental to the product. Accordingly, a conclusion is reached that the software is not incidental to the product as a whole. Therefore, the provisions of this SOP apply. Additional Software Products Price per Copy Example 1 Facts: A vendor enters into an arrangement under which a customer has the right to make copies of Product A at $100 a copy, copies of Product B at $200 a copy, or copies of Product C at $50 a copy until such time as the customer has made copies aggregating $100,000 based on the per copy prices. The customer is obligated to pay the $100,000 whether or not the customer makes all the copies to which it is entitled under the arrangement. In all other respects, the $100,000 is considered to meet the criteria of a fixed fee, as described in this Statement of Position. Software Revenue Recognition A-30

Master copies of Products A and B are available currently and have been delivered. Product C is not available yet; therefore, no master copy has been delivered. The contract is clear that no portion of the fee allocable to copies made of Products A and B is refundable if Product C is not delivered, nor is there any further obligation to deliver Product C if copies of Products A and B aggregating $100,000 have been made. The per copy prices included in the arrangement for Products A and B are the per copy prices included in the company s price list, and the company has already approved the per copy price list for Product C to be $50 per copy. Product C is not essential to the functionality of Products A or B. The maximum number of copies of Product C that can be made is 500. Revenue Recognition: The vendor should allocate $25,000 of the arrangement fee to Product C. The remaining $75,000 of revenue should be recognized when the master copies of Products A and B are delivered to the customer. The $25,000 allocated to Product C would be recognized when the master copy of Product C is delivered to the customer. If the customer duplicates enough copies of Products A and B so that the revenue allocable to those products exceeds $75,000, the additional revenue should be recognized as the additional copies are made. Discussion: As discussed in paragraph.43 of this SOP, in an arrangement in which a number of products are not deliverable or specified at the inception of the arrangement, an allocation of the arrangement fee generally cannot be made, because the total revenue allocable to each software product is unknown and depends on choices to be made by the customer and, sometimes, future development activity. As discussed in paragraph.46 of this SOP however, if such an arrangement specifies a maximum number of copies of the undeliverable or unspecified product, a portion of the arrangement fee should be allocated to the undeliverable product(s). This allocation should be made assuming the customer elects to receive the maximum number of copies of the undeliverable product(s). Because the arrangement states a maximum number of copies of Product C that can be made, a basis for allocating the fair value to each product of the arrangement exists. The amount allocated to the undelivered product is the maximum amount that can be allocable to that product, based on the maximum number of copies of Product C that can be made (500) and the fee per copy ($50). Accordingly, $25,000 should be allocated to Product C and deferred until delivery of the product master. Because all other conditions for revenue recognition in this SOP have been met, revenue related to Products A and B may be recognized upon delivery of the masters of those products as discussed in paragraph.44 of this SOP. Additional Software Products Price per Copy Example 2 Facts: Assume the same facts as in the preceding example, except the arrangement does not state a maximum number of copies of Product C that can be made. Revenue Recognition: Revenue should be recognized as copies of Products A ($100 of revenue per copy) and B ($200 of revenue per copy) are made, until the master of Product C is delivered to the customer. Any remaining revenue should be recognized upon delivery of the master of Product C. Discussion: As discussed in paragraph.43 of this SOP, although the fee per copy is fixed at the inception of the arrangement and the cost of duplication is incidental, the total fee allocated to the undelivered software (Product C) is unknown and will depend on the choices made by the customers as to how many copies of each product will be utilized. Software Revenue Recognition A-31

Authorization Codes Example 1 Facts: A vendor includes ten optional functions on a compact disc (CD-ROM) on which its software product is licensed. Access to those optional functions is not available without a permanent key. Users can order the optional functions and receive permanent keys to enable the full use of those functions. Revenue Recognition: Revenue for each individual optional function should be recognized by the vendor when the user purchases it by placing an order, evidence of such order exists, and the key is delivered to the user. Discussion: Although the user has received a fully functional version (except for the keys) of the optional functions on the CD-ROM, the user has not agreed to license them. Because no evidence of an arrangement exists (as discussed in paragraphs.15 through.17 of this SOP), revenue for the optional functions may not be recognized when the CD-ROM is delivered. Authorization Codes Example 2 Facts: A software vendor s products run on two different levels of central processing units (CPU) of the same manufacturer Model X and Model Y (both of which are on the same platform). The vendor enters into a license arrangement with a user whereby the user licenses the vendor s products to run on Model X but allows the user to move to Model Y at no additional charge. The vendor delivers the product in the form of a disc pack along with a CPU authorization code. At the time the user chooses to move to Model Y, the user does not receive a new disc pack; rather the vendor gives the user a new CPU authorization code. Revenue Recognition: Revenue should be recognized on the delivery of the disc pack. Discussion: Delivery of the authorization code to move to another CPU is not considered to be an additional software deliverable. Multiple-Element Arrangements Products Example 1 Facts: A vendor licenses a user one license covering a single copy of Products A, B, C, and D for a nonrefundable fixed fee of $80, with no stated price per product. Products A, B, and C are deliverable. Product D is not deliverable and is not essential to the functionality of Products A, B, or C. Persuasive evidence exists that indicates that the revenue related to Products A, B, or C is not subject to refund, forfeiture, other concessions if Product D is not delivered. The vendor has a history of sales prices for Products A, B, and C of $25 each. The vendor s pricing committee has established a price for Product D of $25. It is probable that the price established by the pricing committee for Product D will not change before introduction. Therefore, the vendor is able to derive its specific price for the undelivered software. Revenue Recognition: Revenue allocated to each product based on the existing prices for Products A, B, and C and the probable price for Product D should be recognized when each individual product is delivered. The revenue allocated to each of the products would be $20. Software Revenue Recognition A-32

Discussion: Revenue allocated to each product should be recognized upon the delivery of that product if the criteria in paragraphs.08 through.14 of this SOP have been met. The allocation of revenue to each product is based on the relative fair value of each product. As discussed in paragraph.12 of this SOP, sufficient vendor-specific objective evidence must exist to determine allocation. In this example, sufficient vendor-specific objective evidence exists to determine that the fair value of each product on a stand-alone basis is $25. Therefore, in accordance with paragraph.41 of this SOP, the discount should be allocated evenly to each product, and revenue of $20 per product should be recognized when each product is delivered. Multiple-Element Arrangements Products Example 2 Facts: The transaction is the same as that outlined in the prior example. The contract is silent about penalties for the nondelivery of Product D, but the proposal and other communications indicate that it is a required capability of the offering and that the user does not want any of the vendor s products unless Product D is delivered. Revenue Recognition: All revenue must be deferred until delivery of Product D. Discussion: Because revenue allocable to the delivered software is subject to forfeiture, refund, or other concession if Product D is not delivered, all revenue under the agreement should be deferred until Product D is delivered, in accordance with paragraph.13 of this SOP. Multiple-Element Arrangements Products Example 3 Facts: A vendor licenses version 1.0 of a software product to 100 customers for $300 per copy with a right to receive version 2.0 at no additional cost when it becomes available. The pricing committee has not yet decided whether version 2.0 will be offered to users of version 1.0 for $100 or for $200. Revenue Recognition: All revenue should be deferred until the pricing committee makes its decision and it is probable that the price established will be the price charged upon introduction. Discussion: Because the pricing committee has not yet decided whether version 2.0 will be offered at $100 or at $200, sufficient vendor-specific objective evidence does not yet exist supporting the price of the undelivered software. As discussed in paragraph.12 of this SOP, if sufficient vendor-specific objective evidence does not exist to determine the allocation of revenue, all revenue should be deferred until sufficient vendor-specific objective evidence exists. Multiple-Element Arrangements Products Example 4 Facts: In the preceding example, assume that the pricing committee determines that version 2.0 will be offered to users of version 1.0 as a specified upgrade/enhancement at a price of $100. It is probable that such price will not change prior to introduction. Persuasive evidence exists indicating that the amount allocated to version 1.0 will not be subject to forfeiture, refund, or other concession. Also, the vendor s experience indicates that 40% of customers do not exercise upgrade rights. Software Revenue Recognition A-33

Revenue Recognition: The vendor should defer $6,000 (upgrade price of $100 multiplied by 100 copies, reduced by 40% to account for the customers expected not to exercise the upgrade right) until delivery of the upgrade/enhancement, and recognize the remaining $24,000 on delivery of version 1.0. Discussion: The portion of the arrangement fee allocated to the upgrade right is equal to the price for the upgrade/ enhancement determined pursuant to paragraph.37 of this SOP. This amount should be deferred and recognized on the delivery of version 2.0. The amount deferred for the specific upgrade/enhancement should be reduced to reflect the percentage of customers that, based on experience, are not expected to exercise the upgrade right (see paragraph.37 of this SOP). Accordingly, the $10,000 revenue allocated to the upgrade right should be reduced by $4,000 (40% of the allocated revenue). If the vendor did not have information based on experience that indicates the percentage of customers that do not exercise the upgrade right, the vendor should defer the entire $10,000 of revenue allocated to the upgrade right, under the assumption that, in the absence of vendorspecific objective evidence to the contrary, 100% of customers will exercise the upgrade right. Multiple-Element Arrangements Products and Services Example 1 Facts: A vendor has entered into an arrangement to provide a customer with its off-the-shelf software product and related implementation services. The software and service elements of the contract are stated separately and the company has a history of selling these services separately such that the revenue allocation criteria of paragraphs.08 through.14 of this SOP can be satisfied. The software license fees are due under the com-pany s normal trade terms, which are net 30 days. The services are expected to be provided over the next 90 days and are of the type performed routinely by the vendor. The features and functionality of the software are not altered to more than a minor degree as a result of these services. Revenue Recognition: The vendor should recognize the license revenue allocated to the software element upon its delivery and the revenue allocated to the service element as such services are performed. Discussion: When license arrangements have multiple elements, revenue should be allocated to each of the elements and recognized when the related element is delivered and the following occur. 1. The undelivered elements are not essential to the functionality of the delivered elements. 2. The revenue allocated to the delivered elements is not subject to forfeiture, refund, or other concession if the undelivered elements are not delivered. 3. Sufficient company-specific objective evidence exists to allocate separate prices to each of the elements. The service element in this arrangement is not deemed to be essential to the functionality of the software element because the features and functionality of the software are not altered to more than a minor degree as a result of the services. Multiple-Element Arrangements Products and Services Example 2 Facts: Assume the same transaction as described above except that the vendor agrees to make more than minor modifications to the functionality of the product to meet needs as defined by the user. Payment terms are 10% upon installation of the software, with the remainder according to a time line, and the final 25% withheld until acceptance. The desired modifications are not unusual; the vendor has made similar modifications to the product many times and is certain that the planned modifications will meet the user s needs. Software Revenue Recognition A-34

Revenue Recognition: This arrangement should be accounted for pursuant to the guidance on contract accounting (using either the percentage-of-completion or completed-contract method, depending on the facts and circumstances) included in paragraphs.74 through.91 of this SOP. Discussion: The new conditions would preclude service transaction accounting because the functionality of the software product is being altered in more than a minor way, the payment of the fees is coincident with the services being performed, and the software is subject to the user s unique acceptance criteria. Multiple-Element Arrangements Products and Services Example 3 Facts: Assume the same transaction as described in Multiple-Element Arrangements Products and Services Example 1, except that the vendor never sells implementation services separately. The implementation services do not involve significant customization of the software. Revenue Recognition: The vendor should recognize all revenue from the arrangement over the 90-day period during which the services are expected to be performed, commencing with delivery of the software product. Discussion: The criteria for vendor-specific objective evidence of the fair value require that the element be sold separately or be planned to be sold separately. Because implementation services are neither sold separately nor planned to be sold separately, and upon delivery of the software product such services are the only undelivered elements, paragraph.67 of this SOP requires that all revenue be recognized over the period during which the implementation services are expected to be provided. Multiple-Element Arrangements Products and Services Example 4 Facts: A vendor sells software Product A for $950. The license arrangement for Product A always includes one year of free PCS. The annual renewal price of PCS is $150. Revenue Recognition: Assuming that, apart from the lack of vendor-specific objective evidence of the fair value of the delivered software element, all applicable revenue recognition criteria in this SOP are met, revenue in the amount of $150 should be deferred and recognized in income over the one-year PCS service period. Revenue of $800 should be allocated to the software element and recognized upon delivery of the software. Discussion: Vendor-specific objective evidence of the fair value of the software does not exist because the software is never sold separately. Consequently, sufficient vendor-specific objective evidence of fair value does not exist for the allocation of revenue to the various elements based on their relative fair values. Paragraph.12 of this SOP states, however, that the residual method should be used when there is vendor-specific objective evidence of the fair values of all undelivered elements; all other applicable revenue recognition criteria in this SOP are met; and the fair value of all of the undelivered elements is less than the total arrangement fee. If there had been vendor-specific objective evidence of the fair value of the delivered software but not of the undelivered PCS, the entire arrangement fee would be deferred and recognized ratably over the contractual PCS period in accordance with paragraphs.12 and.58 of this SOP Software Revenue Recognition A-35

Multiple-Element Arrangements Products and Discounted PCS Example 1 Facts: A software vendor has entered into an arrangement under which it has licensed software that has a list price of $1 million to a customer for $600,000 (which is the price being charged for the software when sold separately under other arrangements). The arrangement also includes annual PCS, priced for the first year at 15% of the discounted license fee, or $90,000 (rather than 15% of the list price of the licensed software). After the first year, the customer will have the right to renew annual maintenance on the licensed software at 15% of the list price of the software (or $150,000). There are no other undelivered elements. All revenue recognition conditions of this SOP have been satisfied. The vendor does not have sufficient vendor-specific historical evidence that costs of providing PCS are incurred on other than a straight-line basis. Revenue Recognition: In Year 1, the total arrangement fee is $690,000. Of this amount, $552,000 should be allocated to the software element and recognized upon delivery of the software element. The remaining $138,000 should be allocated to the PCS element and recognized ratably over the period during which the PCS services are expected to be performed. The allocation of the $690,000 arrangement fee is determined as shown in the following table. Fair value when sold separately: Software element $600,000 80% PCS element $150,000 20% $750,000 100% Allocation: PCS element $690,000 x.20 = $138,000 Software element $690,000 x.80 = $552,000 Discussion: In allocating the arrangement fee to the PCS element, the vendor should look first to the price the customer will pay for the PCS when it is sold separately as a renewal under the arrangement. In this example, that price is $150,000. This price is considered the vendor-specific objective evidence of the fair value for the PCS element, as discussed in paragraph.10. If the customer were entitled to the PCS in subsequent years at the same price at which it had been included in the initial year of the arrangement (that is, $90,000), and the vendor s pricing practices were such that renewals of PCS were based on the discounted value of license fees, no additional fees would have been allocated from the software element to the PCS element. Therefore, the vendor would have allocated $600,000 to the software element and $90,000 to the PCS element. [As amended, effective for transactions entered into in fiscal years beginning after March 15, 1999, by Statement of Position 98-9.] Software Revenue Recognition A-36

.147 Appendix B Response to Comments Received B.1. An exposure draft of a proposed Statement of Position (SOP), Software Revenue Recognition, was issued for public comment on June 14, 1996. B.2. The majority of the comments received related to the basic principles of the exposure draft, particularly the provisions requiring the allocation of the arrangement fee to individual elements in a multiple-element arrangement based on vendor-specific objective evidence of the fair value. Several commentators requested clarification of the wording in the exposure draft related to extended payment terms and the effect of such terms on the determination of whether a fee is fixed and determinable or collectible. Some commentators requested guidance on the application of the provisions of the SOP to marketing arrangements in which coupons or other price incentives are offered. Other commentators requested the reconsideration of the transition provisions of the exposure draft, which required a cumulative-effect adjustment. B.3. These comments and the Accounting Standards Executive Committee s (AcSEC s) response to them are discussed below. Multiple-Element Arrangements B.4. Several commentators responded that the limitations on what constitutes vendor-specific objective evidence of the fair value were too onerous. These commentators stated that many instances exist in which elements are not priced separately, and that because of these limitations, revenue related to delivered elements would be deferred even though the customer received the element. Additionally, several commentators expressed concern that the requirement to allocate revenue to all elements, particularly those deliverable when-and-if-available was not meaningful. (Obligations to deliver when-and-if-available elements were considered by the commentators to be either insignificant vendor obligations or not vendor obligations at all.) B.5. AcSEC considered these comments but continues to support the provisions of the exposure draft. AcSEC noted that these comments had been considered in the process leading to the exposure draft. Although AcSEC agrees that the provisions of the SOP may be troublesome to some companies, AcSEC notes that commentators did not suggest alternatives that AcSEC considered adequate to meet the criteria of objective evidence of fair value. B.6. AcSEC continues to believe that the allocation of the arrangement fee to all elements, including those deliverable on a when-and-if-available basis, is meaningful. AcSEC believes that these elements are bargained for by the customer and should be accounted for. Furthermore, AcSEC believes that the concept of significant versus insignificant obligations should not be used to determine whether revenue should be allocated to an element. This concept had been included in SOP 91-1 and had resulted in varying interpretations in practice. AcSEC further notes that these comments had been considered previously by AcSEC during the process leading to the exposure draft. B.7. Several commentators stated that the limitations on vendor-specific objective evidence of fair value should be expanded to permit the use of prices in published price lists. AcSEC believes that the price for an element as included in a price list does not necessarily represent the fair value of that element. Software Revenue Recognition A-37

Extended Payment Terms B.8. The exposure draft stated that a software licensing fee should not be considered fixed or determinable if the payment of a significant portion of the licensing fee is not due until after the expiration of the license or more than twelve months after delivery. Exceptions were permitted for vendors that have a business practice of using installment contracts and an extended history of entering into contracts with terms in excess of twelve months and successfully enforcing payment terms without making concessions. Several commentators requested clarification of these provisions. B.9. AcSEC considered these comments and agreed that clarification was needed. Relevant clarifications were made to paragraphs.27 through.29 of the SOP. The revised provisions now state that any extended payment terms in a software licensing arrangement may indicate that the fee is not fixed or determinable, particularly if the use of extended payment terms is not the vendor s customary practice. Further, if the payment of a significant portion of the software licensing fee is not due until after the expiration of the license or more than twelve months after delivery, the licensing fee should be presumed not to be fixed or determinable. However, this presumption may be overcome by evidence that the vendor has a standard business practice of using long-term or installment contracts and a history of successfully collecting under the original payment terms without making concessions. Such a vendor should consider such fees fixed or determinable and should recognize revenue upon the delivery of the software, provided all other conditions for revenue recognition in this SOP have been satisfied. B.10. Several commentators requested guidance on the application of the SOP to arrangements in which discounts are offered on subsequent licenses of software. The exposure draft did not have provisions addressing such arrangements. B.11. AcSEC has added wording to the scope section (paragraph.03) of the SOP to address these questions. The new wording states that arrangements in which a vendor offers a small discount on additional licenses of the licensed product or other products that exist at the time of the offer represent marketing and promotional activities that are not unique to software and, therefore, are not included in the scope of this SOP. However, judgment will be required to assess whether price-off and other concessions are so significant that, in substance, additional elements are being offered in the arrangement. Transition B.12. The exposure draft required a cumulative-effect adjustment for the adoption of the SOP. Several commentators noted that considerable effort would be required on the part of many vendors to measure the cumulative effect. Additionally, it was noted that in many instances, the application of the provisions of this SOP to contracts existing in prior periods would require a significant amount of judgment. AcSEC was concerned that the application of that judgment likely would be impacted by the hindsight a company would have, resulting in judgments based on information that did not exist at the time of the initial judgment but that would be called for if the SOP were to be applied retroactively. B.13. AcSEC considered these issues and determined that the transition requirements of the SOP should be amended to require prospective application. Software Revenue Recognition A-38

.148 Appendix C Revenue Recognition on Software Arrangements The following flowchart illustrates a decision process for recognizing revenue on software arrangements. The flowchart is intended to illustrate the basic principle of revenue recognition and does not address the difference in accounting depending upon the type of element (services, upgrade rights, additional software products, or postcontract customer support) included in the arrangement. The flowchart summarizes certain guidance in this SOP and is not intended as a substitute for the SOP. Software Revenue Recognition A-39

Software Revenue Recognition A-40

Software Revenue Recognition A-41

.149 Glossary Authorization Codes (keys). A vehicle used by vendors to permit customers access to, use of, or duplication of software that would otherwise be restricted. Core software. An inventory of software that vendors use in creating other software. Core software is not delivered as is because customers cannot use it unless it is customized to meet system objectives or customer specifications. Software Revenue Recognition A-42

Customer. A user or reseller. Delivery. A transfer of software accompanied by documentation to the customer. The transfer may be by the following: a. A physical transfer of tape, disk, integrated circuit, or other medium b. Electronic transmission c. Making available to the customer software that will not be physically transferred, such as through the facilities of a computer service bureau d. Authorization for duplication of existing copies in the customer s possession If a licensing agreement provides a customer with the right to multiple copies of a software product in exchange for a fixed fee, delivery means transfer of the product master, or the first copy if the product master is not to be transferred. Fixed fee. A fee required to be paid at a set amount that is not subject to refund or adjustment. A fixed fee includes amounts designated as minimum royalties. Licensing. Granting the right to use but not to own software through leases or licenses. Milestone. A task associated with long-term contracts that, when completed, provides management with a reliable indicator of progress-to-completion on those contracts. Off-the-shelf software. Software marketed as a stock item that customers can use with little or no customization. Platform. The hardware architecture of a particular model or family of computers, the system software, such as the operating system, or both. Platform-transfer right. A right granted by a vendor to transfer software from one hardware platform or operating system to one or more other hardware platforms or operating systems. Postcontract customer support (PCS). The right to receive services (other than those separately accounted for as described in paragraphs.65 and.66 of this Statement of Position) or unspecified product upgrades/enhancements, or both, offered to users or resellers, after the software license period begins, or after another time as provided for by the PCS arrangement. Unspecified upgrades/enhancements are PCS only if they are offered on a when-and-if-available basis. PCS does not include the following: Installation or other services directly related to the initial license of the software; Upgrade rights as defined in this Statement of Position; and Rights to additional software products. PCS may be included in the license fee or offered separately. PCS is generally referred to in the software industry as maintenance, a term that is defined, as follows, in paragraph 52 of FASB Statement No. 86, Accounting for the Costs of Computer Software to Be Sold, Leased, or Otherwise Marketed: Activities undertaken after the product is available for general release to customers to correct errors or keep the product updated with current information. Those activities include routine changes and additions. However, the term maintenance is not used in this Statement of Position for the following reasons: 1. It has taken on a broader meaning in the industry than the one described in FASB Statement No. 86. 2. It may be confused with hardware maintenance as it is used elsewhere in accounting literature. 3. Its meaning varies from company to company. Software Revenue Recognition A-43

The right to receive services and unspecified upgrades/enhancements provided under PCS is generally described by the PCS arrangement. Typical arrangements include services, such as telephone support and correction of errors (bug fixing or debugging), and unspecified product upgrades/enhancements developed by the vendor during the period in which the PCS is provided. PCS arrangements include patterns of providing services or unspecified upgrades/enhancements to users or resellers, although the arrangements may not be evidenced by a written contract signed by the vendor and the customer. Reseller. Entity licensed by a software vendor to market the vendor s software to users or other resellers. Licensing agreements with resellers typically include arrangements to sublicense, reproduce, or distribute software. Resellers may be distributors of software, hardware, or turnkey systems, or they may be other entities that include software with the products or services they sell. Site license. A license that permits a customer to use either specified or unlimited numbers of copies of a software product either throughout a company or at a specified location. Upgrade/enhancement. An improvement to an existing product that is intended to extend the life or improve significantly the marketability of the original product through added functionality, enhanced performance, or both. The terms upgrade and enhancement are used interchangeably to describe improvements to software products; however, in different segments of the software industry, those terms may connote different levels of packaging or improvements. This definition does not include platform-transfer rights. Upgrade right. The right to receive one or more specific upgrades/enhancements that are to be sold separately. The upgrade right may be evidenced by a specific agreement, commitment, or the vendor s established practice. User. Party that ultimately uses the software in an application. When-and-if-available. An arrangement whereby a vendor agrees to deliver software only when or if it becomes deliverable while the arrangement is in effect. When-and-if-available is an industry term that is commonly used to describe a broad range of contractual commitments. The use of the term when-and-if-available within an arrangement should not lead to a presumption that an obligation does not exist. Accounting Standards Executive Committee (1996-1997) G. Michael Crooch, Chair James F. Harrington Philip D. Ameen R. Larry Johnson James L. Brown David B. Kaplan Joseph H. Cappalonga James W. Ledwith John C. Compton Louis W. Matusiak, Jr. Leslie A. Coolidge James P. McComb Edmund Coulson Charles L. McDonald Roger H. Molvar Software Revenue Recognition Working Group George P. Fritz, Chair H. John Dirks Michele Axelson Jerry Masters AICPA Staff Jane B. Adams, Director Richard Stuart, Technical Manager The Accounting Standards Executive Committee and the Software Revenue Recognition Working Group gratefully acknowledge the contributions of the former Software Revenue Recognition Task Force members Joseph Lhotka, Naomi Erickson, James Gillespie, Francis O Brien, and Paul Wilde in the development of this Statement of Position. Software Revenue Recognition A-44

Note fn 1 1 Terms defined in the glossary are set in boldface type the first time they appear in this SOP. Note fn 2 2 Indicators of whether software is incidental to a product as a whole include (but are not limited to) (a) whether the software is a significant focus of the marketing effort or is sold separately, (b) whether the vendor is providing postcontract customer support, and (c) whether the vendor incurs significant costs that are within the scope of FASB Statement No. 86, Accounting for the Costs of Computer Software to Be Sold, Leased, or Otherwise Marketed. An example of the applicability of this SOP to revenue earned on products containing software is included in appendix A [paragraph.146]. Note fn 3 3 As discussed in paragraph.09, arrangements may include multiple elements. If the discount or other concessions in an arrangement are more than insignificant, a presumption is created that an additional element(s) (as defined in paragraph.09) is being offered in the arrangement. Note fn 4 4 If a software arrangement includes services that meet the criteria discussed in paragraph.65 of this SOP, those services should be accounted for separately. Note fn 5 5 The term probable is used in this SOP with the same definition as used in FASB Statement No. 5, Accounting for Contingencies. Note fn 6 6 This does not apply to changes in the estimated percentage of customers not expected to exercise an upgrade right. See paragraph.37. Note fn 7 7 Contractual arrangements under which the reseller is obligated to pay only as and if sales are made to users should be accounted for as consignments. Note fn 8 8 The evaluation of whether the level of uncertainty of possible cancellation is remote should be consistent with FASB Statement No. 5, which defines remote as relating to conditions in which the chance of the future event or events occurring is slight. Software Revenue Recognition A-45

Appendix B: Statement of Position 98-4, Deferral of the Effective Date of SOP 97-2, Software Revenue Recognition March 31, 1998 Issued by the Accounting Standards Executive Committee American Institute of Certified Public Accountants Note Statements of Position (SOPs) on accounting issues present the conclusions of at least two-thirds of the Accounting Standards Executive Committee, which is the senior technical body of the Institute authorized to speak for the Institute in the areas of financial accounting and reporting. Statement on Auditing Standards No. 69, The Meaning of Present Fairly in Conformity With Generally Accepted Accounting Principles, identifies AICPA SOPs that have been cleared by the Financial Accounting Standards Board as sources of established accounting principles in category b of the hierarchy of generally accepted accounting principles that it establishes. AICPA members should consider the accounting principles in this SOP if a different accounting treatment of a transaction or event is not specified by a pronouncement covered by Rule 203 of the AICPA Code of Professional Conduct. In such circumstances, the accounting treatment specified by the SOP should be used, or the member should be prepared to justify a conclusion that another treatment better presents the substance of the transaction in the circumstances. SOP 98-4 is amended by SOP 98-9, Modification of SOP 97-2, Software Revenue Recognition, With Respect to Certain Transactions. The provisions of this SOP that extend the deferral of the application of certain passages of SOP 97-2 are effective December 15, 1998. All other provisions of this SOP are effective for transactions entered into in fiscal years beginning after March 15, 1999. Earlier adoption is permitted as of the beginning of fiscal years or interior periods for which financial statements or information has not been issued. Retroactive application of the provisions of this SOP is prohibited. Copyright 1998 by American Institute of Certified Public Accountants, Inc., New York, NY 10036-8775 All rights reserved. For information about the procedure for requesting permission to make copies of any part of this work, please call the AICPA Copyright Permissions Hotline at 201-938-3245. A Permissions Request Form for emailing requests is available at www.aicpa.org by clicking on the copyright notice on any page. Software Revenue Recognition B-1

Table of Contents Paragraphs Summary Forward Introduction and Background 1-3 Scope 4 Conclusions 5-6 Effective Date and Transition 7 Basis for Conclusions 8-15 Effective Date 16 Transition 17 Appendix Response to Comments Received A.1-A.3 Software Revenue Recognition B-2

Summary This Statement of Position (SOP) defers for one year the application of the following passages in SOP 97-2 [section 10,700], which limit what is considered vendor-specific objective evidence (VSOE) of the fair value of the various elements in a multiple-element arrangement: (a) the second sentences of paragraphs 10, 37, 41, and 57 [section 10,700.10,.37,.41, and.57], (b) example 3 in Multiple-Element Arrangements Products (appendix A [section 10,700.146]), and (c) example 3 in Multiple-Element Arrangement Products and Services (appendix A [section 10,700.146]). All other provisions of SOP 97-2 [section 10,700] remain in effect. This SOP applies to all multiple-element software arrangements, as defined in paragraph 9 of SOP 97-2 [section 10,700.09], and is effective as of March 31, 1998. If an enterprise had applied SOP 97-2 [section 10,700] in an earlier period for financial statements or information already issued prior to the promulgation of this SOP, amounts reported in those financial statements or as part of that information may be restated to reflect the deferral of the effective date of the second sentences of paragraphs 10, 37, 41, and 57 of SOP 97-2 [section 10,700.10,.37,.41, and.57] and the related examples. Forward The accounting guidance contained in this document has been cleared by the Financial Accounting Standards Board (FASB). The procedure for clearing accounting guidance in documents issued by the Accounting Standards Executive Committee (AcSEC) involves the FASB reviewing and discussing in public board meetings (a) a prospectus for a project to develop a document, (b) a proposed exposure draft that has been approved by at least ten of AcSEC s fifteen members, and (c) a proposed final document that has been approved by at least ten of AcSEC s fifteen members. The document is cleared if at least five of the seven FASB members do not object to AcSEC undertaking the project, issuing the proposed exposure draft, or after considering the input received by AcSEC as a result of the issuance of the exposure draft, issuing a final document. The criteria applied by the FASB in their review of proposed projects and proposed documents include the following: a. The proposal does not conflict with current or proposed accounting requirements, unless it is a limited circumstance, usually in specialized industry accounting, and the proposal adequately justifies the departure. b. The proposal will result in an improvement in practice. c. The AICPA demonstrates the need for the proposal. d. The benefits of the proposal are expected to exceed the costs of applying it. In many situations, prior to clearance, the FASB will propose suggestions, many of which are included in the documents. Introduction and Background.01 On October 27, 1997, the AICPA Accounting Standards Executive Committee (AcSEC) issued Statement of Position (SOP) 97-2, Software Revenue Recognition [section 10,700]..02 The first two sentences of paragraph 10 of SOP 97-2 [section 10,700.10] state: If an arrangement includes multiple elements, the fee should be allocated to the various elements based on vendor-specific objective evidence of fair value, regardless of any separate prices stated within the contract for each element. Vendor-specific objective evidence of fair value is limited to the following: The price charged when the same element is sold separately; and For an element not yet being sold separately, the price established by management having the relevant authority; it must be probable that the price, once established, will not change before the separate introduction of the element into the marketplace. Software Revenue Recognition B-3

.03 This SOP defers for one year the application of the following passages in SOP 97-2 [section 10,700], which limit what is considered vendor-specific objective evidence (VSOE) of the fair value of the various elements in a multiple-element arrangement: (a) the second sentences of paragraphs 10, 37, 41, and 57 [section 10,700.10,.37,.41, and.57], (b) example 3 in Multiple- Element Arrangements Products (appendix A [section 10,700.146]), and (c) example 3 in Multiple-Element Arrangements Products and Services (appendix A [section 10,700.146]). Scope.04 This SOP applies to all multiple-element software arrangements, as defined in paragraph 9 of SOP 97-2 [section 10,700.09]. Such multiple-element arrangements include all software arrangements that provide licenses for multiple software deliverables such as software products, upgrades/enhancements, postcontract customer support (PCS), or services. Conclusions.05 The second sentences of paragraphs 10, 37, 41, and 57 of SOP 97-2 [section 10,700.10,.37,.41, and.57], which limit what is considered VSOE [vendor-specific objective evidence] of the fair value of the various elements in a multiple-element arrangement, and the related examples noted in paragraph.03 of this SOP need not be applied to transactions entered into before fiscal years beginning after March 15, 1999. [As amended, effective for transactions entered into in fiscal years beginning after March 15, 1999, by Statement of Position 98-9.].06 All other provisions of SOP 97-2 [section 10,700], including the remainder of paragraph 10 [section 10,700.10], should be applied as stated in SOP 97-2 [section 10,700]. Accordingly, this SOP does not alter the requirements that (a) any allocation of the fee in a multiple-element arrangement to the various elements should be based on the fair values of each element, (b) those fair values must be supported by VSOE, and (c) in instances where there is insufficient VSOE of the fair values of each element to allow for an allocation of revenue to each element, all revenue from the arrangement should be deferred pursuant to paragraph 12 [section 10,700.12] of that SOP. Effective Date and Transition.07 This SOP is effective as of March 31, 1998. If an enterprise had applied SOP 97-2 [section 10,700] in an earlier period for financial statements or information already issued prior to the promulgation of this SOP, amounts reported in those financial statements or as part of that information may be restated to reflect the deferral of the effective date of the second sentences of paragraphs 10, 37, 41, and 57 of SOP 97-2 [section 10,700.10,.37,.41, and.57] and the related examples noted in paragraph.03 of this SOP. The provisions of this Statement need not be applied to immaterial items. Basis for Conclusions.08 Paragraph 10 of SOP 97-2 [section 10,700.10] establishes that the fee in a multiple-element arrangement should be allocated to the various elements based on VSOE of fair values. The second sentence of paragraph 10 [section 10,700.10] adds that evidence of VSOE of fair values is limited to the price charged when the same element is sold separately or is to be sold separately..09 In developing the unbundling guidance in SOP 97-2 [section 10,700], AcSEC emphasized the need for VSOE of each element s fair value to properly recognize revenue upon delivery of each element. That principle remains unchanged. Software Revenue Recognition B-4

.10 AcSEC concluded that the best evidence of the fair value of an element is the price charged for that element when it is sold separately. Some have argued, however, that conclusions with respect to the best evidence should not preclude revenue recognition when the fair value of an element can be determined by reference to other vendor-specific objective information..11 Financial Accounting Standards Board (FASB) Statement of Financial Accounting Concepts No. 2, Qualitative Characteristics of Accounting Information, states the following in paragraphs 95 and 96: Conservatism no longer requires deferring recognition of income beyond the time that adequate evidence of its existence becomes available or justifies recognizing losses before there is adequate evidence that they have been incurred. The Board emphasizes that any attempt to understate results consistently is likely to raise questions about the reliability and the integrity of information about those results and will probably be self-defeating in the long run. That kind of reporting, however well-intentioned, is not consistent with the desirable characteristics described in this Statement. On the other hand, the Board also emphasizes that imprudent reporting, such as may be reflected, for example, in overly optimistic estimates of realization, is certainly no less inconsistent with those characteristics. Bias in estimating components of earnings, whether overly conservative or unconservative, usually influences the timing of earnings or losses rather than their aggregate amount. As a result, unjustified excesses in either direction may mislead one group of investors to the possible benefit or detriment of others..12 Subsequent to the issuance of SOP 97-2 [section 10,700], several examples of multipleelement arrangements were brought to AcSEC s attention in which the application of the limitations on VSOE of fair values in paragraph 10 of SOP 97-2 [section 10,700.10] would not allow unbundling and, as a result, may produce an unduly conservative pattern of revenue recognition. Those examples include the following: Software is sold only, or substantially always, in combination with PCS or other elements and there is VSOE of the fair value of the PCS or other elements and of the total arrangement. The restrictions in paragraph 10 of SOP 97-2 [section 10,700.10] led some to the conclusion that VSOE of fair value does not exist for the software element because that element is not sold separately. Pursuant to paragraph 12 of SOP 97-2 [section 10,700.12], revenue for the entire fee, representing the value of both the software and PCS or other elements, would be recognized ratably over the period during which the obligations are discharged, even if the software product has been delivered. PCS or other elements are sold only, or substantially always, in combination with software in transactions for which there is VSOE of the fair value of the software and of the total arrangement. Paragraph 10 of SOP 97-2 [section 10,700.10] led some to the conclusion that VSOE of fair value does not exist for the PCS element in such circumstances, because that element is not sold separately (nor has a price been established in anticipation of separate introduction of PCS into the marketplace). Revenue for the entire fee would be recognized ratably over the period during which the PCS obligations are discharged, even if the software product has been delivered. Multi-year PCS is included in a multiple-element transaction in situations in which PCS renewals are sold only for periods of one year. Paragraph 10 of SOP 97-2 [section 10,700.10] could lead to the conclusion that VSOE does not exist for the multi-year PCS because PCS renewals are sold separately only for one-year periods. Pursuant to paragraph 12 of SOP 97-2 [section 10,700.12], revenue for the entire fee would be recognized ratably over the period during which the PCS obligations are discharged. Software Revenue Recognition B-5

AcSEC considered the FASB guidance contained above in FASB Concepts Statement No. 2 and certain examples of transactions as presented above. AcSEC concluded that, although the best evidence of fair value of an element is the price charged for that element when it is sold separately, requiring deferral of recognition of revenue related to the delivered element when there is sufficient other VSOE of fair value to support the allocation of the fee to the various elements may be unduly conservative. Therefore, AcSEC concluded that the application of the second sentences of paragraphs 10, 37, 41, and 57 of SOP 97-2 [section 10,700.10,.37,.41, and.57] should be deferred for one year pending reconsideration by AcSEC..13 AcSEC notes that the requirement in the first sentence of paragraph 10 of SOP 97-2 [section 10,700.10] remains in effect during this deferral period, that is, revenues from a multiple-element arrangement should be allocated to each element on the basis of its fair value. This allocation principle is consistent with analogous provisions in other areas of accounting literature directed to multiple-element arrangements. Paragraph 99 of SOP 97-2 [section 10,700.99] cites the requirements of FASB Statement No. 45, Accounting for Franchise Fee Revenue, as one such example. Another example is the consensus on FASB s Emerging Issues Task Force (EITF) Issue 97-13, Accounting for Costs Incurred in Connection with a Consulting Contract or an Internal Project That Combines Business Process Reengineering and Information Technology Transformation, which requires allocation of third-party consulting costs to different activities based on the relative fair values of the separate activities. A further requirement imposed by the first sentence of paragraph 10 of SOP 97-2 [section 10,700.10] is that the amounts determined to be fair value need to be supported by VSOE. The basis for such a conclusion is set forth in paragraph 100 of SOP 97-2 [section 10,700.100]..14 There may be situations in which VSOE of the fair value of each element does not exist. Not all vendor-specific evidence is sufficiently objective and reliable to support a conclusion as to the fair value of an element. For example, amounts set forth for software products on a published price list may not represent customary sales prices. In the absence of representative selling prices, VSOE may not exist..15 It is AcSEC s intention to immediately begin a project to consider whether guidance is needed on any restrictions that should be placed on VSOE of fair value and, if so, what that guidance should be. Deferral of the second sentence of paragraph 10 of SOP 97-2 [section 10,700.10] will allow AcSEC sufficient time to reconsider its conclusions. Positions of AcSEC are determined through committee procedures, due process, and deliberation. Accordingly, this deferral should not be construed as a conclusion that AcSEC will amend SOP 97-2 [section 10,700]. AcSEC intends to complete its deliberations and, if determined appropriate, issue an SOP before the end of 1998. Effective Date.16 SOP 97-2 [section 10,700] was issued on October 27, 1997, and is effective for transactions in fiscal years beginning after December 15, 1997. This SOP is being issued before the end of the earliest three-month period for which SOP 97-2 [section 10,700] must be applied. Consequently, it is appropriate for this SOP to be effective upon issuance. Transition.17 Paragraph 92 of SOP 97-2 [section 10,700.92] prohibits retroactive application but encourages early application as of the beginning of a fiscal year or interim period for which financial statements or interim information have not been issued. AcSEC believes that permitting entities that may have adopted the SOP early to restate previously issued financial statements or information to reflect simultaneous adoption of SOP 97-2 [section 10,700] and this SOP will improve comparability among reporting entities. AcSEC believes that very few, if any, entities will be affected by the retroactive restatement provisions of this SOP. Software Revenue Recognition B-6

.18 Appendix Response to Comments Received A.1. On February 11, 1998, AcSEC issued an exposure draft of a proposed Statement of Position (SOP), Deferral of the Effective Date of Certain Provisions of SOP 97-2, Software Revenue Recognition, for Certain Transactions. The exposure draft proposed deferring the effective date of the provisions of paragraph 10 of SOP 97-2 [section 10,700.10] with respect to what constitutes vendor-specific objective evidence (VSOE) of fair value of the software element in multipleelement arrangements in which: a. A software element is sold only in combination with postcontract customer support (PCS) or other service element(s) that qualify for separate accounting pursuant to SOP 97-2 [section 10,700], or both. b. There is VSOE of the fair values of each of the service elements determined pursuant to paragraphs 10, 57, and 65 of SOP 97-2 [section 10,700.10,.57, and.65]. A.2. None of the commentators on that exposure draft objected to deferral of the effective date of paragraph 10 of SOP 97-2 [section 10,700.10] with respect to multiple-element arrangements within the scope proposed in the exposure draft. A significant number of commentators were concerned, however, about the implications of restricting the scope to only certain multipleelement arrangements, and they urged AcSEC to broaden the scope to all multiple-element arrangements. A.3. As a result of AcSEC s deliberations of the comment letters and examples of arrangements brought to AcSEC s attention, AcSEC: a. Concluded that, for arrangements for which there is sufficient VSOE of the fair value of each element, even if each element is not sold separately, the basis for deferral of revenue recognition with respect to those elements that otherwise satisfied the criteria for revenue recognition in SOP 97-2 [section 10,700] needs to be reconsidered. Accordingly, AcSEC expanded the deferral to all arrangements discussed in paragraph.04 of this SOP, not just those arrangements described in paragraph A.1. of this SOP. b. Affirmed the requirement in SOP 97-2 [section 10,700] that any allocation of the fee in a multiple-element arrangement to the various elements should be based on fair values of each element and that such fair values must be supported by VSOE, thus reinforcing the applicability of that requirement to all arrangements. Software Revenue Recognition B-7

Accounting Standards Executive Committee (1997-1998) David B. Kaplan, Chair James W. Ledwith Mark M. Beilstein Louis W. Matusiak, Jr. James L. Brown James P. McComb Joseph H. Cappalonga Charles L. McDonald Robert O. Dale Roger H. Molvar Joseph F. Graziano David M. Morris James F. Harrington Benjamin S. Neuhausen Mark V. Sever Software Revenue Recognition Working Group George P. Fritz, Chair H. John Dirks Michele Axelson Jerry Masters AICPA Staff Elizabeth A. Fender, Director Frederick Gill, Senior Technical Manager Software Revenue Recognition B-8

Appendix C: Statement of Position 98-9, Modification of SOP 97-2, Software Revenue Recognition, with Respect to Certain Transactions December 22, 1998 Issued by the Accounting Standards Executive Committee American Institute of Certified Public Accountants Note Statements of Position on accounting issues present the conclusions of at least two-thirds of the Accounting Standards Executive Committee, which is the senior technical body of the Institute authorized to speak for the Institute in the areas of financial accounting and reporting. Statement on Auditing Standards No. 69, The Meaning of Present Fairly in Conformity With Generally Accepted Accounting Principles, identifies AICPA Statements of Position that have been cleared by the Financial Accounting Standards Board as sources of established accounting principles in category b of the hierarchy of generally accepted accounting principles that it establishes. AICPA members should consider the accounting principles in this Statement of Position if a different accounting treatment of a transaction or event is not specified by a pronouncement covered by Rule 203 of the AICPA Code of Professional Conduct. In such circumstances, the accounting treatment specified by the Statement of Position should be used, or the member should be prepared to justify a conclusion that another treatment better presents the substance of the transaction in the circumstances. Copyright 1998 by American Institute of Certified Public Accountants, Inc., New York, NY 10036-8775 All rights reserved. For information about the procedure for requesting permission to make copies of any part of this work, please call the AICPA Copyright Permissions Hotline at 201-938-3245. A Permissions Request Form for emailing requests is available at www.aicpa.org by clicking on the copyright notice on any page. Software Revenue Recognition C-1

Table of Contents Paragraphs Summary Forward Introduction and Background 1-4 Scope 5 Conclusions 6-8 Effective Date and Transition 9 Background Information and Basis for Conclusions 10-25 Effective Date and Transition 26-29 Due Process 30-31 Software Revenue Recognition C-2

Summary This Statement of Position (SOP) amends paragraphs 11 and 12 of SOP 97-2, Software Revenue Recognition [section 10,700.11 and.12], to require recognition of revenue using the residual method when (1) there is vendor-specific objective evidence of the fair values of all undelivered elements in a multiple-element arrangement that is not accounted for using long-term contract accounting, (2) vendor-specific objective evidence of fair value does not exist for one or more of the delivered elements in the arrangement, and (3) all revenue recognition criteria in SOP 97-2 [section 10,700] other than the requirement for vendor-specific objective evidence of the fair value of each delivered element of the arrangement are satisfied. Under the residual method, the arrangement fee is recognized as follows: (1) the total fair value of the undelivered elements, as indicated by vendor-specific objective evidence, is deferred and subsequently recognized in accordance with the relevant sections of SOP 97-2 [section 10,700] and (2) the difference between the total arrangement fee and the amount deferred for the undelivered elements is recognized as revenue related to the delivered elements. Effective December 15, 1998, this SOP amends SOP 98-4, Deferral of the Effective Date of a Provision of SOP 97-2, Software Revenue Recognition [section 10,740], to extend the deferral of the application of certain passages of SOP 97-2 [section 10,700] provided by SOP 98-4 [section 10,740] through fiscal years beginning on or before March 15, 1999. All other provisions of this SOP are effective for transactions entered into in fiscal years beginning after March 15, 1999. Earlier adoption is permitted as of the beginning of fiscal years or interim periods for which financial statements or information has not been issued. Retroactive application of the provisions of this SOP is prohibited. Forward The accounting guidance contained in this document has been cleared by the Financial Accounting Standards Board (FASB). The procedure for clearing accounting guidance in documents issued by the Accounting Standards Executive Committee (AcSEC) involves the FASB reviewing and discussing in public board meetings (1) a prospectus for a project to develop a document, (2) a proposed exposure draft that has been approved by at least ten of AcSEC s fifteen members, and (3) a proposed final document that has been approved by at least ten of AcSEC s fifteen members. The document is cleared if at least five of the seven FASB members do not object to AcSEC undertaking the project, issuing the proposed exposure draft, or after considering the input received by AcSEC as a result of the issuance of the exposure draft, issuing a final document. The criteria applied by the FASB in their review of proposed projects and proposed documents include the following. 1. The proposal does not conflict with current or proposed accounting requirements, unless it is a limited circumstance, usually in specialized industry accounting, and the proposal adequately justifies the departure. 2. The proposal will result in an improvement in practice. 3. The AICPA demonstrates the need for the proposal. 4. The benefits of the proposal are expected to exceed the costs of applying it. In many situations, prior to clearance, the FASB will propose suggestions, many of which are included in the documents. Introduction and Background.01 On October 27, 1997, the AICPA Accounting Standards Executive Committee (AcSEC) issued Statement of Position (SOP) 97-2, Software Revenue Recognition [section 10,700]. Software Revenue Recognition C-3

.02 Paragraph 10 of SOP 97-2 [section 10,700.10] states that, if an arrangement includes multiple elements, the fee should be allocated to the various elements based on vendor-specific objective evidence of fair value. Vendor-specific objective evidence of fair value is limited to the following: a. The price charged when the same element is sold separately; and b. For an element not yet being sold separately, the price established by management having the relevant authority (it must be probable that the price, once established, will not change before the separate introduction of the element into the marketplace)..03 Paragraph 12 of SOP 97-2 [section 10,700.12] requires deferral of all revenue from multipleelement arrangements that are not accounted for using long-term contract accounting if sufficient vendor-specific objective evidence does not exist for the allocation of revenue to the various elements of the arrangement..04 This SOP amends that guidance to require recognition of revenue in accordance with the residual method in the limited circumstances described in paragraph.05 of this SOP. Scope.05 This SOP applies only to multiple-element arrangements in which (a) a software element or other delivered element is sold only in combination with one or more other elements that qualify for separate accounting pursuant to SOP 97-2 [section 10,700], (b) vendor-specific objective evidence of fair value does not exist for one or more of the delivered elements, and (c) there is vendor-specific objective evidence of the fair value of each of the undelivered elements determined pursuant to paragraphs 10, 37, 57, and 66 of SOP 97-2 [section 10,700.10,.37,.57, and.66]. Conclusions.06 The following changes are made to SOP 97-2 [section 10,700]. a. The following sentence is added to the end of paragraph 11 of SOP 97-2 [section 10,700.11]. Moreover, to the extent that a discount exists, the residual method described in paragraph 12 [of SOP 97-2] attributes that discount entirely to the delivered elements. b. The following is added to the end of paragraph 12 of SOP 97-2 [section 10,700.12]. There may be instances in which there is vendor-specific objective evidence of the fair values of all undelivered elements in an arrangement but vendor-specific objective evidence of fair value does not exist for one or more of the delivered elements in the arrangement. In such instances, the fee should be recognized using the residual method, provided that (a) all other applicable revenue recognition criteria in this SOP [SOP 97-2] are met and (b) the fair value of all of the undelivered elements is less than the arrangement fee. Under the residual method, the arrangement fee is recognized as follows: (a) the total fair value of the undelivered elements, as indicated by vendorspecific objective evidence, is deferred and (b) the difference between the total arrangement fee and the amount deferred for the undelivered elements is recognized as revenue related to the delivered elements. c. The following example is added to appendix A of SOP 97-2 [section 10,700.146], following Multiple-Element Arrangements Products and Services Example 3. Multiple-Element Arrangements Products and Services Example 4 Facts: A vendor sells software product A for $950. The license arrangement for product A always includes one year of free PCS. The annual renewal price of PCS is $150. Software Revenue Recognition C-4

Revenue Recognition: Assuming that, apart from the lack of vendor-specific objective evidence of the fair value of the delivered software element, all applicable revenue recognition criteria in this SOP [SOP 97-2] are met, revenue in the amount of $150 should be deferred and recognized in income over the oneyear PCS service period. Revenue of $800 should be allocated to the software element and recognized upon delivery of the software. Discussion: Vendor-specific objective evidence of the fair value of the software does not exist because the software is never sold separately. Consequently, sufficient vendor-specific objective evidence of fair value does not exist for the allocation of revenue to the various elements based on their relative fair values. Paragraph 12 of this SOP [SOP 97-2][section 10,700.12] states, however, that the residual method should be used when there is vendor-specific objective evidence of the fair values of all undelivered elements; all other applicable revenue recognition criteria in this SOP [SOP 97-2] are met; and the fair value of all of the undelivered elements is less than the total arrangement fee. If there had been vendor-specific objective evidence of the fair value of the delivered software but not of the undelivered PCS, the entire arrangement fee would be deferred and recognized ratably over the contractual PCS period in accordance with paragraphs.12 and.58 [of SOP 97-2] [section 10,700.12 and.58]..07 Paragraph 5 of SOP 98-4, Deferral of the Effective Date of a Provision of SOP 97-2, Software Revenue Recognition [section 10,740.05], is replaced with the following: The second sentences of paragraphs 10, 37, 41, and 57 of SOP 97-2 [section 10.700.10,.37,.41, and.57] which limit what is considered VSOE [vendor-specific objective evidence] of the fair value of the various elements in a multiple-element arrangement, and the related examples noted in paragraph 3 of this SOP [SOP 98-4][section 10,740.03] need not be applied to transactions entered into before fiscal years beginning after March 15, 1999..08 All provisions of SOP 97-2 [section 10,700] for software transactions outside the scope of this SOP and all other provisions of SOP 97-2 [section 10,700] for transactions within the scope of this SOP should be applied as stated in SOP 97-2 [section 10,700]. Effective Date and Transition.09 The provisions of this SOP that extend the deferral of the application of certain passages of SOP 97-2 [section 10,700] are effective December 15, 1998. All other provisions of this SOP are effective for transactions entered into in fiscal years beginning after March 15, 1999. Earlier adoption is permitted as of the beginning of fiscal years or interim periods for which financial statements or information has not been issued. Retroactive application of the provisions of this SOP is prohibited. The provisions of this Statement need not be applied to immaterial items. Background Information and Basis for Conclusions.10 SOP 97-2, Software Revenue Recognition [section 10,700], was issued on October 27, 1997 and became effective for transactions entered into in fiscal years beginning after December 15, 1997, with earlier application encouraged. Software Revenue Recognition C-5

.11 Paragraph 10 of SOP 97-2 [section 10,700.10] provides that, if a software arrangement includes multiple elements, the fee should be allocated to the various elements based on vendorspecific objective evidence of fair value. Paragraph 12 of SOP 97-2 [section 10,700.12] provides that, if sufficient vendor-specific objective evidence of fair value does not exist for the allocation of revenue to the various elements of the arrangement, all revenue from the arrangement should be deferred..12 Paragraph 10 of SOP 97-2 [section 10,700.10] establishes only two conditions that constitute vendor-specific objective evidence of fair value. Neither of those conditions allows for the determination of the fair value of an element of a multiple-element arrangement that is never sold separately. A consequence of not having separate sales of one or more elements under SOP 97-2 [section 10,700], as issued, is that all revenue from such an arrangement would be deferred in accordance with paragraph 12 of SOP 97-2 [section 10,700.12]..13 In developing the unbundling guidance in SOP 97-2 [section 10,700], AcSEC deliberated the need for verifiable fair values of each of the elements. AcSEC did not support permitting allocation of the sales price of the package of elements to the individual elements using differential measurement, in which an amount to allocate to an element for which there is no separate vendor-specific objective evidence of fair value is inferred by reference to the fair values of elements for which there is vendor-specific objective evidence of fair value and the fair value of the total arrangement.fn1 AcSEC was concerned that, under differential measurement, any difference between the fair values of the individual elements when sold separately and the fair value of the elements when sold as a package (that is, a discount) would be allocated entirely to undelivered elements, possibly resulting in a significant overstatement of reported revenue in the period in which the software is delivered..14 In arriving at its conclusion in SOP 97-2 [section 10,700], AcSEC did not deliberate situations in which software or other delivered elements would always be sold with one or more services or other undelivered elements that qualify for separate accounting. In such situations, there could be vendor-specific objective evidence of the fair value of the undelivered elements when sold separately (for example, by reference to renewal PCS or to the price for user training that is sold separately). Application of the conclusions in paragraph 10 of SOP 97-2 [section 10,700.10], however, would have resulted in a determination that there was not vendor-specific objective evidence of the fair value of the delivered element (for example, software). The provisions in paragraph 12 of SOP 97-2 [section 10,700.12] would have required the initial deferral of all revenue from such arrangements..15 Subsequent to the issuance of SOP 97-2 [section 10,700], some AcSEC members came to believe that it is inappropriate to defer all revenue from the arrangement in such situations, because the use of the residual method would result in allocation of any discount entirely to the delivered element. Thus, there would be no potential for overstatement of revenue at the time of initial delivery of the software element. Indeed, it had been argued that recognizing no revenue from the delivered software element in such circumstances would inappropriately understate reported income..16 AcSEC considered this matter in light of paragraphs 95 and 96 of Financial Accounting Standards Board (FASB) Statement of Financial Accounting Concepts No. 2, Qualitative Characteristics of Accounting Information. Those paragraphs state the following: Conservatism no longer requires deferring recognition of income beyond the time that adequate evidence of its existence becomes available or justifies recognizing losses before there is adequate evidence that they have been incurred. Software Revenue Recognition C-6

The Board emphasizes that any attempt to understate results consistently is likely to raise questions about the reliability and the integrity of information about those results and will probably be self-defeating in the long run. That kind of reporting, however well-intentioned, is not consistent with the desirable characteristics described in this Statement. On the other hand, the Board also emphasizes that imprudent reporting, such as may be reflected, for example, in overly optimistic estimates of realization, is certainly no less inconsistent with those characteristics. Bias in estimating components of earnings, whether overly conservative or unconservative, usually influences the timing of earnings or losses rather than their aggregate amount. As a result, unjustified excesses in either direction may mislead one group of investors to the possible benefit or detriment of others..17 On February 11, 1998, AcSEC issued an exposure draft of a proposed SOP, Deferral of the Effective Date of Certain Provisions of SOP 97-2, Software Revenue Recognition, for Certain Transactions. The exposure draft proposed deferring the effective date of the provisions of paragraph 10 of SOP 97-2 [section 10,700.10] with respect to what constitutes vendor-specific objective evidence of fair value of the software element in multiple-element arrangements in which: a. A software element is sold only in combination with PCS or other service elements that qualify for separate accounting pursuant to SOP 97-2 [section 10,700], or both. b. There is vendor-specific objective evidence of the fair value of each of the service elements determined pursuant to paragraphs 10, 57, and 65 of SOP 97-2 [section 10,700.10,.57 and.65]..18 None of the commentators on that exposure draft objected to deferral of the effective date of paragraph 10 of SOP 97-2 [section 10,700.10] with respect to multiple-element arrangements within the scope proposed in the exposure draft. A significant number of commentators were concerned, however, about the implications of restricting the scope to only certain multipleelement arrangements, and they urged AcSEC to broaden the scope to all multiple-element arrangements..19 As a result of AcSEC s deliberations of the comment letters on the February 11, 1998, exposure draft and examples of arrangements brought to AcSEC s attention, AcSEC a. Concluded that, for arrangements for which there is sufficient vendor-specific objective evidence of the fair value of each element, even if each element is not sold separately, the basis for deferral of revenue recognition with respect to those elements that otherwise satisfied the criteria for revenue recognition in SOP 97-2 [section 10,700] needed to be reconsidered. Accordingly, AcSEC expanded the deferral to encompass all multipleelement software arrangements. b. Affirmed the requirement in SOP 97-2 [section 10,700] that any allocation of the fee in a multiple-element arrangement to the various elements should be based on fair values of each element and that such fair values must be supported by vendor-specific objective evidence, thus reinforcing the applicability of that requirement to all arrangements. These conclusions were set forth in SOP 98-4, Deferral of the Effective Date of a Provision of SOP 97-2, Software Revenue Recognition [section 10,740]..20 On July 31, 1998, AcSEC issued an exposure draft of an SOP, Modification of the Limitations on Evidence of Fair Value in Software Arrangements (A proposed amendment to SOP 97-2, Software Revenue Recognition). That exposure draft proposed rescinding the second sentences of paragraphs 10, 37, 41, and 57 of SOP 97-2 [section 10,700.10,.37,.41, and.57]. Further, the exposure draft proposed that vendor-specific objective evidence of the fair value of any one element of an arrangement could be inferred by reference to vendor-specific objective evidence of the fair value of the remaining elements in the arrangement and vendor-specific objective evidence of the fair value of the total arrangement. An example in the exposure draft suggested that such vendor-specific objective evidence of the fair value of the total arrangement, which could differ from the arrangement fee, might be provided by sufficiently consistent pricing for the total arrangement in sales to other customers. Software Revenue Recognition C-7

.21 Under AcSEC s July 31, 1998 proposal, any difference between the fair value of the total arrangement and the arrangement fee (the discount) for the particular transaction would be allocated to each element in the arrangement based on each element s fair value without regard to the discount, in accordance with paragraph 11 of SOP 97-2 [section 10,700.11]..22 AcSEC received twenty comment letters on the exposure draft. Although none of the commentators opposed modification of the evidentiary requirements of the second sentence of paragraph 10 of SOP 97-2 [section 10,700.10], approximately half of the commentators requested further guidance on some aspect of what would constitute vendor-specific objective evidence of fair value and on some aspect of what might constitute consistent pricing. Five respondents requested reconsideration of the acceptability of methods, perhaps in addition to the exposure draft method, that would permit recognition of a minimum amount of revenue when vendor-specific objective evidence of fair value does not exist for each element in an arrangement or for the total arrangement..23 The Software Revenue Recognition Working Group, which had been advising AcSEC during this process continued to support the position in the exposure draft. However, AcSEC was troubled by the significant number of comment letters requesting more guidance on the terms consistent pricing and vendor-specific objective evidence. In addition, certain comment letters explained that determining vendor-specific objective evidence of fair value of total arrangements is difficult because, in many cases, each sale represents an independent negotiation. AcSEC believes that, because of the wide variety of facts and circumstances that influence individual transactions, not all of which can be anticipated, it cannot further define the term consistent pricing without making arbitrary decisions and drafting a multitude of rules. AcSEC believes that promulgating such specificity and arbitrary rules would be unwise. AcSEC was further troubled by the concept that there could be a fair value for a multiple-element arrangement that differs from the price paid for the total arrangement, which is negotiated between independent parties..24 AcSEC concluded, based on the information obtained during AcSEC s due process, that the approach proposed in the July 31, 1998, exposure draft was not operational for multiple-element software arrangements. This conclusion, combined with concerns about the potential for a disproportionate allocation of any discount on an arrangement to undelivered elements (possibly resulting in an overstatement of revenue reported in the period of initial delivery of the software), caused AcSEC to conclude that it should retain the limitations on evidence of fair value in SOP 97-2 [section 10,700]. AcSEC did agree, however, to provide for the use of the residual method in circumstances where there is vendor-specific objective evidence of the fair value of all the undelivered elements in an arrangement but there is not vendor-specific objective evidence of the fair value of one or more delivered elements..25 AcSEC notes that the residual method is not an acceptable alternative to allocation based on relative fair values when there is vendor-specific objective evidence of the fair value of each element in a multiple-element arrangement. AcSEC acknowledges that the residual method represents an exception to the revenue recognition model in SOP 97-2 [section 10,700] that the arrangement fee should be allocated on the basis of relative fair values. AcSEC believes, however, that, in the particular circumstances discussed in this SOP, recognition of some revenue for a delivered element is more appropriate than deferral of all revenue. Software Revenue Recognition C-8

Effective Date and Transition.26 AcSEC initially agreed that this SOP should be effective for transactions entered into in fiscal years beginning after December 15, 1998, the date on which the deferral of certain passages of SOP 97-2 [section 10,700] that is provided by SOP 98-4 [section 10,740] would have expired. However, several subsequent letters from the software industry stated that some software companies would have difficulty implementing this SOP (and the provisions of SOP 97-2 [section 10,700] that had been deferred for one year by SOP 98-4 [section 10,740]) by that date. In response, AcSEC agreed to change the effective date of this SOP to make it apply to transactions entered into in fiscal years beginning after March 15, 1999. Moreover, in order to avoid the need for two accounting changes, AcSEC agreed to amend SOP 98-4 [section 10,740] to extend the deferral period through fiscal years beginning on or before March 15, 1999. AcSEC believes that this additional three-month period is sufficient to permit companies to implement both this SOP and the passages of SOP 97-2 [section 10,700] that had been deferred by SOP 98-4 [section 10,740]..27 The transition provisions of both SOP 97-2 [section 10,700] and SOP 98-4 [section 10,740] are transaction based. It is, therefore, appropriate for this SOP to be applied on a prospective basis to transactions entered into in fiscal years beginning after March 15, 1999..28 The guidance that was deferred by SOP 98-4 [section 10,740] was to have been applied prospectively. As this SOP reinstates the guidance in SOP 97-2 [section 10,700] while adding one narrow exception, it is appropriate for this SOP to provide also for prospective application..29 Some entities may have adopted SOP 97-2 [section 10,700] before its December 15, 1997, effective date and, upon the issuance of SOP 98-4 [section 10,740], may have chosen not to restate their financial statements to reflect the deferral of the second sentences of paragraphs 10, 37, 41, and 57 of SOP 97-2 [section 10,700.10,.37,.41, and.57], as was permitted. Any differences in reported revenue pursuant to SOP 97-2 [section 10,700] from the revenue that would have been reported under SOP 97-2 [section 10,700] as amended by this SOP will reverse as the revenue recognition criteria are met for the undelivered elements of these arrangements. This is consistent with the transition methodology incorporated in SOP 97-2 [section 10,700]. AcSEC believes that it is therefore unnecessary to permit retroactive application of this SOP by any entities. Due Process.30 The exposure draft that preceded this SOP proposed rescinding the second sentences of paragraphs 10, 37, 41, and 57 of SOP 97-2 [section 10,700.10,.37,.41, and.57]. Further, the exposure draft proposed that vendor-specific objective evidence of the fair value of any one element of an arrangement could be inferred by reference to vendor-specific objective evidence of the fair value of the remaining elements in the arrangement and vendor-specific objective evidence of the fair value of the total arrangement. An example in the exposure draft suggested that such vendor-specific objective evidence of the fair value of the total arrangement, which could differ from the arrangement fee, might be provided by sufficiently consistent pricing for the total arrangement in sales to other customers..31 The July 31, 1998, exposure draft did not propose the use of the residual method that is required by this SOP. However, the comment letters on the exposure draft clearly identified perceived weaknesses in the proposed approach. The comment letters also included recommendations to adopt the residual method in addition to the proposed approach that AcSEC ultimately rejected. Moreover, AcSEC received and considered comments on the scope of the February 11, 1998 exposure draft, which was similar to the scope of this SOP. AcSEC concluded that it could reach an informed decision based on the comments received on the two exposure drafts, without issuing a revised exposure draft for public comment. Software Revenue Recognition C-9

Accounting Standards Executive Committee (1998-1999) David Kaplan, Chair Albert G. Adkins Mark M. Bielstein Cassandra A. Camp Joseph H. Cappalonga John T. Ciesielski Robert O. Dale Joseph F. Graziano Ray L. Krause Louis W. Matusiak, Jr. David M. Morris Benjamin S. Neuhausen Paula C. Panik Mark V. Sever Mary Stone Software Revenue Recognition Working Group George P. Fritz, Chair H. John Dirks Michele Axelson Jerry Masters AICPA Staff Elizabeth A. Fender, Director, Accounting Standards Frederick Gill, Senior Technical Manager, Accounting Standards Software Revenue Recognition C-10

Appendix D: Technical Practice Aids for SOP 97-2, Software Revenue Recognition Questions and Answers The AICPA Staff, helped by industry experts, released a fifth set of technical questions and answers (Q&As) on financial accounting and reporting issues related to Statement of Position (SOP) 97-2, Software Revenue Recognition. For the convenience of interested parties, the fifth set of Q&As are included with previously released Q&As. Following is the release date for each set of Q&As: TPAs 5100.38-.44 (1/8/99); TPAs 5100.45-.49 (11/5/99); TPAs 5100.50-.59 (5/8/00); TPAs 5100.60-.69 (12/29/00); TPAs 5100.70-.74 (5/24/02); and TPAs 5100.75-.76 (2/7/03). The Staff may continue to issue Q&As on software revenue as issues arise. Q&As will be housed in the AICPA publication titled, Technical Practice Aids, copies of which are available through the AICPA order department at (888) 777-7077. In addition, the Q&As will be placed in the accounting standards part of the AICPA Web site (http://www.aicpa.org/members/div/acctstd/general/ othitem.htm). Questions on these Q&As may be sent to Dan Noll via e-mail (mailto:dnoll@aicpa.org). TPA 5100.38 Subsequent event related to vendor-specific objective evidence for software revenue recognition Inquiry Vendor-specific objective evidence (VSOE) of fair value may be established by management after the balance sheet date but before the issuance of the financial statements, either by separate sales or by establishment of a price by a pricing committee. May an entity use such evidence to recognize revenue at the balance sheet date in accordance with SOP 97-2, Software Revenue Recognition? Reply No. Establishment of VSOE after the balance sheet date is a Type II subsequent event, as discussed in Professional Standards AU Section 560, Subsequent Events. As a result, revenue should be deferred at the balance sheet date in accordance with paragraph 12 of SOP 97-2, as amended by SOP 98-9 (Modification of SOP 97-2, Software Revenue Recognition, With Respect to Certain Transactions). However, if subsequent to the balance sheet date, management merely compiles evidence that existed at the balance sheet date, that evidence should be used to assess whether there is sufficient VSOE (in accordance with paragraph 10 of SOP 97-2) to recognize revenue at the balance sheet date. TPA 5100.39 Software revenue recognition for multiple-element arrangements Inquiry Software vendors may execute more than one contract or agreement with a single customer. Should separate contracts or agreements be viewed as one multiple-element arrangement when determining the appropriate amount of revenue to be recognized in accordance with SOP 97-2, Software Revenue Recognition? Reply A group of contracts or agreements may be so closely related that they are, in effect, parts of a single arrangement. The form of an arrangement is not necessarily the only indicator of the substance of an arrangement. The existence of any of the following factors (which are not allinclusive) may indicate that a group of contracts should be accounted for as a single arrangement: The contracts or agreements are negotiated or executed within a short time frame of each other. The different elements are closely interrelated or interdependent in terms of design, technology, or function. Software Revenue Recognition D-1

The fee for one or more contracts or agreements is subject to refund or forfeiture or other concession if another contract is not completed satisfactorily. One or more elements in one contract or agreement are essential to the functionality of an element in another contract. Payment terms under one contract or agreement coincide with performance criteria of another contract or agreement. The negotiations are conducted jointly with two or more parties (for example, from different divisions of the same company) to do what in essence is a single project. TPA 5100.40 Software revenue recognition related to Year 2000 compliant software Inquiry Is a commitment to deliver in the future a Year 2000 compliant version of a software product to an existing customer or to a customer that is acquiring a non-year 2000 compliant version considered an upgrade right or specified upgrade in accordance with SOP 97-2, Software Revenue Recognition? Reply Yes. The criteria of SOP 97-2 related to specified upgrades apply whether or not the commitment is contained under a warranty provision. Given the ramifications of non-year 2000 compliant software, special attention should be given to paragraphs 13 and 14 of SOP 97-2. Further, the Securities and Exchange Commission released an Interpretation in August 1998 titled, Statement of the Commission Regarding Disclosure of Year 2000 Issues and Consequences by Public Companies, Investment Advisors, Investment Companies, and Municipal Securities Issuers. Part of that Interpretation states, Year 2000 issues may affect the timing of revenue recognition in accordance with (SOP 97-2). For example, if a vendor licenses a product that is not Year 2000 compliant and commits to deliver a Year 2000 compliant version in the future, the revenue from the transaction should be allocated to the various elements the software and the upgrade. Entities should also consider FASB Statement No. 48, Revenue Recognition When the Right of Return Exists, relating to any product return issues such as for products containing hardware and software, including whether the necessary conditions have been met to recognize revenue in the period of sale, whether that revenue should be deferred, or whether an allowance for sales return should be provided. In such situations, a vendor generally would be required to defer all revenue until it delivers the upgraded (compliant) version. TPA 5100.41 Effect of prepayments on software revenue recognition Inquiry Paragraph 29 of SOP 97-2, Software Revenue Recognition, states that if a fee on a software arrangement with extended payment terms is not fixed or determinable at the outset of an arrangement revenue should be recognized as payments become due. Should a vendor recognize revenue for amounts (related to an arrangement with extended payment terms) received directly from customers (without the software vendor s participation in its customers financing arrangements) in advance of scheduled payments? Reply Yes, provided all other requirements of revenue recognition in SOP 97-2 are met. TPA 5100.42 Extended payment terms and software revenue recognition Inquiry A software vendor with a fiscal year ending September 30 enters into a licensing arrangement and simultaneously delivers its product to a customer on September 29. Payment terms are as follows: $600,000 due thirty days from September 29; $400,000 due thirteen months from September 29. The licensing fee is not fixed or determinable because a significant portion of the fee is due more than one year after delivery of the software and the vendor cannot overcome the presumption in paragraph 28 of SOP 97-2, Software Revenue Recognition. How much revenue should the vendor recognize during the current fiscal year ending September 30? Reply None. Paragraph 29 of SOP 97-2 requires that the vendor recognize revenue as payments from customers become due (assuming all other conditions for revenue recognition in the SOP are met). In this situation, $600,000 should be recognized as revenue on October 29 when the payment becomes due and the remaining $400,000 should be recognized twelve months later on October 29 of the following fiscal year. Software Revenue Recognition D-2

TPA 5100.43 Corrections of errors in computer software (bug fixes) Inquiry A software vendor licenses software products to customers. Customers may elect to obtain postcontract customer support (PCS) from the software vendor as an element of the software arrangement, or customers may choose not to obtain PCS. In order to satisfy its warranty obligations, the software vendor provides bug fixes (free of charge) that are necessary to maintain compliance with published specifications to those customers that do not obtain PCS from the software vendor. Paragraph 31 of SOP 97-2, Software Revenue Recognition, states, obligations related to warranties for defective software, including warranties that are routine, short-term, and relatively minor, should be accounted for in conformity with FASB Statement No. 5. However, the SOP s glossary indicates that PCS may include services such as the correction of errors (for example, bug fixing). If a software vendor provides bug fixes (under warranty obligations) free of charge that are necessary to maintain compliance with published specifications, should the software vendor account for the estimated costs to correct the bugs in accordance with FASB Statement No. 5 or should the vendor consider the practice of providing bug fixes free of charge part of PCS (which may result in the deferral of revenue)? Reply In this situation, the software vendor should account for the estimated costs to provide bug fixes (that are necessary to maintain compliance with published specifications) in accordance with FASB Statement No. 5. TPA 5100.44 Postcontract customer support during the deployment phase of computer software Inquiry A software vendor enters into an arrangement with a customer to deliver its software product and to provide postcontract customer support (PCS). The product will be deployed in stages. The stipulated term of the PCS period begins six months after delivery of the product, though the vendor has a history of regularly making available to all customers the services or unspecified upgrades/enhancements normally associated with PCS as soon as its products are delivered. (That is, the customer receives any upgrades/enhancements released by the vendor during the six-month period after product delivery.) The PCS rate inherent in the licensing fee increases over time based on the customer s deployment of the product. After three years, the predetermined renewal rate for PCS for a fully deployed license is set at a stipulated rate multiplied by the aggregate list price (as established at the inception of the arrangement) of the licensed product, regardless of the status of the deployment efforts. The vendor does not have vendor-specific objective evidence (VSOE) of fair value of the PCS when the product is less than fully deployed because the only PCS sold separately is the renewal of PCS (that is, the predetermined renewal rate). Is PCS considered to commence at the date of product delivery or six months after delivery? Should the vendor consider the PCS predetermined renewal rate to be VSOE of fair value for PCS? Reply In this situation, the PCS arrangement commences upon product delivery because the customer receives any upgrades/enhancements released by the vendor during the six-month period after product delivery. In addition, the predetermined renewal rate is the only indicator of fair value because it is the only arrangement under which PCS is sold separately, and therefore, it should be used to establish VSOE of fair value of the PCS. In this situation, the vendor should initially defer the portion of the arrangement fee related to the three years of PCS provided under the arrangement based on the predetermined renewal rate. Software Revenue Recognition D-3

TPA 5100.45 Effect of change in license mix on software revenue recognition Inquiry Software arrangements may allow a user to change or alternate its use of multiple products/licenses (license mix) included in a license arrangement after those products have been delivered by the software vendor. The user has the right under the arrangement to deploy and utilize at least one copy of each licensed product (that is, the user has a license to use each delivered product). The products may or may not be similar in functionality. These arrangements may limit the customer s use at any time to any mix or combination of the products as long as the cumulative value of all products in use does not exceed the total license fee. Certain of these arrangements may not limit usage of a product or products, but rather, they may limit the number of users that simultaneously can use the products (referred to as concurrent user pricing). When should the software vendor recognize revenue for these kinds of arrangements? Reply If the other criteria in SOP 97-2, Software Revenue Recognition, for revenue recognition are met, revenue should be recognized upon delivery of the first copy or product master for all of the products within the license mix. Subsequent remixing is not an exchange or a return of software because the master or first copy of all products has been licensed and delivered, and the customer has the right to use them. TPA 5100.46 Nonmonetary exchanges of software (Part I) Inquiry Is an exchange by a software vendor of a license of its software to a customer in exchange for a license to the customer s technology that permits the software vendor to sublicense the customer s technology to other customers as a component of the software vendor s products or as a stand-alone additional product the culmination of the earnings process? That is, should that exchange be recorded at fair value or at carryover basis? Reply Paragraph 21a of APB Opinion No. 29, Accounting for Nonmonetary Transactions, states that an exchange of a product or property held for sale in the ordinary course of business for a product or property to be sold in the same line of business to facilitate sales to customers other than the parties to the exchange does not culminate an earnings process. Therefore, if the technology/products received by the software vendor in the exchange were to be sold, licensed, or leased in the same line of business as the software vendor s technology/products delivered in the exchange, the software vendor should record the exchange at carryover basis. However, if the technology/products received by the software vendor in the exchange were to be sold, licensed, or leased in a different line of business from the software vendor s technology/products delivered in the exchange, the exchange is the culmination of the earnings process and the exchange should be recorded at fair value provided that: the fair value of the technology/products exchanged or received can be determined within reasonable limits (that is, vendor-specific objective evidence of fair value of the software given up, or the value of the technology/products received, as if the software vendor had received or paid cash); and the technology/products received in the exchange are expected, at the time of the exchange, to be deployed and utilized by the software vendor and the value ascribed to the transaction reasonably reflects such expected use. If neither the fair value of the technology/products exchanged nor the fair value of the technology/products received can be reasonably determined, the exchange should be recorded at carryover basis. Paragraph 26 of APB Opinion No. 29 states that if neither the fair value of a nonmonetary asset transferred nor the fair value of a nonmonetary asset received in exchange is determinable within reasonable limits, the recorded amount of the nonmonetary asset transferred from the enterprise may be the only available measure of the transaction. TPA 5100.47 Nonmonetary exchanges of software (Part II) Inquiry Is an exchange by a software vendor of a license of its software to a customer in exchange for a license to the customer s technology that the software vendor intends to utilize for internal use the culmination of the earnings process? That is, should that exchange be recorded at fair value or at carryover basis? Software Revenue Recognition D-4

Reply Providing that the fair value of either of the nonmonetary assets involved in the transaction can be determined within reasonable limits, the software vendor should record the exchange at fair value because the exchange is subject to the guidance in paragraph 18 of APB Opinion No. 29, Accounting for Nonmonetary Transactions. Further, EITF Issue No. 86-29, Nonmonetary Transactions: Magnitude of Boot and the Exception to the Use of Fair Value, which provides guidance on interpreting APB Opinion No. 29, states that a product or property held for sale and exchanged for a productive asset does not fall within the modifications to the basic principle of paragraph 18 of APB 29 (even if they were in same line of business) and should be recorded at fair value. Thus, that exchange is the culmination of the earnings process and that exchange should be recorded at fair value provided that: the fair value of the technology/products exchanged or received can be determined within reasonable limits (that is, vendor-specific objective evidence of fair value of the software given up, or the value of the technology/products received, as if the software vendor had received or paid cash); and the technology/products received in the exchange are expected, at the time of the exchange, to be deployed and utilized by the software vendor and the value ascribed to the transaction reasonably reflects such expected use. If neither the fair value of the technology/products exchanged nor the fair value of the technology/products received can be reasonably determined, the exchange should be recorded at carryover basis. Paragraph 26 of APB Opinion No. 29 states that if neither the fair value of a nonmonetary asset transferred nor the fair value of a nonmonetary asset received in exchange is determinable within reasonable limits, the recorded amount of the nonmonetary asset transferred from the enterprise may be the only available measure of the transaction. The following matrix summarizes the answers in TPAs 5100.46 and 5100.47. Software Vendor s Software Vendor s Use Same Line Accounting Technology Exchanged of Technology Received of Business Treatment Software product held Technology to be held 1. Yes 1. Record at for sale in the ordinary for sale in the ordinary historical cost course of business course of business (i.e., inventory) 1 (i.e., inventory) 2 2. No 2. Record at fair value 3 Software product held Internal-use software 4 N/A 3. Record at fair for sale in the ordinary value. course of business (i.e., inventory) 1 Licenses to software products, source code, and object code that the software vendor sells, licenses, or leases in the ordinary course of business would constitute inventory. 2 A software vendor that receives any of the following would be receiving inventory: i. a product to resell, sublicense, or sublease; ii. a right to embed the technology received into a product; or iii. a right to further develop the technology received into a product. 3 Assumes that fair value is determinable and the transaction has a business purpose. 4 A software vendor that receives any of the following would be receiving something other than inventory: i. a product or technology that only can be used internally (e.g., a financial or management application); or ii. a product or technology that only can be used internally to make a product but which does not become part of the product. Software Revenue Recognition D-5

The following example illustrates the answers in TPAs 5100.46 and 5100.47. Software vendor XYZ licenses software Product A (a suite of financial accounting applications) to customers in the normal course of business. Software vendor XYZ has vendor-specific objective evidence of fair value of Product A resulting from prior cash transactions with its customers. Product A includes technology (Product B) sublicensed by software vendor XYZ from Company PQR. Software vendor XYZ agrees to exchange Product A with Company PQR for licenses to Product B. Software vendor XYZ intends to relicense Product B (as a stand-alone product or embedded in Product A) to its customers. Company PQR intends to use Product A for internal use. Accounting by software vendor XYZ. The exchange of Product A for Product B by software vendor XYZ would not result in the culmination of the earnings process for software vendor XYZ because software vendor XYZ exchanged property held for sale (Product A) for property to be sold in the same line of business (Product B) to facilitate future sales to other customers. The exchange should be recorded at carryover basis (that is, no revenue should be recognized until Product B was sublicensed to other customers in a subsequent transaction). Accounting by Company PQR. The exchange of Product B for Product A by Company PQR would result in the culmination of the earnings process for Company PQR because Company PQR exchanged property held for sale (Product B) for a productive asset (Product A, which will be used by Company PQR as an amortizable asset). The exchange should be recorded by Company PQR at fair value (that is, revenue should be recognized on the exchange). Such accounting treatment is based on the fact that the fair value of the technology exchanged or received can be reasonably determined and that a business purpose exists for the transaction. TPA 5100.48 Application of contract accounting in software arrangements (Part I) Inquiry In paragraph 7 of SOP 97-2, Software Revenue Recognition, what is the meaning of the phrase using the relevant guidance herein? Reply The phrase using the relevant guidance herein refers to paragraphs 74-91 of SOP 97-2, which provide guidance on applying contract accounting to certain arrangements involving software. TPA 5100.49 Application of contract accounting in software arrangements (Part II) Inquiry Footnote 4 to paragraph 7 of SOP 97-2, Software Revenue Recognition, states: If a software arrangement includes services that meet the criteria discussed in paragraph 65 of this SOP, those services should be accounted for separately. The type of services addressed by paragraph 65 are described in paragraph 63 and specifically exclude post contract customer support (PCS)-related services. For a software arrangement that is subject to contract accounting and that includes PCS-related services (other than those meeting the cost accrual criteria in paragraph 59 of SOP 97-2), how should the software vendor account for such PCS-related services? Reply If the software vendor has vendor-specific objective evidence of the fair value of such PCS-related services that has been determined pursuant to paragraph 57 of SOP 97-2, those PCS-related services should be accounted for separately from the balance of the arrangement that is being accounted for in conformity with Accounting Research Bulletin (ARB) No. 45, Long- Term Construction-Type Contracts, and the relevant guidance in paragraphs 74-91 of SOP 97-2 and in SOP 81-1, Accounting for Performance of Construction-Type and Certain Production-Type Contracts. Software Revenue Recognition D-6

TPA 5100.50 Definition of more-than-insignificant discount and software revenue recognition Inquiry As discussed in paragraph 3 of SOP 97-2, Software Revenue Recognition, in connection with the licensing of an existing product, a vendor might offer a small or insignificant discount on additional licenses of the licensed product or other products that exist at the time of the offer but are not part of the arrangement. Paragraph 3 indicates that those discounts are not within the scope of SOP 97-2. However, footnote 3 to paragraph 3 states that [i]f the discount or other concessions in an arrangement are more than insignificant, a presumption is created that an additional element(s) (as defined in paragraph 9) is being offered in the arrangement. What is a more-than-insignificant discount, as discussed in footnote 3 to paragraph 3 of SOP 97-2? Reply For purposes of SOP 97-2, a more-than-insignificant discount with respect to future purchases that is provided in a software arrangement is a discount that is: (1) incremental to the range of discounts reflected in the pricing of the other elements of the arrangement, (2) incremental to the range of discounts typically given in comparable transactions, and (3) significant. Insignificant discounts and discounts that are not incremental to discounts typically given in comparable transactions (for example, volume purchase discounts comparable to those generally provided in comparable transactions) are not unique to software transactions and are not included in the scope of SOP 97-2. Judgment is required when assessing whether an incremental discount is significant. The provisions of footnote 3 to paragraph 3 of SOP 97-2 should not be applied to an option within a software arrangement that allows the customer to purchase additional copies of products licensed by and delivered to the customer under the same arrangement. In that case, revenue should be recognized as the rights to additional copies are purchased, based on the price per copy as stated in the arrangement. Additional copies of delivered software are not considered an undelivered element. Paragraph 21 of SOP 97-2 says that duplication of software is considered incidental to an arrangement, and the delivery criterion is met upon the delivery of the first copy or product master. TPA 5100.51 Accounting for significant incremental discounts in software revenue recognition Inquiry How should a software vendor account for significant incremental discounts that are within the scope of SOP 97-2, Software Revenue Recognition? Reply If a software arrangement includes a right to a significant incremental discount on a customer s future purchase of a product(s) or service(s), a proportionate amount of that significant incremental discount should be applied to each element covered by the arrangement based on each element s fair value (VSOE) without regard to the significant incremental discount. (See Examples 1 through 6 below.) If (a) the future product(s) or service(s) to which the discount is to be applied is not specified in the arrangement (for example, a customer is allowed a discount on any future purchases), or (b) the fair value of the future purchases cannot be determined under paragraph 10 of SOP 97-2, but the maximum amount of the incremental discount on the future purchases is quantifiable, that quantifiable amount should be allocated to the elements of the arrangement and the future purchases assuming that the customer will purchase the minimum amount necessary to utilize the maximum discount. (See Examples 2 and 3 below.) If the maximum amount of the significant incremental discount on future purchases is not quantifiable (for example, the future purchases that can be purchased under the significant incremental discount arrangement are not limited by quantity of product(s) or service(s)), revenue otherwise allocated to each element covered by the arrangement without regard to the significant incremental discount should be reduced by the rate of the significant incremental discount. (See Example 5 below.) Software Revenue Recognition D-7

The portion of the fee that is deferred as a result of the significant incremental discount should be recognized as revenue proportionately as the future purchases are delivered, assuming all other revenue recognition criteria are met, such that a consistent discount rate is applied to all purchases under the arrangement. If the future purchases are not limited by quantity of product(s) or service(s), the portion of the fee that is deferred as a result of the presence of a significant incremental discount should be recognized as revenue as a subscription in accordance with paragraphs 48 and 49 of SOP 97-2. EXAMPLES (For purposes of the examples, VSOE of fair value equals list price) Example 1: A software vendor sells Product A for $40 along with a right to a discount (the coupon ) of $30 on another of its software products, Product B. VSOE of fair value for Product A is $40 and VSOE of fair value for Product B is $60. The $30 discount on Product B is a significant incremental discount that would not normally be given in comparable transactions. The vendor should allocate the $30 discount across Product A and Product B. The overall discount is 30% ($30/$100). Therefore, upon the delivery of Product A, the vendor would recognize $28 of revenue and defer $12. If the customer uses the discount and purchases Product B, the vendor would recognize $42 in revenue upon delivery of Product B ($30 in cash received plus the $12 previously deferred). If the discount expires unused, the $12 in deferred revenue would be recognized at that time. Example 2: A software vendor sells Product A for $40 along with a right to a discount (the coupon ) of $20 on any one of its other software products, Products B through Z. VSOE of fair value for Product A is $40 and VSOE of fair value for Products B through Z ranges from $30 to $100. The $20 discount is a significant incremental discount that would not normally be given in comparable transactions. The vendor should allocate the $20 discount across Product A and the assumed purchase of whichever of Product B through Z has the lowest fair value ($30). The overall discount is 28.57% ($20/$70). Therefore, upon delivery of Product A, the vendor would recognize $28.57 in revenue, and defer $11.43. If the customer uses the discount and purchases the additional product with a fair value of $30, the vendor would recognize $21.43 in revenue upon its delivery (the $11.43 previously deferred and the additional cash license fee due of $10). If the discount expires unused, the $11.43 in deferred revenue would be recognized at that time. Example 3: A software vendor sells Product A for $40 along with a right to a discount (the coupon ) of 50% off list price on any future purchases of its other software products, Products B through Z, with a maximum cumulative discount of $100. VSOE of fair value for Product A is $40 and VSOE of fair value for Products B through Z ranges from $20 to $100. The 50% discount is a significant incremental discount that would not normally be given in comparable transactions. The vendor should assume that the maximum discount will be utilized. Therefore, the vendor would allocate the $100 discount across Product A and the assumed additional products to be purchased. The overall discount is 41.67% ($100/$240). Therefore, upon the delivery of Product A, the vendor would recognize $23.33 of revenue and defer $16.67. If the customer uses the discount by purchasing additional products with fair value totaling $200, the vendor would recognize $116.67 in revenue upon delivery of those products ($100 in cash received plus the $16.67 previously deferred). If the discount expires unused, the $16.67 in deferred revenue would be recognized at that time. Example 4: A software vendor sells Product A for $60, which represents a 40% discount off its list price (VSOE) of $100. In the same transaction, it also provides the right to a discount of 60% off of the list price (VSOE) on any future purchases of units of software Product B for the next six months with a maximum discount of $200. The discount of 60% on future purchases of units of Product B is a discount not normally given in comparable transactions. Software Revenue Recognition D-8

Because the discount offered on future purchases of Product B is not normally given in comparable transactions and is both significant and incremental in relation to the 40% discount, it must be accounted for as part of the original sale consistent with Example 3 above. The vendor should assume that the maximum discount will be utilized. Therefore, the vendor would allocate the $240 discount ($40 on Product A and $200 maximum on future purchases) across Product A and the assumed additional products to be purchased. The overall discount is 55.38% ($240/$433.33) ($433.33 is the sum of the $100 list price of Product A and the $333.33 accumulated list price of Product B that results in a maximum discount of $200). Therefore, upon the delivery of Product A, the vendor would recognize $44.62 of revenue and defer $15.38. If the customer uses the discount by purchasing additional products with fair value totaling $333.33, the vendor would recognize $148.71 in revenue upon delivery of those products ($133.33 in cash received plus the $15.38 previously deferred). If the discount expires unused, the $15.38 in deferred revenue would be recognized at that time. Example 5: A software vendor sells Product A for $40 along with a right to a discount (the coupon ) of 50% off list price on any future purchases of its other software products, Products B through Z, with no maximum cumulative discount. VSOE of fair value for Product A is $40 and VSOE of fair value (which equals list price) of Products B through Z ranges from $20 to $100. The 50% discount is a significant incremental discount that would not normally be given in comparable transactions. The vendor should apply the 50% discount to Product A and all future products purchased using the discount. Therefore, upon the delivery of Product A, the vendor would recognize $20 of revenue and defer $20. If the customer purchases additional products using the discount, the vendor would recognize revenue equal to the cash received upon the delivery of those products. The previously deferred $20 should be accounted for as a subscription in accordance with paragraphs 48 and 49 of SOP 97-2 and recognized pro rata over the discount period or, if no period is specified in the arrangement, over the estimated period during which additional purchases will be made. Example 6: A software vendor sells Product A for $30 along with the right to a discount for 70% off list price (VSOE) on any future purchases of its other software products, Products B through P, for the next six months with no maximum cumulative discount. Product A is also given at a 70% discount and the VSOE of fair value of Product A is $100. As the discount offered on future purchases over the next six months is equal to the discount offered on the current purchase (70%), there is no accounting necessary in the original sale for the discount offered on future purchases. TPA 5100.52 Fair value of PCS in a perpetual license and software revenue recognition Inquiry The fee for a perpetual software license includes postcontract customer support (PCS) services for a term of two years. However, only one-year PCS renewal rates are offered to those holding the perpetual license rights. Do rates for the PCS renewal terms provide vendor-specific objective evidence (VSOE) of the fair value of the PCS element included (bundled) in the software arrangement pursuant to the provisions in paragraphs 10 and 57 of SOP 97-2, Software Revenue Recognition? Reply Yes, if the PCS renewal rate and term are substantive. The dollar amount of the one-year PCS renewal rate multiplied by two (which reflects the PCS term included in the arrangement) constitutes VSOE of the fair value of PCS pursuant to the provisions in paragraphs 10 and 57 of SOP 97-2. Software Revenue Recognition D-9

TPA 5100.53 Fair value of PCS in a short-term time-based license and software revenue recognition Inquiry A multiple-element software arrangement subject to the accounting requirements of SOP 97-2, Software Revenue Recognition, provides a 12-month time-based software license that includes (bundles) six months of postcontract customer support (PCS) services for a total fee of $100,000, and specifies a six-month renewal fee for PCS services of $5,000. Are there arrangements that include time-based software licenses and PCS services wherein the duration of the time-based software license is so short that a renewal rate or fee for the PCS services does not represent vendor-specific objective evidence (VSOE) of the fair value of the bundled PCS? Reply Yes, and the fact pattern in this question is an example of such a situation. For timebased software licenses with a duration of one year or less, the fair value of the bundled PCS services is not reliably measured by reference to a PCS renewal rate. The short time frame during which any unspecified upgrade provided under the PCS agreement can be used by the licensee creates a circumstance whereby one cannot objectively demonstrate the VSOE of fair value of the licensee s right to unspecified upgrades. Though a PCS service element may not be of significant value when it is provided in a short duration time-based license, SOP 97-2 does not provide for an exception from its provision that VSOE of fair value is required for each element of a multiple-element arrangement. Consequently, when there is no VSOE of the fair value of PCS services included (bundled) in a multiple-element arrangement, even if the arrangement provides a short duration time-based software license, the total arrangement fee would be recognized under paragraph 12 (or paragraph 59, if applicable) of SOP 97-2. TPA 5100.54 addresses circumstances where a PCS renewal rate in connection with a multi-year time-based license may not constitute VSOE of the fair value of PCS. TPA 5100.54 Fair value of PCS in a multi-year time-based license and software revenue recognition Inquiry Arrangements for multi-year time-based software licenses may include: (1) initial (bundled) postcontract customer support (PCS) services for only a portion of the software license s term (for example, a five-year time-based software license that includes initial PCS services for one year) and (2) a renewal rate for PCS for an additional year(s) within the timebased license period. Does that renewal rate constitute vendor-specific objective evidence (VSOE) of the fair value of the PCS under paragraphs 10 and 57 of SOP 97-2, Software Revenue Recognition? Reply Yes, if the PCS renewal rate and term are substantive. Circumstances that indicate that the PCS renewal rate or term is not substantive include: The period of initial (bundled) PCS services is relatively long compared to the term of the software license (for example, four years of initial PCS services in connection with a fiveyear time-based software license, with a specified PCS renewal rate for the remaining year). The aggregate PCS renewal term is less than the initial (bundled) PCS period (for example, a five-year time-based software license with three year bundled PCS and two annual PCS renewals). A PCS renewal rate that is significantly below the vendor s normal pricing practices in combination with a time-based software license that is for a relatively short period (for example, a two-year time-based software license that includes initial [bundled] PCS for one year for a total arrangement fee of $1,000,000 and that stipulates a PCS renewal rate for the second year of $25,000 when the vendor s normal pricing practices suggest higher renewal rates). Software Revenue Recognition D-10

TPA 5100.55 Fair value of PCS with a consistent renewal percentage (but varying renewal dollar amounts) and software revenue recognition Inquiry A software vendor charges Customer A $100,000 for a software license with a postcontract customer support (PCS) renewal rate of 15% of the license fee while charging Customer B $150,000 for the same software license with a PCS renewal rate of 15% of the license fee. Does the existence of varying dollar amounts of PCS renewal fees for the same software product (resulting from using a renewal rate that is a consistent percentage of the stipulated software license fee for the same software product) indicate an absence of vendorspecific objective evidence (VSOE) of the fair value of PCS or the possible presence of discounts on PCS that should be accounted for under paragraph 11 of SOP 97-2, Software Revenue Recognition? Reply No. Assuming that the PCS renewal rate expressed as a consistent percentage of the stipulated license fee for customers is substantive, that PCS renewal rate would be the VSOE of the fair value of PCS. TPA 5100.56 Concessions and software revenue recognition Inquiry Paragraph 27 of SOP 97-2, Software Revenue Recognition, states that Because a product s continuing value may be reduced due to the subsequent introduction of enhanced products by the vendor or its competitors, the possibility that the vendor still may provide a refund or concession to a credit-worthy customer to liquidate outstanding amounts due under the original terms of the arrangement increases as payment terms become longer. What kinds of changes to an arrangement would be considered concessions? Reply Concessions by a software vendor may take many forms and include, but are not limited to, any one of the following kinds of changes to the terms of an arrangement: Changes that would have affected the original amount of revenue recognized; Changes that reduce the arrangement fee or extend the terms of payment; and Changes that increase the deliverables or extend the customer s rights beyond those in the original transaction. Examples of concessions by a software vendor that reduce an arrangement fee or extend the terms of payment include, but are not limited to, the following: Extending payment due dates in the arrangement (except when the extension is due to credit problems of the customer); Decreasing total payments due under the arrangement (except when the decrease is due to credit problems of the customer); Paying financing fees on a customer s financing arrangement that was not contemplated in the original arrangement; and Accepting returns that were not required to be accepted under the terms of the original arrangement. Examples of concessions by a software vendor that increase the deliverables include, but are not limited to, the following: Providing discounted or free postcontract customer support that was not included in the riginal arrangement; Providing various types of other discounted or free services (beyond those provided as part of the vendor s normal product offerings or warranty provisions), upgrades, or products that were not included in the original arrangement; Allowing the customer to have access to products not licensed under the original arrangement without an appropriate increase in the arrangement fee; For term licenses, extending the time frame for a reseller to sell the software or an end user to use the software; and For limited licenses, extending the geographic area in which a reseller is allowed to sell the software, or the number of locations in which an end user can use the software. Software Revenue Recognition D-11

Although the nature of a concession may vary by type of arrangement, many of the above concessions could be granted for any type of license arrangement regardless of its form (that is, term arrangement, perpetual arrangement, site license arrangement, enterprise license arrangement, etc.). Examples of changes to the terms of an arrangement that are not concessions include, but are not limited to, the following: Changes that increase the deliverables with a corresponding appropriate increase in the arrangement fee; and Changes that eliminate the software vendor s delivery obligation without a refund of cash. TPA 5100.57 Overcoming presumption of concessions in extended payment term arrangements and software revenue recognition Inquiry Paragraph 28 of SOP 97-2, Software Revenue Recognition, indicates that, if a significant portion of the software licensing fee is not due until after expiration of the license or more than twelve months after delivery, the licensing fee should be presumed not to be fixed or determinable. That presumption may be overcome by evidence that the vendor has a standard business practice of using long-term or installment contracts and a history of successfully collecting under the original payment terms without making concessions. What types of evidence are useful in determining whether the vendor has a history of successfully collecting under the original payment terms without making concessions? Reply To have a history of successfully collecting under the original payment terms without making concessions, a vendor would have to have collected all payments as due under comparable arrangements without providing concessions. For example, one year of payments under three-year payment arrangements would not provide sufficient history because all of the payments under the contracts would not yet have been paid as due. In addition to a history of collecting payments as due without making concessions, paragraph 14 of SOP 97-2 requires that the software vendor must intend not to provide refunds or concessions that are beyond the provisions of the arrangement. In evaluating a vendor s history, the historical arrangements should be comparable to the current arrangement relative to terms and circumstances to conclude that the history is relevant. Examples of factors that should be assessed in this evaluation include, but are not limited to, the following: Similarity of customers; Type or Class of Customer: New arrangements with substantially the same types and class of customer is an indicator that the history is relevant. Significant differences call into question the relevance of the history; Similarity of products included; Types of Products: Similarity in the types of products included under the new license arrangement (for example, financial systems, production planning, and human resources); Stage of Product Life Cycle: Product maturity and overall stage within its product life cycle should be considered when assessing the relevance of history. The inclusion of new products in a license arrangement should not automatically preclude the vendor from concluding that the software products are comparable. For example, if substantially all of the products under one license arrangement are mature products, the inclusion of a small number of newly developed products in a subsequent arrangement may not change the overall risk of concession and economic substance of the subsequent transaction; Elements Included in the Arrangement: There are no significant differences in the nature of the elements included in the arrangements. The inclusion of significant rights to services or discounts on future products in some arrangements, but not others, could indicate that there is a significant difference between the arrangements. For example, a history developed for arrangements that included bundled postcontract customer support Software Revenue Recognition D-12

(PCS) and rights to additional software products would not be comparable to an arrangement that does not include these rights; Similarity of license economics; Length of Payment Terms: In order for the history to be considered relevant, the overall payment terms should be similar. Although a nominal increase in the length of payment terms may be acceptable, a significant increase in the length of the payment terms may indicate that the terms are not comparable; and Economics of License Arrangement: The overall economics and term of the license arrangement should be reviewed to ensure that the vendor can conclude that the history developed under a previous arrangement is relevant, particularly if the primary products licensed are near the end of their lives and the customer would not be entitled to the updated version under a PCS arrangement. TPA 5100.58 Effect of prepayments on software revenue recognition (Part II) Inquiry Paragraph 28 of SOP 97-2 says that any extended payment terms in a software licensing arrangement may indicate that the fee is not fixed or determinable. In addition, the licensing fee is presumed not to be fixed or determinable if payment of a significant portion of the fee is not due until after expiration of the license or more than twelve months after delivery. Is the presumption overcome if the software vendor transfers the rights to receive amounts due on an extended payment term arrangement to an independent third party without recourse to the vendor? Reply No. The presumption that the licensing fee is not fixed or determinable is NOT overcome if at the outset of the arrangement, or subsequently, the vendor receives cash on the transfer of the extended payment term arrangement. That answer does not change if the extended payment term arrangement is irrevocably transferred or otherwise converted to cash without recourse to the vendor. The difference in this situation as compared to TPA 5100.41 (which addresses prepayments received directly from customers) is that the transfer of the extended payment term arrangement does not change the nature or structure of the transaction between the vendor and customer. Therefore, the presumption in paragraph 28 of SOP 97-2 has not been overcome. TPA 5100.59 Subsequent cash receipt in an extended payment term arrangement for software revenue recognition Inquiry Paragraph 28 of SOP 97-2, Software Revenue Recognition, says that the presumption that an extended payment term license fee due more than twelve months after delivery of the software is not fixed or determinable may be overcome by evidence that the software vendor has a standard business practice of using long-term or installment contracts and has a history of successfully collecting under the original payment terms without making concessions. A calendar year-end software vendor enters into a two-year installment payment licensing arrangement with a customer on December 1 and the first payment is due in May of the following year. Subsequent to its December 31 year-end but before it issues the financial statements, the software vendor receives from the customer payment of the full amount due. As of December 1, the software vendor has met all other conditions of revenue recognition except that it does not have a standard business practice of using long-term or installment contracts. Does the subsequent cash receipt provide sufficient evidence to render the licensing fee as fixed or determinable, and thus allow the software vendor to recognize revenue in the December 31 financial statements? Reply No. Paragraph 29 of SOP 97-2 requires that the software vendor make the determination of whether the fee is fixed or determinable at the outset of the arrangement, which in this situation is December 1. The only circumstances sufficient to overcome the presumption that the license fee is not fixed or determinable are that the software vendor has (1) a standard business practice of using long-term or installment contracts and (2) has a history of successfully collecting under the original payment terms without making concessions. Since the software vendor has met all other conditions of revenue recognition, it should recognize revenue in the period it receives payment in full directly from the customer (see TPA 5100.41, Effect of prepayments on software revenue recognition). Software Revenue Recognition D-13

TPA 5100.60 Customer financing with no software vendor participation and software revenue recognition (For illustrative purposes, the following inquiry and reply assumes that the software arrangement is a single product/single element arrangement; however, the inquiry and reply also applies to multiple-element arrangements.) Inquiry TPA 5100.41 addresses a situation in which a customer obtains financing, without the software vendor s participation, and prepays amounts due the software vendor under previously negotiated extended payment terms. That TPA indicates that a software vendor should recognize revenue in advance of scheduled payments if amounts related to extended payment terms are received directly from customers without the software vendor s participation in its customers financing arrangements, providing all other requirements of revenue recognition in SOP 97-2, Software Revenue Recognition, are met. TPA 5100.58 indicates a software vendor should not recognize revenue in advance of scheduled payments if amounts related to extended payment terms are received as a result of the software vendor s transfer of a customer s extended payment term obligation to a third party, without recourse to the software vendor. Given the two aforementioned TPAs, how should a software vendor recognize revenue if it enters into an arrangement with an end-user customer that contains customary (that is, non-extended) payment terms and the end-user customer obtains, without the software vendor s participation, financing from a party unrelated to the software vendor? Reply Because the software arrangement s payment terms are not extended, as contemplated in paragraph 28 of SOP 97-2, and the software vendor does not participate in the end-user customer s financing, the software vendor should recognize revenue upon delivery of the software product, provided all other requirements of revenue recognition in SOP 97-2 are met. TPA 5100.61 Effect of prepayments on software revenue recognition when vendor participates in customer financing (For illustrative purposes, the following inquiry and reply assumes that the software arrangement is a single product/single element arrangement; however, the inquiry and reply also applies to multiple-element arrangements.) Inquiry TPA 5100.41 addresses a situation in which amounts related to extended payment terms are received directly from customers without the software vendor s participation in its customers financing arrangements. The specific reference to without participation suggests that the answer might be different if the software vendor participates in the customer s financing. How should a software vendor recognize revenue under SOP 97-2, Software Revenue Recognition, if it enters into an arrangement with an end-user customer that contains extended payment terms and the software vendor receives payments in advance of the scheduled due dates after the software vendor participated in the customer s financing with a party unrelated to the software vendor? Reply If the software vendor s participation in the customer s financing results in incremental risk that the software vendor will provide a refund or concession to either the end user customer or the financing party (as discussed in TPA 5100.62), the presumption is that the fee is not fixed or determinable. If the software vendor cannot overcome that presumption, the software vendor should recognize revenue as payments from the customer become due and payable to the financing party, provided all other requirements of revenue recognition in SOP 97-2 are met. The software vendor should account for any proceeds received from the customer or the financing party prior to revenue recognition as a liability for deferred revenue. TPA 5100.63 addresses when the presumption may be overcome. Software Revenue Recognition D-14

TPA 5100.62 Indicators of incremental risk and their effect on the evaluation of whether a fee is fixed or determinable and software revenue recognition (For illustrative purposes, the following inquiry and reply assumes that the software arrangement is a single product/single element arrangement; however, the inquiry and reply also applies to multiple-element arrangements.) Inquiry Based on the reply to TPA 5100.61, and as implied in TPA 5100.41, considering whether a software vendor participated in the customer s financing is important to how revenue is recognized in a software arrangement that contains extended payment terms. A software vendor enters into an arrangement with an end-user customer that contains customary (that is, nonextended) payment terms for which the arrangement fee ordinarily would be considered fixed or determinable. Simultaneously with entering into a software arrangement, or prior to the scheduled payment due date(s), the software vendor participates in the end-user customer s financing with a party unrelated to the software vendor. In what circumstances would the software vendor s participation in the end-user customer s financing (a) preclude a determination by the software vendor that the software arrangement fee is fixed or determinable pursuant to paragraph 28 of SOP 97-2, Software Revenue Recognition, or (b) lead to a presumption (that can be overcome) that the fee is not fixed or determinable in accordance with paragraph 28? Reply A software arrangement fee is not fixed or determinable if a software vendor: (a) lacks the intent or ability to enforce the original payment terms of the software arrangement if the financing is not successfully completed, or (b) in past software arrangements, altered the terms of original software arrangements or entered into another arrangement with customers, to provide extended payment terms consistent with the terms of the financing. If a software vendor s participation in an end-user customer s financing results in incremental risk that the software vendor will provide a refund or concession to either the end-user customer or the financing party, there is a presumption that the arrangement fee is not fixed or determinable. Any one of the following conditions or software vendor actions results in incremental risk and a presumption that the fee is not fixed or determinable: Provisions that require the software vendor to indemnify the financing party above and beyond the standard indemnification provisions that are explicitly included in the software arrangement between the software vendor and the end-user customer; Provisions that require the software vendor to make representations to the financing party related to customer acceptance of the software that are above and beyond the written acceptance documentation, if any, that the software vendor has already received from the end-user customer; Provisions that obligate the software vendor to take action (such as to terminate the license agreement and/or any related services), which results in more than insignificant direct incremental costs, against the customer on behalf of the financing party in the event that the end- user customer defaults under the financing, unless, as part of the original arrangement, the customer explicitly authorizes the software vendor upon request by the financing party to take those specific actions against the customer and does not provide for concessions from the vendor as a result of such action; Provisions that prohibit or limit the ability of the software vendor to enter into another software arrangement with the customer for the same or similar product if the end-user customer defaults under the financing, unless, as part of the original arrangement, the customer explicitly authorizes the software vendor upon request by the financing party to take those specific actions against the customer; Provisions that require the software vendor to guarantee, certify, or otherwise attest in any manner to the financing party that the customer meets the financing party s qualification criteria; Software vendor has previously provided concessions to financing parties or to customers to facilitate or induce payment to financing parties; and Provisions that lead to the software vendor s guarantee of the customer s indebtedness to the financing party. Software Revenue Recognition D-15

If the presumption is not overcome, the software vendor should recognize revenue as payments from the customer become due and payable to the financing party, provided all other requirements of revenue recognition in SOP 97-2 are met. TPA 5100.63 Overcoming the presumption that a fee is not fixed or determinable when vendor participates in customer financing and software revenue recognition Inquiry TPA 5100.62 provides indicators of incremental risk that result in a presumption that a fee is not fixed or determinable in an arrangement in which a software vendor participates in an end-user customer s financing with a party unrelated to the software vendor. What evidence should the software vendor consider to overcome the presumption that the fee is not fixed or determinable, as discussed in TPA 5100.62? Reply The presumption may be overcome in certain circumstances. The software vendor should use the guidance in paragraph 28 of SOP 97-2, Software Revenue Recognition, and TPA 5100.57. To overcome the presumption, there should be evidence that the software vendor has a standard business practice of entering into similar arrangements with financing parties that have substantially similar provisions, and has a history of not providing refunds or concessions to the customer or the financing party. Additionally, with respect to incremental risk indicator 7 in TPA 5100.62, in those circumstances in which the software vendor has relevant history with arrangements in which it granted extended payment terms to its customers, the software vendor should consider that history. A history of the software vendor granting concessions to either (a) its customers in similar arrangements in which it provided extended payment terms or (b) unrelated financing parties in similar arrangements in which the software vendor participated, would prevent the software vendor from overcoming the presumption that the fee is not fixed or determinable. In circumstances where there is sufficient evidence to overcome the presumption that the fee is not fixed or determinable, the software vendor should nevertheless evaluate the nature of the incremental risk to determine if there are other accounting ramifications, for example, accounting for the software vendor s continuing involvement that results from a guarantee of the customer s indebtedness (recourse). TPA 5100.64 Indicators of vendor participation in customer financing that do not result in incremental risk and software revenue recognition (For illustrative purposes, the following inquiry and reply assumes that the software arrangement is a single product/single element arrangement; however, the inquiry and reply also applies to multiple-element arrangements.) Inquiry Related to TPA 5100.62, are there examples of software vendor actions that generally do not cause the software vendor to assume incremental risk that the software vendor will provide a refund or concession to either the end-user customer or the financing party related to the software vendor s participation in an end-user customer s financing of a software arrangement? Reply Yes. The following examples of software vendor actions generally do not cause a software vendor to assume incremental risk: Software vendor introduces the customer and financing party and facilitates their discussions. Software vendor assists the customer in pre-qualifying for financing as long as the software vendor does not guarantee, certify, or otherwise attest in any manner to the financing party that the customer meets the financing party s qualification criteria. Software Revenue Recognition D-16

Software vendor represents to the financing party that the software vendor has free and clear title to the licensed software or the right to sublicense if the software vendor makes the same written representations in the software arrangement with the end-user customer. Software vendor warrants to the financing party that the software functions according to the software vendor s published specifications if the software vendor makes the same written warranty in the software arrangement with the end-user customer. Software vendor takes action, which was explicitly authorized by the customer in the original arrangement, to terminate the license agreement and/or any related services, or to not enter into another arrangement for the same or similar product. Software vendor makes customary recourse provisions to its customer related to warranties for defective software. TPA 5100.65 Software vendor interest rate buy downs on customer financing and software revenue recognition (For illustrative purposes, the following inquiry and reply assumes that the software arrangement is a single product/single element arrangement; however, the inquiry and reply also applies to multiple-element arrangements.) Inquiry A customer may desire, and a software vendor may be willing to assist the customer in obtaining financing with a party unrelated to the software vendor that has a more attractive interest rate than typically offered by the financing party. For example, a software vendor arranges to buy down the interest rate a financing party would otherwise charge to the software vendor s customer. That interest rate buy down may occur simultaneously with the original arrangement between the software vendor and customer, or it may occur at a later point in time. Further, that interest rate buy down may occur with or without the customer s awareness. Does either the point in time of the interest rate buy down, or the awareness by the customer of it, affect revenue recognition under SOP 97-2, Software Revenue Recognition? Reply The point in time that the interest rate buy down occurs affects revenue recognition; however, whether the customer is aware of the buy down does not affect revenue recognition. An interest rate buy down which is evidenced contemporaneously and occurs simultaneously with the original arrangement between the software vendor and customer is considered an integral part of the arrangement because of its timing. Because the interest rate buy down is an integral part of the original arrangement, it is irrelevant whether the customer is or is not aware of it. The amount of the interest rate buy down should be treated as a reduction of the total arrangement fee to be recognized in accordance with SOP 97-2, and not as a financing or other expense. A software vendor s buy down of an interest rate which is not evidenced contemporaneously or occurs other than simultaneously with the original arrangement is not considered an integral part of the original arrangement, rather it constitutes a concession because it represents a reduction in the arrangement fee not contemplated in the original arrangement (see TPA 5100.56). Because the interest rate buy down is a concession, it is irrelevant whether the customer is or is not aware of it. TPA 5100.66 Consideration of other TPAs on customer borrowing when customer is a reseller and software revenue recognition (For illustrative purposes, the following inquiry and reply assumes that the software arrangement is a single product/single element arrangement; however, the inquiry and reply also applies to multiple-element arrangements.) Software Revenue Recognition D-17

Inquiry The inquiries in TPAs 5100.60 through 5100.65 specifically refer to a software vendor s arrangements with an end-user customer. Are the replies different if the customer is a reseller? Reply The inquiries and replies in TPAs 5100.60 through 5100.65 are phrased in the context of end-user customers to eliminate the additional discussion that may be necessary to address the complexities that exist for resellers. Paragraph 30 of SOP 97-2, Software Revenue Recognition, provides additional factors to consider in evaluating whether an arrangement fee is fixed or determinable if the customer is a reseller. The underlying concepts in the replies should be applied to customers that are resellers; however, all of the additional factors in paragraph 30 of SOP 97-2 also should be considered. Further, the existence of financing by a reseller customer may increase the risk that: Payment of the arrangement fee is substantially contingent on the distributor s success at reselling the product. The reseller may not have the ability to honor a commitment to pay, which could increase the risk of software vendor concessions regardless of the source of the financing. Returns or price protection cannot be reasonably estimated because of the potential for increased concession risk. TPA 5100.67 Customer acceptance and software revenue recognition Inquiry Paragraph 20 of SOP 97-2, Software Revenue Recognition, says, After delivery, if uncertainty exists about customer acceptance of the software, license revenue should not be recognized until acceptance occurs. In a software arrangement that contains a customer acceptance provision, can a software vendor ever recognize revenue (provided all of the other revenue recognition criteria of SOP 97-2 have been met) before formal customer acceptance occurs? Reply Yes. Paragraph 20 of SOP 97-2 is not intended to suggest that the mere existence of a customer acceptance provision precludes revenue recognition until formal acceptance has occurred. Items to consider in evaluating the effect of customer acceptance on revenue recognition include, but are not limited to, (a) historical experience with similar types of arrangements or products, (b) whether the acceptance provisions are specific to the customer or are included in all arrangements, (c) the length of the acceptance term, and d) historical experience with the specific customer. Public registrants subject to SOP 97-2 should also consider the guidance in SEC Staff Accounting Bulletin No. 101 (SAB 101), Revenue Recognition in Financial Statements, and the Frequently Asked Questions to SAB 101, as it relates to customer acceptance. TPA 5100.68 Fair value of PCS in perpetual and multi-year time-based licenses and software revenue recognition Inquiry Software licenses for the same product currently are offered by a software vendor as: (1) a perpetual license and (2) a multi-year time-based license (for example, two or more years). The pricing of the licenses reflects the duration of the license rights. Vendor-specific objective evidence (VSOE) of fair value exists for postcontract customer support (PCS) services in the perpetual licenses. For the multi-year time-based licenses, PCS services for the entire license term are included (bundled) in the license fee and there is no renewal rate inasmuch as the timebased license rights are co-terminus with the PCS service period. Do the PCS renewal terms in the perpetual license provide VSOE of the fair value of the PCS services element included (bundled) in the multi-year time-based software arrangement pursuant to the provisions of SOP 97-2, Software Revenue Recognition? Reply No. SOP 97-2 states that VSOE of fair value is provided by the price charged when the same element is sold separately. PCS services for a perpetual license and PCS services for a multi-year time-based license are two different elements. Though the same unspecified product upgrades or enhancements may be provided under each PCS arrangement, the time period during which the software vendor s customer has the right to use such upgrades or Software Revenue Recognition D-18

enhancements differs based on the terms of the underlying licenses. Because PCS services are bundled for the entire term of the multi-year time-based license, those PCS services are not sold separately. However, in the rare situations in which both of the following circumstances exist, the PCS renewal terms in a perpetual license provide VSOE of the fair value of the PCS services element included (bundled) in the multi-year time-based software arrangement: (1) the term of the multiyear time-based software arrangement is substantially the same as the estimated economic life of the software product and related enhancements that occur during that term; and (2) the fees charged for the perpetual (including fees from the assumed renewal of PCS for the estimated economic life of the software) and multi-year time-based licenses are substantially the same. If the software vendor also offers multi-year time-based licenses for the same product that include bundled PCS services for a portion of the license period (instead of only including bundled PCS services for the entire license term), the renewal terms of those transactions may provide VSOE of the fair value of the PCS services elements that are bundled for the entire license term. See TPA 5100.54 for additional guidance on VSOE of PCS renewals. TPA 5100.69 Delivery terms and software revenue recognition Inquiry SOP 97-2, Software Revenue Recognition, says that delivery is one of the basic criteria for revenue recognition. In an arrangement that requires physical delivery of software, are delivery terms that indicate when the customer assumes the risks and rewards of its licensing rights (for example, FOB Destination and FOB Shipping Point terms) relevant in the assessment of whether software has been delivered? Reply Yes, including in arrangements in which a software vendor licenses a software product and retains title to the product. For example, software arrangements that include FOB Destination terms do not meet the delivery criterion until the customer receives the software. Public registrants subject to SOP 97-2 should also consider the guidance in SEC Staff Accounting Bulletin No. 101, Revenue Recognition in Financial Statements, as it relates to when delivery is considered to have occurred. TPA 5100.70 Effect of commencement of an initial license term and software revenue recognition Inquiry Revenue recognition in software arrangements that do not require significant production, modification, or customization of the software should occur when all four basic revenue recognition criteria (persuasive evidence of an arrangement, delivery, fixed or determinable fee and probable collectibility) of SOP 97-2, Software Revenue Recognition, are met. None of the four basic criteria specifically address whether the license term also must commence. For example: On December 20, X0, a software vendor enters into a software arrangement with a firsttime customer for the license of Product A and PCS. VSOE of fair value exists for PCS. For reasons that may or may not be known by the software vendor, the customer desires the license to terminate on January 2, X4. The software vendor accepts the customer s terms and structures the arrangement as a three-year term beginning January 3, X1 and ending January 2, X4. On December 20, X0, the software vendor ships the software and collects the fee. Assuming all other criteria for revenue recognition are met, should the software vendor recognize any of the arrangement fee before the license term begins (that is, January 3, X1)? Reply No. Revenue should not be recognized prior to the commencement of the initial license term. Deferring recognition of revenue until the initial license term commences is consistent with TPA 5100.45, which includes a right to use concept, and the overall concept of delivery addressed in SOP 97-2. If the software arrangement were to have been structured as a three-year and 14-day license commencing on December 20, X0 and ending January 2, X4, the software vendor would recognize revenue in December X0 if all other revenue recognition criteria had been met. Software Revenue Recognition D-19

TPA 5100.71 Effect of commencement of an extension/renewal license term and software revenue recognition Inquiry TPA 5100.70, which addresses the effect of commencement of an initial license term on software revenue recognition, indicates revenue should not be recognized before the license term commences even if all other criteria for revenue recognition have been met. If the license were an extension/renewal of a pre-existing, currently active license for the same product(s), would commencement of the extension/renewal term also be a prerequisite for revenue recognition? For example: Consider the arrangement described in TPA 5100.70, including that VSOE of fair value exists for PCS. The license term commenced on January 3, X1 and ends on January 2, X4. Now assume that in September X3, the customer decides it wants to be able to continue to use Product A beyond January 2, X4. The software vendor and customer execute an arrangement on September 20, X3 to extend/renew the terms of the existing license through December 31, X5. The extension/renewal arrangement includes only product(s) already included in the existing, currently active arrangement. Assuming all other revenue recognition criteria are met, should the software vendor recognize the portion of the extension/renewal arrangement fee allocated to the license of Product A as revenue on September 20, X3 or January 3, X4? Reply The software vendor should recognize the portion of the extension/renewal arrangement fee allocated to the license of Product A as revenue on September 20, X3 if all other revenue recognition criteria are met. In the case of an extension/renewal of a pre-existing, currently active license for the same product(s), the customer already has possession of and the right to use the software to which the extension/renewal applies. However, if the customer s pre-existing license for the product(s) had lapsed (that is, was not currently active), a new arrangement including the same software product(s) should be accounted for as an initial arrangement and not as an extension/renewal. In considering the guidance in paragraphs 28 and 29 of SOP 97-2, Software Revenue Recognition, for determining whether the extension/renewal fee is fixed or determinable, the date that the extension/renewal arrangement is executed should be used to determine whether the extension/renewal payment terms are extended. TPA 5100.72 Effect of additional product(s) in an extension/renewal of license term and software revenue recognition Inquiry TPA 5100.71 addresses the effect of commencement of an extension/renewal license term when the extension/renewal arrangement includes only a product(s) already included in the existing, currently active arrangement. If the extension/renewal arrangement includes additional product(s), how should the extension/renewal arrangement fee be allocated to the different products? For example: Consider the arrangement described in TPA 5100.71, including that VSOE of fair value exists for PCS. The license term of Product A commenced on January 3, X1 and ends on January 2, X4. In September X3, the customer decides it wants to be able to continue to use Product A beyond January 2, X4 and now assume that the customer also wants to include in the arrangement a license to Product B, which will commence upon the delivery of Product B. The software vendor and customer execute an arrangement on September 20, X3 to extend/renew the terms of the existing, currently active license of Product A through December 31, X5 and also to license Product B. The software vendor has VSOE of fair value for Products A and B, and Product B is expected to be delivered in the first quarter of X4. How should the software vendor allocate and recognize the portions of the extension/renewal arrangement fee allocated to Products A and B? Software Revenue Recognition D-20

Reply The software vendor should allocate the extension/renewal arrangement fee using VSOE of fair value consistent with paragraph 10 of SOP 97-2, Software Revenue Recognition. Consistent with TPA 5100.71, the software vendor should recognize the portion of the extension/renewal arrangement fee allocated to Product A as revenue on September 20, X3 (if all other revenue recognition criteria are met) because the customer already has possession of and the right to use the software to which the extension/renewal applies. The portion of the extension/renewal arrangement fee allocated to Product B should be recognized when the criteria of paragraph 8 of SOP 97-2 are met and the license period for Product B has commenced. In considering the guidance in paragraphs 28 and 29 of SOP 97-2 for determining whether the extension/renewal fee is fixed or determinable, the date that the extension/renewal arrangement is executed as it relates to the portion of the arrangement fee allocated to Product A, and the date Product B is delivered as it relates to the portion of the arrangement fee allocated to Product B, should be used to determine whether the extension/renewal arrangement payment terms are extended. TPA 5100.73 Software revenue recognition for an arrangement containing an option to extend a time-based license indefinitely Inquiry A software vendor sells Product A with PCS under a three-year term license with PCS renewable after year 1. VSOE of fair value exists for PCS. The arrangement specifies that any time during its term the customer can extend the license for Product A indefinitely for an additional fee. Effectively, the arrangement contains an option to convert the three-year term license into a perpetual license for Product A. Does the option to convert represent an element as that term is used in paragraph 10 of SOP 97-2, Software Revenue Recognition? Would the answer differ if the perpetual license for Product A necessitated another delivery of software media because the term license software media contained a self-destruct or similar mechanism to allow the vendor to control the usage of its intellectual property? Reply The option itself is not an element as contemplated in paragraph 10 of SOP 97-2 because there is no new deliverable. The exercise of the option merely affords the customer a longer time period over which to use the same Product A that it already has as part of the original arrangement. The additional fee to exercise the option is essentially the same as the fee for an extension/renewal of a license, as discussed in TPA 5100.71. Further, the need for another delivery of the software media as a result of a self-destruct or similar mechanism would not create an element or deliverable to be accounted for in the original arrangement; however, such media would need to be delivered before the option exercise fee could be recognized as revenue. TPA 5100.74 Effect of discounts on future products on the residual method and software revenue recognition Inquiry TPA 5100.50 defines a more-than-insignificant discount with respect to future purchases and TPA 5100.51 provides examples of accounting for significant incremental discounts that are within the scope of SOP 97-2, Software Revenue Recognition. The term discount, as used in SOP 97-2 and the related TPAs, is the difference between the arrangement fee and VSOE of fair value when VSOE of fair value exists for all elements in the arrangement. A question arises as to how to compute the amount of a discount when the software vendor is applying the residual method because VSOE of fair value does not exist for all of the elements in the arrangement but does exist for all of the undelivered elements. For example: A software vendor enters into an arrangement with a customer that licenses currently available software products and services (referred to as the initial arrangement) and offers a discount off of its published list price on future purchases of products not previously licensed by the customer. The software vendor does not have VSOE of fair value of its software products. However, the software vendor is able to apply the residual method pursuant to SOP 98-9, Modification of SOP 97-2, Software Revenue Recognition, With Respect to Certain Transactions, when the only undelivered elements are services. Software Revenue Recognition D-21

How should the software vendor determine if the discount on future purchases of future products is significant and incremental (as discussed in TPA 5100.50) since it does not have VSOE of fair value of its software products? Reply In this situation, the software vendor should compute the discount provided in the initial arrangement by comparing the published list price of the delivered elements in the initial arrangement to the residual value attributable to those delivered elements. If the discount on future purchases of future products is significant and incremental to the discount provided on the delivered elements in the initial arrangement, the software vendor should apply the significant and incremental discount on future purchases to the initial arrangement using the guidance in TPA 5100.51. Example: On December 31, 20X1, software vendor licenses Product A (with a published list price of $100) on a perpetual basis, bundled with PCS for the first year, to a customer for $80. The customer may elect to renew PCS following the initial year at a stipulated rate of $15, which requires the software vendor to apply the residual method pursuant to SOP 98-9. In conjunction with the licensing of Product A, the software vendor offers the customer a 55% discount off of its published list price on the purchase of all new products released by the software vendor during the three years subsequent to December 31, 20X1, with no maximum cumulative discount. Based on the guidance in the reply above, the software vendor would perform the calculation below to assist in determining whether the discount offered on future purchases of future products is significant and incremental (as discussed in TPA 5100.50): Published Residual Discount from List Price Value Published List Price Product A $100 $65 35.00% Future products Unknown Unknown 55.00% Additional discount from published list price 20.00% Assuming that the software vendor concludes that the additional discount (that is, 20.00% in this example) on future purchases is significant and incremental, the software vendor should allocate such discount to Product A and defer revenue related to the PCS in the initial arrangement as follows: (a) (b) (a)*(b)= (c) (d) (c)+(d)= (e) (f) (f)-(e) Revenue Deferral for Revenue Total Up-front Published Addt l Additional Deferral Revenue Arrangement Revenue List Price Discount Discount for PCS Deferral Fee Product A $100 20% $20 $15 $35 $80 $45 Consistent with Example 5 in TPA 5100.51, upon delivery of Product A, the vendor should recognize $45 of revenue and defer $35, provided all other requirements of revenue recognition in SOP 97-2 are met. The revenue related to PCS ($15) deferred pursuant to the residual method should be recognized over the initial year of the license in accordance with paragraph 57 of SOP 97-2. The deferred revenue related to the discount ($20) should be accounted for as a subscription in accordance with paragraphs 48 and 49 of SOP 97-2 and recognized pro rata over the three-year discount period. If the customer purchases additional products using the discount, the vendor would recognize revenue equal to the fee attributable to those additional products, provided all other requirements of revenue recognition in SOP 97-2 are met. Software Revenue Recognition D-22

TPA 5100.75 Fair value of PCS renewals based on users deployed and software revenue recognition Inquiry A software vendor offers a perpetual license to an end-user customer for a software product with post-contract customer support (PCS) bundled for the initial year. The initial fee is $1,150,000 ($1,000,000 is stated as the software license fee and $150,000 is stated as the PCS fee). The end-user customer is entitled to deploy an unlimited number of copies of the licensed software product for a 3-year period. During the 3-year unlimited deployment period, the end-user customer has the option to renew PCS annually for years 2 and 3 for a stipulated fee of 15% of the stated license fee, which is $150,000 per year. After the expiration of the 3-year unlimited deployment period, the end-user customer is required to pay additional license and PCS fees if it deploys additional copies of the software product. The optional PCS fee for year 4 and annually thereafter is based on the ultimate number of copies of the software product deployed by the enduser customer at the end of the 3-year unlimited deployment period. Do the annual PCS renewal rates stipulated for years 2 and 3 constitute vendor-specific objective evidence (VSOE) of fair value for the year 1 PCS in accordance with SOP 97-2, Software Revenue Recognition? Reply No. In this arrangement there are two different pricing methodologies for PCS and no basis for determining which pricing methodology produces the appropriate VSOE of fair value of the PCS bundled in year 1 and offered in years 2 and 3. Accordingly, the vendor should recognize the entire arrangement fee ($1,450,000) ratably over the three-year deployment period (the aggregate fee recognized should not exceed the amount that is not subject to forfeiture, refund, or other concession, as required in paragraph 14 of SOP 97-2). This presumes that PCS will be renewed in years 2 and 3; however, if the customer does not renew PCS in year 2 or year 3, the vendor should recognize the remaining deferred revenue at the time PCS is no longer being provided. If sufficient objective evidence demonstrated that the renewal rate in year 4 and thereafter is more likely than not (that is, a likelihood of more than fifty percent, as that term is used in FASB Statement No. 109, Accounting for Income Taxes) to approximate or be less than the amount charged in years 2 and 3, the annual PCS renewal rates stipulated for years 2 and 3 would constitute VSOE of fair value of PCS. One example of such evidence would be a vendor s past history of deployment with other comparable arrangements that result in postdeployment PCS fees that approximate PCS fees charged during the unlimited deployment period. Another example of such evidence would be a stated cap or maximum on the price to be charged for PCS in year 4 and thereafter that would result in a price that approximates or is less than the amount charged in years 2 and 3. In such a circumstance, the amount allocated to the perpetual license ($1,000,000) would be recognized immediately provided all other requirements for revenue recognition in SOP 97-2 are met, and the fair value of PCS in year 1 would be recognized ratably over the PCS period. Likewise, the fees related to PCS renewals after year 1 ($150,000 each for years 2 and 3) would be recognized ratably over the respective PCS periods. TPA 5100.76 Fair value in multiple-element arrangements that include contingent usagebased fees and software revenue recognition Inquiry Software vendors may enter into various multiple-element arrangements that provide for both licensing rights and post-contract customer support (PCS) and that include contingent usage-based fees. Usage-based fees are determined based on applying a constant multiplier to the frequency that the licensee uses the software, for example, customer call center software wherein a fee of $.01 is charged for each call handled. That fee structure is different from fees that are determined based on the number of individuals or workstations that use or employ the software (that is, user-based fees). If usage-based fees are not paid timely, the licensee's perpetual license to use the software is vacated and there is no continuing obligation to provide PCS. Software Revenue Recognition D-23

The following scenarios focus on circumstances in which software functionality is used by the software licensee only in processing the activity that underlies the measurement of the usagebased fee, that is, the software provides the licensee with no internal-use functionality for which a usage-based fee would not be charged. In each of the three scenarios, how should a software vendor recognize revenue for the perpetual license, PCS, and contingent usage-based fee elements? Scenario No. 1 Arrangement provides for a non-refundable initial fee for the perpetual license and contingent usage-based fees determined monthly or quarterly and due shortly thereafter. PCS is provided at no additional charge for the first year and the licensee may purchase renewal PCS annually thereafter for a fixed amount that is deemed substantive (the renewal rate). Scenario No. 2 Arrangement provides for a non-refundable initial fee for the perpetual license and contingent usage-based fees determined monthly or quarterly and due shortly thereafter. PCS is provided at no additional stated charge (or the pricing of PCS is stated as being included in the contingent usage-based fee). Scenario No. 3 Arrangement provides for a perpetual license solely in exchange for contingent usage-based fees determined monthly or quarterly and due shortly thereafter. PCS is provided at no additional stated charge. Reply Usage-based fees are not specifically addressed in SOP 97-2, Software Revenue Recognition. However, paragraph 10, which provides guidance as to what constitutes vendorspecific objective evidence (VSOE) of fair value of the elements of a software arrangement, states, in part: "When a vendor's pricing is based on multiple factors such as the number of products and the number of users, the amount allocated to the same element when sold separately must consider all the factors of the vendor's pricing structure." Accordingly, usagebased fees should be considered in determining whether there is sufficient VSOE of fair value of all the elements of an arrangement. Scenario No. 1 The existence of a substantive renewal rate for PCS allows for the determination of the portion of the initial fee that should be allocated to the perpetual license through the application of the residual method described in SOP 98-9, Modification of SOP 97-2, Software Revenue Recognition With Respect to Certain Transactions. That amount should be recognized as revenue when the criteria in paragraph 8 of SOP 97-2 are satisfied. The amount allocated to PCS should be recognized pursuant to the requirements of paragraph 57 of SOP 97-2. The usage-based fee should be recognized at the time a reliable estimate can be made of the actual usage that has occurred (estimates may be used, for example, if there is a lag in the reporting of actual usage), provided collectibility is probable. Scenario No. 2 Because there is no substantive renewal rate for PCS, there is no VSOE of fair value of the PCS that is to be provided, which precludes application of the residual method to determine the portion of the initial fee allocable to the perpetual license. Further, there is not sufficient objective evidence to demonstrate that some portion of the initial fee does not represent payment for future PCS. Accordingly, pursuant to paragraphs 12 and 58 of SOP 97-2, the initial fee should be recognized ratably over the period that the vendor expects to provide PCS because there is no contractual term for the PCS. The usage-based fee should be recognized at the time a reliable estimate can be made of the actual usage that has occurred, provided collectibility is probable. Scenario No. 3 The usage-based fee represents payment for both the perpetual license right and PCS. However, that fee becomes fixed or determinable only at the time actual usage occurs. Therefore, revenue should be recognized at the time a reliable estimate can be made of the actual usage that has occurred, provided collectibility is probable. Software Revenue Recognition D-24

Pub code: SRR101 pwcrevrec.com 2009 PricewaterhouseCoopers LLP. All rights reserved. "PricewaterhouseCoopers" refers to PricewaterhouseCoopers LLP or, as the context requires, the PricewaterhouseCoopers global network or other member firms of the network, each of which is a separate and independent legal entity.