For many years, the industry-wide standard practice for calculating and reporting software engineering R&D projects expenses was simple — everyone accounted for the project’s activities exclusively in the current period.
The alternative is to capitalize the cost and amortize it over a longer period of time. This allows organizations to improve their balance sheets, gain tax benefits, and even earn R&D credit subsidies in jurisdictions that offer them.
However, applying cost capitalization to an R&D software engineering context is not always simple. Many engineering leaders think it drags down individual performance, increases audit risks, and slows down project timelines.
This is no longer the case. Emerging advances in automating development projects and reporting are changing the way engineering leaders approach cost capitalization. Many of the challenges associated with capitalizing Agile software development tasks can now be addressed with highly automated software reporting. This opens up opportunities for engineering leaders and key stakeholders to treat R&D projects as revenue-generating assets instead of pure expenses.
At its core, R&D cost capitalization is a simple concept. Instead of listing software R&D costs as expenses on the company’s balance sheet, you treat them as investments.
Accountants treat capitalized costs differently on the company’s balance sheet. Instead of recognizing the cost as a single lump sum spent at one particular time, the cost is distributed more evenly over multiple periods of time as long as the asset generates revenue.
Most executives, stakeholders, and engineering leaders would agree that software R&D projects are in fact investments. According to one report, the average software company spends up to 20% of its revenue on R&D.
The problem isn’t that people don’t see R&D projects as investments. The problem of cost capitalizing software R&D expenses comes from a different place altogether — the difficulty of matching accounting principles with outdated development methodologies.
Under the US Generally Accepted Accounting Principles (GAAP), three criteria must be met for costs to be capitalizable. They must be:
This means that internal-use software and external-use software must be capitalized differently. Internal-use software can be capitalized entirely, while only costs incurred in the technological feasibility and development stage can be capitalized for external-use software. Initial planning and prototyping is not covered.
The traditional Waterfall development methodology has multiple distinct steps that are followed sequentially. Only two of these phases can be cost capitalized for software development projects designed for external use under the GAAP:
Other steps, like identifying requirements and specifications, creating designs, post-release bug fixing, and maintenance cannot be capitalized.
Under the Agile method, each phase of the development process happens simultaneously. Separating design, development, testing, and fixing costs at the Sprint level requires changing the way developer performance is measured on a fundamental level.
Essentially, every engineer must be capable of recording and coding their efforts during a Sprint. They must be prepared to explain which efforts apply to initial product development and which ones represent upkeep and maintenance, while maintaining detailed proof establishing technological feasibility.
If developers have to complete these tasks manually, engineering performance and time-to-market will be slower. The accounting benefits of capitalization may not adequately outweigh this additional performance drag.
However, this is a technical problem, not a fundamental problem. It is the perfect use case for highly automated software capitalization and cost reporting software to prove it makes a significant difference.
GAAP practices were invented at a time when software companies primarily followed the waterfall model. But as the software development lifecycle becomes less linear, engineering leaders are under pressure to find better ways to account for their teams’ activities.
The first step is quantifying software engineering work in ways that align with GAAP methods. Engineering leaders must often work on multiple projects at once, which makes it difficult to log work hours manually. Many turn to Jira issues that include human resources outputs that provide capitalizable costs, but these are still time-consuming and error-prone.
Instead of giving developers even more responsibilities and creating a prohibitive, expensive tracking culture, software engineering leaders need to deploy solutions that automatically capture data-driven engineering analytics and provide objective real-time tracking of engineering work and spending.
This requires making collaboration and transparency part of the way engineering teams work. However, the benefits of software capitalization far outweigh the costs. Some of the benefits of R&D cost capitalization include:
Software cost capitalization is a great way to improve the cost structure of software engineering projects under strict GAAP rules. Applying capitalization to software R&D efforts ensures that the organization treats its R&D program as a revenue-generating investment instead of a pure cost. When done correctly, this approach can transform the way the software R&D team works.
The Waydev platform helps software engineering leaders visualize and project costs using key performance metrics that accurately reflect the value of development time worked in an Agile context. It provides the insight leaders need to increase development velocity and maximize the business impact of R&D projects while minimizing costs.
For example, Waydev’s Resource Planning report allows leaders to support software engineering projects, improve team dynamics, and optimize the allocation of engineering resources. The Project Costs report correlates data from your issue tracking system with payroll data, providing visibility into how much money the organization is spending to meet project goals.
Ready to improve your SDLC performance?
