Third Place Massachusetts
Society of CPA's Student Manuscript!

Let’s Give Some Recognition to SOP 97-2
By David Heinze
Bridgewater State College

Since the Accounting Standards Executive Committee (AcSEC) of the American Institute of Certified Public Accountants (AICPA) issued Statement of Position (SOP) 91-1, Software Revenue Recognition, in 1991, there have been many changes in the software industry that have lead to complex transactions and a diversity of practices in recognizing revenue. Because of the diverse practices in the industry of recognizing revenue, issues relating to reliability of financial statements and comparability among companies in the industry have been increasingly apparent. Although complex, a more conservative approach to recognizing software revenue was outlined to address these issues. In October 1997, the AICPA issued SOP 97-2, Software Revenue Recognition, which supersedes SOP 91-1. As paragraph 2 states, SOP 97-2 applies to any entity that earns revenue by leasing, licensing, selling, or otherwise marketing computer software. However, it does not apply to products or services that are incidental to the product or service as a whole.

According to the Financial Accounting Standards Board’s (FASB) Statement of Financial Accounting Concepts (SFAC) 5, Recognition and Measurement in Financial Statements of Business Enterprises, revenue as an element of financial statements must meet the following four recognition criteria: (1) meet the definition of a revenue, (2) be measurable, (3) be relevant, and (4) be reliable (Delaney 59). Because of complexities in software transactions, SOP 97-2 expands on this concept and targets software revenue recognition specifically.

Basic software revenue recognition exists if an arrangement or contract to deliver software does not require substantial customization, modification, or production of the software. If the arrangement or contract involves more than one element, revenue recognition is applied to each element separately ("Statement" 3). For arrangements that do require substantial customization, modification, or production of the software, paragraph 7 of SOP 97-2 mandates that the entire arrangement be accounted for in conformity with Accounting Research Bulletin (ARB) 45, Long-Term Construction-Type Contracts, and SOP 81-1, Accounting for Performance of Construction-Type and Certain Production-Type Contracts. Similarly to SFAC 5, paragraphs 14 through 33 of SOP 97-2 detail four recognition criteria. These paragraphs detail the four basic criteria needed for software revenue recognition: (1) persuasive evidence that an arrangement exists, (2) delivery has occurred, (3) the vendor’s fee is fixed or determinable, and (4) collectibility is probable.

Persuasive evidence that an arrangement exists is first and foremost in recognizing revenue. In order to be persuasive evidence of an arrangement, the arrangement must be made using the vendor’s usual or customary practice of making an arrangement. If a vendor normally uses contractual agreements, evidence of an arrangement is only provided by a contract signed by both parties. If a vendor normally uses on-line acknowledgments, evidence of an arrangement is provided when the customer agrees to the arrangement on-line ("Statement" 3). In comparing SOP 97-2 with SOP 91-1, persuasive evidence of an agreement is required for both SOP’s. However, SOP 97-2 further defined persuasive evidence by the vendor’s customary practices ("Software", Guidebook, 4). Using a vendor’s customary practice helps reduce the diversity of practice when determining that an arrangement has taken place.

Although persuasive evidence that an arrangement exists is first and foremost in recognizing revenue, delivery is the deciding factor for revenue recognition. This is consistent with the principles set forth in SFAC 5, where revenues are usually realized or realizable and earned when the product is delivered (Delaney 828). Delivery is considered to have occurred upon transfer of the software, usually the product master copy or first copy, to the customer’s place of business or a site specified by the customer. Delivery to anyone other than the customer, such as a delivery agent or fulfillment house, does not constitute delivery. Delivery is also considered to have occurred when the customer downloads the software via electronic data or is given access to the software via authorization codes or keys (SOP 97-2, para. 18-25). In SOP 91-1, delivery was considered to have occurred when risk of loss was transferred to the customer. This is basically the same as SOP 97-2 for the physical delivery of software. However, SOP 97-2 includes the alternate forms of delivery as discussed above ("Software", Guidebook, 4). Because SOP 97-2 further clarifies when a delivery has occurred, it alleviates the diversity of practices among companies regarding delivery.

