Periodically we get asked by our clients about the accounting treatment for the software development costs to develop the services they sell and the sites they use for commerce. We recommend in most cases that companies expense research and development (R&D) in the current period rather than capitalizing the cost and amortizing over a longer period. There are multiple reasons that this is a relatively standard approach in scaled SaaS businesses which we will outline. In this post we will walk through accounting regulations that apply to software that a company sells or leases to customers (a company’s products). We will not address internal use software (employee facing, IT owned solutions) which is subject to its own accounting guidelines.

Matching Principle

The application of accounting rules to the cost to develop a technology solution is in alignment with the accounting concept of the Principle of Matching (matching principle defined) which is the foundation for accrual-based accounting to which US GAAP and IFRS adhere. The idea behind this principle is to match expenses with related revenues in order to report a company's profitability during a specified time interval. The linkage is based on a cause-and-effect relationship, for example sales causes the cost of goods sold expense and the sales commissions expense.

Now let’s rewind briefly to link the principle of matching to the origins of accrual accounting itself. Why does it matter and when it did come to be? Some of the earliest more formal investment vehicles were related to shipping expeditions in the 1600’s for exploration and trade. The Dutch were prolific traders during this period and undertook many expeditions. Initially, each voyage was planned, financed and executed as a one-off and would take years from the point of funding to mobilizing, building the ship, hiring a crew, setting sail and returning with the goods (or sinking!). Investors in a voyage couldn’t dissolve their investment until the voyage returned and received very little information about the success or failure until the ship’s return.

It was hard to scale the global shipping trade with this one-off voyage high risk funding approach and loooonnnnggg timeline. What to do? Big government to the rescue! In 1602, the Dutch government changed the landscape by sponsoring the creation of the Dutch East India Company (Verenigde Oost-Indische Compagnie). 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. Guidance is set by the current version of the Financial Accounting Standards Board (FASB) ASC-985. These rules were updated in Statement 86 and came into effect at the end of 1985 (FASB ASC-985, statement 86) .

Waterfall Methodology and Capitalizing R&D

Under Topic 985, the critical issue in determining whether external-use software development costs should be capitalized revolves around the term “technological feasibility.” Any software development costs that are incurred prior to the point where the project has demonstrated technological feasibility should be expensed as they are incurred (e.g. design, analysis, prototyping) because these are experimental/exploratory and don’t constitute the enduring value of building the product for sale to customers. 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. It was also normal to do more up-front design and analysis work to establish technical feasibility, again as its own distinct phase. But now we live in an agile world, where almost all companies strive to release new feature functionality frequently, some every second or minute – and some every quarter or annually depending on their capabilities and their type of product and customer. But suffices to say everyone is trying to become more agile in order to survive and thrive as the pace technology and business change accelerates and that means improving time to market and frequency of customer value adding releases.

An agile world looks more like the figure above, where all phases happen in every iteration and separating the level of effort of design/dev/test/fix at the sprint level is challenging if not close to impossible to do accurately. Furthermore, companies develop applications with an infinite life that are constantly innovating and evolving.

So back to the question of accounting for the cost to develop an application that will be sold to customers - like many things in life the question of CAN you do something is a different question than SHOULD you do it. Let’s first look at how the cost of developing an application impact the company’s overall financial position based on either scenario consider the pro’s and con’s.

Agile World and Expensing R&D

Following is a simple illustrative example comparing the Balance Sheet and Income Statements of ACME Company in the case where they DO and DO NOT Capitalize R&D (DO NOT = they expense all R&D cost in the current period) to show the ripple through effects of the two different approaches to R&D cost treatment on a company's financial statements.

Pros & Cons of Capitalization vs. Expensing R&D Costs

Now that we see the financial position difference, let’s consider the pros and cons of capitalizing R&D expenditures in order to develop a philosophy and point of view for our own products.

Pros of Capitalization

If we are building a truly technologically new application that will provide foundational business value for many years, capitalizing the core of the development effort may be of value and accurate to categorize as a Balance Sheet asset of enduring value that is amortized over time and therefore incrementally matched with sales of said product.

Cons of Capitalization

