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