I'm guessing that this will result in many employers reclassing many engineers into COGS, S&M, G&A, etc (in other words, not calling their work R&D).
This is relatively easy to do. If an engineer is fixing bugs, helping support team, helping sales in any way, participating in customer onboarding, keeping the servers online, etc, a company can argue the engineer is a cost of doing business rather than true "R&D".
In reality, the % of time most engineers spend exclusively on 100% new products is much smaller than you'd assume at face value. Even at a young startup, I'd guess at most 50% of the work is true R&D.
To reiterate, things like devops, managing infrastructure, patching servers, upgrading code, fixing bugs, professional services, etc... none of that is R&D and it's pretty easy for a small company to say that the majority of their engineering expense is not R&D (extremely difficult for the IRS to argue otherwise if they audit a company unless detailed timesheets are kept).
Edit: I'm not an accountant, but pretty familiar with R&D / IRS stuff
> For purposes of this section, any amount paid or incurred in connection with the development of any software shall be treated as a research or experimental expenditure.
My guess is they'll treat it like repairs and improvements on physical equipment. Fix a broken calculation, that's opex. Add an API for better Google integration, that's capex.
I think that will actually be decided by IRS interpretation. I can’t imagine an administrative judge would have that narrow a view, given the way other assets are treated.
We won't know where the line is until we get guidance from the courts.
A lot of things in real estate that you might think qualify as just maintenance actually have to be depreciated. Like, repairing a roof has to be capitalized since the roof will be around for awhile. The devops equivalent might be migrating from docker swarm to k8s-- the k8s cluster will be around for awhile.
The average roof has a lifespan at least an order of magnitude greater than a k8s cluster. Most roofs being put on today will outlast k8s itself.
Software is a liability, not an asset. Treating the construction and maintenance of this horrible liability knows as “code” is a complete misunderstanding of what software actual is.
It's just an example. Another is paint. The rule is close to but not exactly "if it lasts more than a year it has to be depreciated instead of expensed."
The book value of the k8s work could be completely expensed as soon as it is replaced.
Also, your belief that "software is a liability" is irrelevant. What matters is that tax law calls software an asset (as does most everyone else, even ones who fundamentally understand it).
I agree with you, lots and lots of software definitely has the properties of an asset. There’s also plenty of software that’s hastily written, untested, and basically not fit for use beyond a short expiration date. More like a jug of milk with a shelf life than a fine grand piano with resale value.
The value people produce is an asset. After all, you don't own people, you buy their effort.
A contract can be an asset. Usually the unrealized future value of the agreement has value should you need to make a deemed disposition (or have some other valuation event). It gets very obviously complicated and fuzzy though, which is where accountants make the big bucks. It's pretty rare that a company chooses to make a contract valuable, but it often comes up in bankruptcy proceedings.
As an example of contracts having value, a few years ago I was involved in the acquisition of some media distribution assets, and one such asset was a transferable "MFN" contract with a major publisher. That was a very, very valuable asset.
A contract for a typical SaaS company, billed annually, is actually a liability (from an accounting perspective) up until the point where the contract has been completely fulfilled.
Others (say, an investor) might view a contract as an “asset” because of the future value it might bring, but not in a traditional accounting sense.
"New product" is a distinction without a difference. Literally all software development efforts are in the interest of "new products" depending on your definition of "new product."
Leaving arguments about new patch releases out, how could we practically track this? Would every engineer log the time they work and track feature work separately from bug fixes?
It's a bit strained, but car or TV companies often put out a new model that's identical to the old model +- some but fixes. There's a line somewhere but the law does not specify the line, it seems
Precisely. The difference with software is that the production process is so iterative that experimentation becomes a relatively rational tactic for getting things done.
This is relatively easy to do. If an engineer is fixing bugs, helping support team, helping sales in any way, participating in customer onboarding, keeping the servers online, etc, a company can argue the engineer is a cost of doing business rather than true "R&D".
In reality, the % of time most engineers spend exclusively on 100% new products is much smaller than you'd assume at face value. Even at a young startup, I'd guess at most 50% of the work is true R&D.
To reiterate, things like devops, managing infrastructure, patching servers, upgrading code, fixing bugs, professional services, etc... none of that is R&D and it's pretty easy for a small company to say that the majority of their engineering expense is not R&D (extremely difficult for the IRS to argue otherwise if they audit a company unless detailed timesheets are kept).
Edit: I'm not an accountant, but pretty familiar with R&D / IRS stuff