Developed software capitalization

Industry-Specific Modeling. Real Estate. Professional Skills. Finance Interview Prep. Corporate Training. Technical Skills. View all Free Content.

Learn Online Now Link Copied! Table of Contents When can a company capitalize software costs? Software developed for internal use Software that companies sell or market to the public Software costs that qualify for capitalization Benefits of capitalizing software How much leeway do companies have in deciding what to capitalize vs expense Capitalized software development costs, an example.

Inline Feedbacks. X Please check your email. Learn Advanced Accounting Online. Finally, once development is complete and the software is made available for release to customers, capitalization no longer is appropriate because any remaining costs are considered ongoing maintenance and support. These costs always must be expensed as they are incurred.

In conventional software development projects with well-defined, consecutive phases, technological feasibility generally is demonstrated through either a detailed program design or, when a detailed program design is absent, a working model that is ready for customer testing.

These are familiar milestones for projects using the waterfall approach. In an agile project environment, however, individual functions and features are developed separately in a series of sprints. Each sprint or module is envisioned, planned, funded, developed, and tested individually to be incorporated into the overall project when ready.

In such an environment, comprehensive program designs or working models often are impractical or irrelevant. Companies using an agile approach to develop software might conclude inappropriately that technological feasibility has not been met significantly before the software enhancement is available to customers, resulting in costs being expensed as incurred rather than being capitalized. If significant costs accrue between when technological feasibility actually was reached and when the software is available to customers, the resulting accounting could be inconsistent with GAAP.

Although current GAAP guidance for external-use software is not tailored to the agile environment, that does not mean that agile development costs cannot be capitalized at all.

There are, after all, varying levels of agility. While a pure agile project might begin with just an idea and relatively little design work, some agile projects do have detailed program designs with in-depth storyboarding, market acceptance studies, and other design work documents put together before actual development begins. Such documents could be used to help assess technological feasibility. The risk is that project teams may not do enough front-end planning or retain adequate documentation to demonstrate they have met this threshold.

Demonstrating technological feasibility is likely to require the project team to do more planning and compile more documentation than is typical in most agile projects.

Other important considerations when determining technological feasibility relate to high-risk development features.

For example, is the project a completely new software platform, or is it an enhancement or re-creation of something that has been done before? Is the company developing software from the ground up, or is it piecing together various software components that already exist?

High-risk development features may require additional analysis of when technological feasibility is reached and, in some cases, expensing of previously capitalized costs. Product enhancements that are not considered maintenance activities sometimes can meet the technological feasibility threshold more easily because the developers are adding functions to an already successful product. Then companies shifted to more agile methods of software development.

Agile development teams are organized by product and task rather than by overall project. In addition, the teams themselves can be highly fluid, with people often staying only as long as their skills are required. These and other process innovations help software developers produce functionality in a faster, nimbler way.

But the same processes that make agile development teams more efficient can also make it harder to identify costs for capitalization.

More specifically, because agile efforts are fluid, it can be difficult to differentiate development from planning and maintenance since agile teams often go through all three phases very quickly during a sprint. Further, it can be difficult to identify sprints that include efforts that qualify for capitalization. It helps if an entire product team is dedicated to application development. One of the criteria to capitalize costs is that management has approved the project and the funds have been committed to complete development.

But if the organization has a history of abandoning sprints or stories before releasing them into production, it calls into question whether those costs are really for development and therefore eligible to be capitalized at all.

Organizations can also hit a snag when determining costs related to identified enhancements. When an agile team develops functionality into production, they may or may not have created a new asset that the organization should start amortizing.

It depends on whether the team intends to build on their work in a subsequent sprint. All of this can make it hard to properly identify and capitalize costs in an agile environment.

The shift to cloud delivery models means companies are developing software to provide a service versus software to be marketed or sold as a product like a traditional software license sold as an on-premises solution.

The distinction is important because software capitalization requirements are different between the two. For software that the organization aims to sell or market, most if not all of the development cost is expensed as incurred.

For software that the organization will deliver as a service, on the other hand, much of the development cost will likely have to be capitalized.

Although these guidelines seem straightforward enough, the timing of a shift from on-premises to cloud delivery may not always be clear. The accounting gets especially complicated when the organization delivers software through a hybrid of cloud and on-premises infrastructure.

This is because an entity will need to identify development activities that are dedicated to the cloud environment, which may need to be accounted for differently from the activities that enhance the on-premises technology. On top of that, the accounting team may lack visibility into a few vital pieces of information needed to properly identify and account for development costs. One of those pieces is when functionality is no longer available for on-premises deployment which could be the case when new functionality is only available in the cloud.

This stage is when the software has been rolled out and is being used for its intended purpose. Training and maintenance costs are some of the costs that should be expensed as incurred during this stage. Kosnac provides accounting, auditing and business consulting services to businesses in both the public and private sectors. He also contributes to EisnerAmper's technology and life sciences blog. The entities falling under the EisnerAmper brand are independently owned and are not liable for the services provided by any other entity providing services under the EisnerAmper brand.