Printer Friendly

Revenue Recognition on Sales 0f Software: 97-2 + 98-9 The Solution.

In October 1997, the AICPA issued Statement of Position (SOP) 97-2, entitled Software Revenue Recognition. Issued by the Accounting Standards Executive Committee (AcSEC), SOP 97-2 provides guidance on applying revenue recognition principles to software transactions. SOP 97-2 superseded SOP 91-1, also entitled Software Revenue Recognition that had served as the previous guidance on the topic. Since the issuance of SOP 91-1, practice issues had been identified that AcSEC believed had not been addressed adequately in the technical literature. Further, AcSEC concluded that some of the guidance in SOP 91-1 needed to be reconsidered. The result of this reconsideration process was the issuance of SOP 97-2. However, subsequent to the issuance of SOP 97-2, additional questions were raised about AcSEC's conclusions with respect to certain "multiple element" arrangements. Because of this, AcSEC found it necessary to amend SOP 97-2 by the issuance of SOP 98-9, entitled Modification of SOP 97-2, "Software Revenue Recognition," With Respect to Certain Transactions in December 1998.

Because of the applicability of the standard, many entities which do not necessarily think of themselves as "software companies," may find that they are required to comply with these provisions nonetheless. Additionally, the broader issue of revenue recognition has received a significant amount of attention in recent months. (e.g., speeches by SEC commissioners and staff members, AICPA Practice Alert 98-3, Revenue Recognition, AICPA publication, Audit Issues in Revenue Recognition) As a consequence, it is important that practitioners in a wide range of businesses be alert to the provisions of these SOPs. In this paper, the provisions of SOP 97-2, as amended by SOP 98-9, will be presented.


SOP 97-2 provides guidance on when revenues should be recognized and in what amounts for licensing, selling, leasing, or otherwise marketing computer software. The provisions in SOP 97-2 should be applied to those activities by all entities that earn revenue from these activities. Importantly, however, SOP 97-2 is not applicable to revenue earned on products or services containing software that is incidental to the products or services as a whole. As can be seen, making the determination of whether or not the software is incidental to the products or services as a whole, is key to identifying the applicability of these standards. In today's economic environment, virtually every product--from automobiles to televisions to communications devices and systems--contains software.

While it is often difficult to make a categorical determination, the entity may find it helpful to place itself in the customer's shoes. In essence, one way to address the issue of whether the software is incidental is to ask: Does the customer think that the software is a major component of what is being purchased? For example, in the case of a PC, it can be argued that the software is a significant component of what the customer is buying. Stated differently, the customer does not think he/she is just buying a PC. Rather, it is highly likely that the customer thinks he/she is buying both a PC and the pre-installed software. Conversely, while an automobile has software, the customer is unlikely to think he/she is buying both a car and software. Rather, that customer thinks he/she is buying an automobile.

Given the applicability of these SOPs, many entities will find that they are selling both hardware and software. (Or some other product and the related software) In that case, the entity will need to separate the amount attributable to the non-software product from that attributable to the software product(s). Furthermore, if a software lease includes property, plant and/or equipment (PPE), the revenue attributable to the PPE should be accounted for in accordance with the FASB's Statement of Financial Accounting Standards (SFAS) No. 13, entitled Accounting for Leases. Thus, any revenue attributable to the software, including post-contract customer support (PCS), should be accounted for separately based on the provisions of SOP 97-2. However, if the PPE contains software that is incidental to the PPE as a whole, (such as the automobile example) the software should not be accounted for separately.

Many of the requirements in SOP 97-2 are similar to requirements in certain other authoritative literature. (Such as SFAS No. 48, entitled Revenue Recognition When Right of Return Exists) It is important to note that SOP 97-2 does not amend the requirements of any of these other pronouncements.