Additional book-keeping is required in order to satisfy accounting standards and withstand potential audits. Book-keeping and documentation are not bad things in and of themselves. However, under Agile development processes documentation and tracking needed for accounting purposes is often much more than would be ideal to meet the spirit of an agile framework. For example, separating out time spent on design vs coding vs bug fixing within one sprint for a given feature may be tedious if not impossible to do accurately. Following are some of the areas to consider:

  • Capitalizing will require engineers track their time
  • Time must be tracked by phase of work consistent with FASB guidelines which means more detailed tracking than is normally optimal (Note AKF is a proponent of tracking engineering effort but only for the purposes of optimizing business outcomes – think aligning investment to portfolio priorities - and balancing with ongoing application quality and overall health)
  • Capitalizing means you must ensure detailed proof of establishing technology feasibility, again – which may be more than is optimal in an agile context and may just not even be appropriate for the vast majority of application development that is sustaining innovation on a well understood technology platform
  • For capitalized software development in a public company, the engineering team will also have to evaluate the asset being depreciated EVERY quarter to assess impairment, i.e. to certify that the value of the application still exists and is in use with customers
  • Public companies will set materiality levels for capitalization and subsequently follow those guidelines. I have seen as a result based on the desire to capitalize, they adjust release size of new features in order to adhere to the self-imposed threshold, which can also create perverse outcomes like increasing time to market for a significant new feature - primarily for the purpose of adhering to their own financial engineering rules – tail wagging the dog comes to mind!

Now that we understand the financial impact and pro’s/con’s to capitalizing R&D, let’s look at how some of the most successful and innovative companies in the world think about this topic – what do google, Amazon and Facebook do?

GOOG 1-K Q4 2020 – NOPE they don’t capitalize R&D!

How about Amazon?

AMZN 10-K 2020 – NOPE – they don’t capitalize R&D!

And how about our friends at Facebook?

FB 10-K Q4 2020 - NO – they don’t capitalize R&D either!!

Now where does this leave us as far as guidance on the capitalization of external use software development costs? Although there may be exceptional cases where it makes sense to capitalize engineering effort, for most ongoing sustaining innovation, where a product is constantly evolving and the company strives for agility in its business and its approach to product development, then the company should expense the cost to develop software it sells as it reflects appropriately the matching of revenue to cost in a world where an ever improving product drives incremental sales for a (hopefully) infinite period of time.

Why not? Your software is not usually new and novel! Building on and evolving successful products is never “done” – in most cases you are doing sustaining innovation and rapidly experimenting to discover customer wants – hard to even know which features will have multi-year enduring value that will drive revenue!


At its VERY worst – I have seen companies capitalize primarily in order to improve short term Profit and Loss (P&L) of a product with a low margin and/or poor top line growth. This allows for larger near-term investment in new features with less impact on the current P&L than if ALL or most of development was expensed in the current period. This is because the company puts more of the investment on the balance sheet and incrementally amortizes this asset each quarter on the income statement – which drives the P&L financial view including EBIT, EBITDA which are commonly used by Financial Analysts and Investors to assess a businesses’ health.

However if you are capitalizing R&D in order to show a healthier near term EBITDA and your investors don’t understand that (i.e. they can’t read and understand financial statements) then there is an argument that you and your investors ‘deserve each other.’ And although capitalizing R&D may improve a businesses’ financial health in the near term if this approach continues year after year without the corresponding top line revenue growth, then guess what – you end up with the same operating margin eventually based on the gradual accumulation of the same larger expense line on the Income statement as waves of amortization compound on one another. AND it also eventually becomes harder to impact the overall cost profile of the application in the short term since the depreciation line is a large albatross that cannot be changed unless you impair or retire the application and write it off! CASH IS KING!

Key take-aways:

  • Don’t capitalize R&D costs for most ongoing product innovation investment
  • Capitalization introduces additional hassle for no value
  • Capitalizing R&D is difficult to do well in an agile context
  • Capitalizing ongoing R&D comes home to roost anyways if you do it on an ongoing basis, since the drag of depreciation is layered on quarter on quarter on the Income Statement, and this practice actually removes degrees of financial and investment agility down the road if you do want to change product investment levels more quickly (unless you retire or impair the product)

We've helped dozens of companies of all sizes improve their technology and strategic leadership approach. Contact us, we can help!