Comment by PaulDavisThe1st
2 years ago
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.
> Just tacking it onto the "R&D" category really serves no-one very well at all.
Well, it is called Research and Development. Perhaps that is the right place for it? :)
But your point about it being tacked on is well taken. However, I don’t think this problem is unique to this instance. It’s similar to updating software. When you update the law, you often have to tack things on and find a way to make it fit.
To their credit, the IRS has taken pains to define what constitutes software, as well as to differentiate between what is merely maintenance—including bug fixes and so on—and what constitutes upgrades and enhancements. They’ve specified this quite clearly in the guidance, which perhaps addresses your concern about distinguishing these different activities.
You acknowledge that there is certainly software that companies create and then use or license to others, providing them with long-term value, much like an asset. However, you also suggest there’s a lot of software that doesn’t serve as a long-term asset.
I’d be interested in examples of the type of software that doesn’t provide that long-term value.
4 replies →