Software arrangements range from those that provide a license for a single product to those that, in addition to the delivery of software or a software system, require significant production, modification or customization of software. If an arrangement to deliver software or a software system, either alone or together with other products or services, requires significant production, modification or customization of software, the entire arrangement should be accounted for in conformity with Accounting Research Bulletin (ARB) No. 45, entitled Long-Term Construction-Type Contracts, using the relevant guidelines in SOP 97-2, and in SOP 81-1, entitled Accounting for Performance of Construction-Type and Certain Production-Type Contracts. Again, this determination can be a difficult one. What constitutes "significant customization or modification?" Entities will often find it necessary to evaluate the skills of the members of the project team. If the project team is composed largely of programmers and systems analy sts; as opposed to installers, testers, etc., it is more likely that contract accounting (usually percentage-of-completion) would be appropriate.


If the arrangement does not require significant production, modification or customization of software, revenues should be recognized when all of the following four criteria are met:

* Persuasive evidence of an arrangement exists.

* Delivery has occurred.

* The vendor's fee is fixed or determinable.

* Collectibility is probable.

Persuasive Evidence of an Arrangement

Practice varies with respect to the use of written contracts. Although a number of sectors of the industry rely upon signed contracts to document arrangements, other sectors of the industry that license software do not. In those circumstances where a vendor does not rely on a signed contract to document the elements/obligations of an arrangement, the vendor should have some form of written evidence to document the transaction. For example, a purchase order from a third party or an on-line authorization could serve as documentary evidence.

While it is possible to have alternative forms of documentation, the presumption in SOP 97-2 is that there is a signed contract that serves as the documentation which demonstrates that there is pervasive evidence of an arrangement. Additionally, if it is the entity's typical practice to obtain a signed contract, then Sop 97-2 states that a contract signed by both parties is the only acceptable form of documentation. Stated differently, until there is a binding agreement between the parties, (as evidenced by an executed contract) the entity cannot possibly have revenue. The result of this requirement is that entities which typically use signed contracts to document the agreement with the customers, will be precluded from recognizing any revenue until the contract has been signed by both parties--even though the product may have been delivered and, potentially, cash collected.

Delivery Has Occurred

The fundamental provisions for revenue recognition are found in the FASB's Conceptual Framework documents. In particular, Statement of Financial Accounting Concepts (SEAC) No.5, Recognition and Measurement in Financial Statements of Business Enterprises, specifies the following criteria for the recognition of revenue: (a) the revenue is realized or realizable and (b) the revenue is earned. Clearly, if the product has not yet been delivered, then the revenue has not been earned. In discussing the notion of delivery, SOP 97-2 notes that this criterion applies whether the customer is a user or a reseller, In the case where delivery has occurred electronically; e.g., via the Internet or E-mail, then delivery is deemed to have occurred when the customer is provided the information needed to access the product. If access codes are needed to download the software, delivery occurs when the customer is provided the access code information.

Another important aspect of delivery relates to the issuance of customer acceptance of the software. If there is uncertainty after delivery due to the need to obtain customer acceptance of the software, delivery has not yet occurred and revenue recognition should be delayed until customer acceptance. Some companies have discovered that the terms of their sales leave the issue of customer acceptance open-ended. There are no terms in the sales agreement which put a limit on how long the customer has to accept the product such as, "if the customer has not notified the vendor within 30 days, customer shall have accepted the product as delivered" or similar terminology. As a result, the company's revenue recognition process may be held hostage to receiving acceptance from the customer. Because of this criterion, and the need to meet all four criteria before revenue is recognized, it is extremely important that entities evaluate the acceptance terms of their sales agreements.

Fee is Fixed or Determinable

As was discussed previously, SFAC No. 5 requires that revenue be realized or realizable prior to its recognition. Stated differently, if the entity is not sure how much the revenue is, recognition would be premature. Many software agreements are structured with the total sales tied to the number of copies or licenses. SOP 97-2 states that a software licensing fee is not fixed or determinable if the amount is based on the number of units distributed/copied, or the expected number of users of the product. Further, if the software includes return rights or rights to refunds without return of the software, the provision of SFAS No.48 must be met before revenue can be recognized.

