Is it mandatory for software companies to classify engineer salaries as "R&D"? I haven't yet gotten an answer for this each time this issue comes up.
I know it used to be advantageous due to the R&D amortization period, and I feel this was abused in cases were there was effectively no research or development (in the traditional sense). How is your example materially different from a furniture shop that has similar revenue & salary numbers, but previously wasn't able to amortize salaries as "R&D"?
On the one hand, Section 174 clearly stipulates: "(3)Software development
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." [1]
Section 174 R&E expenses are much more expansive than what qualifies under the R&D tax credit criteria. This article has a rundown of some of the activities included in 174. It's well beyond software or salaries -- it also includes things like market research. It also includes any expenses in connection with R&E, so for example time using a server for new features or new products would have to be amortized but maintenance (bug fixes) wouldn't. Even if a company files for R&D tax credits, they won't be able to offset this increase. [2]
Lastly, since Congress was widely expected to revert this before it took effect, the IRS didn't issue full guidance on how to implement it. They've never had to define software development before, but the interpretation that Big 4 accounting firms are taking is that it covers new products AND new features on existing commercial products, but not straight maintenance.
Link [2] lists activities related to software development and includes maintenance and debugging. As I understand it this is for the older #41?
• Programming
• Tuning and benchmarking of software
• Performing software maintenance and debugging
...
Am I understanding this correctly that there are two different things at play here: the Section 41 tax credit which works in the companies' favor by allowing them to deduce R&D expenses. Then the Section 174 that requires all expenses to be amortized and the big issue for software firms is that the definitions of R&D differes where it's narrow R&D for the credit, but very broad for #174, resulting in a cash flow problem?
Is it? "In the case of a taxpayer’s specified research or experimental expenditures for any taxable year—" is pretty clear. That means what someone wants to claim as research and experimental expenditures. "For the purposes of this section" also seems pretty clear. If you want to claim software development as R&E, it unambiguously qualifies. And now all R&E must be amortized.
I am not a tax expert, but it doesn't seem like there's any reason you have to claim software development as R&E.
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.
It means before you may have had to justify whether software development qualified as R&E, now you don’t. It unambiguously qualifies, if you’re claiming it as R&E. And unlike before, R&E must now be amortized.
But AFAIK you don’t need to claim it as R&E. That everyone has to claim all software development as “research and experimental expenditure” seems completely unfounded and a misunderstanding.
Yup. Exactly. And from that perspective this is actually a good thing, because now you don’t have to worry about whether software development qualifies as R&E.
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?
I still don’t understand why it has to be RnD? If I made a million dollars and spent a million in salaries, I made no profit. The government shouldn’t be taxing me on no money made. They already get taxes on the salaries I’m giving out.
Because it was a way to get the budget "balanced". They declared R&D expenses to be different from operating expenses -- if you have the money to spend on R&D then you have money to spend funding the country.
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.
Spending resolutions are more important than budgets. So much more important that they're usually just called "budgets" because nobody cares about the thing that is actually a budget.
It comes down to whether these salaries were a sheer cost and not partly an investment.
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)
Fair enough. If you made a million dollars and bought land with it, sure you can tax it. But something as basic as employee salaries that are a cost to any business should definitely be deductible from the profits as cost of running the business. Especially when the company is supposed to pay payroll taxes and the employees themselves pay income tax on their salaries.
I'm with you in that it probably needs more nuance on what exaclty the developpers are doing (TBF I haven't read the details, so maybe there is already a lot of nuance in all of it.)
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.
If you buy something for a million dollar you are buying an asset.
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.
I'm with you on the unknown part. We could this it as a risk, with the upside that you might have paid less in total by taking the risk and hiring the guy, than buying the proven end result at price reflecting the total value of the asset.
> you can not own an employee.
You own everything the employee produced during the contract, whenever they quit.
Right but what you paid for was not the outputs of the employee, you paid for the inputs of the employee -- meaning the employee's time spend on the work.
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.
It feels like a distinction without a difference: trying to apply the same logic to something that is material and not just bits in a computer:
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 paid an architect to come up with the blueprint
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.
What would a welder do that isn't research or development? I believe for both jobs certain tasks are journeyman-like, but others are legit R&D. I don't think software ought to be blanket-exempted because its done on a computer.
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.
Yeah, forcing physical-world norms into technology will always result in weird shit like this.
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.
> 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 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).
Welding stuff is developing a product. Basically the same thing software developers do. It seems like a nonsense differentiation if those are categorized differently for taxes.
It can be development, if you are building a prototype for example. a good welder will notice that a bracket is missing and design one one the spot so the whole can be built for now - while telling the engineers about the problem.
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?
Sure, I agree, but there are likely standard approaches, especially in the older trades, where the development is making ~1 decision and then measuring.
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 same can be said for a lot of software developers. How many people spend their days gluing together existing libraries vs. writing their own? This rule seems ridiculous; I fail to understand why they're are different tax write off rates for employees based on what they're doing. Either way they're being paid by the business!
The entirety of the rule seems to exist to punish small players in the market. A barrier to entry to box out competition.
The difference is repetition. Many welders work some form of assembly line, where they constantly are welding the same bracket on and sending the part down the line.
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.
In "research and development", that typically means "research of new ideas and methods, and developing them into commercially viable products". So are there things that software engineers do that fall under R+D? Absolutely! Is adding a sorting feature to a grid in your app one of those things? Probably not!
You should never assume legal terms mean what they colloquially mean.
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.
What I find most confounding is that I know some folks who do what I'd call research, in that they do EDA and develop models, but since those aren't necessarily destined for development of software, their hours are not counted in this exercise. It's too, um, researchy to qualify as research, I guess? or it's just classified as fancy analytics.
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.
The full IRS clarification on this will helpfully be available in a few months (a few months after the deadline), but it doesn't look like things like maintenance work will qualify, only new software projects. I'm expecting that a lot of savvy companies are going to decide that a lot of software development (using the common term) is not software development in the legal sense.
> I'm expecting that a lot of savvy companies are going to decide that a lot of software development (using the common term) is not software development in the legal sense.
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.
Maintain services. Why was everyone expecting Twitter to go down after the layoffs if software developers only do research and development of new products?
Honestly this whole thing looks like a huge tax loophole, now being closed. I don't know of any jurisdiction (apart from the US, apparently) which allowed 100% non-amortized tax credit for loosely defined R&D salaries. No wonder everyone and their dog started software companies in the US.
> I don't know of any jurisdiction (apart from the US, apparently) which allowed 100% non-amortized tax credit for loosely defined R&D salaries.
This is not about tax credits, this is about whether salaries are an expense. If Widget Inc makes and sells a bunch of widgets for $100m, and then they pay $20m in rent, and $30m for materials, and $40m for salaries, with $10m left over, with no other complexities (eg, interest, depreciating factory equipment, etc.), then is their profit this year:
1) $10m (or maybe a bit less, if they got any tax credits)?
2) Some other larger number closer to $50m?
You'd be hard pressed to find many jurisdictionns where the answer isn't option 1. I certainly don't know any offhand.
> If I pay a worker to frame up a house it is an expense
If you are getting paid to build the house because you're in the business of building houses, then yes it is an expense. If you're building a house to keep ownership of and rent out, then no, that cost has to be capitalized and depreciated over the expected lifetime of the improvement.
The general question addressed by this law is "should it be allowed to reinvest profits tax-free and delay paying taxes indefinitely?". There are many places in the tax code where this answer is "no" (eg you pay taxes on bank interest yearly, even on a long term CD), and there are many places where this answer is "yes" (retirement accounts, US savings bonds, stock buybacks, 1031 exchange).
It's ridiculous that software development is getting singled out, given that for most business activity the answer is default yes, with only specific list of things that have to be capitalized. I'm just saying the right answer isn't set in stone, apart from of what the tech industry has gotten used to and how effectively abrupt this change was.
Came here to say this. The level of general ignorance of how accounting and tax works on this thread (not you, others) is astounding.
Of course, if anyone had owned real estate, they'd understand things like depreciation, and the fact that you can spend money without it being an 'expense', or that no, just because you 'made $1,000,000 and spent $1,000,000' doing something like building a house, or a piece of code, you could of course show an accounting profit. You created something of value--that's the point. There's something of value left over. Maybe there won't be in five years, but you can't expense the entire thing immediately.
I actually think this treatment (capitalization of software R&D) is more "correct" from a theoretical accounting perspective. Clearly, software companies are creating something that has residual value with all those developer salaries. As for the politics, I'm not sure. I do know that RE has the same problem (accounting profit can run far ahead of cashflow), but has so much crazy advantaged tax treatment (arguably "loopholes")--1031 exchanges, bonus depreciation--and that's on top of stuff like 179 expensing (not specific to RE I know, but still), that maybe software just needs to work more like RE, where the baseline is "many things capitalized", but all sorts of crazy loopholes driven by the whims of short-term politics.
It certainly makes the accountants rich...
FWIW, my wife's architecture practice is dealing with this 174 amortization (on their salaries, some of which were classified as R&D) and it's killing them, too.
TBF I hate accounting too, and now that it's past tax season I look forward to pushing as much as possible to the back of my head...
When you say some of your wife's architecture practice's salaries "were classified" as R&D, who/what did that classification?
I'm wondering if a large part of the pain is businesses that were classifying as much as possible as R&D to get the R&D tax credit, and now that classification is a liability and they can't change so quickly. Otherwise it would seem that established companies could call much of their software engineer activity "maintenance" rather than "development" (and the change shouldn't really matter to pre-revenue startups).
It's not "just an expense". Think about an architect designing a house. The tax treatment depends on how the person spending the money "uses" the labor. It might be an ordinary operating expense (fully deductible), but could also be inventory, or a depreciated "capital asset" (closely related to the idea of "capital gains" taxes) whose value is spread over a long period of time, generally related to the asset's usable life.
There is a large body of work around the correct treatment of this stuff, which sits at the core of accounting in the same way data structures sit at the core of CS. It's not the most straightforward thing to explain. The tax code contains a ton of exceptions, but in general, a thing that is long-lived, expensive, not routinely bought or sold, and provide some kind of long-lived economic benefit (e.g. shelter, the ability to produce something, or facilitate some kind of industrial process), is a capital asset. (Sounds a lot like software, doesn't it?) Inventory is something routinely bought and sold, generally for profit. A server is inventory for Dell. For a typical software startup, it's a capital asset.
The whole point of accounting is trying to accurately measure economic activity. It's more complicated than it looks. If you agree to a five-year contract and get paid upfront, not all that money is "earned" (hence taxable) in the first year. If you're in debt and the debt is forgiven, no money changes hands, but that's very much beneficial (and taxable) to you. And if you own a long-lived asset, you don't just get to say, oh, I spent all this money upfront, that's an expense I can use to reduce my taxes. Not how it works.
Just trying to shed some light on this. It is indeed rather complex.
Maybe it was the point? Didn't you notice that the US gained certain lead in software technologies?
The developers, who are paid rather handsomely, also pay rather large amounts of taxes from their salaries. (If fired and jobless, they stop doing that.)
Well, salaries are expenses though. And software development is not necessarily R&D, so if 99% of software development has to be classified as such, that's a problem.
I know it used to be advantageous due to the R&D amortization period, and I feel this was abused in cases were there was effectively no research or development (in the traditional sense). How is your example materially different from a furniture shop that has similar revenue & salary numbers, but previously wasn't able to amortize salaries as "R&D"?