Expand
Resize
Add to favorites
ASC 985-20 applies to development costs for software that the vendor intends to sell, lease, or otherwise market separately or as part of a product. The cost guidance in ASC 985-20 follows an inventory model with respect to what software costs are capitalized and how the costs are eventually derecognized and recognized as cost of revenue or cost of sales. Costs incurred are capitalized once technological feasibility is reached, and capitalization of costs ceases when the product is available for general release.
For guidance on the presentation and disclosure of software to be sold, leased, or otherwise marketed, see FSP 8.8.

7.3.1 Establishing technological feasibility

Except when acquired in a business combination, ASC 985-20-25-1 requires that all costs incurred to establish the technological feasibility of software to be sold, leased, or otherwise marketed be charged to expense as research and development (R&D) when incurred. Refer to PPE 8.3 for additional discussion on R&D costs. Refer to BCG 4 for additional information on intangible assets acquired in a business combination.
Technological feasibility “is established when the entity has completed all planning, designing, coding, and testing" necessary to determine that the product will meet its design specifications, including functions, features, and technical performance specifications. Once technological feasibility has been established, subsequent costs should be capitalized until the software begins to be marketed.
Technological feasibility is a critical determination for the accounting for software to be sold, leased, or otherwise marketed to others. The two criteria for establishing technological feasibility are discussed in ASC 985-20-25-2.

ASC 985-20-25-2

For purposes of this Subtopic, the technological feasibility of a computer software product is established when the entity has completed all planning, designing, coding, and testing activities that are necessary to establish that the product can be produced to meet its design specifications including functions, features, and technical performance requirements. At a minimum, the entity shall have performed the activities in either (a) or (b) as evidence that technological feasibility has been established:
a. If the process of creating the computer software product includes a detail program design, all of the following:       
1. The product design and the detail program design have been completed, and the entity has established that the necessary skills, hardware, and software technology are available to the entity to produce the product.       
2. The completeness of the detail program design and its consistency with the product design have been confirmed by documenting and tracing the detail program design to product specifications.       
3. The detail program design has been reviewed for high-risk development issues (for example, novel, unique, unproven functions and features or technological innovations), and any uncertainties related to identified high-risk development issues have been resolved through coding and testing.
b. If the process of creating the computer software product does not include a detail program design with the features identified in (a), both of the following:       
1. A product design and a working model of the software product have been completed.       
2. The completeness of the working model and its consistency with the product design have been confirmed by testing.

See PPE 7.3.1.1 and PPE 7.3.1.2 for further details on the two criteria described above in ASC 985-20-25-2.
As ASC 985-20-25-2 indicates, technological feasibility is established through completion of a detailed program design or a working model. This is not an accounting policy election. Rather, which milestone establishes technological feasibility is a function of the reporting entity’s software development process for each project.
In practice, the process of establishing when technological feasibility occurs is varied. Many software companies do not have significant capitalized software because they define technological feasibility as the creation of a working model, which often occurs late in the development cycle. ASC 985-20-55-7 addresses how to determine technological feasibility when a product comprises various modules.

ASC 985-20-55-7

When a product comprises various modules that are not separately saleable, technological feasibility is established for the product as a whole, not on a module-by-module basis. The detail program design or the working model of the entire product (all modules linked together) must be completed before capitalization.

7.3.1.1 Technological feasibility supported by detailed program design

As detailed in ASC 985-20-25-2, in order to achieve technological feasibility by reference to a detailed program design, the product design must be complete, all resources necessary to produce the product must be available, the completeness of the detailed program design must have been confirmed by documenting and tracing to product specifications, and all high-risk development issues must have been resolved through coding and testing.
In the unusual case when a high-risk development issue arises after management has established technological feasibility, the provisions of ASC 250-10-45-17 for changes in accounting estimates would apply to the previously capitalized costs, as well as the costs to resolve any high-risk development issue. Any previously capitalized costs for that product, as well as any additional costs incurred to re-establish technological feasibility, should be charged to expense as research and development costs.
Detailed program design requirements are generally not met simply by a chart outlining work plan tasks or an overview flowchart or diagram of the product. Conceptually, a detailed program design is analogous to an engineering blueprint.
In each development environment, the form of a detailed program design will vary; however, it should typically include:
  • A detailed description of product specifications (the product design)
  • Detailed program design and detailed flowcharts documenting the program procedures, data flow, and interaction with other applications. This documentation should take product function, feature, and technical requirements to their most detailed, logical form and should be ready for coding.
  • Documentation of the consideration and resolution of high-risk development issues through coding and testing
  • Actual coding and testing of specific program sections, when warranted
