54
However, AcSEC also was concerned that if revenue recognition were permitted to begin at the
inception of the arrangement, revenue may be recognized too early, particularly in arrangements
in which the first product was not delivered for some time after inception. Accordingly, AcSEC
concluded that revenue from the arrangement should be recognized ratably over the term of the
arrangement beginning with the delivery of the first product.
.121 Rights to Exchange or Return Software. AcSEC believes that the rights to exchange or
return software (including platform transfer rights) are subject to the provisions of FASB
Statement No. 48, even if the software is not returned physically. Accordingly, AcSEC concluded
that the accounting for exchanges of software for products with no more than minimal differences
in price, functionality, and features by users qualify for exchange accounting because, as
discussed in footnote 3 to FASB Statement No. 48, (a) users are “ultimate customers” and (b)
exchanges of software with no more than minimal differences in price, functionality, and features
represent “exchanges ... of one item for another of the same kind, quality, and price.” AcSEC
concluded that because resellers are not “ultimate customers,” such exchanges by resellers
should be considered returns.
.122 AcSEC reached similar conclusions related to certain platform-transfer rights. Additionally,
AcSEC concluded that in situations in which customers are entitled to continue using the software
that was originally delivered (in addition to the software that is to be delivered for the new
platform), the customer has received additional software products, and the platform-transfer right
should be accounted for as such. Other platform-transfer rights do not allow customers to
continue to use the software on the original platform. Those platform-transfer rights should be
accounted for as exchange rights or rights of return.
.123 It is possible that exchange rights may be granted for software that has not been developed
for other platforms at the time revenue from the arrangement is recorded. AcSEC did not address
the issue of whether such future development costs related to deliverable software, for which no
further revenue will be received, should be capitalized pursuant to FASB Statement No. 86
because it was believed that such costs would not be significant. Accordingly, AcSEC concluded
that in the event of significant development costs, the vendor would not be likely to be able to
demonstrate persuasively that the future software would have similar pricing, features, and
functionality, and would be marketed as the same product (that is, qualify as an exchange for
accounting purposes). In that event, the vendor has granted a return right that must be accounted
for pursuant to FASB Statement No. 48.
Postcontract Customer Support
.124 An obligation to perform PCS is incurred at the inception of a PCS arrangement and is
discharged by delivering unspecified upgrades/enhancements, performing services, or both over
the period of the PCS arrangement. The obligation also may be discharged by the passage of
time. AcSEC concluded that because estimating the timing of expenditures under a PCS
arrangement usually is not practicable, revenue from PCS generally should be recognized on a
straight-line basis over the period of the PCS arrangement. However, AcSEC also concluded that
if there is sufficient vendor-specific historical evidence that costs to provide the support are
incurred on other than a straight-line basis, the vendor should recognize revenue in proportion to
the amounts expected to be charged to the PCS services rendered during the period.
.125 SOP 91-1 required that revenue from both the PCS and the initial licensing fee be
recognized ratably over the period of the PCS arrangement if no basis existed to derive separate
prices for the PCS and the initial licensing fee. Diversity in practice arose as to what constituted a
sufficient basis in arrangements involving vendors that did not have a basis to derive a separate
price for the PCS. In this SOP, AcSEC has concluded that arrangement fees must be allocated to
elements of the arrangement based on vendor-specific objective evidence of fair value. Because
AcSEC determined that the evidence should be limited to that which is specific to the vendor,
AcSEC believes that vendors that do not sell PCS separately have no basis on which to allocate
fair values. AcSEC concluded that the total arrangement fee should be recognized in accordance
Software Revenue Recognition
⎢
A-25
50
with the provisions on recognition of PCS revenues. AcSEC also believes that, because a
substantial portion of the arrangement fee typically is represented by the delivered software
(rather than the performance of support), requiring the deferral of all revenues until the PCS
obligation is fully satisfied would be too onerous. Accordingly, AcSEC concluded that, as
discussed in the previous paragraph, the total arrangement fee generally should be recognized
ratably over the period of the PCS arrangement.
Services
.126 Certain software arrangements include both a software element and an obligation to perform
non-PCS services. SOP 91-1 provided guidance on the conditions that must be met in order to
account for the obligation to provide services separately from the software component. AcSEC is
aware that this guidance has been interpreted in varying ways, leading to a diversity in practice.
During its deliberations on this SOP, AcSEC reached conclusions intended to clarify this issue,
but did not redeliberate the other conclusions related to services that were included in SOP 91-1.
.127 AcSEC believes the service element should be accounted for separately if the following
occur.
a. All other revenue allocation provisions of this SOP are met.
b.The services are not essential to the functionality of any other element in the arrangement.
c. The service and product elements are stated separately such that the total price of the
arrangement would vary as a result of inclusion or exclusion of the services.
Accordingly, AcSEC concluded that a service element need not be priced separately in an
agreement in order to account for the services separately. AcSEC believes that this conclusion
represents the original intent of SOP 91-1, and wishes to clarify the language at this time.
.128 Paragraphs .129 through .132 of this SOP are carried forward from SOP 91-1 with certain
editorial changes.
.129 Service Elements. Footnote 1 to paragraph 11 of SOP 81-1 [section 10,330.11, footnote 1]
excludes service transactions from the scope of the SOP, as follows:
This statement is not intended to apply to “service transactions” as defined in the FASB’s
October 23, 1978 Invitation to Comment, Accounting for Certain Service Transactions.
However, it applies to separate contracts to provide services essential to the construction or
production of tangible property, such as design . . . [and] engineering . . . .
.130 The previously mentioned Invitation to Comment, which was based on an AICPA-proposed
SOP, was issued in 1978. The FASB later included service transactions as part of its project to
develop general concepts for revenue recognition and measurement. The resulting FASB
Concepts Statement No. 5, however, does not address service transactions in detail.
Nevertheless, some of the concepts on service transactions developed in the Invitation to
Comment are useful in accounting for certain software transactions.
.131 A service transaction is defined in paragraphs 7 and 8 of the Invitation to Comment as
follows:
•
A transaction between a seller and a purchaser in which, for a mutually agreed price, the
seller performs . . . an act or acts . . . that do not alone produce a tangible commodity or
product as the principal intended result . . . A service transaction may involve a tangible
product that is sold or consumed as an incidental part of the transaction or is clearly
identifiable as secondary or subordinate to the rendering of the service.
The term service transaction is used in the same sense in this SOP but, as used in this SOP,
does not apply to PCS. Items classified as tangible products in software service transactions
generally should be limited to off-the-shelf software or hardware.
Software Revenue Recognition
⎢
A-26
41
.132 This SOP, like the Invitation to Comment, recommends the separation of such arrangements
with discrete elements into their product and service elements. Paragraph 8(b) of the Invitation to
Comment states the following:
If the seller of a product offers a related service to purchasers of the product but separately
states the service and product elements in such a manner that the total transaction price
would vary as a result of the inclusion or exclusion of the service, the transaction consists of
two components: a product transaction that should be accounted for separately as such and
a service transaction . . . .
Contract Accounting
.133 SOP 91-1 included guidance on the application of contract accounting to software
transactions. Questions arose as to whether output measures could be used to measure
progress-to-completion if the amounts recorded would differ from those that would have been
reported had input measures been used. During its deliberations of this SOP, AcSEC reached
conclusions intended to clarify this issue, but did not redeliberate the other conclusions related to
services that were included in SOP 91-1.
.134 AcSEC believes that the method chosen to measure progress-to-completion on an individual
element of a contract should be the method that best approximates progress-to-completion on
that element. Accordingly, AcSEC concluded that output measures may be used to measure
progress-to-completion, provided that the use of output measures results in “the method that best
approximates progress-to-completion.”
.135 Paragraphs .136 through .142 of this SOP are carried forward from SOP 91-1 with certain
editorial changes.
.136 ARB No. 45 established the basic principles for measuring performance on contracts for the
construction of facilities or the production of goods or the provision of related services with
specifications provided by the customer. Those principles are supplemented by the guidance in
SOP 81-1 [section 10,330].
Distinguishing Transactions Accounted for Using Contract Accounting From Product
Sales
.137 SOP 81-1 [section 10,330] suggests that transactions that normally are accounted for as
product sales should not be accounted for using contract accounting merely to avoid the delivery
requirements for revenue recognition normally associated with product sales. Paragraph 14 of
SOP 81-1 [section 10,330.14] states the following:
Contracts not covered . . . include . . . [s]ales by a manufacturer of goods produced in a
standard manufacturing operation, even if produced to buyers’ specifications, and sold in the
ordinary course of business through the manufacturer’s regular marketing channels if such
sales are normally recognized as revenue in accordance with the realization principle for
sales of products and if their costs are accounted for in accordance with generally accepted
principles of inventory costing.
Software Revenue Recognition
⎢
A-27
47
Application of ARB No. 45 and SOP 81-1
.138 SOP 81-1 [section 10,330] provides guidance on the application of ARB No. 45 that applies
to a broad range of contractual arrangements. Paragraph 1 of SOP 81-1 [section 10,330.01]
describes contracts that are similar in nature to software arrangements, and paragraph 13
[section 10,330.13] includes the following kinds of contracts within the scope of that SOP:
•
Contracts to design, develop, manufacture, or modify complex . . . electronic equipment
to a buyer’s specification or to provide services related to the performance of such
contracts; and
•
Contracts for services performed by . . . engineers . . . or engineering design firms.
.139 ARB No. 45 presumes that percentage-of-completion accounting should be used when the
contractor is capable of making reasonable estimates. Paragraph 15 of ARB No. 45 states the
following:
[I]n general when estimates of costs to complete and extent of progress toward completion of
long-term contracts are reasonably dependable, the percentage-of-completion method is
preferable. When lack of dependable estimates or inherent hazards cause forecasts to be
doubtful, the completed-contract method is preferable.
Evidence to consider in assessing the presumption that the percentage-of-completion method of
accounting should be used includes the technological risks and the reliability of cost estimates, as
described in paragraphs 25, 26, 27, 32, and 33 of SOP 81-1 [section 10,330.25, .26, .27, .32, and
.33].
.140 Paragraph 24 of SOP 81-1 [section 10,330.24] specifies a further presumption that a
contractor is capable of making reasonable estimates and states the following:
[T]he presumption is that [entities] . . . have the ability to make estimates that are sufficiently
dependable to justify the use of the percentage-of-completion method of accounting.
Persuasive evidence to the contrary is necessary to overcome that presumption. [Footnote
omitted]
.141 Although cost-to-cost measures may be verified easily, they tend to attribute excessive profit
to the hardware elements of arrangements with combined software and hardware elements for
contracts under which segmentation is not permitted. Although the hardware elements of such
arrangements have high cost bases, they generally yield relatively low profit margins to vendors.
Furthermore, if excessive revenue is attributed to the hardware element, revenue recognition on
the arrangement becomes overly dependent on when that element is included in the
measurement of progress-to-completion.
.142 For off-the-shelf software elements, the application of the cost-to-cost method produces the
opposite effect. The book basis of the software tends to be low, because most of the costs
associated with software development frequently are charged to expense when incurred in
conformity with FASB Statement No. 86. Although the profit margins associated with software are
generally higher than those for other elements of the arrangement, the application of cost-to-cost
measures with a single profit margin for the entire arrangement would attribute little or no profit to
the off-the-shelf software. Similarly, the application of the cost-to-cost method to arrangements
that include core software, which also has a relatively low cost basis, would attribute a
disproportionately small amount of profit to the software.
Software Revenue Recognition
⎢
A-28
20
Effective Date and Transition
.143 AcSEC concluded that the provisions of this SOP should be applied prospectively and that
retroactive application should be prohibited. AcSEC recognizes the benefits of comparable
financial statements but is concerned that the application of the provisions of this SOP to
contracts existing in prior periods would require a significant amount of judgment. The application
of that judgment likely would be impacted by the hindsight a company would have, resulting in
judgments based on information that did not exist at the time of the initial judgment but that would
be called for if the SOP were to be applied retroactively.
.144 Additionally, AcSEC concluded that some entities would be required to incur large
expenditures in determining restated amounts or the cumulative effect of adoption. AcSEC
concluded that the cost of calculating such amounts likely would exceed the related benefit of that
information. This SOP does not preclude an entity from disclosing in the notes to the financial
statements the effect of initially applying this SOP if an entity believes it is practicable to do so.
Items Not Retained From SOP 91-1
.145 AcSEC believes that the guidance included in SOP 91-1 related to discounting receivables
and the collectibility of receivables (discussed in paragraphs 56 and 78, respectively, of SOP 91-
1) is not specific to the software industry and thus does not need to be retained in this SOP.
Software Revenue Recognition
⎢
A-29
50
Appendix A
Examples of the Application of Certain Provisions of This Statement of Position
.146 Scope – Example 1
Facts:
An automobile manufacturer installs software into an automobile model. This software is used
solely in connection with operating the automobile and is not sold or marketed separately. Once
installed, the software is not updated for new versions that the manufacturer subsequently
develops. The automobile manufacturer’s costs for the development of the software that are
within the scope of FASB Statement No. 86, Accounting for the Costs of Computer Software to
Be Sold, Leased, or Otherwise Marketed, and the production costs of such software are
insignificant relative to the other development and production costs of the automobile.
Applicability:
The Statement of Position (SOP) is not applicable to such software because the software is
deemed incidental to the product as a whole.
Discussion:
Although the software may be critical to the operations of the automobile, the software itself is not
the focus of the marketing effort, nor is it what the customer perceives he or she is obtaining. The
development and production costs of the software as a component of the cost of the automobile
is incidental.
Scope – Example 2
Facts:
An entity develops interactive training courses for sale or licensing to customers. These courses
are delivered on a compact disc, which is loaded onto a customer’s computer. The courses are
developed such that, based on the responses received to a particular question, different
questions are generated and content of the course material that is displayed is determined in a
manner that directs the user’s learning experience in a more focused way. The course
developer’s costs for the development of the software content are within the scope of FASB
Statement No. 86 and are significant. The interactive nature of the courses is mentioned
prominently in the marketing efforts.
Applicability:
The SOP is applicable because the software is not incidental to the product.
Discussion:
Although some might say that the product is educational services, the marketing of the product
focuses on the software-reliant interactive features. In addition, the course developer incurs
significant costs that are within the scope of FASB Statement No. 86. The nature of the
relationship between the vendor and the customer is not one in which the customer would have a
need for postcontract services. Consequently, the absence of PCS is not presumptive that
software is incidental to the product. Accordingly, a conclusion is reached that the software is not
incidental to the product as a whole. Therefore, the provisions of this SOP apply.
Additional Software Products – Price per Copy – Example 1
Facts:
A vendor enters into an arrangement under which a customer has the right to make copies of
Product A at $100 a copy, copies of Product B at $200 a copy, or copies of Product C at $50 a
copy until such time as the customer has made copies aggregating $100,000 based on the per
copy prices. The customer is obligated to pay the $100,000 whether or not the customer makes
all the copies to which it is entitled under the arrangement. In all other respects, the $100,000 is
considered to meet the criteria of a fixed fee, as described in this Statement of Position.
Software Revenue Recognition
⎢
A-30
Documents you may be interested
Documents you may be interested
