Periodically, our clients ask us about the accounting treatment for the software development costs to develop the services they sell and the sites they use for commerce. In most cases, we recommend that companies expense research and development (R&D) in the current period rather than capitalizing the cost and amortizing over a more extended period. There are multiple reasons that this is a relatively standard approach in scaled SaaS businesses, which we will outline.

Let's walk through accounting regulations that apply to software a company sells or leases to customers (a company’s products - not internal-use software). 

MATCHING PRINCIPLE

The “Principle of Matching” means that expenses should match the income generated within a specific period. In other words, you record expenses when they lead to revenue.

Historical Background

The historical foundation for the matching principle is related to shipping expeditions in the 1600s for exploration and trade. The Dutch were prolific traders during this period. 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 successfully with goods – or not returning at all (sinking, pirate looting, etc.).

Understandably, it was challenging to scale the global shipping trade given the potential for a one-off failed voyage, a high-risk funding approach, and loooonnnnggg timeline.

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). Under this company, the focus shifted from individual journeys to periodical accounts of accumulated journeys, resulting in the development of accrual accounting.

The assumption was that corporations had potentially infinite lives, thus requiring a way for a company entity to be valued periodically. A snapshot in time would need to quantify multiple voyages mid-journey and not just when any given expedition ends.

For the Dutch East Indian Company, their initial investment horizon and periodic reporting was every ten years. Debates about the optimal reporting period for current-day public companies aside, accrual accounting examines economic events when they happen rather than only when cash exchanges occur.

Accrual accounting records financial transactions when they are earned (revenue) or incurred (expenses), regardless of when the actual cash exchange occurs, providing a more accurate picture of a company’s financial performance than cash accounting.

Applying To Our Present Day

So, how do we translate this to developing software-based products?

US GAAP Financial Accounting Standards Board (FASB) ASC-985 Statement 86 informs capitalizing software development costs for products sold externally.

WATERFALL METHODOLOGY AND CAPITALIZING R&D

Under ASC-985, any software development costs incurred before demonstrating technological feasibility must be expensed as they are incurred (e.g. design, analysis, prototyping, etc.). The rationale is that the costs are experimental and exploratory and do not constitute the enduring value of building a customer product for sale.

It is easier to align development costs to these sequential phases in waterfall software development with clear starting and stopping of each step. Waterfall also defines up-front design and analysis work to establish technical feasibility as a distinct phase.

As e-commerce and other companies have moved to an Agile ongoing development and release of products to provide more instantaneous customer value (often multiple releases a week if not a day or hour), the phases are more challenging to define.

AGILE WORLD AND EXPENSING R&D

An Agile software development world resembles the figure above, where all phases happen in every iteration. Separating the level of effort of design/dev/test/fix at the Sprint level is challenging – if not close to impossible – to do accurately. And with companies developing applications with a seemingly infinite life, constantly innovating and evolving, how do we best match costs and revenue? 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 impacts the company’s overall financial position based on either scenario and consider the pros and cons.

A simple illustration below shows $150k in software product investment to build something that could be capitalized if you choose to do so. Let's see how this impacts the Income Statement as capitalized vs. expensed. 

PROS & CONS OF CAPITALIZATION

Pros of Capitalization

  • Improved Financial Statements: When development costs are capitalized, they are not immediately expensed on the income statement. This results in higher initial profits and an improved net income in the short term.
  • Balance Sheet Enhancement: Capitalizing costs adds an asset to the balance sheet, which may improve the company's financial ratios, such as the return on assets (ROA) or debt to equity. This can be particularly beneficial when seeking financing or investment, as it shows a company has more assets.
  • Tax Benefits: By capitalizing and then amortizing the development costs, a company may be able to defer some tax liabilities, as the expenses are recognized over a period of time rather than immediately.
  • R&D Credits: In some jurisdictions, capitalizing development costs may be required to qualify for research and development tax credits.

    Cons of Capitalization

    • Administrative Drag on Engineer: Capitalization requires each engineer to be capable of recording and coding their efforts for designing, coding, and fixing bugs within a Sprint. The accounting benefit of capitalization may not be worth this additional effort. (AKF Partners is a proponent of tracking engineering efforts, but only to optimize business outcomes!).
    • Audit Risk: Capitalization adds the risk of potential audits and engineers having to justify later which efforts apply to initial product development versus upkeep and bug fixing.
    • Feasibility Justification: Capitalizing means ensuring detailed proof of establishing technology feasibility.
    • May Slow Time-to-Market: For public companies, you must also depreciate EVERY quarter to certify that the value of the application still exists and is in use with customers. This can lead to adjusting the release size of new features to adhere to the self-imposed threshold, resulting in slower time to market – tail wagging the dog comes to mind!

    Top Technology Company Approach

    With these pros and cons in mind for capitalizing on R&D, let’s consider how some of the world’s most successful and innovative companies think about this topic using their financial reporting from 2018 - 2020.

    How about Alphabet (Google)? 

    NOPE. They do not capitalize!

    What about Amazon?

     NOPE, they also do not capitalize R&D!

    Okay, let's look at Facebook ...

    Three strikes – they additionally do not capitalize R&D!

    For most ongoing sustaining innovation, a company should expense the cost to develop software it sells as it appropriately reflects the matching of revenue to cost in a world where an ever-improving product drives incremental sales for a (hopefully) infinite period.

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

    CONCLUSIONS

    At its very worst – I have primarily seen companies choose to capitalize software development costs to improve the short-term Profit and Loss (P&L) of a product with a low margin or poor top-line growth.

    Capitalization of R&D costs puts more of the investment on the balance sheet. It incrementally amortizes this asset each quarter on the income statement – which drives the P&L financial view, including EBIT, and EBITDA, which financial analysts and investors commonly use to assess the health of a business.

    Suppose you are capitalizing R&D to show a healthier near-term EBITDA to try and pull the wool over your investor’s eyes (assuming they do not read or understand financial statements). In that case, there is an argument that you and your investors deserve each other.

    While there may be short-term financial benefits, continuing to capitalize development costs year after year without 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 more extensive expense line on the Income Statement as waves of amortization compound on one another).

    It also eventually becomes more challenging to impact the overall cost profile of the application in the short term since the depreciation line is a giant albatross that cannot be changed unless you impair or retire the application and write it off! CASH IS KING!

    Key takeaways:

    • Do not capitalize R&D costs for most ongoing product innovation investments.
    • Capitalization introduces additional hassle for little to no value.
    • Capitalizing R&D is challenging to do well in an Agile context.
    • Capitalizing ongoing R&D comes home to roost eventually if you do it on an ongoing basis since the drag of depreciation is layered quarter-on-quarter on the Income Statement. This practice removes degrees of financial and investment agility if you want to change product investment levels more quickly (unless you retire or impair the product).