New IRS R&E Rules Risk Stifling Software Innovation for Startups

The IRS’s September Notice 2023-63 clarifies the definition of software development for purposes of current year expensing, encompassing nearly every aspect of the software development process. In doing so, it’s requiring most related expenses be amortized.

This is a major problem for so-called “bootstrap” software developers, or those that fund their development without access to typical streams of capital. Exact numbers vary, but many of these types of developers don’t make it to the five-year mark.

Those startups, which typically self-fund or have an informal investment process, need to be able to expense their software development costs. For many, this may encompass a good portion of their total expenses in the year in which they’re incurred.

Section 174 of the tax code permits businesses either to deduct in the current year or amortize research and experimentation expenditures. There are individual taxpayer-specific reasons to prefer amortization, or capitalization, over a period of years—but most taxpayers would prefer the ability to take expenses in the current year, and not have to wait to recoup outlaid costs over the statutory five or 15 years required.

Upgrading by Downgrading

Occasionally a new piece of software, bug fix, or upgrade will introduce new issues that outweigh whatever improvements are made. In those cases, the solution is often to simply roll back to an earlier version.

In years prior to 2022, Section 174 allowed for the current deduction of research or experiment expenditures, including those related to software development. Developers had hoped first that the changes made by the Tax Cuts and Jobs Act would be repealed and current year expensing returned.

When that deadline passed, they hoped for a restrictive definition of “software development” to allow for most project costs to be expensed. They got neither.

Tax policy ambiguities can arise from changes in the marketplace, which makes any proposed policy solution merely theoretical until implemented and tested. The solution is pretty simple in the case of TCJA changes to research and experimentation expensing, as least as far as software development goes: Revert to pre-TCJA current year expensing.

Under the previous treatment of software costs, development and acquisition were given different treatment through the interplay of Section 174 of the tax code and Reg. Section 1.263(a)-4.

The former permitted development costs to be expensed and the latter required the amortization of acquisition costs as an amount paid to acquire or create an intangible asset. Innovation was “subsidized” and acquisition was treated the same as most capital asset acquisitions.

Now, the ambiguity under Section 174, coupled with the administrative overhead requirement of keeping track of development expenses, creates a situation where some taxpayers may find it advantageous to acquire software rather than develop it—thus discouraging innovation.

They likely will be required to amortize the costs for the software in either case, but the administrative overhead will be significantly reduced in acquisition.

A rollback to pre-TCJA treatment would be a boost for development and effectively leave acquisition tax treatment untouched.

A Microsoft Surface Laptop computer sits in a soundproof anechoic chamber in Redmond, Wash., on April 20, 2017.

Photographer: Mike Kane/Bloomberg via Getty Images

Maintenance Activities

The largest exception to the amortization requirement is the carve-out for maintenance activities that don’t upgrade or enhance software. The necessity for the “upgrades or enhancements” caveat is obvious, as without it, “maintenance” could be the exception that swallows the rule.

However, this leaves open the question of what constitutes “maintenance activities” that “do not give rise to upgrades and enhancements.” While such distinctions—essentially expensable bug fixes and feature upgrades that must be amortized—are simple in theory, reality is more complicated.

Even assuming these stretched definitional arguments are dismissed out of hand, there are legitimate, good-faith questions: What about labor costs for development on a piece of software that enables it to function with a piece of hardware it didn’t previously work on? Would significantly enhancing the security of a piece of software constitute a bug fix that does not give rise to an upgrade or enhancement? How about accessibility improvements that enable the software to work for a broader base of users?

The life cycle of a piece of software isn’t as clear-cut as the notice would seem to assume, and the current administration isn’t going to work in practice. Consequently, either the post-TCJA changes must be rolled back or a more well-considered policy must be implemented—clearly delineating what constitutes maintenance versus feature work.

This may necessitate simply cleaving off as expensable any costs incurred on a piece of software that has already been put in service as de facto maintenance.

Administrative Burden

There’s always a corresponding administrative burden on taxpayers whenever there’s a new distinction in tax treatment. In this case, the developers will need to meticulously track and categorize their activities to differentiate between what can and can’t be expensed in the current year.

This not only increases the complexity of tax compliance, and its corresponding cost, but also demands additional resources and training.

Furthermore, this new gray area all but guarantees differing interpretations of what constitutes “maintenance” that doesn’t give rise to “upgrades and enhancements” between individual firms and developers. This will invariably lead to increased litigation, further straining IRS resources. A repeal, followed by a more clearly drafted amendment to Section 174, could save the IRS more than it stands to recover from this provision.

Prior to tax year 2022, Section 174 allowed for current year expensing of research and development costs, including those incurred in software development, in most instances. This incentivized innovation and development and was particularly beneficial to startups and smaller companies that relied on being able to offset the costs associated with software development in the current year.

If we fail to revisit and revise these changes, we run the risk of stifling innovation—potentially signaling that the golden era of new software development is behind us.

This is a regular column from tax and technology attorney Andrew Leahey, principal at Hunter Creek Consulting and adjunct professor at Drexel Kline School of Law. Follow him on Mastodon at @andrew@esq.social.