Comment by keepamovin
2 years ago
One could argue that the tax approach outlined in Way #2 rightly adjusts for the longstanding discrepancy where software development costs, particularly salaries, have been treated as immediate expenses rather than capitalized investments in software IP—an asset with enduring value. The explicitness in software development and employment contracts about the creation of IP suggests this capitalization is a reflection of actual business transactions, making the tax treatment more aligned with economic reality.
This change might not be as much an undue burden as it is a logical extension of tax principles applied across various industries. From this perspective, the software industry's ability to immediately expense these costs could be viewed by other sectors as an inequitable advantage, one that is now being corrected.
While the apprehension around these changes is understandable due to the added complexity and potential for increased tax liabilities, it's worth considering that some of the more intense reactions could be driven by a concerted effort from larger entities aiming to generate grassroots resistance against the new rules. It’s conceivable that the IRS, aware of the potential burden on smaller companies, might enforce these rules with a revenue threshold, thus sparing smaller enterprises from the need to capitalize software costs.
Moreover, it's crucial to recognize the benefits of capitalizing software expenses: it affords companies the opportunity to match tax deductions more closely with the productive life of the software. This can lead to a smoother tax liability schedule and cash flow, particularly advantageous for companies with consistent earnings and those that stand to gain from representing their software development efforts as capital assets on their balance sheets.
A major issue is that in many cases most of the software asset value is explicitly conditional on the continued involvement of the people that created it. The value of the code base is orthogonal to its existence. I’ve seen this pattern many times in software IP licensing (or startup acquihires).
There are many instances where companies buy the team that created software rather than the software itself because so much of the value resides there. For obvious and good reasons, a company has no ability to claim a team as an asset because they have little control over its disposition since people are free to work when and where they want.
The continued erosion of enforceability of non-competition in employment contracts, which I agree with as a matter of policy, aggravates this situation in that the company has few levers to ensure that software development has asset-like characteristics. Large companies with many revenue producing software products can amortize the risk but the great many small shops with a single software product cannot.
This is a fantastic point that I think the IRS needs to consider. Have you thought about how this reality interfaces with the seemingly incoming new regulations? How could they be made more fair, in other words more reflective of this reality you identify?
I agree that you could argue all these points.
I have to agree, because I don't agree with any of them :)
While the actual duration of software value is neither the day it was created nor "forever", the idea that a fixed amortization schedule is appropriate seems clearly wrong to me. Even crazier that it would depend on the geographic location of the person who did the work.
The productive life of any particular blob of source code is an awfully complicated thing to talk about, and the idea that the tax code should attempt to incorporate such a concept into a relatively simplistic rule (or pair of rules) seems faintly ludicrous to me.
> The productive life of any particular blob of source code is an awfully complicated thing to talk about
The IRS does this all the time. Code isn’t some special magic enigma, businesses depreciate property, trucks, aircraft..all of these are equally as complex as code or significantly more complex to value over time. Usually it’s simplified to some degree for practicality, as I’m sure this will be.
I completely agree with that! One requirement of effective taxation is having this granular, high-resolution inspectability of economic activity, but also keeping it abstract and general enough that it can be more efficiently be used a large number of diverse businesses.
I understand :)
So you think software development costs should not be capitalized, right? What makes you say that?
I think it's more complicated than that. Some software is developed and then provides value to the company that owns it in a way that is clearly comparable to other capital investment. But lots of other software just isn't. There's also the problem of differentiating between ongoing work that is supposed to just be "maintenance" and essentially identical work that is "updates" and "new features". Even at the code level it is not always easy to tease these apart.
Also, the change to Sec 174 is related to R&D expenditures. This is also another aspect of trying to fit a multiheaded hydra into a small sphere: yes, some software development does share many similarities with R&D activities, but lots of software development does not (unless you label R&D in a way that is so broad as to encompass just about anything).
If the US wants to force amortization on software development expenses, I think that should be stated more explicitly, and with a much more detailed rationale. Just tacking it onto the "R&D" category really serves no-one very well at all.
5 replies →