Once technological feasibility has been attained by development of an appropriately detailed program design, capitalization of software costs should begin. In other words, reporting entities cannot elect to delay capitalization until a working model has been completed. Refer to PPE 7.3.1.2 for further details on technological feasibility supported by a working model.

7.3.1.2 Technological feasibility supported by a working model

If the working model approach is used (i.e., when the development process does not include a detail program design with the characteristics described in PPE 7.3.1.1), ASC 985-20 requires that the completeness of the working model and its consistency with the product design be confirmed by testing before capitalization begins. A working model is not the same as a prototype; a working model is typically available only near the end of the development process and is generally the beta testing version of the software.

Definition from ASC Master Glossary

Working Model: An operative version of the computer software product that is completed in the same software language as the product to be ultimately marketed, performs all the major functions planned for the product, and is ready for initial customer testing (usually identified as beta testing).

7.3.2  Types of capitalizable costs for externally marketed software

ASC 985-20 states that all costs incurred to establish technological feasibility of a software product must be charged to expense. Once technological feasibility is established, subsequent costs that directly relate to the project should be capitalized until the product is available for general release to customers. This is when the externally marketed software or the product which contains the externally marketed software is available for purchase. ASC 985-20-25-2 through ASC 985-20-25-5 discusses the types of costs that should be capitalized once technological feasibility is established. These costs include costs to perform coding and testing activities, including employee costs directly associated with those tasks. Both direct and indirect costs, such as overhead related to programmers and the dedicated computer hardware and systems they utilize, would qualify for capitalization. However, an allocation of general and administrative expenses would not be appropriate because those costs are not directly related to the project.
Question PPE 7-1 addresses whether a reporting entity could elect to expense all software development costs incurred.
Question PPE 7-1

May a reporting entity elect to expense all software development costs?
PwC response
No. A reporting entity should capitalize those costs that meet the criteria of ASC 985-20 for capitalization (or ASC 350-40 for internal-use software). However, in practice, many reporting entities utilize the working model to establish technological feasibility for software, which generally results in technological feasibility being established later than under the detailed program design approach. As a result, the working model approach usually results in a shorter capitalization window and the costs to be capitalized during this period may be immaterial.

7.3.3 Purchased software to be externally marketed

The cost of purchased software to be sold, leased, or otherwise marketed that has no alternative future use is accounted for in the same manner as costs incurred to develop such software internally (unless it is acquired in a business combination). See BCG 4 for information on in-process research and development assets acquired in a business combination. If technological feasibility of the product to be ultimately marketed has been established, the cost should be capitalized; if technological feasibility has not been established, the costs are R&D expenses until technological feasibility is established.
If the purchased software, acquired before technological feasibility was established, has an alternative future use, the cost should be capitalized when acquired and accounted for in accordance with its alternative use. However, the amount capitalized would be limited to the amount realizable from the alternative future use. This scenario is described in ASC 985-20-55-14.

ASC 985-20-55-14

An entity may purchase software before technological feasibility has been established. For example, an entity purchases software for $100,000 that can be resold for $75,000. The amount of $25,000 would be charged to research and development, and $75,000 would be capitalized. If the software product reached technological feasibility, the $75,000 would be included in the cost of the software product. If the technological feasibility of the software was never established, the $75,000 would be classified as inventory.

7.3.4  Amortization of capitalized cost of externally marketed software

Amortization of software should commence when the product is available for general release to customers. The method of amortizing costs capitalized for software to be sold, leased, or otherwise marketed to others is discussed in ASC 985-20-35-1 through ASC 985-20-35-2.

ASC 985-20-35-1

Capitalized software costs shall be amortized on a product-by-product basis. The annual amortization shall be the greater of the amounts computed using the following:
a. The ratio that current gross revenues for a product bear to the total of current and anticipated future gross revenues for that product.
b. The straight-line method over the remaining estimated economic life of the product including the period being reported on.

