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
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.
If that's considered maintenance activities then would maintaining a software codebase not be considered maintenance activities then?
(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.
The real issue is the auditors will flag it.
For tax books?
I may be way, way wrong though.
If it leads to a new release, then its software dev. Meaning anything more than a minor patch is going to count.
The issue is that this is a lot of unnecessary complexity for orgs that aren't doing that kind of work.
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.
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.
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.
> 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
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.
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
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.
The same is true for many capital assets. There are people who have time to look into these things because that’s their job.
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.
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.
Probably a broad enough definition to net the US Government the greatest tax revenue possible for the effort to enact this.
The folks advocating for this could care less about the deficit, but they need to act like they care.
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.
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.
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 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.
I can’t believe you’re trying to claim the high ground in rationalism here and have no clue how bad it is.
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.
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.
So basically the same situation that we have with bullshit speed limits everywhere.
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).'
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, 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)
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.
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.
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.
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 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.
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...
And maybe as a Bonus what do you make of the smaller (relative) taxrate the bigger fish (companies/wealthier individuals) pay?
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.
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".
So no, "just" is hardly fair.
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.
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
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.
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.
Of course not. The Glorious Leader is rescuing the american hardware sector.
R&D is amortized, COGS is not.
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.
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.
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.