Welcome to Luca!globe
 The CPA Journal Online Current Issue!    Navigation Tips!
Main Menu
CPA Journal
Professional Libary
Professional Forums
Member Services
August 1994

Software revenue recognition.

by Mooney, J. Lowell

    Abstract- The American Institute of Certified Public Accountants has issued SOP 91-1, a standard which delineates acceptable practice in the recognition of revenue obtained from computer software. SOP 91-1 states that revenue can be recognized only after the delivery of the software to a customer. Moreover, it holds that recognition can begin only if two basic criteria are met. The first is that the customer must have accepted the software product after its delivery. The second is that the collectibility of the amount due to the software developer is taken into account when revenue is recognized. As such, SOP 91-1 is consistent with the general rules covering the accounting of product sales. Under SOP 91-1, customer acceptance can be determined in several ways. This could be after testing of the software or after any modifications are cleared. SOP 91-1 also clarifies other revenue recognition rules in relation to contractual differences in various software agreements.

A variety of recognition approaches were followed prior to SOP 91-1. Perhaps the two most common practices were to recognize revenue upon shipment of the software or upon the signing of a contract to deliver the software. Many companies recognized revenue at the earlier contract signing date. Some firms even followed the practice of recognizing revenue upon the customer's acceptance of a software product (i.e., even earlier than the contract signing). Finally, some firms may have followed questionable recognition practices. For example, Exhibit 1 lists allegations against Oracle Company, a major software manufacturer, made by the SEC and a group of investors who claimed the company followed recognition practices designed to inflate and maintain the price of the company's securities at artificially high levels.


* Keeping the company's books and records open for additional business days after the close of the last day of the period

* Back-dating licensing and other agreements

* "Filling the pipeline" by postponing recognition of revenues and net income from one period to another

* Recognizing revenue upon execution of sales contracts when a product was not in production or was unavailable

* Improperly recognizing the entire amount of potential income called for in an agreement immediately upon signing of the contract

* Failing to deduct product returns from revenues

* Double billing customers

Such inconsistencies in practice made it difficult for interested parties to make meaningful comparisons among the financial statements of different software companies. Lenders were wary about providing financing. In December 1991, the AICPA issued a SOP on software revenue recognition.

SOP 91-1 Requirements

SOP 91-1 has the general requirement that revenue be recognized no earlier than upon delivery of the software. However, no revenues may be recognized until two criteria are met: acceptance and collectibility. First, firms may not book revenue from software transactions when there are significant uncertainties regarding the customer's acceptance of the product. Second, if the software is sold on account there must be a reasonable basis for estimating the collectibility of the receivable amount. If no basis for estimating collectibility exists, revenue should be recognized using the installment method or the cost-recovery method.

Recognizing revenue at the time of delivery is consistent with the accounting treatment for the sale of products. According to SOP 91-1 the legal distinction between a license and a sale should not cause a difference in the recognition or revenue, because the rights transferred under software licenses are substantially the same as those normally expected to be transferred via sale.

Customer acceptance may be evidenced in a variety of ways. For PC software, acceptance is evidenced when the shrink-wrap is removed from the package. For software that runs on large networks, minicomputers, and mainframe computers, acceptance may be conditioned upon the buyer being allowed to test the software with live data. If the vendor has to make modifications to the software followed by more on-site testing, the acceptance process could drag on for an extended period with no guarantee that the software will ever be accepted. SOP 91-1 requires that revenue be deferred until any uncertainty regarding acceptance becomes insignificant.

SOP 91-1 provides for several exceptions to the basic requirement that revenue be recognized upon delivery of the software. These exceptions are discussed below. Exhibit 2 presents a summary of the software revenue requirements as set forth in SOP 91-1.


Licenses with No Vendor Obligations

* Recognize revenue upon delivery of the software

Licenses with Insignificant Vendor Obligations

