Software Revenue Recognition Under SOP 97-2

To Realize or Defer Income, That Is the Question.

AcSEC has issued SOP 97-2, Software Revenue Recognition, to replace SOP 91-1 of the same name. In issuing these SOPs, AcSEC determined that the same basic criteria for revenue recognition should apply to software arrangements as applied to sales of other products. The same underlying concept of delivery being the critical event for identifying when revenue was earned was adopted. The same basic criterion for collectibility being probable was also adopted for identifying when revenue was realized or realizable. The requirement that revenue be fixed or determinable was also adopted, but additional industry-relevant details were added.

Because of the nature of software arrangements, AcSEC determined there was a need for persuasive evidence of an arrangement. This is not the norm in all product sales, but can sometimes be critical for revenue recognition. Practice abuses forced this criterion to be spelled out in greater detail in SOP 97-2.

AcSEC initially tried the same criterion that applies to revenue recognition transactions generally that the seller not have significant future obligations or involvement related to the sale. This criterion proved difficult to apply to software arrangements involving complex mixes of products and services both specified and unspecified with a single fee for the bundled products and services. As a result, SOP 97-2 provides much more detailed and specific guidance on how to account for multiple-element arrangements.

Revenue recognition in the software industry presents an intriguing object lesson in adapting the generalized concepts of revenue recognition to the characteristics and business and operating practices of a specialized industry. Prevalent accounting practices in an industry can establish those practices as GAAP, if the accounting treatment for a transaction is not specified at a higher level in the hierarchy of sources of accounting principles that are generally accepted. The history of the development of an authoritative pronouncement on software revenue recognition goes back over fifteen years to a time when industry practice was the primary source of GAAP. The latest chapter in that history is Statement of Position (SOP) 97-2, Software Revenue Recognition, issued by the AICPA's Accounting Standards Executive Committee (AcSEC) in October 1997.

The guidance of SOP 97-2 is effective for software arrangements entered into in fiscal years beginning after December 15, 1997. Software vendors with a calendar year end would need to begin applying SOP 97-2 to arrangements entered beginning January 1, 1998. Retroactive application to prior period's financial statements is prohibited, but early application may be elected as of the beginning of a fiscal year or interim period for which financial statements have not yet been issued. For public software companies, the first quarterly financial statements that would include the effects of SOP 97-2 would be the first quarter of 1998. The effective date of one of the key provisions of SOP 97-2, however, has already been delayed for certain limited circumstances.

Early Efforts at Establishing Software Revenue Recognition Criteria

In January 1983, ADAPSO, a computer services industry trade organization, released a 1982 survey of accounting practices in the computer services industry. Almost 100% of large software companies (revenues over $10 million) responded, and of these, 25% were public companies.

The survey results showed substantial diversity in revenue recognition practices ranging from the very conservative--on customer payment--to the decidedly aggressive--immediately on contract signing. A full 15% of the companies used contract signing--the point when the customer became obligated to license the software--as the critical event for revenue recognition purposes.

Several industry characteristics were said to justify contract signing as the critical event in the earnings process. One argument was that the usual criteria for transfer of the risks and rewards of ownership were not relevant. The risks of loss associated with possession of a software product are minimized by the low cost of duplicating software. Also, in the software industry, transfer of rights to software is by license rather than outright sale to protect vendors from unauthorized duplication of their products. Thus, it was argued that the focus should be on when the customer's obligation to license is absolute rather than the customer's receipt of the product.

In April 1987, AcSEC sent an issues paper on software revenue recognition to the FASB. AcSEC concluded that 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. The rights transferred under software licenses are substantially the same as those normally expected to be transferred in sales of other kinds of products.

AcSEC was virtually unanimous in the conclusion that delivery was the critical event for revenue recognition purposes, the same as for other product sales. The legal right to software obtained on contract signing was worth nothing without the ability to actually use the software.

The FASB encouraged AcSEC to develop the issues paper into an SOP, and an exposure draft of a proposed SOP was released in January 1991. The underlying concept of recognition of revenue from software product sales at delivery remained constant. AcSEC pointed out that this was consistent with FASB Statement of Financial Accounting Concepts (SFAC) No. 5 (paragraphs 83 and 84) that "the 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.)"

