Home

Revenue Recognition for Software
(Internally Generated)

DRAFT

THIS DRAFT SHOULD NOT BE RELIED UPON FOR ACADEMIC, SCIENTIFIC, LEGAL OR OTHER USES. THIS DRAFT CONSISTS OF UNVETTED, UNVERIFIED STATEMENTS THAT COULD CHANGE AT ANY TIME.

 

Yigal Rechtman
2001-2002

Introduction

A rising discontent of investor over revenue recognition under a pro-forma method as in the Financial Statement of Computer Associate's underlines the recognition question of intangible assets, such as software. Under current U.S. GAAP, the pro-forma revenue recognition constitute a departure from US-GAAP. In the knowledge industry, Software is divided into three areas:

(1) Purchased software (or software license)

(2) Internally developed software

(3) Rented software usage, mostly via public network such as the Internet.

This paper attempts to address the cost recognition of development of software to the software publishers. The elements of timing and valuation of such costs are at the core of this recognition discontent. Other elements in recognitions include title to the software, maintenance and recall costs, et al.

The method of addressing this issue will be by reading appropriate published research and by inspecting, on an empirical basis, the cost recognition methods of software developers in the annual financial statements. To the extent available, arguments for any recognition model (regardless of its GAAP acceptability) will be presented.

Generally Accepted Accounting Principles

Computer software development has two flavors to the accounting treatment. The Statement of Financial Accounting Standard (SFAS) No. 86 Accounting for the Costs of Computer Software to Be Sold, Leased or Otherwise Marketed require expenditure of the costs to develop software as they incur. Thus, software development is not a capitalization event, but treated as other Research and Development (R&D) costs(1). Most software companies, include Microsoft(2) and Computer Associates(3) follow this GAAP method of expenditure.

Some might argue that the concept behind SFAS No. 86 is counter intuitive to the concept that holds that an asset can not be considered complete, until all the development costs to make the asset useable. Thus, contrary to SFAS No. 86 a software package is not a revenue-generating asset until it is completely ready to ship. Thus, software vendors whose assets are mostly intangible, do not capitalize these assets; instead, vendors recognize only the incidental costs of "bringing to service" the related asset. By not capitalizing software development costs, the need for valuation of the final product is averted (such a process is typically rich with uncertainties).

The AICPA's Statement of Position No. 97-2 Software Revenue Recognition Revenue of a combined software and maintenance is to be recognized over the term of the contract, using determinable and certain amounts in order to value the recognized portion. The same is true for other substantial mixes that include intangible asset (software) and software-related services such as consulting, maintenance, training et cetera.

However, direct licensing of software, which is the greater part of revenues for software developers, are recognized upon shipment of the license and is not deferred to later period. For example, the two software development companies examined in this paper, Computer Associates and Microsoft, product sale as a percentage of revenue of 2000 is 94% and 88%, respectively. The high proportionate elements of the revenue recognition highlights two conflicting purposes in revenue recognition from sale of software products.

On the one hand, as illustrated by the Income Statement of Microsoft(4), and the practice of the majority of software companies(5), the business purpose of the sale is the driving force behind recognition. Barring contingencies and other uncertainties, Microsoft, for example recognizes software license sale upon shipment (or invoicing) of the product. This, in turn follows the business model that allows for faster recovery of the R&D costs incurred in recent periods. Because the average development cycle lasts between 24-30 months, most software companies hope to report recovery of the costs incurred during the preceding two and a half years, by following this method of accounting.

Contrary to the industry-at-large viewpoint, recent changes to the reporting practices of a few software companies bring to contrast the prevailing method of full recognition. Because most direct software sale are not a mix of licensing and other services. As in an operating lease, there are those who argue that the "business purpose" principle should prevail when recognizing revenues from a licensing agreement. The argument has three parts: First, the licensing agreement, unbound by other services, should be viewed as a series of events over time (or a continuous flow) whereas the user-licensee is using the asset owned by the developer-licensor. Second, Recognizing the full contract amount upon delivery of the license, understates the level of liability that is attached to the delivery of the software. Although some software packages are delivered "as is", most high-end software contract require the vendor to deliver updates, corrections and maintenance to the product. Thus, some researchers conclude that "non refundable up-front fee should be recognized as revenue evenly during the subscription period"(6).

Finally, The quasi-Off Balance Sheet Accounting method used by software developers has also caused a phenomena that exposes the business itself to reduced bargaining leverage: the "Quarter End Crunch" is described as the rush of software developers to sign contracts at the end of a period in order to enhance the recognized sales amounts(7). Prospective users, knowing the pressure on the developers, use that deadline approach for leverage in negotiation. In response, some companies such as Computer Associates and Synopsys, use a provision in the AICPA's SOP 97-2 that allows for residual method of revenue recognition. Under the residual method, the contract terms determine that amount of revenue recognized, whereas the remainder remains unearned. The re-statement of revenues does require a leap of faith: Synopsys(8), for example, had to revise their earning per share for 2001 by decreasing it 380% ($0.90 versus $3.84) because of this accounting change.