ASC 985-20-35-2

Because a net realizable value test, which considers future revenues and costs, must be applied to capitalized costs (see paragraph ASC 985-20-35-4), amortization shall be based on estimated future revenues. In recognition of the uncertainties involved in estimating revenue, amortization shall not be less than straight-line amortization over the product's remaining estimated economic life.

The straight-line computation is the minimum annual amortization. Because the requirement is to use the greater of the amortization calculated using the ratio method or the straight-line amount, changing between the methods to meet this requirement is not considered a change in accounting principle. However, if comparability is materially impacted, disclosure may be appropriate.
Example PPE 7-1, Example PPE 7-2, and Example PPE 7-3 illustrate the calculation of software amortization.
EXAMPLE PPE 7-1
Software amortization example – year 1
PPE Corp has capitalized costs associated with software to be sold in accordance with ASC 985-20. At the beginning of 20X1, PPE Corp has capitalized $100 of software costs and has determined that amortization should begin because the product is available to customers.
PPE Corp estimates $625 of revenue to be recorded over the software’s 5-year economic life. PPE Corp expects the revenue to be recorded as follows:
20X1
$100
20X2
$150
20X3
$200
20X4
$100
20X5
$75
Total
$625
During 20X1, PPE Corp recorded revenue of $100 (which is in line with its expectation). PPE Corp’s future revenue projections are unchanged.
What is PPE Corp’s amortization expense for 20X1?
Analysis
ASC 985-20-35-1 indicates that amortization should be the greater of (1) the ratio that current gross revenues for a product bear to the total of current and anticipated future gross revenues for that product or (2) the straight-line method over the remaining estimated economic life of the product including the period being reported on.
Those amounts would be calculated as follows.
Ratio Method: ($100 current year revenue / ($100 current year revenue + $525 anticipated future revenue)) × $100 capitalized software = $16
Straight-Line Method: $100 / 5 years = $20
As a result, during 20X1, PPE Corp should record amortization of $20.
EXAMPLE PPE 7-2
Software amortization example – year 2
PPE Corp has capitalized costs associated with software to be sold in accordance with ASC 985-20. At the beginning of 20X1, PPE Corp has capitalized $100 of software costs and has determined that amortization should begin because the product is available to customers.
PPE Corp estimates $625 of revenue to be recorded over the software’s 5-year economic life. PPE Corp expects the revenue to be recorded as follows:
20X1
$100
20X2
$150
20X3
$200
20X4
$100
20X5
$75
Total
$625
During 20X2, PPE Corp exceeds budget and records revenue of $325. Additionally, PPE Corp revises its future revenue projections as follows:
20X3
$350
20X4
$200
20X5
$125
Total
$675
What is PPE Corp’s amortization expense for 20X2?
Analysis
At the beginning of 20X2, PPE Corp had unamortized capitalized software of $80 ($100 cost less $20 amortization in 20X1). PPE Corp would determine amortization expense in 20X2 as follows.
Ratio Method: ($325 current year revenue / ($325 current year revenue + $675 anticipated future revenue)) × $80 unamortized capitalized software = $26
Straight-Line Method: $80 / 4 years = $20
As a result, during 20X2, PPE Corp would record amortization of $26.
EXAMPLE PPE 7-3
Software amortization example – year 3
PPE Corp has capitalized costs associated with software to be sold in accordance with ASC 985-20. At the beginning of 20X1, PPE Corp has capitalized $100 of software costs and has determined that amortization should begin because the product is available to customers.
PPE Corp estimates $625 of revenue to be recorded over the software’s 5-year economic life. PPE Corp expects the revenue to be recorded as follows:
20X1
$100
20X2
$150
20X3
$200
20X4
$100
20X5
$75
Total
$625
During 20X3, PPE Corp does not meet budget and records revenue of $125. However, PPE Corp estimates that revision of its anticipated future revenue is not required, which are as follows:
Year 4
$200
Year 5
$125
Total
$325
What is PPE Corp’s amortization expense for 20X3?
Analysis
At the beginning of 20X3, PPE Corp had unamortized software capitalized cost of $54 ($100 less accumulated depreciation of $46). PPE Corp would determine amortization expense in 20X3 as follows.
Ratio Method: ($125 current year revenue / ($125 current year revenue + $325 anticipated future revenue)) × $54 unamortized capitalized software = $15
Straight-Line Method: $54 / 3 years = $18
As a result, during 20X3, PPE Corp would record amortization of $18.

