What would a software developer do that isn't research or development? Maybe my understanding of "research and development" is wrong. Is there a formal definition that I can go by?
It's never supposed to be about what's "fair" or what they "should" do. It's about the fact that they want to spend $X, and need to raise $X one way or the other.
In this case, though, it was purely a trick. They were required to balance the budget over the long term, so they spent money now and identified a pot of money they could take from later. They just kicked the can down the road, and now we've arrived where the can landed. They actually don't think it's fair, or reasonable, or productive. But changing it does make somebody responsible for a huge increase in the deficit... and it's the people who spent the money 5 years ago.
This change taxes you on profit you never made, and specifically targets software companies.
It’s insane.
If you made a million dollar and bought a million in patents, you still would have no money but wouldn't expect to be paying 0 tax, would you ? How RnD should be taxed is up for debate, but at least the logic is that it's not a simple cost (in comparison to paying a janitor to clean the office for instance)
I kinda see many cases where a salary isn't as clear cut as a simple cost...for instance comparing two cases:
- we buy for a million dollar an exclusive right on an innovative system from a freelance guy that developed it on his own
- we contract for 10k a month the same guy to design and develop the same innovative system, he takes a year or two to develop it.
In one case it's a purchase of an asset, in the other case it's a salary. The resulting asset is the same though.
But if you make an employment contract with somebody it is totally unknown what is the value you are or will be getting out of the employee. You are not buying an "asset" because you can not own an employee. They can quit any time.
> you can not own an employee.
You own everything the employee produced during the contract, whenever they quit.
Time spent is NOT an asset, it is consumed, hour by the hour. It is an expense.
It is not an asset also because you can not choose to sell it to someone else and thus recoup the money you have placed on it.
You'd be saying you didn't pay for a house, instead you paid an architect to come up with the blueprint and paid the salaries and purchases of a construction team hour by hour for X months to execute on the design, additional work included, until you got a satisfying product. An accountant looking at it afterwards would still tell you you now have an asset estimated at Y thousands on the market.
> you can not choose to sell it to someone else
You can of course sell a developped product or a service to another company. Or even just the research part if it would cost enough to the buyer to reproduce it.
You didn't pay the architect to work on the blueprint, you paid FOR the blueprint.
The blueprint is an asset, architect's time is not. You are not the employer of the architect, you are their client. The business transaction is money-for-blueprint. Whereas with an inhouse software developer the business-transaction is salary-for-time-spent.
If the software developer does not come up with a working program you can not take away their already earned salary. Whereas if the architect does not give you the blueprint you don't have to pay for it.
And once you get the blueprint you can sell it to someone else, it is an asset. Once the SW-developer-employee goes home you might or might not be able to sell their work-products to somebody else, because maybe the program does not run. If it does not run you can not sue the employee. If the architect's blueprints do not produce a working house you can sue them.
Here's the IRS' guidance on software: https://www.irs.gov/businesses/audit-guidelines-on-the-appli...
Weld stuff?
That's why you have to take into account that it's "research and development", and not "research" and "development". As in research and the development of that research, not separately research and development.
For the "real" world, Research would be studying different compounds to see which ones work well as anode or cathode.
Development would be creating the industrial processes required to scale up manufacturing, or the ancillary infrastructure to support the new battery, or designing a new package for this awesome new cell. All the things that take the new thing from the lab to a marketable product.
So if you come up with a new method for welding ("My new filler alloy reduces argon requirements by half!" or "My new pulsing methodology results in 23% stronger welds between dissimilar alloys.") That's Research. Then the Development of that might be "How do we manufacture these new filler rods to the exacting specs required?" or "We need to have the EE people incorporate my pulsing algo in our welders. Right now it's running on an Arduino in the lab, we need it included in next year's Welder XL4000 model."
Actually doing the weld is just doing the job.
So, back to software. What kind of coding is considered R&D and what is considered "just doing the job"? I guess creating new algorithms, or new features that you expect to be in the product for years to come; those would be R&D. Whereas fixing bugs, working on Kubernetes stuff, writing database backup routines, etc. would not be?
I don't know. This is just my impression of the difference. I'm no economist.
I would still count the later as R&D. It's akin to having an industrial engineer re-design the manufacturing floor to accommodate for the different manufacturing process of the anodes.
As soon as you need to customize something, it becomes R&D (else you would have purchased it). The "just the job" part is invisible because, well, it's the machine who's doing it (applications auto-start, install, send updates).
That is a small % of welding though. Most is just straight production work. The % is open to question - if I ask you to put a winch mount on my trailer how much of that is custom R&D, and how much is production of the one off product?
If you have a clear, standard approach to the installation, then the development is likely to be a small portion of the work.
If neither of those are true then you are in the hard to figure area.
A programmer building a custom abstraction for domain feature x
A plumber laying a new line from the basement to the second floor
All require some surveying and development of a solution, gluing existing parts together in a unique way
Like if the carpenter is installing some shelves, they are most likely picking a shelving system or approach they know how to work with and measuring for fit, not coming up with a brand new way to mount shelves. They might come up with a new way, it just isn't all that likely.
The entirety of the rule seems to exist to punish small players in the market. A barrier to entry to box out competition.
Even if they are not on a line, few welders are designing the bracket, instead they cut it out according to blueprints (this might be a separate person) and then weld it on. Then they look at the next part of the blueprint and put it on.
Just like how "work" in physics has a precise definition which doesn't mean what it colloquially means, or "tree" in computer science.
In this case, software development of any kind is explicitly included:
> 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.
The debate over whether Excel counts as programming and thus software development just got a lot more heated. The question is how is "software" defined in the context of the tax code, in particular in the phrase "development of any software" from above.
https://www.lawinsider.com/dictionary/software gives a couple definitions.
Even if this risks an IRS judgement against them, a savvy company might want to take such a judgement to court, and let a jury decide.
Yeah, the love the tax write-off - they don't love paying people to actually research anything.