How to apply ASC 985-20 and ASC 350-40 for software costs

Matthew Rosenblatt, CPA, and Esther Assouline, CPA
2/2/2023
How to apply ASC 985-20 and ASC 350-40 for software costs

Two standards offer guidance for determining how to account for software development costs; however, the determination of asset versus expense is not always obvious.

In today’s economy, software development costs often are a significant part of many companies’ operating budgets. How a company accounts for those costs – that is, whether they are expensed as a regular cost of doing business or capitalized as an investment in a company asset – can have a major impact on the bottom line. In many cases, determining which costs to capitalize and which to record as an expense is one of the most important financial and accounting determinations a company’s management team must address. 

The determination of which capitalization model to use is not always obvious. Subtopics ASC 985-20 and ASC 350-40 of the Financial Accounting Standards Board (FASB) Accounting Standards Codification (ASC) framework outline the specifics for how to approach software development costs. Determining which capitalization criteria to use is critical to software companies and other technology sector businesses, but it also is a significant concern for organizations that are not typically regarded as technology companies in the conventional sense. The following are examples of companies that develop software for purposes of supporting internal operations or processes, which would be considered internal use software in accordance with ASC 350:

  • Manufacturers that implement their own robotic production software
  • Banks that develop online banking tools or loan management systems
  • Healthcare organizations that develop or enhance various software applications including electronic patient records, telemedicine platforms, appointment scheduling, billing, and practice management systems 
  • Sales organizations that develop or enhance their account management and customer relations software
  • Companies of all types that develop customized software to process payroll, manage payables and receivables, track inventory, or perform various other management and operational functions

By understanding the complexities associated with the applicable guidance, management teams will be better prepared to make consistent, informed decisions about how they account for these costs. What’s more, this knowledge also can help them do a better job of understanding and managing the long-term financial and strategic impacts of their software initiatives.

An overview of ASC 985-20 and ASC 350-40

Two primary subtopics in the FASB ASC framework apply to the accounting treatment of software development costs:

  • ASC 985-20, “Software – Costs of Software To Be Sold, Leased, or Marketed,” applies to costs that are incurred when developing software that will be sold, leased, or otherwise marketed as a separate product or as part of a product or process. Traditional licensing of software (software installed on a customer’s server) generally would fall into this category (for example, standard word processing or spreadsheet software traditionally installed on an individual’s computer).
  • ASC 350-40, “Intangibles – Goodwill and Other – Internal-Use Software,” applies to costs incurred in developing software that is used solely to meet a company’s internal needs or to provide services to its customers. This would include hosting a version of a software application for customers to access online – that is, acting as a software as a service (SaaS) provider.

Although the distinction seems straightforward enough at first glance, determining which standard applies to a specific piece of software is not always so clear-cut in practice.

Unlike in the past, when most software was delivered on a disk or downloaded as a set of digital files, many of today’s software products are offered on a subscription basis rather than as an outright purchase. The advent of SaaS, cloud hosting, and other advances has resulted in much of today’s software development work being done to enable a company to provide a service to its customers rather than to deliver a physical copy of the software. As a result, the related software development costs (for example, SaaS) typically would be within the scope of ASC 350-40, rather than ASC 985-20, since the software itself will be used within the company to provide that service.

The distinction between the capitalization criteria (that is, ASC 985 versus ASC 350) matters because the two standards spell out significantly different thresholds for determining when a company can begin capitalizing software development costs. For example, costs related to the design, configuration, and coding of software are usually expensed under ASC 985-20, while ASC 350-40 typically requires most of those costs to be capitalized. The two standards also differ in terms of the point in the development process when the company should begin capitalizing costs, so it is important for companies to be sure they are following the appropriate guidance. (Please note: This is just a general example, and it should not be considered definitive advice or guidance in determining which standard applies to specific development costs.)

As a rule, determining which guidance applies depends on the answers to two questions: 

  1. Can the customer take possession of the software during the hosting or subscription period without a significant penalty? 
  2. Can the customer either operate the software by itself or contract with an unrelated third party to host the software? 