SOP 91-1

In December 1991, AcSEC released SOP 91-1, Software Revenue Recognition, without substantial change from the exposure draft. SOP 91-1 applied the basic conditions for revenue recognition of SFAC No. 5 of being earned and being realized or realizable to software arrangements.

Revenue is earned when an entity has substantially accomplished what it must do in its ongoing major operations, or earnings process, to be entitled to the benefits represented by the revenues. This criterion has sometimes been described as the earnings process being complete or substantially complete. The earnings process is substantially complete when the seller does not have significant future obligations and the buyer is vested with the usual risks and rights of ownership.

Revenue is realized or realizable when the product is exchanged for cash or for claims to cash or other assets that are readily convertible into known amounts of cash. An inability to estimate the amount that will ultimately be collected precludes accrual of revenue.

SOP 91-1 specified the following revenue recognition criteria for licenses of software to either end-users or resellers:

* Delivery has occurred.

* The vendor has no or insignificant obligations remaining.

* Collectibility is probable.

The first two criteria relate to the condition of being earned. The earnings process is substantially completed on delivery, unless the other vendor obligations remaining are significant. If other vendor obligations remaining after delivery are significant, revenue should not be recognized because those obligations must be fulfilled before the earnings process can be considered substantially completed.

The last criterion of probable collectibility relates to revenue being realizable. SOP 91-1 endorsed the existing guidance of APB Opinion No. 10 that where receivables are collectible over an extended period of time and, because of the terms of the transactions or other conditions, there is no reasonable basis for estimating the degree of collectibility, either the installment method or cost recovery method of accounting should be used. SOP 91-1 also stated explicitly that the license fee should be presumed not to be fixed and, thus, revenue should not be recognized if--

* payment was not due until more than 12 months after delivery,

* a significant portion of the licensing fee was not due until after expiration of the license or,

* there were other contingencies that would cause adjustment of the fee based on future developments.

SOP 91-1 also provided guidance on the effect on revenue recognition of software contract provisions that required significant software modification or the provision of other services to implement or maintain the software. The significance of vendor obligations had to be evaluated by assessment of potential risks, estimates of related costs, and the probability that the vendor would be able to fulfill the obligations within the cost estimates. The vendor's service obligations might include software production, modification, customization, or implementation services such as installation, testing, training, data conversion, and establishing interfaces.

If vendor obligations were evaluated as insignificant, revenue could be recognized at delivery as long as the other conditions were met. The remaining vendor obligations could be accounted for by accruing the cost, or by pro rata deferral of a portion of revenue. If the remaining obligations were evaluated as significant, the agreement had to be examined to determine whether to account for the arrangement under contract accounting or as a service transaction. If contract or service accounting did not apply, revenue could not be recognized until the remaining vendor obligations were no longer significant. If there was significant uncertainty about customer acceptance of the software, revenue could not be recognized until the uncertainty became insignificant.

SOP 91-1 renamed the software industry term of maintenance as postcontract customer support (PCS). PCS was defined as a package of services and product enhancements offered after the license term begins. PCS does not include services such as installation related to the initial license. If collectibility was probable, revenue from PCS, including revenue that was bundled with an initial licensing fee, generally was to be recognized ratably over the term of the PCS arrangement. This was a big change in practice because the software industry practice was generally to recognize revenue on signing of the maintenance contract.

In the development of SOP 91-1, AcSEC identified several issues as not unique to the software industry, and essentially referenced the guidance of existing accounting pronouncements. For example, software vendors often granted resellers rights to exchange software. SOP 91-1 indicated that these exchanges should be accounted for in conformity with SFAS No. 48 on sales with rights of return. Exchanges of software by end-users for products with the same price and functionality could be treated as like-kind exchanges and would not affect revenue recognition. The accounting treatment of exchanges has not changed.

Why SOP 97-2?