The fact that the revenue from software sale is a transfer of ownership of an intangible asset from the developer to the user, and that the duplication of the asset in its tangible form has practically no cost to the developer, should not be confused with the utility that the asset provides to the user. From the users's stand point, this is an asset equivalent to other tangible asset, and costs of obtaining it (especially over a period longer than 12 months), are accrued accordingly.



SFAS No.86

SOP 97-2

Current Treatment

Issue

Current Treatment

Issue

Costs of Development

Period Cost, same as R&D

Software is not revenue-generating until it is shipped, so associated costs should be matched for the period of sale

N/A

N/A

Revenue Recognition - Valuation

N/A

N/A

Revenues from a mixture of software and maintenance should be recognized over term of contract

Product sale, versus maintenance is very high proportion of the revenue stream. This high rate brings to doubt the ability to recognize a mix of software and maintenance over the contract's term

Revenue Recognition - Timing

N/A

N/A

Revenue from a mixture of software license and maintenance is recognized upon inception of contract

Future revenue-stream events are ignored

Liability for subsequent period is un-stated

"Quarter end crunch" exposes sale force to reduced prices

In addition, to the user the timing of the expense is the same as a purchase of a tangible asset.

Table: Summery of Areas and Issues

Revenue recognition in some software developer's financial statements

The discussion in this section is divided into two elements of the financial statement that most affect users: presentation and disclosure. As shown in research [Note here], reasonably careful users make use of both these elements to arrive at informed conclusions.

Presentation

The presentation of the revenue recognition yield some clues about the significance of the method of recognizing revenues in the financial statements examined. In Novell(9) and Microsoft's statements, for example, the mix of services and sales is aggregated as "Revenues". The desegregation of the Revenue figure is done elsewhere in the Financial Statement. On its face, the effect of recognizing license sale in full is favorable to the Operating Income reported. However, the balance sheet effect in terms of liabilities and leverage over contract negotiation is not presented. It is possible that Microsoft, a monopolistic organization without a past of dividend distribution, is in a perfect position to avoid revenue recognition that factors in the time element of the term of sales contract. This explanation however does not work well for Novell, who has a dividend distribution pattern and is facing increased competition.

In contrast, Computer Associates presents the separate amount of revenues from sale of license and revenue from consulting services on the face of the statement. Further, Computer Associates separates costs that are attributed to these items (Development and Commission, respectively). The notes to Computer Associates' Statement refer to the SOP 97-2 provision for residual method of revenue recognition.

Disclosure

In all cases examined, full disclosure was present to the method and effect of the accounting for revenues. It is not clear, however, what is the purpose of aggregating non-mixed sales contracts with mixed sales contract that include services (as in the case of Novell, Microsoft) . Although completely within the scope of full disclosure, the assumption of a reader should be one of reasonable (versus susceptible to presentation method.)



Conclusion

Barring any inappropriate disclosure, vis--vis the utility of the presentation financial statement to its users, the residual method of revenue recognition seems beneficial in two areas: operation and financial reporting. As effect on operation, the recognition of sales upon shipping is an intuitive answer to the "rush-to-book" syndrome at period-end, weakening the customer's leverage and, by inversion, increasing the company's bargaining power.

As a reporting tool, reporting "pro forma" results of operation may be a disguised "cost deferral" scheme, also known as "capitalization". However, in substance there is economic meaningfulness to recognizing costs of internally developed software over a period of time under which it is created. Thus, substance prevails over form.

Historically, the late 1990s are marred with dot-com and fly-by-night software companies that all but vanished by 2001. It would be appealing to inspect in the current decade, the correlation between the result of operation of companies reporting o the residual method, and their GAAP-compliant contemporaries.





Notes and References

1. R&D Spending Patterns of Global Firms. Research Technology Management; Washington; Sep/Oct 2000; B Bowonder et al; Volume 43; Issue 5; pp. 40-56

2. Microsoft 2001 Online Annual report. Notes to the Financial Statement: Research and Development.

3. Computer Associates, Annual Report 2001, Notes to the Financial Statement: Capitalized Software Costs, page 31.

4. Microsoft 2001 Online Annual report. Notes to the Financial Statement: Revenue Recognition.

5. Revenue Recognition; Accountancy; London; May 2001; Michele Caso; Vol 127; Issue 1293; Page 104.

6. Revenue Recognition; Accountancy; London; May 2001; Michele Caso; Vol 127; Issue 1293; Page 104.

7. Software Makers Get Freed by an Accounting Change; Fortune; New York; Mar 19, 2001; Herb Greenberg; Volume 143; Issue 6; page 200.

8. Synopsys 2000 Financial Pro forma Performance Summary, Year Ended Oct 31, 2000, Note No. 4 relating to the decrease in revenue attributable to the change in the license strategy change.

9. Novell, Inc. Financial Statements and Supplementary Data; For the Fiscal Year Ended October 31, 2000; page 23.


DRAFT

Yigal Rechtman 2001-2002
Reproduction of this article without
the written consent of the author is prohibited

Yigal Rechtman

Required disclosure