So it applies to software engineers but under what definition of software engineer?
This [1] is the only definition the code actually give.
> (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. https://www.law.cornell.edu/uscode/text/26/174
-----
Is a test or QA engineer considered a software engineer?
Is an FPGA or ASIC engineer still considered a software engineer if they are writing in HDLs?
Is a systems engineer, electrical engineer, or mechanical engineer considered a software engineer because they use MATLAB, etc and use programming to do their design work?
Is a sysadmin, DB admin, or other IT staff considered a software engineer because they write software as part of their job?
What about a quantitative analyst, data scientist, accountant, actuary, or any of the other maths and analysis adjacent job roles that regularly use some level of programming to do their job (and therefore write software)?
What about HR, etc who use excel documents? Excel is fundamentally just a graphical array programming language (and the design of spreadsheet tools is heavily inspired directly from APL). Is anyone who uses excel or builds/maintains spreadsheets considered a software engineer?
Like software engineering is such a broad field and programming bleeds into every part of modern business at this point.
The IRS released guidance back in 2023: https://www.irs.gov/pub/irs-drop/n-23-63.pdf
It starts on page 23.
Plenty of analysis online by tax firms but I'll quote from this one: https://insightplus.bakermckenzie.com/bm/attachment_dw.actio...
> Generally, activities treated as software development for section 174 purposes include, but are not limited to, the following.
• planning the development of the computer software
• designing the computer software
• building a model of the computer software
• writing source code and converting it to machine-readable code
• testing the computer software (up to the point that a taxpayer places the computer software into service or determines that the computer software is ready for sale or licensing to others)
• producing product master(s), if the taxpayer develops the computer software for sale or licensing to others.
> Activities that are not treated as software development vis-à-vis software developed by a taxpayer for use in its trade or business are as follows:
• training employees and other stakeholders that will use the computer software
• maintenance activities after the taxpayer places the computer software into service
• data conversion activities, except for activities to develop computer software that facilitate access to existing data or data conversion
• installing the computer software and other activities relating to placing the computer software into service
> maintenance activities after the taxpayer places the computer software into service
This is the part that I think makes this whole jig of treating software development like a purely capitalizable expense so nuts.
I previously worked at a public company that wanted software developers to treat as much work as possible as CapEx - it makes you look more profitable than you actually are, which is bad for taxes but good for your stock price. Developers hated it. The problem with it is that with modern web based software, CI/CD, A/B testing, etc. that the line between "new software" (i.e. CapEx) and "maint" (i.e. OpEx) is so blurred as to be pointless. E.g. many times I'd be fixing a bug (technically OpEx) but that would often lead to some new features ideas, or ways to structure the software to make it easier to add new features (technically CapEx). Software is fundamentally different from capital expenditures in other areas, and assuming a 5 year straightline depreciation schedule for software is laughably absurd.
What other sort of capital expenditure has you do releases every day, or requires 24/7 monitoring? I would argue that the business of software has changed so drastically over the past 20 or so years that it makes much more sense just to categorize it as OpEx by default (for both tax and GAAP purposes), and only have it be capitalized as CapEx for very small and specific reasons.
Your Honor, here printed on paper is what the Prosection calls "software". Actually as anyone can see on the paper, what is there is just ordinary typing A-Z and 0-9 with a lot of the typing in English. Businesses have been doing typing for many decades. E.g., this typing is much like instructions to a delivery truck driver to deliver goods to customers. And it's the same if a drone reads those instructions and makes the delivery. Prosecution has yet to show what of this paper is other than business typing ~100 years old.
It runs on a computer. It tells a computer how to do things. You can type once and have the same instructions run again and again on the same computer or on different computers. It can run on many computers simultaneously. No human intervention is required for all of the above.
> What other sort of capital expenditure has you do releases every day, or requires 24/7 monitoring?
Quite a lot of them actually. If I spend $$$$ setting up a car factory with a big production line, I'm going to have people monitoring it 24/7. If I build an airport, I'm going to have air traffic controllers working 24/7. And so on.
Of course, the air traffic controllers didn't build the runway, and the construction crew don't direct air traffic, so the whole situation is much less ambiguous.
How exactly does the construction of an airport (runway, terminals, parking, etc.) satisfy "releases every day" during the construction? I could see if it were adding a runway or a terminal, but until at least some of the infrastructure is there it's not exactly usable to the end user, the public, as say a stand-in definition for "released."
> I'm going to have people monitoring it 24/7. If I build an airport, I'm going to have air traffic controllers working 24/7. And so on.
> Of course, the air traffic controllers didn't build the runway, and the construction crew don't direct air traffic, so the whole situation is much less ambiguous.
That is precisely why those salaries are NOT capex
Your example was quite good actually. Even in sw the people that build the system is not necessarily the people that monitor, maintain and use it, even for systems used only inside a company. I used to work in a telco and we had 3 separate departments, plus a 4th one for testing. And yet all of them seem to be subject to section 174, builders, maintainers, testers.
A country wide power grid or telecommunications network are other examples that come to my mind. They are never complete, they get more features every day (new cables?), they are monitored 24/7. The owner companies also use them.
> And yet all of them seem to be subject to section 174, builders, maintainers, testers.
Do they?
Upthread one can read: > Activities that are not treated as software development vis-à-vis software developed by a taxpayer for use in its trade or business are as follows: […] • maintenance activities after the taxpayer places the computer software into service
You are right. I also read other comments pointing at that. Nevertheless it's often debatable what's maintenance and what's a new feature. Hopefully nobody is looking at it in too much detail.
Example: a one line change to ignore non Unicode codepoints in PDF files loaded in a web app (I did it yesterday.) Is that a new feature? Is that a bug fix? And if it's a bug fix, is that part of a feature that we should have developed before putting the sw into service? Is that maintenance? And what if that particular code point that triggered the issue did not even exist when we released the sw years ago (the code around it is from 2021)?
I believe that nobody has the time to dig the (tens of?) thousands of issues that a company opens and completes every year but there are a lot of gray areas to exploit if somebody has any reason to be pedantic.
> Nevertheless it's often debatable what's maintenance and what's a new feature.
The same is true for many capital assets. There are people who have time to look into these things because that’s their job.
What we do is enforce that everyone keeps one ticket in JIRA as in progress and use a timekeeping add on. The tickets role up to epics and initiatives. I review each top level initiative and epic with finance and they deem it capitalizable or not. Then we add a haircut. It’s really not that much work. We have an hour meeting monthly to work it out but I make sure to exclude my mainline engineers. They don’t need that
How many engineer-hours are lost amongst the whole company each semester to report all these mindless tickets?
A lot.
It also warps outcomes towards a metric which "is only used for tax purposes" but which also is reported ritualistically with an expectation of compliance.
The entire thing is nuts.
And no one thinks it was sensible.
The only reason it exists is for political games by Trump 1.
Now imagine all the nonsense that’s gonna go into the much bigger Trump 2 tax cut bill.
> • data conversion activities, except for activities to develop computer software that facilitate access to existing data or data conversion
ex: linking excel spreadsheets or setting up excel to ingest data from a sharepoint or network drive would still fall under the definiton of software developer
> • maintenance activities after the taxpayer places the computer software into service
So a sysadmin or a DB admin writing scripts or a DB admin writing queries and adding new reports would be considered software development
It just seems way too easy for arbitrary employees to get pulled in under this definition because it just fundamentally misunderstands how widespread programming is.
You missed the paragraph saying that maintenance activities are not considered development activities
But that's the rub right? What is the definition of maintenance activities? And for what software? If you are writing a new script to automate something or updating an existing script, is that not software development?
If that's considered maintenance activities then would maintaining a software codebase not be considered maintenance activities then?
In my simple mind, if software has been "released" it is no longer R&D, and "bug fixes" (which should include continuous improvements such as your example) are not research.
I may be way, way wrong though.
That seems too exploitable to pass muster in the court. If you release Beta 0.0.1 of your software after 2 months of development then spend the next 5 years getting it up to version 1.0 that's clearly a development effort not a maintenance effort.
> such as marketing and promotional activities, maintenance activities that do not give rise to upgrades and enhancements, distribution activities
If it leads to a new release, then its software dev. Meaning anything more than a minor patch is going to count.
That's the reason we have courts, to cut through those gray areas.
No. That is why you have auditors who must sign off on your financial books and records. There are fairly strict rules about capitalization of software development. If it is a meaningful number for your firm, then the auditors will review in detail.
The IRS Guidance says this in 5.05(2), which is most relevant to software startups:
(2) Computer software developed for sale or licensing to others. In the case of
computer software that is developed for sale or licensing to others (or upgrades
and enhancements to such software), activities that occur after such software (or
upgrades and enhancements to such software) is ready for sale or licensing to
others, such as marketing and promotional activities, maintenance activities that
do not give rise to upgrades and enhancements, distribution activities (for
example, making the software available via remote access), and customer support
activities.
Has the IRS actually dinged anyone for fucking with how they categorise software expenses?
They have, but they’ve fired everyone. Literally. I have a relative who was fired while testifying in court, he ended up stranded in some flyover shithole.
The real issue is the auditors will flag it.
The concept and determining factor is how it relates to revenue. Is it an activity that supports or contributed to current revenue generation, or is it something that is expected to only contribute to future revenue generation.
So if you’re just maintaining a software, that’s already used then you’re good.
I used to support this change because I thought that it would fairly make the software industry like many other industries who have to pay this kind of amortization for R&D and I believe that there would be carve outs for small organization so that really large ones are the only ones who bear the cost.
I also believed it unlikely that this would be enforced or audited before there were such corrections or refinement to the original language.
So the way I viewed it was it’s basically a higher tax for giant software companies, but everyone else will be unaffected by it so we shouldn’t worry.
However, I also now support repealing or changing it because whether or not it has ever or was ever gonna be enforced or audited, it’s ended up causing a lot of disruption across the entire software industry. So much so that it actually looks more like an unfair penalty against software development than anything else now unfortunately.
So I’ll definitely be signing that little petition under my US corporation.
What a wonderful sales pitch for a timesheet software feature. Track non-software-related work for expensing in the current tax year.
Any decent sized company already does this. You’ll see a field on things like Jira tickets for whether something is maintenance or capital improvement. And presumably that information can be used to infer the percentage of a given workers time that can be attributed to deductible vs depreciable expenses.
Exactly. Everywhere I’ve worked, this was a quick and non-intensive collaboration between engineering management and like one finance person. It’s baked into a ton of tools already (like you mentioned, Jira) so the percentages are usually just there and eng leaders review it with FP&A twice a year.
Real innovators can’t stand this sort of noise and so it is a direct shot against their bow
This is fairly standard for a lot of larger companies and for companies where your work is contract work (see defense contractors, legal firms, architecture and civil engineering firms). You have to do line item billing on costs for a given contract so you have to track how many hours are spent to do whatever labor needs done.
The issue is that this is a lot of unnecessary complexity for orgs that aren't doing that kind of work.
> under what definition of software engineer?
Probably a broad enough definition to net the US Government the greatest tax revenue possible for the effort to enact this.
They want the change to _seem_ like it will bring in revenue so the CBO number adding to the deficit is lower.
The folks advocating for this could care less about the deficit, but they need to act like they care.
IDK if that's right. Oddly, the current administration has gutted the IRS and seems pretty ambivalent about collecting taxes that are on the books. I wonder if there will be an inconsistent definition of who is a software engineer, based on how friendly the company is with the administration, whether the company still has someone with a DEI title, etc.
Judging by the Big Law shakedown, enforcement will be based on how much of your corporate cash is held in Taco’s shitcoin.
> the current administration… seems pretty ambivalent about collecting taxes that are on the books. I wonder if there will be an inconsistent definition of who is a software engineer, based on how friendly the company is with the administration, whether the company still has someone with a DEI title
So basically the same situation that we have with bullshit speed limits everywhere.
If we had specifically defunded highway patrol that was net-revenue-positive, yes.
Republican defunding of the IRS is literally insane: reform by cutting enforcement.
- It rewards people who cheat on their taxes.
- It costs the government more money that it saves, because IRS investment is net revenue positive.
But then, the modern Republican party seems more concerned with being the party of 'law(s I agree with) and order (for people who aren't me).'
People greatly overestimate the amount of material cheating that happens, especially among large companies and the wealthy. I used to work for a Federal audit organization and almost all of the recoveries had a root cause in sloppy compliance and record-keeping practices rather than intentional malfeasance. It is broadly recognized as optimal that the recovered money should be several-fold the direct costs spent to recover it because this activity incurs a lot of non-obvious indirect costs. It is a variation on the principle that the optimum amount of fraud is non-zero.
Most of the blatant tax fraud is much lower down the economic ladder because below a certain threshold recovery doesn’t justify the cost and people know this. The amount you can get away with is far below the threshold where it would be worth the risk for wealthy parties. The best ROI for auditors in many of these cases is to make regular object lessons at random to discourage it rather than systematically prosecute it.
AFAIK, the increased spending at the IRS did not lead to concomitant offsetting recoveries. This is a predictable outcome, the amount of enforcement activity has been pretty finely tuned for decades to optimize ROI. Most of the recoveries come from changing focuses on compliance to areas that haven’t seen much enforcement activity in many years. Fighting entropy basically.
If you assume that most large recoveries are from sloppiness rather than systematic tax fraud, it changes what is going to be an effective strategy.
>AFAIK, the increased spending at the IRS did not lead to concomitant offsetting recoveries. This is a predictable outcome, the amount of enforcement activity has been pretty finely tuned for decades to optimize ROI. Most of the recoveries come from changing focuses on compliance to areas that haven’t seen much enforcement activity in many years. Fighting entropy basically.
AFAIK, all the data shows exactly the opposite.
https://news.harvard.edu/gazette/story/2023/07/turns-out-irs...
https://www.irs.gov/pub/irs-pdf/p5901.pdf
(There are many more studies from various outside organizations, as well as other non-partisan government bodies outside the IRS concluding similarly)
These are studies designed to show positive results, and are susceptible to the criticism the parent identified.
IRS enforcement has diminishing returns because the IRS starts with the small minority of people who are very obviously cheating on their taxes. Those people get audited and the IRS very easily recovers money from them. If you want to audit more people than that, you have to audit people who are less likely to be cheating. The more people you want to audit, the lower the collections rate gets.
But if you're averaging in the recovery rate from the people who are so obviously cheating, you can get quite far down the road past a marginal benefit before the average becomes a negative number.
Meanwhile, even that isn't considering the indirect costs. The IRS spends $1 and recovers $2, but audits are much cheaper than the IRS than they are for taxpayers. So the IRS spends $1 and the taxpayers (many of whom did nothing wrong, because we're talking about averages here) have to pay $5, in order for the IRS to recover $2. That's quite bad -- $6 is being spent in order to recover $2, but it's being reported as a $1 net gain.
And it's worse than that, because those $6 aren't just money, it's actual spending -- human labor hours that couldn't be allocated to something else -- so what you're losing isn't the cost of that labor, it's the value of that labor. Someone was being paid $1 to create $2 in value but now instead of doing that they have to spend that time on an audit, so the $6 in cost is actually $12 in lost value.
Not accounting for things like this makes it seem like we should be spending a lot more resources on something with diminishing returns and large hidden costs.
The criticism the parent identified has almost nothing to do with these studies. It was that there is an equilibrium point where enforcement is counterproductive, but it did not identify anything about where that is or how that point relates to where we are.
At some point it gets to that level, but all of these studies show it is extremely far from that at present. This is also not at all what the IRS has been advocating going after.
The extremely cheap (for the IRS) audits you are talking about are the ones they have been doing for years because they can afford to. The tax situations are simple so don't require significant resources to audit. These are also the situations the original comment was talking about. The IRS and others have been advocating for years for the resource to go after actual tax cheats of wealthy individuals and corporations, whose tax situations are (intentionally) so complex that it is a serious investment to audit. Once you do audit them however, their tax dodging decreases for years into the future. This costs the employees and financial advisors dedicated to dodging taxes money.
The "hidden costs" you are so concerned about here, in many cases cannot be argued to exist. The people that would spend time defending violators are otherwise fully employed doing the opposite... coming up with ways to get around the taxes their employers or customers are supposed to be paying. Instead of costing $2, that comes out as getting yet another $2 out of that audit by distracting a societal parasite.
> The criticism the parent identified has almost nothing to do with these studies.
The criticism the parent identified is that the cost to the IRS is not the total cost to the public (i.e. innocent taxpayers being audited despite making only honest mistakes or having done nothing wrong at all), which is exactly a problem with these studies. To know where the equilibrium point is, you have to take into account these other costs, and the studies fail to do that.
> The IRS and others have been advocating for years for the resource to go after actual tax cheats of wealthy individuals and corporations, whose tax situations are (intentionally) so complex that it is a serious investment to audit.
What's really going on here is that those are the taxpayers it isn't as cost effective to audit because they have sophisticated lawyers, so they're much less likely to be violating the law. They're doing something which is complicated and then paying very little in taxes, but the complicated thing they were doing is legal so you can't get anything from auditing them. Meanwhile auditing them costs a lot because it's so complicated, so the ROI of doing it is pretty bad.
In particular it's worse than the ROI of auditing other taxpayers who can't afford such expensive lawyers and therefore are more likely to have made a mistake that allows the IRS to collect. But auditing those people makes the IRS much less sympathetic, because those people aren't the billionaires and the money the IRS collects is mostly a result of honest mistakes.
> Once you do audit them however, their tax dodging decreases for years into the future.
The assumption is that they were doing something unlawful to begin with, and then you're talking about the non-billionaires again.
Moreover, what really happens is that the people who made mistakes learn to hire tax lawyers. And then if you audit them again it comes up clean, but that doesn't mean they're paying more in taxes, because tax lawyers are pros at finding legal ways to avoid taxes, so what you've really done is encourage them to hire the people whose primary job it is to minimize tax revenue.
> The people that would spend time defending violators are otherwise fully employed doing the opposite... coming up with ways to get around the taxes their employers or customers are supposed to be paying. Instead of costing $2, that comes out as getting yet another $2 out of that audit by distracting a societal parasite.
It is definitely not the case that the number of tax lawyers and accountants employed is unrelated to the number of audits the IRS does. The more they do, the more business there is for those professions and the more people enter them. These are people who could have been doing something else and, moreover, people who consumed the resources that someone else could have used to do something better.
If you want to account for the social cost: moral hazard.
Who pays taxes when it's well known that the IRS doesn't audit and follow up on tax cheats?
Especially, if all it takes to further dissuade them is engineering complex wealth structures and keeping tax lawyers on retainer.
> Who pays taxes when it's well known that the IRS doesn't audit and follow up on tax cheats?
But they do. They always have. The question is, once they've done that, should then they proceed to audit an even larger number of mostly innocent people, because a small percentage of them did something wrong and finding that small percentage would cover the costs of the IRS, but not any of those other innocent people?
> Especially, if all it takes to further dissuade them is engineering complex wealth structures and keeping tax lawyers on retainer.
This is an entirely different problem. The ones with sophisticated lawyers aren't actually violating the tax code. The problem there is that the tax code is so complicated and poorly considered that fancy lawyers can find ways to avoid taxes without violating the law.
If you have been found to be cheating on your taxes, you should pay a fine that covers the cost of the audit.
They already have that. The problem is, in order to find someone who is actually cheating, they have to audit a lot of innocent people, and who is covering the cost of those audits when they don't find anything?
> the amount of enforcement activity has been pretty finely tuned for decades to optimize ROI
And then cut by 20% by the current adminstration [0].
I'd phrase the question of auditing lower income filers vs higher income filers differently -- do you think people with higher incomes should feel safer about cheating on their taxes?
Because average recoveries do scale with income [1]; unsurprisingly, it seems wealthy people commit tax fraud too [2].
While catching the low-hanging fruit (and therefore better ROI) is one goal, it needs to be balanced with ensuring there are similar levels of compliance (or penalties where it's lacking) in higher income payers.
[0] https://taxpolicycenter.org/taxvox/cuts-spending-and-staff-d...
[1] https://www.nytimes.com/2025/06/05/upshot/tax-audits-wealthy...
[2] https://www.irs.gov/newsroom/irs-launches-new-effort-aimed-a... https://www.irs.gov/newsroom/irs-tops-1-billion-in-past-due-... https://www.foxbusiness.com/politics/yellen-touts-irs-enforc...
Whats your view on Cum-Ex?
And maybe as a Bonus what do you make of the smaller (relative) taxrate the bigger fish (companies/wealthier individuals) pay?
I’d think it’s normal and expected that the “mistakes” made will err on the side of benefiting the taxpayer, i.e., reducing their tax bill.
This comment (currently downvoted to hard-to-read grey-on-grey) is an excellent example why you should always enable "showdead" in your profile, use user CSS to make downvoted comments readable again (e.g., https://news.ycombinator.com/item?id=41514726), and browse https://news.ycombinator.com/active instead of the homepage once in a while.
What's really going on here is that this provision was part of the tax acts from the first Trump administration. Due to procedural rules in Congress, they had to make those cuts appear revenue neutral over a 10 year time period. This tax increase is part of that. Very likely nobody involved really had a reason or cared that SEs get categorized this way, it just let them pass the changes they really wanted at the time.
A sufficiently idiotic tax scheme such as Section 174 can destroy far more income tax revenue than it collects, by destroying jobs and small businesses, and knocking high earners down a tax bracket or three. Section 174 isn’t doing much to tax FANG companies. Apple has all their profits in their Double Irish Dutch Sandwich racket. Amazon cooks the books to appear unprofitable on paper, in a manner that would make Hollywood accountants blush.
This really only hurts the competition, who is completely unprofitable in every sense of the word. And all for what? Left-shifting the collection of a 21% income tax by a couple years? I think many of us would’ve done terrible things in 2021 to only have an effective tax rate of 21%. The government mugged Peter the payroll tax man to pay Paul the corpo tax man, but they disemboweled Peter in the process, and most of the money had to be disposed of as a biohazard.
I don’t believe Section 174 was an honest attempt to manage the deficit. I think Zuck, the PayPal Mafia, and the blood-boy cabal bribed some Congresscritters to kill off what remained of their competition.
> I think Zuck, the PayPal Mafia, and the blood-boy cabal bribed some Congresscritters to kill off what remained of their competition.
What's with the craze for finding conspirational incentives?
There's a repeatable pattern where commenters hallucinate an unreasonable incentive for everything.
Motivations are difficult to discern (see courtrooms), and it is a modern vice to try and analyse incentives, but too often the cause-and-effect imaginations are not even reasonable guesses, but are just pure fiction.
My best guess (based off word choices made) is that we all love to create new stories/narratives, that fit into our personal tribal stories.
My best guess is that legalizing corruption has made everyone a bit more deranged. Some more than others.
I don’t think it’s such a huge leap that a policy with such unanimous opposition was put in place by the select few special interests who benefit from it. It helps (or doesn’t help?) when they all got together for that photo op at the inauguration.
Believing in corruption doesn't have to be in the same league as believing the moon landings were faked. I don't particularly think this tax thing is something other than short-sightedness, but there is a tendency among some to dismiss even blatant cases of corruption.
Believing in fake moon landings requires believing in a level of competence I don't think exists in large organizations, but the same applies to believing there is no corruption or backroom deals, which are exposed all the time and seemingly rarely punished.
It’s much simpler than that. People have figured out that if you follow the money (ask who profits financially or in terms of market power), then even confusing political actions make sense.
Uh have you worked in policy in faang? I have that would be the least insane tactic I saw used.
I can’t believe you’re trying to claim the high ground in rationalism here and have no clue how bad it is.
No, but clearly you also have zero idea.
People in policy are not dealing with bribery and corruption (which is the framing of the comment I replied to).
If bribery is occurring, then I would expect it to be used to get higher value personally directed outcomes (not a few percent on the bottom line). The suggested incentives sound completely wrong to me (which is the point of my comment). Obviously my own ignorant opinion given that I have zero experience "bribing Congresscritters".
I can believe there is corruption, but I also believe smart people will hide their goals better than the internet peanut gallery assume.
Several heads of policy directly attend trumps fundraisers currently. Are You kidding me it’s not even covered up anymore.
What I’m saying is you in your not doing this mentality think this is fine all cloak and dagger.
It isn’t. It’s legal and it’s done very directly.
The answer to all these questions is yes, i don't see the point in trying to obfuscate this with artificial complexity.
What about HR, etc who use excel documents?
IF they are using it rather than developing it, no. If they put in 5 hours a week writing code, yes for those 5 hours. This isn't hard.
Okay so your random HR person at a nontechnical small to medium sized business now is on the line for developing spreadsheets to manage scheduling.
OR they need to maintain a set of activity codes and a timesheet outlining how many hours (or partial hours) each week are spent on what types of tasks.
It's unnecessary complexity if you want to be in actual compliance with the tax code vs just guessing whether XYZ task is on one side of the line vs the other and hoping it doesn't come back to bite you later.
How is an HR person writing a script to do their HR work better considered an R&D expense?
Scripted automation is quite literally development of IP. It's an asset that belongs to the company and will be counted as such on its balance sheet.
What if they literally just write a post-it note of how to perform certain actions? Are those 5 minutes capital investment? The information on that scrap of paper is subject to copyright and is a company asset in just the same way as a script. Where do they draw the line?
Anytime someone has a good idea, it should be depreciated over 5 years? Why is software special? It is all just the composition of simple machines.
I'm pretty sure it's because other industries wondered why they were having to spread such costs over 5 years while software firms were able to write them all down at once. It's not that I have a strong opinion about this either way (I'm not running or employed in a business where this matters), but that ultimately this is a philosophical argument. There isn't an objectively correct way to do this, how you view it is down to what your economic interests happen to be.
It's the other way around. Software used to be special, in that money the company spent to improve its internal processes by, say, buying a calculator had to be amortized, while money spent on developing software automation were not.
So now every engineer has to record how many hours each day were spent doing "software development" vs. "software maintenance"/"overhead"/"etc..."?
You just add a row to spreadsheet at the end of the month. 30% maintenance, 70% development or whatever
My last company required timesheets to be submitted daily.
This is common in Canada for companies claiming SR&ED credits: https://www.canada.ca/en/revenue-agency/services/scientific-...
The word “just” in your comment disgusts me
Why?
They're suggesting you spend a minute or two per month thinking about it, not meticulous tracking.
That might not be practical, but what they are describing is a perfectly good use of the word "just".
A minute or two (or even 10 minutes) per month is basically just guessing/bullshitting. Anything that is accurate rather than imagination requires more overhead than this. Likely anything even remotely accurate requires the sort of micromanagement software that lawyers use to track billable hours, requires desktop-surveillance, and meeting minutes-dissection after-the-fact. Not sure how they will decide to rate reddit doomscrolling when tax season rolls around either, which if we're honest, is some significant fraction of our in-office hours (hell, strangely, some of that time is when I figure out the tricky stuff).
So no, "just" is hardly fair.
Government wants a number -- they get a number. How I get to the number is precise enough in my opinion and you are free to disagree with my methodology.
When I was doing it, I worked in an actual startup and granularity of time allocation was in weeks. This week I was doing the thing, the other I was mostly doing bugfixes/refactorings etc.
You could do more precise and account with hour or minute granularity with tools if you have to
> A minute or two (or even 10 minutes) per month is basically just guessing/bullshitting.
Correct, they are suggesting basically just guessing.
Which is why "just" is correct for their suggestion.
It's not a good suggestion but it really is that easy to implement.
> 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.
For me that sounds like everyone and everything in a company that develops software of any kind, including low-/no-code stuff, accounting, HR, travel costs, massages. Like who is not "in connection with the development of any software" in a company that develops software? Without further definitions this is even worse then just software engineering costs.
> This [1] is the only definition the code actually give.
Like most of our tax code, its overly complicated by unclear or incomplete codes.
The IRS will give guidance with examples, but those examples are still incomplete.
Ultimately our tax code always comes down to the filer doing whatever they (a) think they can get away with or (b) are willing to defend if they get audited.
I’m a solo founder and sometimes outsource projects. How does that work if I pay a contractor a few thousand for a project? Are contractors allowed to be deducted fully at 100% expense?
Yes, this is an insane policy that reflects a complete ignorance of the on-ground realities. It was almost certainly only passed to help the 2017 tax bill's legislative scoring by the CBO.
I posted about this on Reddit the other day. https://www.reddit.com/r/Economics/comments/1l3lo7j/the_hidd...
> Yeah, it's pretty much completely insane. Although in your example I think you accidentally picked numbers that actually work out precisely to zero dollars in taxable income. The company (if US-based) would have zero taxable income in the first year because they can deduct 1/5th of the salaries (because there is a five year amortization for US companies, and 15 year for foreign companies), so they would have $1m in gross income and $1m in deductions resulting in $0 in taxable income. But you can tweak the numbers a bit to get the result you intended, e.g., $1m in revenue and $2.5m in salary would result in $500,000 additional taxable income under the TCJA's version of Section 174 over the previous version of the code, even though in reality the company operated at a net loss. (edit, just looked this up and actually the amortization is dated from the midyear of the tax year in which the expense is incurred, which is also just fucking bonkers, but that means I was incorrect and your example does yield a taxable income, because the first year in your example would have $500k in deductions rather than the full 20% of the $5m expense, resulting in $500k taxable profit)
> All of which means that we treat R&D salaries less favorably than ordinary salaries, which are fully deductible in the year they are incurred. So our tax code now not only fails to incentivize R&D as under the previous R&D tax credit regime, it actively treats R&D employee salaries worse than non-R&D salaries. Even though R&D jobs are generally the highly skilled, well compensated, white collar careers we want to keep in this country.
> Section 174 also specifically designates all software development as R&D, so there's no way to develop software while claiming it is not R&D. I'm sure accountants have been jumping through hoops in their efforts to reclassify other kinds of product development jobs as not R&D, which is the exact opposite of what R&D tax studies used to do, which was to label as much employee compensation as R&D expenses as possible, because §174 and the related, intersecting provisions of §41 (the R&D tax credit itself), treated R&D salaries more favorably than other salaries. To a certain extent, the OP article understated how much of a swing this revision to the tax code is. It isn't just that we are treating R&D salaries worse than we used to, but that we are treating them even worse than we treat other kinds of salaries. Which is bizarre in a world where the policy objective is to retain R&D jobs in the US.
> The purpose of capitalization is to match expenses to benefits over multiple tax years. So that the tax payer can't take a huge tax deduction up front to generate an economically fictional loss in the short term on an asset that will generate income over the many years. Amortization forces them to deduct the expense of the asset over time as the benefit accrues over time.
> This model is a poor fit for software. Construction workers produce an asset with a generally predictable and known useful lifetime and long-term stable value that is independent of the business. You can always sell a building.
> Software, however, does not generally create value for very long if it is not subject to continuous development and improvement. It also decays very rapidly when not maintained (e.g. security patches), yet there is no distinction in the tax code between new development and production support/maintenance software development. Nor would any such distinction make any sense in reality, because unlike a physical asset software is subject to continuous change and there is little distinction between adding new features and maintaining existing features. This approach to capitalizing salaries contrasts with other capitalized assets like buildings, where most ordinary maintenance costs are deducted in the current year, not capitalized.
> The value of software can be much harder to predict than other capitalized assets. Both in terms of the demand, but also in terms of the technical capability to deliver the desired product. Which is why it's considered R&D in the first place: there is inherent technical risk in many if not most software projects which is not present in other kinds of economic activities that produce capitalized assets.
> Software is often so specialized that it cannot be sold on to a third-party without selling the entire business around the software, including existing customers, distribution and sales channels, and supporting software engineering staff. It's not a liquid, fungible, alienable asset the way other capitalized assets typically are. There is no real market for the source code to Reddit, for example, because there is nothing technically special about Reddit. The company's value derives from the user base, the community, and the data, not anything particularly special about its software.
> The tax code also confuses the output of the software development process with the value software can generate. Software developers produce code. Some of that code is valuable, much is not. Unlike with other capitalized assets, you can't know in advance whether the software you produce actually works 100% of the time, even with robust testing and QA. Whereas you can be quite certain that a building will continue to function as a building if it is built correctly. Many software engineers actually regard code as a liability rather than an asset. The more you have to maintain, the more work you have to do to maintain the code base and the harder it is to add new features or debug issues with existing features. So if you can deliver the same capability to your customers with less code, then that is preferable. Which is to say, the output of the software development process is much more loosely tied to predictable economic value than other capitalized assets.
> Software is also frequently delivered as a service, which highlights the inanity of treating software as a fixed, long-term asset. The team maintaining a SaaS will handle day-to-day site reliability engineering work, which is never a stable output but needs to be constantly tweaked to match actual usage patterns.
> Last, and this is implicit in much of the above, but unlike other capitalized assets, software is never really complete. There are always more features, more optimizations, more bug fixes. Software development is never steady state. Either the software isn't being developed actively and quickly loses nearly all value due to code rot, or it is being actively maintained and improved and is producing value. Buildings don't stop functioning as buildings when you stop paying the construction workers. Thus, software development does not produce a long-term fixed asset but rather is a continuous service delivery process, where the revenue produced in any given year was produced by the same year expenses to maintain the software. Thus, software expenses and revenues are mostly naturally aligned in a single tax year, and therefore software is not suitable for amortization.
From the wording, it sounds like it applies to contracting non-US resident software development as well.
> Is an FPGA or ASIC engineer still considered a software engineer if they are writing in HDLs?
Of course not. The Glorious Leader is rescuing the american hardware sector.
There is a substantially more definition, but the tl;dr is this an R&D expense, or COGS expense?
R&D is amortized, COGS is not.