Since the issuance of SOP 91-1, several practice issues were identified that had not been addressed adequately in SOP 91-1 and certain of its provisions were being applied inconsistently in practice. They include the following:

* SOP 91-1 made the accounting for vendor obligations remaining after delivery of software dependent on whether the obligation was significant or insignificant. However, such determinations were not being made in a consistent manner, leading to a diversity in practice.

* SOP 91-1 did not address arrangements that included software deliverable only when-and-if-available. Implementation questions arose as to whether when-and-if-available terms created contingencies that could be regarded as significant.

Basic Revenue Recognition Criteria

SOP 97-2 restates 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.

The first two criteria relate to the revenue being earned, and the second two criteria relate to the revenue being realized or realizable. Exhibit 1 presents the revenue recognition criteria in comparative form. The additions to the basic revenue recognition criteria (the first and third above) amount to little more than geography as far as the pronouncement goes. Both criteria were already required by SOP 91-1 as part of the implementation guidance. Now they have been moved from the back to the front of the book and given more prominence. However, the significance to practice is greater.

Persuasive Evidence of an Arrangement. The implementation guidance of SOP 91-1 had stated explicitly that "even if all other requirements set forth in this SOP for recognition of revenue are met, revenue should not be recognized on those licenses until persuasive evidence of the agreement exists. Such evidence is usually provided by the signed contract." SOP 97-2 underlines the point by specifying that if a vendor has a customary practice of using written contracts, evidence of the arrangement is provided only by a contract signed by both parties. For example, a letter of intent from a customer would not be enough even if the software was delivered. Also, receipt of a contract after the close of the period would still be inadequate. A written contract signed by both parties must be in hand before recognition.

This explicit requirement was apparently added at the request of the SEC staff and will be expected to be applied very strictly in practice. This type of guidance borders on audit standard setting and is the kind of accounting guidance established in response to abuses in practice.

Fixed or Determinable Fee. As mentioned earlier, SOP 91-1 did require that the vendor's fee be fixed or determinable. This criterion has generally been recognized as an integral aspect of revenue being realized or realizable. Collectibility cannot be adequately evaluated if the amount of revenue is unknown or undeterminable at the date of recognition. SOP 97-2 repeats the prior guidance that the fee should be presumed not to be fixed or determinable if payment of a significant portion is not due until after expiration of the license or more than 12 months after delivery. The guidance is given more prominence in SOP 97-2 and a practice issue is clarified. SOP 97-2 makes clear that if the entire fee is not fixed or determinable at the beginning of the arrangement, no portion of the fee can be recognized until payments become due and payable, and then only if the other recognition criteria are met. The practice of evaluating whether a fee is fixed on a rolling 12-month basis is prohibited. For example, assume the arrangement provides that a license fee of $500,000 is payable over an 18-month period with $200,000 due at the end of 12 months and the balance six months later. Because of the extended payment terms, the fee is presumed to be not fixed or determinable. None of the $500,000 can be recognized at the outset of the arrangement. The portion of the fee due in 12 months cannot be recognized until month 12 when it is actually due and payable.

SOP 97-2 also provides an extensive list of factors that should be considered when evaluating whether a fee is fixed or determinable in arrangements with resellers. A reseller is not the ultimate user of a software product, and factors may indicate that payment is substantially contingent on the reseller's success in distributing the product. For example, a reseller may be new, undercapitalized, or in financial difficulty and therefore unable to demonstrate an ability to honor a commitment to make fixed or determinable payments until the reseller collects from its customers.

Delivery. The underlying concept of SOP 91-1 of delivery being the critical event for basic revenue recognition is retained in SOP 97-2. This criterion applies whether the customer is an end-user or a reseller. SOP 97-2 addresses practice issues on delivery not previously addressed and clarifies some provisions of SOP 91-1. If the software arrangement involves a site license, the duplication of software is incidental to the arrangement. Delivery is considered to have occurred at delivery of the product master or initial copy.

SOP 97-2 makes clear that delivery has not occurred unless the software is shipped to the customer's place of business or another site specified by the customer. Transfer of software to a delivery agent, such as a fulfillment house, does not meet the delivery criterion.

