Capitalizing costs of software development

What to do? Big government to the rescue! The new company had monopoly powers to trade with Asia as far as the Dutch were concerned although not all of their neighbors were on board with this. Regardless, now the company no longer focused on each individual journey, instead it reported its accounts periodically, which resulted in the development of accrual accounting. This was the early days of corporations with potentially infinite lives.

To expand investment, there must be a way for the entity to be valued periodically; valuing the company at points in time where multiple voyages are mid-flight and not just when any given voyage ends. For the Dutch East Indian company their initial investment horizon and periodic reporting was every 10 years — perhaps that period would help our current markets too!

Debates about the optimal reporting period for current day public companies aside, accrual accounting is based on reflecting economic events when they happen rather than only when cash exchanges occur. Fast forward to present day and we can now look at how these principles relate to costs associated with developing software-based products.

First let us understand what US GAAP accounting standards say about capitalizing software development costs for products a company sells externally. The engineering effort to actually build and initially test the product is capitalizable, however, the time spent in fixing defects as well as ongoing maintenance and support post release are not capitalizable and therefore also must be expensed in the period incurred. In a waterfall world it was easier to align development cost to these sequential phases.

This article is designed to help readers answer this question: Which software costs should be capitalized and which costs should be expensed when an entity builds external-use software using an agile development environment?

The software development method known as agile has become popular in the software industry in recent years. The conventional waterfall development approach involves organizing a project into a series of traditional phases, such as conception, initiation, analysis, design, construction, testing, production and implementation, and maintenance.

These phases are marked by activities, which the guidance uses as a framework to make a conclusion on when technological feasibility is achieved and software development project costs can be capitalized.

Under an agile model, on the other hand, a project is organized into separate modules, and the development and testing work on these modules is done in short sprints. Identifying when the traditional activities of the waterfall approach occur requires significant analysis and judgment in agile development, which can make it more difficult to apply GAAP guidance for capitalizing expenses.

Ultimately, both the agile and waterfall models can produce a successful project; however, determining the point in the software development process to begin and end capitalizing costs can be more challenging with the agile model.

As a starting point to appropriately capitalize software development costs, it is important to determine the proper guidance. Under U. GAAP, two potential sets of major rules may apply when determining whether software development costs should be capitalized or expensed. These rules, commonly referred to as the software capitalization rules for external-use software, are the primary focus of this article.

The other set of rules ASC Topic , Intangibles — Goodwill and Other governs software that the entity does not intend to sell or lease. These rules commonly are referred to as the software capitalization rules for internal-use software.

It is important to note that the threshold for capitalization is lower for internal-use software. Under the internal-use software rules, development costs generally can be capitalized after the end of the preliminary project stage. The threshold for software development costs for external sale or licensing — the focus of this article — is more stringent, which means more analysis is required to determine which development costs should be capitalized.

Once technological feasibility has been established, most but not all development costs can be capitalized. 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. When software is developed for sale, or external use, the accounting treatment differs slightly.

The capitalizable and non-capitalizable costs are still delineated by where or when in the process they occur, but the guidance becomes more granular. Costs to develop external-use software are not capitalizable until the software is declared technologically feasible. Technological feasibility is determined after planning, designing, coding, and testing. If these preliminary steps lead to a realistic product, the remaining development work for features and functionality — from both internal resources and third-parties — can be capitalizable.

Software to be used internally is determined to be an intangible asset and considered to be in scope under GASB GASB 51 allows for costs related to the application development stage of software creation to be capitalized. The application development stage is looked at as the stage after the product has been determined to be technologically feasible but before maintenance and ongoing operation.

Installation, testing, and parallel processing are deemed to be application development activities, but training is defined as a post-implementation activity. External-use software, or software developed for market, is excluded from the scope of GASB 51 and should follow the guidance for investments, GASB 72 Fair Value Measurement and Application , as an asset held by the government primarily for the purpose of profit.

Investments under GASB 72 are generally measured at fair value. The more recent changes to software and its use have been related to a movement towards cloud computing arrangements and software subscriptions.

With these types of arrangements, an organization is not purchasing a specific software, but instead a license or subscription to use the software over a specific period of time. Additionally, as technology has evolved the licenses or subscriptions have moved to being available over the internet or in the cloud.

Under ASC certain implementation costs for cloud computing or hosting arrangements can now be capitalized. The standard was written to mirror GASB 87 in that once an organization determines they have a SBITA within the scope of GASB 96, they establish a subscription asset and subscription liability based on the total expected payments to be made over the subscription term.

We have published an article summarizing the accounting concepts of GASB 96 and an article with a comprehensive example of applying GASB 96 for further explanation of the accounting treatment proscribed in the statement.

Today: Modern SaaS companies update their products constantly. Conclusion: We wrote our first blog post on this subject a few years back, and this blog post will be our last on the topic. SaaS Capital. We can make quick decisions. Learn more about our philosophy. Read More. Essential SaaS Metrics: Revenue Retention Fundamentals SaaS Capital explores the key SaaS metrics: net revenue retention, gross revenue retention, customer count retention, monthly churn, and cohort analysis.

View More.