If the answer to both questions is “yes,” the related software development costs are probably within the scope of ASC 985-20, but SaaS companies should consider the question carefully and consult with their third-party auditor for a definitive answer. 

ASC 985-20 and technological feasibility

Under ASC 985-20, costs are capitalized only after technological feasibility is achieved. According to the standard (ASC 985-20-25-2), technological feasibility is achieved “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.

Until technological feasibility is achieved, all development costs for software that is to be sold, leased, or otherwise marketed must be recorded as research and development expenses at the time they are incurred. After technological feasibility is established, however, the software is considered to be a company asset, so any additional development costs or enhancements incurred after that point are considered investments in the asset and therefore must be capitalized until the software is ready for its intended use.

Technological feasibility can be achieved in one of two ways:  


Program design Working model
Complete a detailed program design – basically a blueprint that includes the specific design configuration and the actual coding and testing of the program, as further defined in the codification. Demonstrate technological feasibility by producing a working model – that is, operative software that is ready for customer testing.

In today’s environment, most software is developed using variations of the “agile” methodology, in which teams of developers work simultaneously rather than sequentially on various software components. In this model, preparing a complete, detailed program design is generally considered a costly and unnecessary step that impedes the synergy that is one of the agile approach’s primary benefits. Given the prevalence of agile development, most technology companies use development of a working model as the milestone that defines technological feasibility. 

It takes considerable technical expertise to determine when a software program has moved beyond the prototype stage and can be considered an actual working model that is ready for release to customers, so coordination between the finance and technology teams is important. In any event, the production of a working model generally happens very late in the overall development process. This means that in many cases virtually all of the development costs for software that is to be sold, leased, or otherwise marketed to outside customers are expensed as research and development costs at the time they are incurred. 

That might not be true, however, for significant enhancements such as upgrades, improvements, adaptations to run the software on different operating platforms, or new features added to existing software. The company still must establish technological feasibility, but this is usually easier to do since it already has a working model, and an experienced programmer with access to the software coding could more easily enhance the software. 

ASC 350-40 and the stages of development

Unlike software that is to be marketed to external customers, software that is intended for internal use is subject to the expense and capitalization rules spelled out in ASC 350-40. Under this guidance, capitalization of costs can begin only after two criteria have been met:  

  1. The preliminary stage of the development process has been completed. 
  2. Company management that has the relevant authority either implicitly or explicitly authorizes the software project and commits to funding it, so that it is probable the project will be completed and the software will be used to perform its intended function. 

More specifically, ASC 350-40 identifies three main stages of development: 


Preliminary Application development  Post-implementation 
The preliminary stage of a development project includes activities such as formulating the initial concept, exploring and evaluating alternative technologies or approaches, making decisions about resource allocation, determining performance requirements, and evaluating and selecting suppliers. All costs associated with this stage are expensed as research and development expenses. This phase begins once the project is approved for development and management with the authority to do so has committed to funding the development of the software. The costs incurred at this stage include the actual design of the software configuration and interfaces, coding, installation of hardware, testing, and related administrative costs and overhead such as for materials, third-party development fees, and supporting software. These costs, including the payroll costs of employees associated with these tasks, are to be capitalized as an asset. This stage includes follow-up activities such as ongoing training, maintenance, and bug fixes. These costs are expensed as research and development expenses.

With more and more software products now being marketed as SaaS or cloud-hosted offerings, a growing number of technology companies and tech-enabled companies are finding their development costs are covered under ASC 350-40 rather than ASC 985-20. This means they must apply the three stages of development when analyzing their product development costs, and they often must begin capitalizing costs they otherwise might have recorded as research and development expenses.  

Timing considerations

Because it might take several years before a software product begins generating revenue, it can be difficult for a technology company or tech-enabled company to determine how to record and account for its development costs while the ultimate distribution model is still subject to change. Any change in the revenue-generating strategy during the course of development could affect how costs are recorded and accounted for, as shown in these examples: 


