The focus of Part 2 of this Article is on the practical steps that a lawyer should consider taking in preparing software agreements and the related policies and procedures to be considered by a software company in view of the new software revenue recognition guidelines, SOP 97-2 (the "New SOP"). Part 1 of this Article provided the lawyer a process for analyzing the accounting and legal implications of the New SOP. This part of the Article includes examples of many of the concepts discussed in Part 1.
This Article is divided into the following sections:
- General Drafting Issues Under the New SOP;
- Drafting Practice Pointers;
- Practice Pointers for Implementing Revenue Recognition Policies.
II. General Drafting Issues Under the New SOP
A. Multiple Element Approach
As discussed in Part 1 of this Article, one of the fundamental differences between the New SOP and the prior software revenue recognition accounting guidelines ("SOP 91-1") is the elimination of SOP 91-1’s "significant remaining vendor obligations" test and the New SOP’s implementation of the multiple element approach. This multiple element approach involves the following primary steps:
- Define Elements - Defining each element of the software arrangement (i.e., the licensed software, software modifications, post contract support (PCS or maintenance), installation, and training offered in an arrangement);
- Determine Allocation - Determining the revenue that should be allocated to each element of an arrangement; and
- Recognize Revenue - Recognizing revenue when each element of an arrangement satisfies the following basic revenue recognition criteria:
- persuasive evidence of an arrangement exists,
- delivery has occurred,
- the software vendor’s fee is fixed or determinable, and
- collectibility is probable. 1
Each of these basic revenue recognition criterion are extensively discussed in Part 1 of this Article.
B. Danger Zones in the New SOP
The following summarizes some of the "danger zones" in the New SOP that may cause a software company to defer revenue recognition in their software agreements: Licensing Software and Performing Modifications to the Licensed Software under Separate Agreements Won’t, by Itself, Solve Revenue Recognition Deferral Problems. Revenue recognition issues are looked at on an arrangement basis rather than a single contract basis. For example, a software company may enter into an arrangement with a user where a software application is licensed to the user under a license agreement, modifications to the licensed software are performed under a separate services agreement, and PCS is provided under a separate software maintenance agreement. If all of these agreements are entered into at approximately the same time, then all of the agreements will be looked at together in order to determine the revenue recognition implications. Therefore, when the lawyer is working with a client on a revenue recognition issue in a specific contract the lawyer should inquire as to whether there will be modifications, other services, or licensed software provided to the user, in addition to the licensed software and services described in the agreement under review.
Beware of the Bundled Offering. Often software companies will license a software application and modify the software to fit the user’s specific needs. Many times software companies will bundle the licensed software and the software modifications together and offer the user a "turn-key" solution for one price. Under the New SOP this practice may result in a deferral of revenue recognition for the license fee.2 As further discussed below, the bundling of software and services may prevent a software company from being able to establish vendor-specific objective evidence of fair value for each element of a software arrangement.
Beware of the One Time Deal. The lawyer should carefully review an agreement for any licensed software or services that his or her client has not previously offered to customers. As discussed in Part 1 of this Article, the New SOP implements a new concept called "vendor-specific object evidence of fair value" that may cause the deferral of revenue recognition for many software companies. This concept prevents companies from arbitrarily shifting revenue to earlier delivered elements (see the section below entitled "Beware of Revenue Shifting").
As discussed above, after an arrangement is divided into its separate elements revenue is allocated to each of the elements. The fees indicated in the agreement for each element will not necessarily be the amount allocated for revenue recognition purposes. The New SOP requires that the amount allocated to an element be based on the vendor-specific objective evidence of fair value for the element being offered and not necessarily based on the prices stated in the contract.3 Vendor-specific objective evidence of fair value is usually determined by the amount the software company typically charges others for the element. If vendor-specific objective evidence of fair value cannot be determined (for example because the software company has never offered the element to others or separately offered the element to establish its individual fair value), then the revenue for the entire arrangement must be deferred until such vendor-specific objective evidence can be established, or until all elements under the arrangement have been delivered, whichever occurs first.4
Small software companies that license software to large companies will be particularly affected by the concept of vendor-specific objective evidence of fair value. Often large companies have very unique requirements. Many times a small software company must agree to a large company’s unique requests in order to make a sale. A common large company requirement relates to the scope of the license being offered. Consider the following example:
Example - A small software company, Smallsoft, typically licenses its product, Sitesoft, for use on a server located at a single location for a $200,000 license fee. A large potential customer, Insureco, has a client/server network with servers at five present locations within the United States. Insureco expects the number of servers on which Sitesoft will be used to increase over the next twelve months. Smallco sees an opportunity to gain service revenue in connection with installation of Sitesoft at each Insureco location. Therefore, Smallsoft decides to grant Insureco a license that allows Insureco to copy and use Sitesoft at an unlimited number of servers at any location in the United States for a $200,000 license fee in an arrangement that includes other products and services. Smallsoft has never granted a U.S. enterprise license as described above.
In the above example, Smallsoft may have difficulty establishing vendor-specific objective evidence of fair value for a U.S. enterprise license of Sitesoft since Sitesoft has never been licensed on this basis. If Smallsoft is unable to establish Sitesoft’s fair value and the arrangement under which Sitesoft is licensed to Insureco includes multiple elements, then the $200,000 Sitesoft license fee must be deferred until all elements of the arrangement have been delivered, or Smallsoft can establish such vendor-specific objective evidence of fair value, whichever occurs first.
Beware of Revenue Shifting. "Revenue shifting" refers to a situation where a software company reduces fees for one element and increases fees for another element. The New SOP provides that if a discount is applied in a multiple element arrangement, then for accounting purposes a proportionate amount of the discount should be allocated among the fair value of all elements of the arrangement, excluding upgrade elements.5 Often, revenue shifting occurs when greater discounts (in comparison to the other elements of the arrangement) are applied to elements that will likely be recognizable at a later time than the other elements in the arrangement. Although the shifting may occur to induce a customer to agree to acquire add-on products or services, the lawyer should confirm that his or her client understands that for accounting purposes the discount will be applied proportionately based on fair value across all elements of the arrangement. Consider the following example:
Example - Smallsoft typically licenses PowerNT for $100,000 and offers to perform services to modify PowerNT at an hourly rate of $125 per hour. Smallsoft licenses PowerNT to Insureco for $110,000 and agrees to perform modifications that are estimated to take 400 hours at a rate of $100 per hour.
In this example Smallsoft has shifted to the license fee $10,000 of service revenue fees that would otherwise be charged by Smallsoft had it applied its standard hourly rate. Under the New SOP, only $100,000 of the $110,000 of the license fee would be recognized when the PowerNT software is delivered to Insureco (assuming all other basic revenue recognition criteria are satisfied). The remaining $10,000 of the license fee will be allocated to the services element and recognized ratably over the term that the services are performed.
Avoid Contract Accounting Where Possible. As discussed in Part 1 of this Article, contract accounting generally involves the recognition of revenue ratably over the term of a contract. In most instances a software company whose goal is to recognize revenue as soon as possible will try to avoid contract accounting. Contract accounting most notably becomes an issue in software arrangements when a software company licenses software that is substantially modified. As discussed in Part 1 of this Article, if the software services involve significant production, modification, or customization of the software6 or the software modifications are essential to the functionality of the licensed software7, then contract accounting will generally apply. The following are factors that are favorable to a finding that the modifications are not "significant" or "essential" as described above and therefore should be emphasized in the agreement where applicable to bolster the software company’s argument that contract accounting should not apply:
- The software modifications are similar to modifications that the software company has made for other users.
- Licensed software is initially delivered to the user without the modifications.
- Licensed software is used by the licensee without the modifications.
- Services will be performed in less than 90 days.
- The software company’s cost for the services is less than 20 percent of the license fee.
- The user’s acceptance of the licensed software is independent of the user’s acceptance of the modifications. For example if modifications are subject to the user’s acceptance, then the acceptance testing provision should provide that the acceptance test is applicable only to the modifications and not to the underlying licensed software.
- Payment of the license fee is independent of payment for the modifications.
- The modifications are not required to add functionality to the licensed software that the user deems necessary for its intended use of the software.
Substantial judgment is often required to determine whether contract accounting applies or whether the services and software elements can be separately accounted for. Therefore, it is important for a software company to initiate a dialog with its accountants and lawyers at an early stage when structuring a licensed software/services arrangement to assess whether contract accounting will apply to the arrangement.
Beware of Specified Upgrade Rights
The New SOP treats any specified upgrade right as a separate element to which revenue should be allocated.8 Therefore, if the goal of the client is the early recognition of revenue, the lawyer should ensure that the client is able to establish the fair value of the upgrade right. Consider the following example:
Solosoft has a software application called Revotech that is compatible with Version 3.0 of SAP’s R/3 software application.9 A Revotech user, Procuro, negotiates into its license agreement that Solosoft will provide, at no additional cost to Procuro, a version of Revotech that is compatible with Version 4.0 of SAP R/3 within six months after SAP makes the Version 4.0 release generally available to its customers.
The New SOP would characterize Procuro’s upgrade right as a "specified upgrade right" and require that a portion of the Revotech license fee be allocated to this upgrade right. This portion of allocated revenue will be equal to the fair value of the upgrade right. If Solosoft does not typically offer the specified upgrade right, then Solosoft may not be able to establish its fair value resulting in a deferral of revenue recognition for the entire Revotech license fee. If Solosoft is able to establish the fair value for the upgrade right, then this amount will generally be deferred until the upgrade right is either delivered to Procuro or Procuro’s election to receive the upgrade right expires.
III. Drafting Practice Pointers
This section of the Article provides practical guidance for the lawyer and software company in drafting and negotiating software agreements. This section is divided into the typical issues confronted by any software company in preparing a software agreement. The questions associated with each issue are designed to guide the lawyer through the various issues to be considered in recognizing revenue as rapidly as possible under the New SOP. While most companies strive to recognize revenue as quickly as possible, some software companies (especially the giants of the industry) may intentionally include provisions in their agreements in an effort to push revenue recognition to a later date to produce a smoother, more predictable revenue recognition pattern. In those instances where a company desires to defer revenue recognition it may consider structuring its agreements so as not to avoid the "danger zones" described above.
Does the agreement include terms as to when software will be delivered to the user? In a software license agreement the license fee allocated to software cannot be recognized until delivery has occurred.10 Therefore, the software license agreement should clearly state when delivery will occur. A statement of delivery terms is particularly important in agreements involving modifications to licensed software. In many instances software companies desire to recognize license revenue prior to completion of software modifications. In these instances the lawyer should make sure that a statement is included in the software agreement that the licensed software will be delivered within a certain number of days after the agreement’s effective date. Additionally, the license fee should be characterized as "non-refundable".
Will the licensed software be operated by a party other than the user? Users are more frequently outsourcing their software applications. If the user elects to have another party (such as the licensor) host the application on the outsourcer’s computer, then satisfaction of the delivery obligations may be difficult to determine. The New SOP does not address the issue of delivery in an outsourcing context. It could be argued that delivery is deemed to occur when the software application is made available for the user’s benefit. However, to satisfy the delivery requirements, the vendor may consider delivering a copy of the licensed software to the user, even if the software will be operated on the vendor’s computer as an outsourced application.
Is the software licensed on a site or enterprise basis? The New SOP provides that software licensed on a site or enterprise basis will be deemed to have been delivered when the first copy of the software is delivered to the user if the license fee does not vary with the number of copies made.11 Therefore, even if a site or enterprise license agreement provides for delivery of additional copies of the software there will generally still be no revenue recognition deferral based on delivery of these additional copies.
Is the software licensed on per copy basis? The New SOP also provides that if the software license fee is dependent upon the number of copies of software either delivered to the user or made by the user, then the software should be deemed to have been delivered as each copy of the software is either delivered to the user or made by the user.12 Consider the following example:
Example - A software company, Y2K, offers Year 2000 diagnostic software called Y2K Solution. Y2K delivers to each user a single copy of Y2K Solution within ten days after the license agreement is executed. Upon receipt of Y2K Solution, the user owes Y2K a $1,000 license fee that enables the user to load Y2K Solution on ten computers for purposes of Year 2000 testing. If the user plans to install Y2K Solution on more than ten computers, then the user must pay Y2K a $500 fee for every five additional computers on which Y2K Solution is installed.
In this example Y2K would be able to recognize the $1,000 license fee upon delivery of the software (assuming the other basic revenue recognition criteria are satisfied). Y2K may continue to recognize additional revenue as the user installs its 11th, 16th, 21st, 25th, etc. copy of Y2K Solution.
Is the user required to purchase a minimum number of licenses? Often reseller agreements and user license agreements require a minimum number of software copies to be licensed. If this minimum license requirement includes a volume discount, then the software company should generally recognize revenue based on the average price per copy based on the number of licenses the user is required to license.
Are the license terms consistent with other licenses that have been granted? If a software company grants a license under terms that have not previously been extended to customers, then the software company may have difficulty establishing the fair value of the license being granted. Those software companies that desire to recognize revenue as soon as possible should consider identifying those elements of their software arrangements that are common to all of its users. For example, if all users license a baseline core product from which the software company makes user-specific changes, then the software company should consider licensing the core functionality as a separate product. The software company should then assess how vendor-specific objective evidence of fair value can be established for the user-specific modifications that it provides. Typically, software companies will offer their services on either a fixed price or a time-and-materials basis. Generally, the vendor-specific objective evidence of fair value for services will be based on the software company’s standard time-and-materials rates for such services. Consider the following example:
Example - A software company offers to perform modifications for a $50,000 fixed fee. The company reasonably estimates that it will take approximately 400 billable hours to perform the modifications by a person who the software company typically bills at $125 per hour.
In this example the software company could likely establish that the fixed price of $50,000 is a reasonable estimate of the fair value of the services that will be performed for the fixed fee.
Is payment of a license fee contingent upon acceptance of software modifications? As discussed above, contract accounting may be applicable to a software arrangement involving licensed software and modifications if payment of the software license fee is contingent upon acceptance of the software modifications. Therefore, if the client desires to recognize the license fee as soon as possible, then the contract terms should provide that the licensed software is delivered and paid for as soon as possible after entering into the license agreement. Further, the license fee should be characterized as "non-refundable." The payment terms for the licensed software and the modifications should also be separately stated from the delivery and payment terms applicable to the software modifications.
Do license fee payment terms extend beyond 12 months after software delivery? The New SOP provides that payment terms that extend for more than 12 months after software delivery are presumed to not be fixed or determinable.13 This presumption can be overcome by the software company demonstrating a history of collecting fees under extended payment terms. Therefore, the payment terms in an agreement should not extend beyond 12 months unless the client can establish a history of collecting fees under longer payment terms without subsequent concessions.
Are the license fees received non-refundable and the license fees owed not subject to forfeiture? The New SOP provides that if "after delivery, uncertainty exists about customer acceptance of the software, license revenue should not be recognized until acceptance occurs."14 Therefore, if the goal of the client is to recognize revenue as soon as possible, then the agreement should provide that the license fee is non-refundable in those instances where modifications to licensed software is subject to the user’s acceptance. Further, if the agreement provides for delivery of software at different times, then the agreement should not tie payment for any delivered software to delivery of undelivered software. The following are examples of situations where a license fee may be refundable or subject to forfeiture:
Example 1 - Insureco commits to purchase and pays Solosoft a license fee for a software product, Accountsoft, prior to its acceptance. The license agreement provides for Insureco’s acceptance testing of Accountsoft for a period of sixty days after its delivery. Solosoft has a practice of refunding license fees if the software is not accepted.
In this example the license fee should not be recognized until Insureco accepts Accountsoft. Note that if the above example is changed so that Insureco’s acceptance testing is 30 days or less after delivery of Accountsoft and Solosoft is able to estimate the percentage of customers that return Accountsoft for non-acceptance (through historical evidence), then Solosoft may be able to recognize the revenue prior to acceptance of the software. The New SOP provides that a short-term right of return, such as a 30-day money-back guarantee, should not be considered a cancellation privilege; and the related returns should be accounted for in conformity with FASB Statement No. 4815 (see the section entitled "Decision Point #13" in Part 1 of this Article for a discussion of recognition of revenue under FASB Statement No. 48). Accordingly, if Solosoft desires the early recognition of revenue and Accountsoft licensees typically require an acceptance testing provision, then Solosoft should not agree to an acceptance testing provision that would extend beyond 30 days after delivery of Accountsoft. Solosoft should also maintain historical information as to the number of Accountsoft licensees that do not accept the software (FASB Statement No. 48 requires that the vendor reasonably estimate the number of returns).
Example 2 - Solosoft delivers Accountsoft to Insureco and payment of the Accountsoft license fee is subject to Solosoft’s later delivery of Procuresoft, a software application separate from Accountsoft.
The New SOP provides that a fee is not considered "collectible" (and therefore does not satisfy the basic revenue recognition criteria) if the fee allocable to delivered elements is subject to forfeiture, refund, or other concession if any of the undelivered elements are not delivered.16 If Solosoft desires the early recognition of revenue, then Solosoft should require payment of the Accountsoft license fee upon its delivery and provide that the license fee is non-refundable.
Does the agreement include a liquidated damage provision? Often, a user will insist on a liquidated damage provision if the software vendor fails to meet certain deadlines or obligations in the agreement. Similarly, the software vendor may desire to limit the amount of damages for nonperformance by including a liquidated damage clause. A liquidated damage provision will be construed as a refund right under the New SOP’s rules regarding collectibility.17 The following is a typical example of how the New SOP would apply to an agreement with a liquidated damage clause:
Example - Solosoft licenses a software product, Acton, for $1,000,000 to Insureco. Acton is not Year 2000 compliant at the time the license is granted. Based on Insureco’s concern over the Year 2000 problem, Insureco negotiates in the Acton license agreement a right to receive, at no additional cost to Insureco, an Acton upgrade that is Year 2000 compliant when and if Solosoft makes such upgrade available. The fair value for Acton and the Acton upgrade are $700,000 and $300,000 respectively. In order to ensure that Solosoft delivers the upgrade, Insureco negotiates into the license agreement that if the Acton upgrade is not delivered by July 31, 1998, then Solosoft will pay a liquidated damage of $250,000.
In the above example, Solosoft will defer recognition of $300,000 of revenue from the $1,000,000 license fee until the Acton upgrade is made available to Insureco. In the above example, the specified damages (i.e., $250,000) are less than the deferred revenue (i.e., $300,000) so no portion of the fee attributable to Acton is subject to refund or forfeiture. Therefore, the license fee revenue attributable to Acton (i.e., $700,000) would not be considered subject to a refund right. However, if the above example were changed so that the liquidated damage amount is $400,000 rather than $250,000, then a portion of the license fee attributable to Acton would be subject to partial refund (i.e., $100,000). Under a literal interpretation of the New SOP, the entire license fee should not be recognized until after delivery of the Acton upgrade because a portion of the user fee attributable to Acton is subject to refund.18 However, arguably under this example the portion of the Acton user fee that is not subject to the liquidated damage provision (i.e., $600,000) may be recognized upon delivery of the Acton software. However, the New SOP does not address the issue of treatment of partial refunds. In order to avoid this uncertain area the amount of any liquidated damages should not exceed the amount of any deferred revenue that is tied to delivery of an element to which the liquidated damage provision is also applicable.
Will licensed software be modified? As discussed in the section above entitled "Avoid Contract Accounting Where Possible," software arrangements that involve the licensing of software and the performance of software modifications will often result in the deferral of license revenue based upon the application of contract accounting. When structuring a transaction with a potential customer, a software company is well advised to review with its accountants and lawyers as early as possible the factors for determining whether software modifications are "essential" or "significant" enough to warrant the application of contract accounting. Sometimes changing several seemingly minor aspects of a software arrangement may be enough to a lead a software company’s accountants to the conclusion that contract accounting should not apply.
Is the user entitled to receive upgrades? Often a license agreement will provide the user the right to receive upgrades. Often the upgrades are provided as part of software maintenance. If the client desires to recognize revenue as soon as possible, then the lawyer will need to make sure that the license agreement provides for the following:
The right to receive upgrades does not designate any specific functionality in the upgrade or specify an upgrade. As discussed in Section II above entitled "Beware of Specified Upgrade Rights," the New SOP treats upgrades which are specified or that are defined with functionality as a separate element of the arrangement even if the upgrade right is included as part of software maintenance. The problem with specified upgrade rights is that they are often offered at no additional cost to a user and usually only offered as a negotiated item. When the specified upgrade right is offered at no additional cost, a portion of the arrangement fee will be deferred until the upgrade right is either exercised or the upgrade right expires. The amount of revenue that will be deferred will equal the fair value of the upgrade right multiplied by the percentage of customers expected to exercise the upgrade right. However, since specified upgrade rights are typically only placed in a license agreement at the user’s suggestion it is often difficult for the software company to establish the upgrade right’s fair value. Additionally, the software company will likely lack historical evidence to establish the percentage of customers that will exercise the upgrade right. Given all the pitfalls associated with upgrade rights, a software company may consider not offering a specified upgrade right unless it is offered as part of its standard product offering. Further, the software company may consider separately licensing the upgrade right for an additional license fee so as to avoid any carve out of revenue from license fees attributable to delivered software that would otherwise be recognizable. Finally, the upgrade right provision should be drafted so that it includes a date by which the user must decide whether to exercise the upgrade right. A time limit on the user’s upgrade right will prevent otherwise recognizable license fee revenue that is allocated to the specified upgrade right from being indefinitely deferred.
The unspecified upgrades are part of software maintenance. A statement that the upgrades are included as part of maintenance will prevent the upgrade right from being construed as a separate element of the software arrangement. If such a statement is not included, then vendor-specific objective evidence of fair value for the upgrade right must be determined separate and apart from the value of maintenance.
Additional Software Products
Is the user entitled to license additional software products? The same issues discussed above relating to specified upgrade rights are equally applicable to additional software products. Offering additional software products does not generally result in deferral of otherwise recognizable revenue if the additional software products are offered for its fair value and the software company offers the additional software products in its normal course of business (thereby enabling the software company to establish the additional software product’s fair value).
Are the licensed software and/or modifications subject to the user’s acceptance? Generally, license revenue associated with any licensed software or modifications that are subject to the user’s acceptance will be deferred until the occurrence of acceptance or expiration of the user’s right to accept or reject the software, whichever occurs first. However, as discussed above, if the customer has committed to purchase the software, a license fee for software that is subject to acceptance testing may be recognized upon delivery in the limited circumstance where (1) the acceptance period is 30 days or less after software delivery; and (2) the vendor is able to estimate the number of returns resulting from non-acceptance among all licensees of the software with an acceptance testing right.
Is acceptance of modifications separate from acceptance of the licensed software that is being modified? In those instances where licensed software is modified to meet a user’s needs often the user will require that the modifications are subject to acceptance testing. As discussed above, the New SOP provides that a license fee for delivered software must be deferred if the license fee is subject to refund if any of the undelivered elements are not delivered.19 Therefore, if a user’s acceptance testing of the modifications also includes acceptance testing of the licensed software, then the license fee for the licensed software may be considered subject to refund if the software is not accepted. Accordingly, if the goal of the client is to recognize revenue as soon as possible, then the lawyer should ensure that any acceptance testing for modifications is only for the modifications and not for the underlying licensed software as well.
Are the acceptance criteria well defined? If the vendor must defer revenue recognition until the user’s acceptance, then it is important that the acceptance criteria be well defined in the license agreement. Generally when the acceptance criteria is not well defined the user is able to assert their own subjective standard for acceptance resulting in prolonging the user’s acceptance of the software. In those instances where licensed software and modifications to the licensed software are provided to the user, the agreements should be structured as follows for the early recognition of revenue for the licensed software:
- The licensed software is delivered to the client soon after the effective date of the license agreement.
- The license fee for the licensed software is payable upon the user’s receipt of the licensed software and is not contingent upon delivery of the modifications.
- Preferably, the licensed software is not subject to acceptance testing.
- In the event the user requires an acceptance test for the licensed software the acceptance test is based on conformance with a vendor-defined acceptance criteria (i.e., conformity with vendor specifications) and not any user-defined criteria.
- The software modifications are delivered to the user within 90 days after the user’s receipt of the licensed software. (Modifications that take longer than 90 days may indicate that the modifications are "significant" to the licensed software thus causing the application of contract accounting to the arrangement.)
- The modifications are subject to an acceptance test that does not include acceptance testing of the licensed software.
Is the warranty routine so as not to be construed as a customer cancellation right? The New SOP provides that license fees in agreements that include a customer cancellation right are neither fixed nor determinable (and thus do not satisfy the basic revenue recognition criteria) until the customer cancellation right expires.20 Typically, a warranty will provide that the licensed software will substantially conform to a vendor defined criteria such as the vendor’s standard documentation provided with the licensed software. However, if the warranty is based upon a user defined criteria that is more extensive than a warranty normally granted by the vendor, then the user may be deemed to have a cancellation right resulting in deferral of revenue until the expiration of the warranty. Therefore, the lawyer should confirm with the client that the warranty granted to a user is based on the vendor’s standard documentation.
Is the term of the warranty re-triggered by future events? The lawyer should carefully review the warranty provision for events that trigger the application of the warranty provision. Preferably, the software warranty should commence upon installation of the software and expire within a defined period of time. Alternatively, an agreement may provide that the warranty term restarts for each new maintenance release provided under the software maintenance terms. These terms are common in user drafted agreements and result in the vendor agreeing to warrant the software for an undefined period of time causing difficulty in estimating the cost of the warranty services.
Negotiating Warranty Terms. Since typically, the maintenance is "free" during the warranty period, a software company may want to consider price concessions to other parts of the arrangement as an alternative to a more extensive warranty provision. For example, price discounts offered proportionately across all elements of a software arrangement may be a way of providing the user the lower total cost of ownership they desire without impacting the vendor’s recognition of revenue.
IV. Practice Pointers for Implementing Revenue Recognition Policies
This section provides practical pointers for businesses and their professional advisors to consider in view of the impact that the New SOP may have on their business. In many cases, these pointers will help to reduce the amount of time required to respond to future inquiries from third parties and accountants regarding a company’s understanding and implementation of revenue recognition practices consistent with the New SOP.
Determine Revenue Recognition Goals. The software company should determine whether its goal is to recognize revenue as soon as possible or defer the recognition of revenue. If the goal is to defer revenue recognition, then the company should determine the desired time for revenue to be recognized.
Adopt and Refine Revenue Recognition Policies. The software company should work with its contract administrator, legal counsel, and accountants/auditors to create a written set of revenue recognition guidelines consistent with the New SOP. The written standards should address --
- Differences between the company’s revenue recognition policies under SOP 91-1 (if any) and its policies under the New SOP.
- The approval process for revising the company’s form agreements after the form agreements have been revised in view of the New SOP.
- The process for setting a range of approved prices that the company’s licensed software and services may be offered.
- The approval process for offering licensed software and services at prices that are not within the company’s pre-approved price range.
Establish a Pricing Committee. A company should consider establishing a Pricing Committee to implement and monitor compliance with its revenue recognition guidelines. This committee could include the company’s CFO, lawyer, contract administrator, and sales representatives.
The following are a suggested list of activities for the pricing committee to perform:
- Identify all types of licensed software and services offered by the company.
- Establish the manner in which the software and services are described and priced in customer agreements and verify that such software and services are separately stated.
- Establish a fee range for each type of license that is authorized to be granted by the company.
- Establish a fee range for each category of service that may be performed by the company.
- Conduct review prior to contract signing of all unique transactions involving elements that have not been previously offered to others.
- Establish standard acceptance testing and warranty periods taking into consideration terms typically offered in the marketplace for similar software.
- Conduct review prior to contract signing of any agreement with acceptance testing and warranty periods that exceed the standard warranty terms established by the Pricing Committee.
- Conduct prior review of any potential refund for licensed software.
- If software agreements provide for exchange or return rights, then determine whether products should be classified as an exchange (exchange of similar products with minimal differences in price, functionality, and features) or a return (exchange for dissimilar products or products with more than minimal differences in price, functionality, and features).
- Periodically review historical information discussed below in the section entitled "Maintain Specific Historical Information on Certain Areas".
Revise Form Agreements. The adoption of the New SOP should lead to a review and revision of form agreements covering software licensing, software development, and software maintenance services. These revisions can be coordinated with the revamping of contracts to conform with the expected adoption of Article 2B of the UCC. The process of preparing new agreements in conformity with these legal and accounting requirements may be time consuming and should be started immediately considering the New SOP becomes effective for transactions entered into in fiscal years beginning after December 15, 1997.
Prepare Pre-Approved Optional Clauses. Certain clauses of a software license are almost always subject to negotiation and revision. These include the –
- scope of software licensing rights
- pricing and payment terms
- reproduction rights for software
- termination and post-termination rights
- remedy/damage provisions
- upgrade rights
Each of the above terms will affect a company’s ability to recognize revenue. Lawyers may consider working with their client to draft "pre-approved" optional clauses that meet the revenue recognition criteria of the New SOP and management’s policies for revenue recognition.
Adopt and Enforce a Contract Approval Process. It is important that a software company adopt an approval process for its software agreements given the multitude of "danger zones" resulting in the deferral of revenue recognition as described above. The company may consider establishing a contract approval process based on the dollar value of the agreement. Additionally, the software company may consider a requirement that any agreement that deviates from its "pre-approved" pricing for licensed software and services as established by the Pricing Committee must be submitted to the Pricing Committee for approval.
Implement Educational Programs for the Sales Force. After the company has completed the above steps, the software company should train the sales force on the company’s efforts in implementing the New SOP. The sales force should be particularly trained on the "danger zones" described above. A software company’s sales force is critical to the success of the company’s revenue recognition policies. Therefore, a software company may want to consider tying sales commission to recognized revenue to provide the company’s sales personnel incentive to further the company’s revenue recognition policies.
Maintain Specific Historical Information on Certain Areas. The New SOP includes a number of requirements that are based on whether a company has specific historical information on certain matters. A written record of these historical practices will be particularly important in the following areas --
Specified Upgrade Rights - The New SOP provides that revenue allocated to a specified upgrade right is the actual price that would be charged to existing users of the software product being upgraded less an amount based on the percentage of customers not expected to exercise the upgrade right.21 Therefore, it is important for a software company to keep a historical record of the number of its customers who do not exercise a specified upgrade right. Further, the actual price that the specified upgrade right is offered to customers should be tracked as well in order to establish the upgrade right’s fair value. Consider the following example:
Solosoft offers Version 3.1 of Accountsoft, Version 5.0 of Procuresoft, and a specific upgrade right to Version 4.0 of Accountsoft all for a license fee of $2,000. Solosoft has determined that the fair value of Version 3.1 of Accountsoft is $1200 and Version 5.0 of Procuresoft is $800 and the upgrade to Release 4.0 of Accountsoft is typically offered for $200 with 10% of the users of Version 3.1 of Accountsoft not expected to upgrade to Version 4.0. In this example $180 of the $2,000 license fee would be allocated to the Version 4.0 upgrade right ($200 minus $200 x 10%) and would be recognized upon the earlier of exercise of the specified upgrade right or expiration of the user’s upgrade right. If Solosoft does not have sufficient experience to make a reasonable estimate of the number of users who will not upgrade, then the calculation must be based on the assumption that 100 percent of the customers will exercise the upgrade right resulting in an increase in the amount of deferred revenue.
PCS/Early Revenue Recognition - Generally, revenue attributable to PCS is recognized ratably over the PCS term. However, Paragraph 59 of the New SOP provides that in certain limited circumstances a software company may recognize revenue allocated to PCS upon delivery of the licensed software if certain criteria are met: (1) the unspecified upgrades/enhancements offered to users historically have been (and are expected to continue to be) minimal and infrequent; (2) the PCS fee is included with the initial licensing fee; (3) the PCS included with the initial license is for one year or less; and (4) the estimated cost of providing PCS during the arrangement is insignificant.22 Therefore, the software company should track the number of unspecified upgrades/enhancements and the amount of effort and cost associated with PCS to determine whether Paragraph 59 of the New SOP is applicable.
Telephone Support - Is there a history of providing substantially all of the telephone support for the software product within one year of licensing the software? If yes, and the telephone support is primarily the only support that is provided by a software company as part of PCS and the other criteria indicated in the immediately preceding paragraph are satisfied, then under Paragraph 61 of the New SOP the revenue allocable to the telephone support may be recognized upon delivery of the software even if the telephone support is offered or available for a period exceeding one year. Otherwise, the fair value of the portion of the telephone fee attributable to PCS must be unbundled and recognized ratably over the term of the PCS arrangement.
Costs of PCS - Is there evidence as to the costs incurred by the client to provide PCS on other than a straight-line basis? Also, does the software company believe that it is probable that the costs incurred in performing under the current arrangement will follow a similar pattern? In the absence of this historical evidence, revenue must be recognized on a straight-line basis.23
Authorization Codes (Keys) - As discussed above, delivery of software is one of the basic revenue recognition criteria. Therefore, when a software arrangement involves the use of a keys an issue arises whether delivery of the key is necessary to consider the software to have been delivered. Paragraph 25 of the New SOP provides that under certain circumstances a software company may recognize revenue prior to delivery of a key; provided, however, among other matters that the software company does not have a history of failing to enforce its right to collect payment under the terms of the original arrangement. If such a history exists, then the software company is required to defer revenue until the permanent key is provided.
Extended Payment Terms - If a software company has a practice of entering into contracts with extended payment terms, then does the software company have a history of collecting the fees? The New SOP provides that payment terms in excess of twelve months are presumed to not be fixed or determinable.24 However, a software company can overcome this presumption by demonstrating a history of enforcing extended payment terms.25
Establish Vendor-Specific Objective Evidence Of Fair Value For All Elements. The New SOP places great emphasis on vendor-specific objective evidence of fair value in order to allocate revenue among the different elements of a software arrangement. As mentioned above, generally the fair value of licensed software or services provided by a software company will be based upon the price the company separately offers the licensed software and services to others. Accordingly, companies should consider offering software "a la carte" in order to establish vendor-specific objective evidence and avoid deferral of revenue based on undelivered elements. If a software company does not separately charge for each element of an arrangement, then satisfactory evidence to meet the test requires that the price for each element of the arrangement be established by "management having the relevant authority."26 The New SOP does not define "relevant authority," but clearly the decision maker must be knowledgeable about the company’s new and proposed software products and services. Generally, when the company establishes the price for an element it must have a present intention that the element will be sold separately in the near future and that the price, once established, will not change prior to entering the marketplace.27
1 See SOP 97-2 ¶ 8
2 See SOP 97-2 ¶ 65
3 See SOP 97-2 ¶ 10
4 See SOP 97-2 ¶ 41
5 See SOP 97-2 ¶ 11
6 See SOP 97-2 ¶ 7
7 See SOP 97-2 ¶¶ 13, 65
8 See SOP 97-2 ¶ 36
9 SAP is a leading software provider in the Enterprise Resource Planning field.
10 See SOP 97-2 ¶ 8
11 See SOP 97-2 ¶ 21
12 See SOP 97-2 ¶ 21
13 See SOP 97-2 ¶ 28
14 See SOP 97-2 ¶ 20
15 See SOP 97-2 ¶ 31
16 See SOP 97-2 ¶ 14
17 See SOP 97-2 ¶ 14
18 See SOP 97-2 ¶ 14
19 See SOP 97-2 ¶ 14
20 See SOP 97-2 ¶ 31
21 See SOP 97-2 ¶ 37
22 See SOP 97-2 ¶ 59
23 See SOP 97-2 ¶ 57
24 See SOP 97-2 ¶ 28
25 See SOP 97-2 ¶ 28
26 See SOP 97-2 ¶ 10
27 See SOP 97-2 ¶ 10