7.3.5 Impairment of capitalized cost of externally marketed software

The impairment test for software to be sold, leased, or otherwise marketed follows the net realizable value (NRV) test described in ASC 985-20-35-4. Considerations when estimating future revenues for the purposes of the NRV test are explored in Question PPE 7-2 and Question PPE 7-3.

ASC 985-20-35-4

At each balance sheet date, the unamortized capitalized costs of a computer software product shall be compared to the net realizable value of that product. The amount by which the unamortized capitalized costs of a computer software product exceed the net realizable value of that asset shall be written off. The net realizable value is the estimated future gross revenues from that product reduced by the estimated future costs of completing and disposing of that product, including the costs of performing maintenance and customer support required to satisfy the entity's responsibility set forth at the time of sale. The reduced amount of capitalized computer software costs that have been written down to net realizable value at the close of an annual fiscal period shall be considered to be the cost for subsequent accounting purposes, and the amount of the write-down shall not be subsequently restored.

The NRV test is required to be performed at each balance sheet date. ASC 985-20 indicates that the unamortized capitalized costs to be used for subsequent accounting purposes (i.e., subsequent NRV tests) is the amount determined by the NRV test performed at the close of the previous annual fiscal period. Thus, capitalized costs that are written down to NRV during an interim period may be written back up during that same fiscal year to an amount not to exceed the current year write-down. Any adjustments to subsequently restore write-downs should be recorded in the interim period in which the revised estimates of future gross revenues are made; previously reported interim amounts should not be restated.
If it is no longer probable the software will be completed, the asset should be written down to the lower of cost or fair value less cost to sell. If the software will be completed but will not include all of the features included in the original product design, the lower of cost or fair value model does not need to be applied as long as the product will continue to be saleable without the omitted features. However, the capitalized costs would still be subject to a net realizable value test, which may require write-down based on changes in projected revenue as a result of the modified features.
Question PPE 7-2 addresses the type of revenues that should be included in the NRV test. 
Question PPE 7-2

In performing the NRV test, may estimated future revenues include both revenues from sales of products and post-contract customer support (PCS) revenues?
PwC response
Yes. ASC 985-20-35-4 states that the future gross revenues from the product should be used in applying the NRV test. The product's future revenues should be reduced by the estimated future costs of completing and disposing of the product, including maintenance and other PCS.
PCS revenues are often intended to recover not only capitalized costs, but also to fund the future development of upgrades and enhancements covered by the PCS arrangement. In applying the NRV test, it would be appropriate to include PCS revenues that have a capitalized cost recovery element. However, if PCS revenues are included in the test, then those revenues should be reduced by the expected future costs of completing the upgrades or enhancements covered by the PCS arrangement. Future costs should include all costs that will be incurred to support the PCS arrangement and the costs of any upgrades that will be provided to the customer.

Question PPE 7-3 addresses whether the revenue projections included in the NRV test should be discounted.
Question PPE 7-3

In performing the NRV test, should the estimated future gross revenues be discounted to their present value?
PwC response
No. ASC 985-20 does not discuss the discounting of gross revenues (unlike Step 2 in the impairment test for long-lived assets under ASC 360-10, Property, Plant, and Equipment—Overall which requires discounting). Conceptually, costs of software to be sold, leased, or otherwise marketed are similar to inventory costs for non-software products. ASC 330-10, Inventory—Overall does not discuss the discounting of inventory when performing the net realizable value test. As such, the NRV test for software to be sold, leased, or otherwise marketed should be performed on an undiscounted basis.

7.3.6 Costs incurred after general release to customers