Another problem for software vendors is the issue of extended payment terms. Because of the rapid technological advances that can and do occur in this industry, extended payment terms can create significant questions regarding the determinability of the fee. According to SOP 97-2, any extended payment terms may indicate that the fee is not fixed or determinable. In deciding whether the payment terms constitute extended payment terms, the entity's normal selling terms must be examined. As used in this context, extended payment terms mean any terms beyond those normally granted to this class/type of customer. Thus, there can be payment terms which are less than a year and which could still be extended payment terms since the terms depart from the company's norm.

Further, if a significant portion of the fee is due after expiration of the license or more than twelve months after delivery, the licensing fee is presumed not to be fixed or determinable. Additionally, SOP 97-2 precludes the use of the "rolling twelve month period" in evaluating whether the payments are fixed and determinable. Thus, in these situations, the vendor must have strong, persuasive evidence to overcome the presumption that the fee is not fixed and determinable. Stated differently, when payment terms cover a significant period of time, the entity must have a strong record of collecting according to the original terms of the agreement. Thus, if the entity has granted concessions to its customers in the past, such as price reductions subsequently negotiated or including additional products in the "basket," then the presumption will not be overcome and the entity will be forced to defer the revenue until the fee is due.

Collectibility is Probable

As is true for any receivable, an assessment of the collectibility must be made. It might seem that the issue of collectibility is closely related to the notion of extended payment terms, as discussed relative to the previous criterion. However, SOP 97-2 requires a separate assessment of collectibiity in addition to the assessment of the payment terms. If there are questions about collectibility, recognition of revenue should be deferred until the payment is deemed to be collectible even if the other criteria are met.


Frequently, software arrangements include multiple software deliverables; e.g., software products, upgrades/enhancements, PCS, or services. These arrangements are referred to as multiple element arrangements in SOP 972. In determining the accounting for multiple element arrangements, it is extremely important to differentiate between delivered and undelivered elements. A key part of that determination may be in the determination as to whether upgrades are deemed to be specified or unspecified upgrades. Specified upgrades are a separate and, initially, undelivered element in the arrangement. Conversely, an unspecified upgrade is not a separate element; rather, it is included in the PCS--which also is undelivered initially.

Oftentimes, a number of the elements--especially upgrades--may be described in the arrangement as being deliverable only on a when-and-if-available basis. When-and-if-available deliverables are included in PCS, thus it constitutes an unspecified upgrade. It should, nonetheless, be considered as a separate element in determining whether an arrangement includes multiple elements. As such, the requirements in SOP 97-2, with respect to arrangements that consist of multiple elements, should be applied to all additional products and services specified in the arrangement, including those described as being deliverable only on a when-and-if-available basis.

According to SOP 97-2, if an arrangement includes multiple elements, the fee should be allocated to the various elements based on vendor-specific objective evidence of fair value, regardless of any separate prices stated within the contract for each element. SOP 97-2 states that vendor-specific objective evidence (VSOE) of fair value is limited to the following:

* The price charged when the same element is sold separately.

* For an element not yet being sold separately, the price established by management. It must be probable that the price, once established, will not change before the separate introduction of the element into the marketplace.

SOP 97-2 specified that in those circumstances where VSOE does not exist for the allocation of revenue to the various elements of the arrangement, all revenue from the arrangement would be deferred until the earlier of: (a) the availability of VSOE for all elements to the arrangement, or (b) all elements of the arrangement have been delivered. SOP 97-2 did provide the following exceptions to this guidance:

* If the only undelivered element is PCS, the entire fee should be recognized ratably--in that situation, delivery of the undelivered element(s) is deemed to occur ratably during the service period.

* If the only undelivered element is services that do not involve significant production, modification or customization of software, (e.g., training or installation) the entire fee should be recognized over the period during which the services are expected to be performed--again, this is essentially another component of PCS which is recognized as the service is provided.

* If the arrangement is in substance a subscription, the entire fee should be recognized ratably.

* If the fee is based on the number of copies, (in arrangements where no allocation can be made) revenue should be recognized as copies of delivered products either (a) are reproduced by the customer, or (b) are furnished to the customer if the vendor is duplicating the software. Revenue from these types of arrangements should not be recognized fully until at least one of the following conditions is met:

* Delivery is complete for all products covered by the arrangement.

* The aggregate revenue attributable to all copies of the software products delivered is equal to the fixed fee, provided that the vendor is not obligated to deliver additional software products under the arrangement.

In the aftermath of SOP 97-2, many software entities expressed concern about these provisions because often, some of the elements in a multiple-element arrangement are never sold separately by the company; e.g., training is only sold in conjunction with the sale of software. As a consequence, the application of SOP 97-2 in these situations would require companies to defer the entire amount of the revenue and recognize it when all the elements have been delivered. If the undelivered element was training and there is no VSOE for training, the entire revenue would be deferred and recognized as the training was provided.

In light of this concern, AcSEC issued SOP 98-4 entitled, Deferral of the Effective Date of a Provision of SOP 97-2, "Software Revenue Recognition," to allow it to reconsider the issue more carefully. SOP 98-4 deferred for one year, the application of the provisions of SOP 97-2, which limited VSOE of the fair value to the two conditions described earlier. With the issuance of SOP 98-9--as discussed below--the deferral of the effective date of those provisions have been extended to years beginning after March 15, 1999. All other provisions of SOP 97-2 remain in effect.

AcSEC's reconsideration of the question of VSOE was subsequently addressed in SOP 98-9 that was issued in December 1998. In a conclusion that was surprising to some, AcSEC reaffirmed its previous conclusions about what constitutes VSOE. However, it did make one significant change from its previous conclusions.

In SOP 98-9, AcSEC allows the use of the "residual method" in certain circumstances when VSOE does not exist for all of the elements of a multiple element arrangement. According to SOP 98-9, the use of residual method is limited to circumstances where VSOE exists for all undelivered elements. Thus, under sop 98-9, the example cited earlier where VSOE did not exist for training, (an undelivered element) the company still would have the accounting problem previously discussed since the provisions of SOP 97-2 would be retained.

If VSOE does exist for all of the undelivered elements, (thus, VSOE is not available for some or all of the delivered elements) the residual method is used. Oftentimes, multiple element arrangements contain an embedded discount. When a discount exists, the residual method attributes the discount entirely to the delivered elements. This has the effect of deferring more of the total revenue since the entire fair value (rather than a proportionate amount of the embedded discount in the arrangement) is assigned to the undelivered elements that will be recognized in later periods as these elements are delivered. According to SOP 98-9, if VSOE exists for undelivered elements, but not for all delivered elements, the fee can be recognized using the residual method if:

* All other revenue recognition criteria of SOP 97-2 are met

* Fair value of all undelivered elements is deferred

Thus, the residual method results in a deferral of the total fair value of undelivered elements with the difference between the total arrangement fee and deferred amount for undelivered elements being recognized as the revenue attributed to the delivered elements. The following examples illustrate the application of SOPs 97-2 and 98-9 to multiple element arrangements depending upon whether VSOE exists for all elements to the arrangement.

Example 1--VSOE Available for Undelivered Elements--Assume that a vendor sells a software product for $950. The license arrangement always includes one year of "free" PCS. The annual renewal price of PCS is $150. Thus, there is VSOE for the PCS--the undelivered element. Since the software is never sold separately, (it always includes one year of PCS) there is no VSOE for the delivered element.

If all revenue recognition criteria are met on the delivered elements, the use of the residual method would result in a deferral of $150--the VSOE for the undelivered element. This amount would be recognized ratably over the one-year service period. The remaining $800 is assigned to the delivered element and is recognized upon delivery. That is, when the four revenue recognition criteria of SOP 97-2 are met.

Example 2--VSOE Not Available for Undelivered Elements--Assume the same information from the previous example EXCEPT that the company does not have VSOE for the PCS. That is, it does not separately sell service. In this case, there is no VSOE for undelivered elements. As a result, in this case, the entire fee would be deferred and recognized ratably over one-year service period--even if the software is sold both with and without the PCS. Note, that even if VSOE exists for the delivered elements, if VSOE does not exist for all undelivered elements, the residual method cannot be use.

