Understanding software capitalization: writing off R&D investments

Software capitalization allows companies to recognize certain software development costs as an asset, rather than an expense. This means the costs of developing software can be spread over the period the software is useful (what’s referred to as its “useful life”), rather than expensing those costs as an upfront lump sum.

There are a number of benefits to software capitalization. In the U.S. and other geographies, capitalized costs, amortized over the useful life of the software, qualify as as a tax deduction. Capitalization also helps a company’s balance sheet, by smoothing expenses over multiple periods. 

“Costs” here include the salaries of the development teams involved, the costs of materials and services used in the project, as well as overhead costs that can be attributed to the project. And this of course underlines the biggest challenge with capitalization: how does a company effectively and reliably tally these costs? As we’ll see, this is where Socratic comes in...

Types of software eligible for capitalization

There are a couple of primary drivers for understanding which costs may be capitalized. The first, of course, depends on the accounting standards being observed—Generally Accepted Accounting Principles (GAAP) for U.S. companies, or International Financial Reporting Standards (IFRS).

The second driver relates to the purpose of software being developed. Is the software to be used internally, or is it being developed for external use, i.e. for customers?

Internal-use software

Internal-use software is developed to be used specifically within the company’s internal team. It is not meant to be exported or given out to other companies or individuals, but rather an application that helps the inner workings of the company or organization.

GAAP’s guidelines state that costs for internal-use software can be capitalized at the development stage. This is after the preliminary stage, which includes ideation, feasibility studies, and research into the project itself. Once the preliminary stage is complete and development commitment is made, capitalization begins. 

Note that there’s an implicit expectation that the software being developed is technologically and economically feasible. This means you can’t proceed to create something that you know you won’t be able to finish, or for which the economic value is unclear. Since companies aren’t in the habit of investing in projects they know won’t finish, or that have no demonstrable value, the feasibility of internal-use software is taken more or less as a given.

For external-use software, it’s a different story.

External-use software

External-use software is built for use outside the company, whether that means the software is being sold, leased, or simply used by external parties.

With internal-use software, capitalization begins at the development phase. For external-use software, capitalization can begin as soon as the project is deemed technologically feasible. This means, in effect, that the company has the resources and capabilities necessary to make the software a reality.

Let’s take the example of a software startup. Time spent fundraising? Not capitalizable. What if that fundraising includes building a working prototype of the product in question? Nope. Without the money and the team to pull it off, you can’t yet make a case that your project is technologically feasible. In essence, GAAP says that you can capitalize only those development efforts likely to result in a marketable product.

Accounting for software development costs

By GAAP standards, internal-use software development costs become capitalizable when the development stage is started. This means all preliminary activities—feasibility studies, cost models, user surveys, etc.—are complete. The transition to capitalization also requires a commitment to funding the software development, which is a clear indication that the project is expected to proceed and be completed.

For external-use software, GAAP allows for capitalization of costs once there’s a completed design or prototype: a “working model.”

IFRS says that for internal-use software, capitalization can begin when there is a clear intention and commitment to complete the development, including adequate resources for completion (money, people, tools), and you can reliably measure the costs involved in developing it. For external-use software, IFRS allows for capitalization of costs that follow a detailed business plan and some level of working functionality, though a full prototype may not be necessary.

Both standards allow for the capitalization of some post-implementation costs. For instance, you can’t capitalize costs for employee training (internal-use software) or marketing (external-use software). But costs for major changes—i.e. beyond bug fixes or small enhancements—are capitalizable.

Since software capitalization requires that companies “reliably measure the costs” of development, this begs the natural question: how? If development teams are wholly committed to capitalizable work, the job is reasonably straightforward. It’s the sum of their salaries for however long initial development lasts.

But things are rarely this simple. More often, teams are working on a myriad of different initiatives, and even within those initiatives some work may be capitalizable (material new features, say) while other work (bug fixes) is not. Asking developers to recall how much time they spend on what kind of work isn’t a realistic approach—and yet timesheets refuse to die. 

Socratic's Allocation capability analyzes your Jira work activity data to show you what kind of work was done, by whom, when and where. This means you can see, for any time period, the investment by person, team, and type of work. You can even see how investment trends are changing over time—by month, quarter, or any period you choose.

I've heard software capitalization described as "free money." There's truth in that—but only if you let data take the place of the old report-and-spreadsheet approach.