Judgment will be required to determine whether additional costs incurred after general release to customers relate to product enhancements or maintenance and customer support. Product enhancements are explicitly included in the scope of ASC 985-20 and may qualify for cost capitalization; maintenance and customer support are generally charged to expense when those costs are incurred.
The evaluations of whether costs are incurred relate to maintenance or enhancements is similar to that used for capital improvements. In general, costs for elements that can be marketed separately or create a new revenue stream can be capitalized as a product enhancement. For example, if a reporting entity commits to maintaining compatibility between its systems software and the related hardware, the costs of doing so would generally meet the definition of maintenance. However, if an existing product is modified to run on a different type of hardware, thereby expanding the market for the product, this activity would generally be classified as product enhancement. Costs relating to product enhancement should be charged to expense until the technological feasibility of the enhancement is established. Once established, capitalization and amortization of the product enhancement costs over the estimated life of the enhancement would be required.
Software or data modifications are minor changes in either the software or data. The changes are not considered product enhancements, since they do not extend the life or improve the marketability of the product. They usually relate to a specific customer's application of the product and would not require a product design.
Technological feasibility may be more easily established for a product enhancement than for a new product, and capitalization of costs may, therefore, begin relatively earlier in the software development process. For example, an enhancement that adds one function to an already successful product may require only minor modifications to the original product's detailed program design to establish technological feasibility. Similarly, in some cases, software that is ported (made available for a different piece of hardware or operating system) may not require a new detailed program design; thus, capitalization of the enhancement costs may begin once any high-risk development issues have been resolved.

7.3.6.1 Amortization of software product enhancement costs

Once a product enhancement has been completed, if the original product will no longer be separately marketed, any unamortized cost of the original product should be included with the cost of the enhancement for purposes of applying the NRV test and amortization provisions. If the original product will remain on the market along with the enhancement, an allocation of the unamortized cost of the original product between the original product and the enhancement will be necessary.
In other words, depending on whether the original product will remain on the market, two methods are commonly used in practice for the amortization of product enhancement costs. The first method, often referred to as the “vintage” method, is used when the original product will continue to be available. In this method, the costs of the initial product and the product enhancement are amortized separately. The initial software would continue to be amortized over its remaining useful life while the enhancement would be separately tracked and amortized over its own remaining useful life.
The second method, often referred to as the “carryover” method, is utilized when the original product will no longer be marketed separately. This method of amortization cannot be applied to other types of assets. Under the carryover method, the costs of the enhancement are added to the unamortized costs of the previous version and the combined amount is amortized over the remaining useful life of the new product. The estimated useful life of a product enhancement should be determined without reference to the estimated future revenue or economic life of the original product.
Amortization of the costs of an enhancement that will be separately marketed follows the same model used for the original product. Refer to PPE 7.3.4 for additional information on amortization.

7.3.7 Software not sold, leased, or marketed as a discrete product

ASC 985-20 establishes technological feasibility as the threshold before software costs can begin to be capitalized. However, when the software is sold as firmware (i.e., embedded in a product and sold as part of the product as a whole), establishing technological feasibility of the software component is not sufficient. The accounting for software that is integral to the product is addressed in ASC 985-20-25-4.

ASC 985-20-25-4

Software production costs for computer software that is to be used as an integral part of a product or process shall not be capitalized until both of the following conditions have been met:
a. Technological feasibility has been established for the software.
b. All research and development activities for the other components of the product or process have been completed.

For an integrated product, even if technological feasibility has been established, software development costs should be expensed as incurred until all research and development for the integrated product are complete. For example, software may be developed that will be embedded in a semiconductor that in turn will be incorporated into a specific piece of hardware. If the semiconductor is not marketable as a stand-alone product, even though the technological feasibility of the software is evident, further software costs would continue to be subject to accounting under ASC 730, Research and Development, until the related hardware in which it will be sold is no longer in the development stage. That may occur well after the point at which the software reached technological feasibility.
This same notion is embodied in ASC 985-20-55-7, which addresses a software product that comprises various modules that are not sold separately (as discussed in PPE 7.3.1), and concludes that technological feasibility must be established for the product as a whole, not on a module-by-module basis. Consistent with ASC 985-20-25-2, the detail program design or the working model of the entire product (all modules linked together) must be completed before software costs can be capitalized.
Expand

Welcome to Viewpoint, the new platform that replaces Inform. Once you have viewed this piece of content, to ensure you can access the content most relevant to you, please confirm your territory.

Your session has expired

Please use the button below to sign in again.
If this problem persists please contact support.

signin option menu option suggested option contentmouse option displaycontent option contentpage option relatedlink option prevandafter option trending option searchicon option search option feedback option end slide