Example 3--VSOE Available on All Elements--Assume that the entity sells 1,000 units to a customer. Included in the sale agreement is a "free" upgrade to version 8.2 of the software (this represents a specified upgrade) and 1 year of PCS. The total fee is $50,000. The sales price of the existing software (which is also sold separately) is $35 per copy. The company's pricing committee has established a sales price for the upgrade of $20. Additionally, the company sells renewals for the PCS for $5 per unit per year. The company estimates that the upgrade rate will be 75%.

Because VSOE exists for all elements, the sales proceeds would be allocated to each of the elements. However, in doing so, the entity must first allocate VSOE to the specified upgrade based on the anticipated (estimated) number of upgrades that will be requested by the customer. The remaining elements of the sales proceeds will then be allocated to the other elements in proportion to VSOE.

Allocation of sales proceeds:

Total Pee $50,000

To Upgrade right (1,000 x 75% X $20) 15,000

Remaining amount to allocate $35,000

Relative Amounts (total remaining VSOE is $40--$35 for the software, $5 for PCS):

To Software ($35/$40) $30,625

To PCS ($5/$40) 4,375

Thus, the $50,000 would be recognized as follows: (assuming the four revenue recognition criteria of SOP 97-2 are met)

Sale of Existing Software-- recognized upon delivery $30,625

PCS--recognized ratably over 1-year PCS period 4,375

Specified Upgrade--deferred and recognized when upgrade is delivered to customer 15,000

AcSEC had originally proposed that the provisions of SOP 98-9 be in effect for calendar 1999. However, because SOP 98-9 was issued so near the end of 1998, AcSEC determined that such an effective date would put an undue hardship on companies in their efforts to comply with these provisions. As such, SOP 98-9 is effective for transactions entered into in fiscal years beginning after March 15, 1999. Thus, as noted earlier, the deferral provisions of SOP 98-4 are continued to the same point in time. Since SOP 98-9 applies to transactions occurring after the effective date, (rather than for periods beginning after that date) the provisions of SOP 98-9 cannot be retroactively adopted. It can, however, be adopted early for periods for which financial statements have not been issued, Exhibit 1 summarizes the application of the revenue recognition criteria of SOPs 97-2 and 98-9.


Another complication with some software arrangements is the possibility that they may involve funded development arrangements. Software-development arrangements that are fully or partially funded by a party other than the vendor that is developing the software, typically provide the funding party with some or all of the following benefits:

* Royalties payable to the funding party based solely on future sales of the product by the software vendor. (i.e., reverse royalties)

* Discounts on future purchases by the funding party of products produced under the arrangement

* A non-exclusive sublicense to the funding party (at no additional charge) for the use of any product developed. (A prepaid or paid-up nonexclusive sublicense)

A funded software-development arrangement within the scope of SPAS No. 68, entitled Research and Development Arrangements, should be accounted for using the provisions of SFAS No. 68. If the technological feasibility of the computer software product (as specified in SFAS No. 86, entitled Accounting for the Costs of Computer Software to be Sold, Leased, or Otherwise Marketed) has been established before the arrangement has been entered into, SFAS No.68 does not apply because the arrangement is not a research and development arrangement.

Accounting for costs related to funded software-development arrangements is beyond the scope of SOP 97-2. However, if capitalization of the software-development costs commences based on the provisions of SFAS No. 86, any income from the funding party under a funded software-development arrangement should be credited first to the amount of the development costs capitalized--that is, this amount is treated as a reimbursement of the capitalized cost. If the income from the funding party exceeds the amount of development costs capitalized, the excess should be deferred and credited against future amounts that subsequently qualify for capitalization. Any deferred amount remaining after the project is completed (i.e., when the software is available for general release to customers and capitalization has ceased) should be credited to income.

If an arrangement to deliver software or a software system (either alone or together with other products or services) requires significant production, modification, or customization of software, the service element does not meet the criteria established for separate accounting since the arrangement would be subject to contract accounting. As such, the entire arrangement should be accounted for in accordance with the provisions ARB No. 45, using the relevant guidance in SOP 81-1. Conversely, however, transactions that normally are accounted for as product sales should not be accounted for as long-term contracts merely to avoid the delivery requirements normally associated with product sales for revenue recognition.