The third criterion for software revenue recognition requires that the vendor fee is fixed or determinable. A vendor fee is usually a licensing fee or a royalty fee and is generally associated with the sale and delivery of software. The vendor fee is not fixed or determinable if it is based on a number of copies or a number of users of the product. Furthermore, the vendor fee is not fixed or determinable if the payment period extends past 12 months or the existing terms are substantially extended past the customer’s expected use. Any fees that are not fixed or determinable would be recognized as they become due ("Statement" 4). Other factors helpful in determining whether a fee is fixed or determinable include business practices, reseller’s operating history, reseller’s financial stability, competitive pressures or any factor that would indicate that payment of the fee is substantially contingent on the reseller’s success. Additionally, vendor fees are not fixed or determinable if there any provisions for customer cancellation or fiscal funding through a government unit (SOP 97-2, para. 30-33). The main difference between SOP 91-1 and SOP 97-2 regarding vendor fees is that SOP 91-1 provided no guidance for recognizing revenue if a fee was not fixed or determinable. Nor did it provide any guidance on fiscal funding ("Software", Guidebook, 5). The possibility for misinterpretation of the provisions set for assessing a fixed or determinable fee under SOP 91-1 was further minimized with changes in SOP 97-2.

The fourth and final criterion for recognizing revenue for software is that the collectibility of the vendor fee is probable. Paragraph 14 of SOP 97-2 outlines the following factors in determining whether the collectibility of the fee is probable: (1) acknowledgment in the arrangement of products not currently available or not to be delivered currently, (2) separate prices stipulated in the arrangement for each deliverable element, (3) default and damage provisions are defined in the arrangement, (4) Enforceable payment obligations and due dates for the delivered elements, coupled with the intent of the vendor to enforce rights of payment, (5) installation and use of the delivered software, and (6) support services related to the delivered software are being provided by the vendor. Regardless of the evaluation of the factors listed above, revenue collectibility should not be considered probable if the vendor has a historical pattern of making concessions. If any portion of the fee is subject to forfeiture, refund, or concession due to the contingency of undelivered goods being delivered, that portion of the fee is deemed not collectible until delivery has taken place ("Statement" 3). The same was true in SOP 91-1. There are no real differences or changes between SOP 91-1 and SOP 97-2 regarding collectibility.

The real differences or changes between SOP 91-1 and SOP 97-2 begin with multiple element arrangements. SOP 91-1 did not explicitly address multiple element arrangements; it implicitly addressed multiple element arrangements by assessing whether significant vendor obligations or insignificant vendor obligations were included in the arrangement. If an arrangement included significant vendor obligations, revenue would not be recognized until the obligation was no longer significant. ("Software", Guidebook, 5). SOP 97-2 eliminated the distinction between significant and insignificant vendor obligations altogether. All obligations are considered to be additional elements of the arrangement and each must be accounted for separately on an element by element basis ("Statement" 5). Revenue recognized on this basis must be allocated to each element in proportion to relative fair values. This allocation process requires that vendor-specific objective evidence (VSOE) of fair value be used. VSOE is the price charged when the element is sold separately. Only VSOE may be used to determine an element’s fair value. Any other prices, such as competitor’s prices or industry averages, may not be used because they may result in an unreasonable allocation of revenue (Delaney 829). This allocation of revenue is only indicative of SOP 97-2. SOP 91-1 did not address ‘when -and-if available deliverables’ either. ‘When-and-if available deliverables’ are usually specified upgrades or enhancements included with a multiple element arrangement that may or may not be available in the future. SOP 97-2 recognizes these possible deliverables as additional elements to the multiple element arrangement. Revenue is not recognized until delivery takes place for the specified upgrade or enhancement ("Software", Guidebook, 6).

