Most of the arguments from startup people about these rules come down to "this change costs me a lot of money" rather than "this change is bad accounting." Does anyone know what the arguments are to support the latter?
When this rule was changed, it was framed as eliminating a tax loophole: R&D work is basically a capital investment, since you are effectively buying and improving intellectual property during the R&D process. That suggests that this sort of expense really is a capex that should be depreciated over the life of the intellectual property rather than an opex. I personally think that this is a compelling line of reasoning.
I think there's a good argument that a forced 5-year amortization schedule is far too long for something like a random SaaS, but I'm not sure if I have a good argument that this is bad accounting otherwise. I don't expect that the IRS will be all that sympathetic to Silicon Valley complaining that one of their favorite loopholes is gone otherwise.
The accounting argument is that not all software development is R&D work or creating an asset with long-term value. A lot of it is operational work or closely tied to the revenue that pays for it (so analogous to COGS.)
There is also an accounting and tax principle that small/solo businesses should be able to maintain simpler books that let them reliably feed their families year-to-year; an sudden upfront tax burden for a solo dev impedes that.
There is also plenty of "R&D" that has only short-term value.
If you make a spam filter, you have to spend resources making sure it can defeat the spammers, but the lifetime of your countermeasures is often measured in months or weeks rather than years.
You may have to pay developers to integrate your product with a third party product, but there is a new version of the third party product released every year so every year you have to do it over again.
> There is also an accounting and tax principle that small/solo businesses should be able to maintain simpler books that let them reliably feed their families year-to-year; an sudden upfront tax burden for a solo dev impedes that.
And the correct accounting period to amortize a particular expenditure may not be known in advance. If you build a product and it has unanticipated flaws that require you to start over, the lifetime of the original R&D is trivial. Or it could be a success and generate revenue for decades.
The IRS gets their money either way, whether it's now or tomorrow, but if in cases of ambiguity they insist on now, the disadvantage is primarily to early startups. Large corporations with a stable R&D budget will be deducting their full R&D expense every year because they'll have R&D expenses from five years ago to deduct this year, but anyone just starting out won't. That's a poor choice as a matter of policy.
The disadvantage is not just to early startups. I have ownership in a 9-year old small software company that has never taken investments and has managed to break even or be slightly profitable every year while growing. We reinvest revenue into a team that keeps improving the product.
In 2022 our reported "taxable income" to the IRS skyrocketed because of this rule change. Despite a small profit, we are paying tax on essentially 50% or more of our REVENUE. And because we are a pass-through entity, it pushes us into tax brackets that are quite ae bit higher than corporate tax rates of C-Corps.
2 or 3 years into this we will either have to take a loan to pay taxes, find a way to cut expenses, or (hopefully) grow enough in revenue while not increasing expenses to cover the additional tax.
It really is insanity. Our accounting firm and everyone they spoke with was convinced it would be "fixed" by congress before the final extension deadline a couple months ago. So we waited to the last minute to file, which, of course, resulted in significant late fees and interest on top of everything else.
As I understand it, under the current rules, you can classify maintenance work as an opex. You just can't argue that development of new software is an opex.
I think it's bad accounting to treat all software development as creating capital assets; some of it clearly is, and should be treated as such, although maybe 5 or 15 years is not the right amortization schedule for software.
I like to use the factory analogy - if you're Ford, and you build a big factory to build cars, that's a capital asset, you need to amortize the costs. But the workers inside, making each car? Their wages are expenses, tracked against the revenue of the cars they make. So - if you make a game engine, that'll be used over the next decade or two, that's a capital asset. If you make a game, that'll see 95% of its revenue in the first year, you should be able to expenses the costs (including salaries) of making it.
(1) Capitalization is for tangible assets with a useful life and some liquid value. You can't meaningfully monetize the R&E of every engineer.
(2) If you analysis held at all you could pull forward the deprecation if you abandon the research, which might be viewed like disposing of the asset. You cannot do this under this law.
(3) This increases the total cost of R&E work substantially. It is a disincentive to innovation.
I don't think the issue is bad accounting. I think it comes down to software being uniquely different than a factory or piece of equipment. Amortization schedules that are even don't make any sense. Neither does anything measure in years. It's because we make improvement to software on a day by day basis. We don't necessarily add on to a factory every day.
For me personally, the 'bad accounting' comes into play with contract work. You build some widget for customer, and if it's anything less than work-for-hire (i.e. you give customer a commercial license but retain copyright or some right to reuse your code in the future), that was research and gets amortized. Think like building or just modifying a Bootstrap template -- is that really "research"?
Maybe it's not concrete, but it feels like there's a difference between investing capex into a planned future product, and retaining some rights in the work you create for others.
"Intellectual property" is a huge misnomer and it should not indicate that software development is a "capital" investment.
If you disagree, I'm curious what you think about this: if the software you develop is all open source would you still call it a capital investment? Maybe it could be classified as a charitable contribution?
When this rule was changed, it was framed as eliminating a tax loophole: R&D work is basically a capital investment, since you are effectively buying and improving intellectual property during the R&D process. That suggests that this sort of expense really is a capex that should be depreciated over the life of the intellectual property rather than an opex. I personally think that this is a compelling line of reasoning.
I think there's a good argument that a forced 5-year amortization schedule is far too long for something like a random SaaS, but I'm not sure if I have a good argument that this is bad accounting otherwise. I don't expect that the IRS will be all that sympathetic to Silicon Valley complaining that one of their favorite loopholes is gone otherwise.