In some cases software is encrypted to protect against unauthorized use or duplication. SOP 91-1 did not provide guidance on the effect of authorization codes, or keys, on the revenue recognition process. Delivery of a key is not necessarily required to satisfy the delivery criterion. Generally a vendor would satisfy the delivery criterion if software has been delivered that is fully functional except for the key and delivery of the key is contingent only on actions to be taken by the customer, such as providing the identifying number for the platform or work station on which the software will be used. The customer's obligation to pay cannot be contingent on delivery of the key.

Probable Collectibility. As mentioned earlier, SOP 97-2 gives greater prominence to and more detailed guidance on whether the fee is fixed or determinable, which relates to collectibility as well. SOP 97-2 also deals explicitly with the effect of fiscal funding clauses. A fiscal funding clause is a type of contract clause that is often found in arrangements with governmental units. A fiscal funding clause generally provides that the contract is cancelable if the legislature or funding authority does not appropriate the necessary funds.

SOP 97-2 makes clear that a fiscal funding clause with a customer other than a governmental unit creates a contingency that precludes revenue recognition. SOP 97-2 adopts the position of FASB Technical Bulletin No. 79-10 on fiscal funding clauses in lease agreements and makes recognition of revenue dependent on an evaluation of the likelihood of cancellation through the exercise of the fiscal funding clause. If the likelihood of exercise is remote, revenue recognition would not be precluded.

Multiple Elements

The biggest change that SOP 97-2 makes to the revenue recognition criteria of SOP 91-1 is the elimination of an explicit criterion related to the significance of remaining vendor obligations. SOP 91-1, as explained previously, required such an assessment. Guidance on how to make the assessment was provided, but there was no bright line test. SOP 97-2 effectively substitutes evaluation of multiple elements for assessment of the significance of remaining vendor obligations.

This change relates only to vendor obligations unique to the software industry, such as delivery of future software products, upgrades or enhancements, PCS, or similar services. In keeping with the philosophy of applying existing accounting guidance to matters not unique to the software industry, there could be remaining vendor obligations that might preclude revenue recognition that would have to be evaluated for significance. For example, if a software vendor grants resellers business rights (a franchise) in accordance with SFAS No. 45, the existence of unperformed material services or conditions relating to the sale would preclude revenue recognition. Remaining vendor obligations for software services or products are treated differently under SOP 97-2.

When-and-if-Available Deliverables. Software arrangements may provide licenses for multiple software deliverables. SOP 97-2 refers to these deliverables, such as new software products, upgrades or enhancements, PCS, or other services, as multiple elements. In software arrangements several such elements might be described as being on a when-and-if-available basis. For example, the arrangement may provide that the customer will receive new versions (upgrades) or enhancements of the software, if any, developed in the following year. The vendor has no obligation to develop upgrades or enhancements within a year, but has to provide any that are developed at no charge. SOP 97-2 provides that when-and-if-available deliverables should be considered on the same basis as current deliverables in determining whether an arrangement includes multiple elements.

Fair Value Allocation Among Multiple Elements. SOP 97-2 provides 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. The fair-value allocation should be made regardless of any separate prices stated within the contract for each element. Exhibit 2 summarizes the accounting for the various possible separate elements of a multiple element arrangement.

The most binding aspect of this new requirement is the limitation placed on what constitutes vendor-specific objective evidence. SOP 97-2 restricts vendor-specific objective evidence to the price actually charged by the vendor when the element is sold separately or the price expected to be charged. A common industry practice has been to use the separate prices for elements stated in a contract. AcSEC's criterion would eliminate this practice but would also exclude a competitor's prices for similar elements, industry average prices, or the vendor's own price list.

The reason this requirement is so significant is that lack of vendor-specific objective evidence causes the entire fee from the arrangement to be deferred. For example, assume a vendor enters an arrangement to license a software product and PCS and any enhancement of the software in the next 12 months for $50,000. The contract specifies a price of $40,000 for the software product and $10,000 for the 12-month PCS and enhancements, if any, developed in that period. The vendor routinely sells the software product for $40,000, but does not offer the PCS services or future enhancements for sale separately. Because there is no vendor-specific objective evidence for the PCS services and enhancements, the entire $50,000 fee would have had to be deferred if AcSEC had not made the deferral at effective date decision described below.