Occasionally, it is not known if or when upgrades or enhancements will be needed in the future. Unspecified upgrades and enhancements are included in the Post-Contract Customer Support (PCS) arrangements. PCS revenue may be recognized with the initial licensing fee if the unspecified upgrades and enhancements have been and are expected to remain minimal and infrequent, the PCS fee is included with the initial licensing fee, the period of the license is one year or less, and the estimate cost of providing PCS is negligible ("Statement" 4). If the PCS revenue cannot be recognized with the initial licensing fee, VSOE of fair values is determined for each element and the corresponding revenue is allocated when each element is delivered. If sufficient VSOE does not exist to allocate revenue to each element, the entire PCS fee would be allocated ratable over the life of the PCS arrangement ("Software", Guidebook, 3). SOP 91-1 recognition was somewhat comparable to SOP 97-2 in recognizing PCS revenue with the exception of specified upgrade rights and specified additional software products. SOP 91-1 included specified upgrade rights and specified additional software products as part of the PCS arrangement. SOP 97-2 made these separate elements from the PCS arrangement. ("Software", Guidebook, 7)

Specified upgrade rights are accounted for as a separate element even if it was originally part of the PCS arrangement. A specific upgrade right may or may not be exercised by the customer because of a lack of need for the upgrade, nominal improvement created by the upgrade, or the upgrade may require additional hardware. Because the upgrade right may not be exercised, any revenue allocated to a specific upgrade right should be reduced by the percentage of customers not expected to exercise the upgrade right (SOP 97-2, para. 118). In SOP 91-1, an overstatement of revenue was possible because there was no provision to reduce the allocation of revenue for customers that did not exercise their specified upgrade right.

In contrast to specified upgrade rights, revenue allocated to specified additional software products should not be reduced because it is probable that the customer is expected to exercise the right to receive additional software products (SOP 97-2, para. 119). Instead, allocated revenue for a specified additional software product is generally recognized when the product is delivered. Because it was part of the PCS arrangement under SOP 91-1, revenue for the specified additional software product was recognized when the PCS revenue was recognized ("Software", Guidebook, 3). Because revenue is recognized over the life of the PCS arrangement, failure to recognize specified additional software product revenue at the time of delivery could result in a large timing difference depending upon the life of the PCS contract.

Service contracts or arrangements are services not included in the PCS contract. Services may include consulting, installation, or training. For an arrangement to be accounted for as a service arrangement it must have sufficient VSOE to allocate revenue among each element of the service arrangement, it must not be essential to the functionality of any other element, and each service must be stated separately in the arrangement. If the arrangement does not qualify as a service arrangement, contract accounting is applied ("Software", Guidebook, 3). As stated earlier, contract accounting must be accounted for in conformity with ARB 45, Long-Term Construction-Type Contracts, and SOP 81-1, Accounting for Performance of Construction-Type and Certain Production-Type Contracts. SOP 97-2 provides a greatly expanded distinction over SOP 91-1 between service arrangements and contract accounting. This distinction helps reduce diverse practices among companies in regard to accounting for service contracts.

The diversity of practices among companies in the software industry is directly related to the complexity and ever-changing software technology. SOP 91-1 was a good start but quickly became obsolete with the changing software technology. SOP 97-2 has addressed many of the pitfalls associated with SOP 91-1 and has created more conservative and reliable environment for accounting. With the software industry following guidelines set by SOP 97-2, comparability is greatly enhanced among software companies. SOP 97-2 will probably become obsolete in the near future due to technological changes. In March 1998, SOP 98-4, Deferral of the Effective Date of a Provision of SOP 97-2, has already amended SOP 97-2. There will probably be more amendments and eventually another SOP that supersedes SOP 97-2. Anyway, let’s give some recognition to SOP 97-2 while it is still here.

 

Works Cited

Delaney, Patrick R., et al. Wiley GAAP 99: Interpretation and Application of Generally Accepted Accounting Principles 1999. New York: John Wiley & Sons, Inc., 1999.

"Software Revenue Recognition." AICPA Statement of Position 97-2. Oct. 1997.

"Software Revenue Recognition: An Analysis of Statement of Position 97-2." SOP 97-2 Guidebook Executive Summary.

"Statement of Position Software Revenue Recognition." Arthur Anderson: SOP Software Revenue Recognition. Nov. 1997.

Last Modified: April 6, 2004