Example 1 Example 2
Change from ASC 350 to ASC 985: If a company begins developing software for its own internal uses, the project falls within the scope of ASC 350-40. This means that, once the preliminary stage of development is completed and management authorizes the software to be funded, subsequent costs incurred during the application development stage will have been capitalized. But if the company later chooses to license the software (that is, allow its current or future customers to take possession), some of those costs would need to be reconsidered because ASC 350-40 applies only if the software will be used exclusively and solely for internal purposes. In such an instance, where the company has completed the development of the software, according to ASC 350-40-35-7 through 10, the revenue generated by the stand-alone sales would reduce the amount capitalized. Change from ASC 985 to ASC 350: Conversely, if a company originally develops software to be sold as a stand-alone product, a portion of its development costs likely have been expensed under ASC 985-20. If it later decides to market an online version that it hosts in the cloud, it could be necessary to reassess the accounting on a prospective basis. Another potential complication can occur if a company decides that software it has been developing for external sale is no longer viable in the market. 

Given a choice, many tech company management teams would prefer to simply expense all software development costs rather than undertake the recordkeeping burden and administrative costs that capitalization requires. This, however, is not an option under U.S. GAAP, which requires that certain software development costs must be capitalized and that companies must determine which of the two ASC subtopics to apply. 

Proper documentation

Any company that develops, adapts, or customizes software – whether for its own internal use or for sale to customers – should understand the documentation and records it must maintain in order for its audit team to do its work. Rather than waiting until the audit is about to begin, management should reach out to the audit team early to discuss the documentation it will need to see. Early preparation can help avoid a last-minute scramble to locate or reconstruct records.  

Required documents might include:

  • Detailed payroll time records with specific tracking of employee time spent on various development activities such as design, coding, testing, and project management
  • Detailed program design documentation for software that is developed for external sale
  • Detailed project status reports

Proper documentation is essential in order to produce financial statements that accurately reflect the value and performance of a company’s software assets.

The bottom line

Understanding ASC 985-20 and ASC 350-40 is essential for organizations that will continue to pursue software development. Knowing when and how software capitalization rules apply and which costs should be expensed and which should be capitalized can have a significant impact on the bottom line. 

When it comes to the technology, media, and telecommunications industry, Crowe has the expertise to help you stay compliant.

Our team has deep knowledge of the TMT industry

We can help you keep pace with the ever-changing global technology industry, FASB standards, and software development costs. Contact us for more information.
people
Esther Assouline

Related insights

loading gif
2024 Crowe Commercial Services Seminar
2024 Crowe Commercial Services Conference
Get the information you need to guide your institution through industry volatility, straight from our team of specialists. Register today.
Read about CFPB open banking rule, FASB ASU 2024-03, SEC commissioner thoughts on regulatory environment, CAQ fall audit partner survey results.
November 2024 Financial Reporting, Governance, and Risk Management
Read about CFPB open banking rule, FASB ASU 2024-03, SEC commissioner thoughts on regulatory environment, CAQ fall audit partner survey results.
Bank Audit Committee Virtual Peer Group
Bank Audit Committee Virtual Peer Group
Join Crowe for the second of two Bank Audit Committee Virtual Peer Group sessions in 2024.
2024 Crowe Commercial Services Seminar
2024 Crowe Commercial Services Conference
Get the information you need to guide your institution through industry volatility, straight from our team of specialists. Register today.
Read about CFPB open banking rule, FASB ASU 2024-03, SEC commissioner thoughts on regulatory environment, CAQ fall audit partner survey results.
November 2024 Financial Reporting, Governance, and Risk Management
Read about CFPB open banking rule, FASB ASU 2024-03, SEC commissioner thoughts on regulatory environment, CAQ fall audit partner survey results.
Bank Audit Committee Virtual Peer Group
Bank Audit Committee Virtual Peer Group
Join Crowe for the second of two Bank Audit Committee Virtual Peer Group sessions in 2024.