In applying contract accounting, the vendor must use either the percentage-of-completion method or the completed-contract method. The determination of the appropriate method should be made according to the conclusions contained in SOP 81-1.

Software contracts may have discrete elements that meet the criteria for segmenting. If a contract is segmented, each segment should be treated as a profit center. Progress-to-completion for each segment should be measured using the conclusions reached in SOP 81-1.

Some vendors of arrangements that include software combined with services or hardware (or both) do not identify the elements separately and do not sell them separately because of agreements with their suppliers. Other vendors that are not restricted by such agreements; nevertheless, bid or negotiate software or other products and services together. Arrangements that do not meet the segmentation criteria contained in SOP 81-1 are prohibited from being segmented, unless the vendor has a history of providing the software and other products and services to customers under separate arrangements and the arrangement meets the criteria in SOP 81-1.

SOP 81-1 describes the approaches to measuring progress on contracts, or contract segments, under the percentage-of-completion method. Those approaches are grouped into input and output measures as follows:

* Input measures are made in terms of efforts devoted to a contract. They include the methods based on costs and on efforts expended.

* Output measures are made in terms of results achieved. They include methods based on units produced, units delivered, contract milestones, and value added. For contracts under which separate units of output are produced, progress can be measured on the basis of units of work completed.

For software contracts, an example of an input measure is labor hours; an example of an output measure is arrangement milestones; e.g., the completion of specific program modules.

Measuring Progress Towards Completion--Input vs. Output Measures

If a software contract includes a discrete element that meets the segmentation criteria of SOP 81-1, the method chosen to measure progress-to-completion on the element should be the method that best approximates progress-to-completion. Progress-to-completion on separate elements of the same software arrangement may be measured by different methods. However, the software vendor should choose measurement methods consistently so that it uses similar methods to measure progress-to-completion on similar elements.

Output measures; e.g., value-added or arrangement milestones, may be used to measure progress-to-completion on software arrangements, but many companies use input measures because they often are established more easily and result in more consistent revenue recognition. As noted in SOP 81-1, the use of either type of measure requires the exercise of judgement and the careful tailoring of the measure to the circumstances. Further, SOP 81-1 states that:

* The acceptability of the results of input or output measures deemed to be appropriate to the circumstances should be periodically reviewed and confirmed by alternative measures that involve observation and inspection. For example, the results provided by the measure used to determine the extent of progress may be compared to the results of calculations based on physical observations by engineers, architects, or similarly qualified personnel.

* That type of review provides assurance somewhat similar to that provided for perpetual inventory records by periodic physical inventory counts.

Input measures of progress-to-completion on arrangements are made in terms of efforts devoted to the arrangement and, for software arrangements, include methods based on costs (e.g., cost-to-cost measures) and on efforts expended; e.g., labor hours or labor dollars. Progress-to-completion is measured indirectly, based on an established or assumed relationship between units of input and productivity. A major advantage of input measures is that inputs expended are easily verifiable. A major disadvantage is that their relationship to progress-to-completion may not hold if inefficiencies exist or if the incurrence of the input at a particular point does not indicate progress-to-completion.

Costs incurred should be included in measuring progress-to-completion only to the extent that they relate to contract performance. Items not specifically produced for the arrangement; e.g., hardware purchased from third parties or off-the-shelf software, should not be included in the measurement of progress-to-completion.

Labor hours often are chosen as the basis for measuring progress-to-completion, because they closely approximate the output of labor-intensive processes and often are established more easily than output measures. Core software requires labor-intensive customization. Therefore, labor hours provide a good measure of progress-to-completion on elements of software arrangements that involve the customization of core software.

If the measurement of progress-to-completion is based primarily on costs, the contribution to that progress of hardware and software that were produced specifically for the arrangement, may be measurable and recognizable before delivery to the user's site. For example, efforts to install, configure, and customize the software may occur at the vendor's site. The costs of such activities are measurable and recognizable at the time the activities are performed.

