Search within this section
Select a section below and enter your search term, or to search all click Software
Favorited Content
2.2 Establishing technological feasibility
Publication date: 31 Dec 2021
us Software costs
ASC 985-20-25-1 requires a reporting entity to expense when incurred all costs prior to establishing technological feasibility of externally marketed software. Those costs are considered R&D expense. The determination of what constitutes technological feasibility, and the point at which it is established are, therefore, critical determinations in the accounting for the costs of externally marketed software. The criteria for establishing technological feasibility are discussed in 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:
- If the process of creating the computer software product includes a detail program design, all of the following:
- 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.
- 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.
- 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.
- 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:
- A product design and a working model of the software product have been completed.
- The completeness of the working model and its consistency with the product design have been confirmed by testing.
As ASC 985‑20‑25‑2 indicates, technological feasibility is established through completion of either (a) a detailed program design or (b) 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, many software companies 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 software product comprises various modules that are not sold separately.
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.
2.2.1 Technological feasibility—detailed program design
As detailed in ASC 985-20-25-2, in order to achieve technological feasibility by reference to a detailed program design, (a) the product design must be complete, (b) all resources necessary to produce the product must be available, (c) the completeness of the detailed program design must have been confirmed by documenting and tracing to product specifications, and (d) 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 issues. 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 R&D 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 the following:
- A detailed description of product specifications (the product design)
- Detailed program design and 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.
2.2.2 Technological feasibility—working model
If the development process does not include a detail program design with the characteristics described in SW 2.2.1, technological feasibility is established by a working model. 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 only available 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).
PwC. All rights reserved. PwC refers to the US member firm or one of its subsidiaries or affiliates, and may sometimes refer to the PwC network. Each member firm is a separate legal entity. Please see www.pwc.com/structure for further details. This content is for general information purposes only, and should not be used as a substitute for consultation with professional advisors.
Link copied