Generally, the fee would have to be deferred until all elements of the arrangement had been delivered or until sufficient vendor-specific evidence existed. If the vendor had a history of selling a contract for PCS and future enhancements for $20,000, then a fair value allocation could be made. Two-thirds, or approximately $33,500, would be allocated to the software product and recognized on delivery if collectibility was probable. One-third would be allocated to the PCS/enhancement element, or approximately $16,500 and recognized in accordance with the SOP 97-2 criteria for these elements. SOP 97-2 specifies recognition of PCS fees ratably over the term of the contract; unspecified enhancements are regarded as PCS and also recognized ratably.

SOP 97-2 provided for some exceptions to the deferral of the entire fee until all elements of the arrangement have been delivered when there is a lack of vendor-specific objective evidence. Essentially the entire fee would be recognized on the same basis as used for the undelivered element. For example, in the preceding situation assuming PCS and enhancements were not sold separately and the entire $50,000 fee had to be deferred, the entire $50,000 would be recognized ratably over the 12 month term of the contract.

Deferred Effective Date on Vendor-Specific Objective Evidence Criteria

AcSEC has decided to defer the application of SOP 97-2 for what constitutes vendor-specific objective evidence for one year, pending reconsideration by AcSEC. The deferral is made in SOP 98-4, which is effective as of March 31, 1998. The delay applies only to multiple-element arrangements in which a software product element is sold only in combination with PCS or other service elements that qualify for separate accounting. All other provisions of SOP 97-2, including the requirement to make a fair value allocation for multiple elements, remain in effect.

In applying SOP 97-2, the requirement for a fair value allocation still has to be followed. But if there is vendor-specific objective evidence for some elements, the fair value of a remaining element can be inferred. In other words, differential measurement can be used, and the value of one element can be derived as a residual from the fair value of the other elements and the total contract price. For example, in the earlier situation described where the fair value of the software product is known to be $40,000, but there are no separate sales of PCS and enhancements, the entire $50,000 fee would not have to be deferred. The fair value of the PCS and enhancement service elements would be $10,000--the residual of the contract price of $50,000 and the vendor-specific objective evidence of $40,000.

If the facts of that example were changed and the software product element was not sold separately, but always with the PCS and enhancement service elements, and there was vendor-specific objective evidence of the service elements, again the entire fee would not have to be deferred. For example, if the vendor offered renewal of the PCS and enhancement service elements for $15,000, but did not sell the software product separately, the allocation of the $50,000 fee would be $35,000 to the software product to be recognized on delivery if collectibility was probable and $15,000 to be recognized ratably over the contract term.

AcSEC initially made this decision to delay the effective date because it had not deliberated about situations in which software would always be sold with PCS or other service elements. AcSEC was informed that the deferral of all revenue from this type of arrangement may result in a significant change in practice that was not contemplated. Ultimately, AcSEC concluded that literal application of the criterion for vendor-specific objective evidence would be unduly conservative. AcSEC has begun reconsideration of this issue.

Other Matters

SOP 97-2 provides very detailed guidance for software arrangements; and not all of them can be fully explained here. SOP 97-2 specifies that if a software arrangement requires significant production, modification, or customization of the software, the entire arrangement would be accounted for using contract accounting. This provision is essentially the same as SOP 91-1, but SOP 97-2 provides more extensive guidance on how to measure progress to completion for software products and services.

SOP 97-2 also provides guidance on funded software development arrangements. If the arrangement falls within the coverage of SFAS No. 68 on research and development arrangements, that guidance should be followed. If SFAS No. 68 does not apply because the technological feasibility of the software has been established, any income received from the funding party should first be credited to the amount of development costs capitalized, and no amount should be credited to income until after the project has been completed and capitalization has ceased. *