Progress on arrangements that call for the production of identifiable units of out-put can be measured in terms of the value added or milestones reached. Although progress-to-completion based on output measures is measured directly from results achieved, thus providing a better approximation of progress than is provided by input measures, output measures may be somewhat unreliable because of the difficulties associated with establishing them.

In order for the value added to be verifiable, the vendor must identify elements or subcomponents of those elements. If output measures are neither known nor reasonably estimable, they should not be used to measure progress-to-completion.

If value added by off-the-shelf software is to be included in the measurement of progress-to-completion, only minor modifications can be made to the software and it must be usable by the customer for the customer's purpose in the customer's environment. If more than minor modifications or additions to the off-the-shelf software are necessary to meet the functionality required under the arrangement terms, either by changing or making additions to the software, or because the software would not be usable by the customer in its off-the-shelf form for the customer's purpose in the customer's environment, it should be accounted for as core software.

Value added by the customization of core software should be included in the measurement of progress-to-completion of the customization and installation at the user's site. However, if the installation and customization processes are divided into separate output modules, the value of core software associated with the customization of a module should be included in the measurement of progress-to-completion when that module is completed.

Contract Milestones

Contract milestones may be based on contractual project plans. Contractual provisions generally require the performance of specific tasks with the approval or acceptance by the customer; project plans generally schedule inspections in which the project's status is reviewed and approved by management. The completion of tasks that trigger these inspections are usually natural milestones since they are subject to relatively independent review by the customer as an intrinsic part of the project management process.

Considerations other than progress-to-completion, affect the amounts that become billable at particular times under many arrangements. Accordingly, although the achievement of contract milestones may cause arrangement revenues to become billable under the arrangement, the amounts billable should be used to measure progress-to-completion only if such amounts do indeed indicate progress to completion.

The milestones that are selected to measure progress-to-completion should be part of the management review process. The percentage-of-completion designated for each milestone should be determined considering the experience of the vendor on similar projects.


Because the provisions of SOP 97-2, as modified by SOP 989, affect all companies which sell software, not just "software" companies, and because these SOPs deal with a significant financial reporting issues--revenue recognition--it is critical that practitioners understand the requirements of these standards. In many cases, application of these standards may result in the delay of revenue recognition for many companies--particularly if there is significant customization or modification (contract accounting), questions about VSOE, (multiple elements) or questions about delivery or payment terms. (Revenue recognition criteria of SOP 97-2) Thus, it is vital that practitioners have a solid working knowledge of these provisions to avoid "earnings surprises" as specific transactions are evaluated.

Paul Munter, Ph.D. CPA, is currently a KPMG Accounting Professor and Chairman of the Dept. of Accounting at the University of Miami in Coral Gables, FL. Professor Munter earned his Ph.D. in accounting at the University of Colorado. He received his B.S. and M.S. degrees from Fresno State University.

Thomas A. Ratcliffe, Ph.D., CPA, is currently Dean of the Sorrell College of Business Administration at Troy State University in Troy, AL. He earned his BBA and Ph.D. in accounting from the University of Alabama.
COPYRIGHT 2000 National Society of Public Accountants
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2000 Gale, Cengage Learning. All rights reserved.

 Reader Opinion




Article Details
Printer friendly Cite/link Email Feedback
Publication:The National Public Accountant
Geographic Code:1USA
Date:Jun 1, 2000
Previous Article:Cash VS. Accrual: The Battle Lines Have Been Drawn.
Next Article:How to Buy a Computer.

Related Articles
Recognize the software, recognize the pitfalls.
SOP 97-2 may be modified.
Informix Q1 Looks Solid in All Areas.
L&H Pips Q3 Earnings Expectations by a Penny.
Managing high-tech revenue streams. (Revenue Recognition).
Heads, it's revenue: why companies struggle to comply with revenue recognition guidance.
Software revenue recognition on the rise: technology boom expands relevance of SOP 97-2.

Terms of use | Copyright © 2014 Farlex, Inc. | Feedback | For webmasters