* Accrue costs of insignificant obligations or defer a pro rata portion of revenue to be recognized ratably as the costs are incurred

Licenses with Significant Vendor Obligations

* Recognize revenue according to the contract accounting method or as a service transaction

* If neither of the above methods is appropriate, revenue should be recognized after the software has been delivered and no significant vendor obligations remain

Software Leases

* Recognize revenue from leases in the same manner as revenue from licenses

Post-Contract Customer Support

* Recognize revenue over the period during which the services are provided

Licenses with No Significant Vendor Obligations

Of course, if there are no vendor obligations beyond delivery of the software, revenue should be recognized upon delivery of the software. In fixed fee site license agreements and reseller arrangements, however, it is not uncommon for vendors to have some additional obligations. For example, a vendor may promise to provide a slightly modified version of the software with minimal enhancements or may agree to provide the software on a different medium (e.g., magnetic tape instead of disk). In such cases, the SOP requires that either 1) the associated costs be accrued or 2) a pro rata portion of the revenue be deferred and recognized ratably as the obligations are satisfied

Licenses with Significant Vendor Obligations

Software licenses with significant vendor obligations, typically those designed for operation on minicomputers or mainframe computers, are accounted for either under the contract accounting method or as service transactions. If neither of those methods is appropriate, revenue may be recognized after the software has been delivered and the vendor has satisfied all significant obligations.

SOP 91-1 provides a list of examples that may represent significant obligations. These include installation, testing, training, data conversion, establishing data communications interfaces, system integration, and porting. Whether an obligation is considered significant depends upon the software tools and automated processes used to satisfy the obligation, how often the required activities are performed, past experience, and the level of staff required to complete the work.

If the software contract includes significant production, modification, or customization requirements, the transaction should be accounted for under the percentage-of-completion method. If the contract requires the vendor to provide significant services that are not essential to the functioning of any other element of the transaction, such as data conversion or training, the service component of the contract should be accounted for separately as a service transaction provided the service is separately stated and priced.

Software Leases

In many cases, leases include both hardware and software. SOP 91-1 makes no distinction between leases and licenses. Therefore, the revenue attributable to the software portion of the lease should be accounted for in the same manner as revenue from licenses. Revenue attributable to the non-software portions of the lease (e.g., computer hardware) should be accounted for in accordance with FASB Statement No. 13, Accounting for Leases.

Post-Contract Customer Support

Post-contract customer support (PCS) refers to maintenance or support services provided after a software contract has been signed. PCS revenue should be recognized over the period during which the services are provided. Prior to the SOP, many firms recognized PCS revenue at the contract signing.

PCS revenue is usually recognized on a straightline basis when it is difficult to estimate the exact timing of the services to be provided. However, alternative methods are acceptable where warranted. For example, when the PCS is sold for a fixed number of hours, revenue can be recognized on an hourly basis as support is provided to the customer.

Finally, the SOP does permit PCS revenue to be recognized entirely at once (upon delivery of the software) provided all of the following conditions are met: a) The PCS offered with the license is for one year or less; b) The estimated cost of providing the PCS is insignificant; c) Any enhancements during the initial PCS period offered in the past or expected to be offered in the future have been minimal; and d) Collectibility is probable.

Other SOP Requirements

Accounting for computer software revenues is complicated by the fact that there is so much variety in software agreements. For example, there are standard agreements, negotiated contracts, reseller agreements, and end-user contracts. In addition, there are several different types of site license plans and complex transactions involving hardware, software, and support. SOP 91-1 contains additional information relating to these matters.

The CPA Journal is broadly recognized as an outstanding, technical-refereed publication aimed at public practitioners, management, educators, and other accounting professionals. It is edited by CPAs for CPAs. Our goal is to provide CPAs and other accounting professionals with the information and news to enable them to be successful accountants, managers, and executives in today's practice environments.

©2009 The New York State Society of CPAs. Legal Notices

Visit the new cpajournal.com.