A lot of people don't know what this Section 174 is about, so here's a brief explainer.
Normally, when you have expenses, you deduct them off your revenue to find your taxable profit. If you have $1 million in sales, and $900k in costs, you have $100k in profit, and the government taxes you on that profit.
Section 174 says you can't do this for software engineers. If you pay a software engineer, that's not "really" an "expense", regardless of the fact that you paid them.
What you've actually done, Congress said, is bought a capital good, like a machine. And for calculating tax owed, you have to depreciate that over several years (5 in this case).
Depreciating means that if you pay an engineer $200k in a year, in tax-world you only had $40k of real expense that year, even though you paid them $200k.
So the effect is that it makes engineers much more expensive, because normally when a company hires an engineer, like they spend on any other expense, they can at least think "well, they will reduce our profit, which reduces our tax obligation," but in this case software engineers are special and aren't deductible in the same way.
In the case of the $200k engineer, you deduct the first $40k in the first year, then you can expense another $40k from that first year in the second year, the third $40k in the third year, and so on through the fifth year. So eventually you get to expense the entire first year of the engineer's pay, but only after five years.
The effect is that companies wind up using their scarce capital to loan the federal government money for five years, and so engineers become a heavy financial burden. If a company hires too many engineers, they will owe the federal government income tax even in years in which they were unprofitable.
These rules, by the way, don't apply to other personnel costs. If you hire an HR person or a corporate executive, you expense them in the year you paid them. It's a special rule for software engineers.
It was passed by Congress during the first Trump administration in order to offset the costs of other corporate tax rate cuts, due to budgeting rules.
I keep seeing an objection in this thread along the lines of "what make software so special that it deserves a tax deduction".
Correct me if I'm wrong, but if a company hires someone to say, mine coal or brew beer, the expense of those employees is an expense any company can claim a full tax deduction on. If you're a line chef or wait tables, your salary is tax deductible to the restaurant.
So it's not that we are asking for R&D to be treated "specially" and get a deduction that other companies don't have. The problem is that R&D salary expense is being singled out as producing an asset (e.g. IP), and thus being classified in the same category as other assets, like, brewing equipment, a mining excavator, or a pizza oven. Simply put, Section 174 argues to classify people in the same category as things because ... 'these people's work outputs may have long-term value, kind of like things'(?).
Allowing Sec 174 to stand is a slippery slope to classifying more and more everyday Americans' salaries into this category. One could argue in the future, for example, that those who design cars or operate machines to produce tooling dies, should not have their labor treated as regular expenses, but instead as capital assets because their labor output is captured in assets, just as Sec 174 treats the labor of software developers as assets. Everyday people should be concerned by this because if the rule stands, it could be extended to you, too.
For those objecting to the equal treatment of R&D employees as all other employees in America of all stripes and vocations, keep in mind that software people have to pay personal taxes on the income, just like everyone else. Section 174 doesn't have anything to do with personal income taxes: we all pay income taxes fair and square. The question is whether there is a double-tax on software labor, paid at the corporate level (and in all likelihood, your salary is currently a tax deduction for your company, unless you write software or do R&D).
I think the assumption that we are asking for "special treatment" is driving some confusion and grass-roots objection to the movement here, so I wanted to highlight that we are just asking for everyday people who work software and other R&D jobs to be treated just like every other American who works a day job.
[edits for clarity]
> Correct me if I'm wrong, but if a company hires someone to say, mine coal or brew beer, the expense of those employees is an expense any company can claim a full tax deduction on. If you're a line chef or wait tables, your salary is tax deductible to the restaurant.
The question is: are you getting the value of that work in the same tax year, or is it creating an asset that creates value over time? If you hire a guy to brew a batch of beer, you’re getting the value with that batch of beer. Once you sell that beer, the value is gone.
But if a brewery hires someone to build a fermentation system, then that person’s salary cost must be allocated to capital expenses that must be depreciated over time.
There’s a good argument that most software development is creating an asset that pays off over time. If you hire someone to upgrade the payroll software, you’ll get the value of that in future tax years.
But in that case, once the fermentation system is built, the brewery no longer needs that employee.
A better analogy is a brewery hires someone who builds a fermentation system, then continues to operate, maintain, repair, and improve the system over time. Some of the employee's time is spent on work that could probably considered R&D, some of it is on work that is clearly operation, and some isn't clearly one or the other. So how do you determine how much of the worker's salary is R&D vs operational expense? You can try and estimate some percentage, but that breakdown is at best an educated guess, and having to try and figure that out just adds pointless friction.
But that still isn't a great analogy, because in that case the fermentation system isn't the product, the beer is. So for a company that sells software, it would be more like if it wasn't a company that sold brew, but a company that rented out or sold its brewing equipment to other companies that made beer.
Also, the same argument about creating value that pays off over time could be said about most employees. An accountant could find a more efficient way to keep the books that pays off over years; the CEO could create a strategy that pays off over years; customer service staff could create a reputation for high quality customer service that pays off over years; etc.
And then, even if you assume that an engineer's salary is entirely R&D, then the only reason I can see to want that salary taxed at a higher rate is if you want to disincentivize R&D. R&D is already a large expense now in the hopes of a payoff later, and by increasing the tax burden now, you are making that upfront cost even higher.
How about actors? They produce a thing (content) that is sold for a prolonged period of time. Copyright is what, 20 years?
How would Disney feel if the salary paid to the cast of the Avengers was no longer an expense in that year, but amortized over the entire copyright period of the film.
That’s how it used to be until a special rule was introduced allowing only $15m (or maybe $20m) to be expensed instead of capitalized.
Doesn’t change much for the Avengers films which have production costs around $500m. Disney still has to capitalize 97% of the cost. $15m doesn’t cover a single star’s salary.
How does a chef get categorized? They develop recipes which have future value but also do a lot of ephemeral work product.
I think the issue is this fantasy that a software develop only produces long term IP. Or how is it different from an executive who is developing strategy and market positions that have future value?
Maybe it would make sense if we could distinguish such work products as a fraction of their total output, tracked as actual inventory that accountants have to assign value and track capital gains on?
I think the fantasy is that software is mostly like inventing the transistor. Most software is CRUD apps that are more akin to a company’s profit-generating physical infrastructure.
Repair and maintenance costs can be either operational expenses or capital expenses: https://www.nashadvisory.com.au/resource-centre/repairs-and-...
For example, if you pay for someone to maintain the brewery plant to keep it working in its current condition, that’s an operational expense that could immediately be deducted. But if the work is on upgrades and improvements, that’s ordinarily would be a capital expense that must be capitalized and depreciated. A bookkeeping strategy isn’t.
Your other examples are off the mark, because the question is whether the investment produces an income-producing asset. Software generally is such an asset. The question of what’s an operational expense versus what’s a capital expense isn’t always clear cut, and is the kind of thing where accountants and tax lawyers have to make judgment calls.
Both cases are tax-deductible, what matters is not whether it's operational or capital, because for example building up inventory would make an operational expense a capital expense, but whether you then sell or rent/lease/use yourself/... what's maintained or repaired (then it's COGS) or you use it yourself (then it needs to be amortized)
The tax code has been optimized by the rich over the past century to extract profits out of industrial firms and that's where the difference comes from. $100 used to, say, produce a car or a cake that you then sell is immediately and fully deductible from tax because otherwise industrial companies just outright can't survive. Hell, you get to claim back/not pay any VAT and/or sales tax you paid for anything related to them. One way to see it is that these rules are designed to get money to the (existing, "old-money") rich, so when investors don't get money, the government doesn't get money.
If it's equipment for the company to use itself, then it has to be amortized, or more to the point, it means industrial companies can't do what Amazon did: use 100% of their free tax flow to grow "tax-free*" instead having to give that money to the government and investors (15-35% to government 65-85% to the rich, sorry, investors), so they can use it for their own ends.
I'm not judging one to be good or bad, just attempting to frame this correctly. I should perhaps point out, as a last point, that this is a massive difference between the US and European countries. In Europe, investors and governments try to have their cake and eat it too: there's tax due (amortization rules, or worse) on new company creation, on company growth, except of course, for the companies of the rich: you can grow financial capital in companies without paying a cent, money, shares, obligations, ..., just nothing else. That's yet another connection to the rich, to investors. New employees, new buildings, ... are double taxed, only money isn't. In Europe, there have only ever been exceptional cases where it was otherwise. In the US "tax-free" new company creation has been the norm for all of history except since Trump changed this rule.
* between quotes because they still have to pay income tax on any wages, sales tax on any purchases, ... it is very far from tax-free, but such companies wouldn't pay a dime to investors. If they did that would make it very hard to create new companies (which is what this regulation does). Amazon's great accomplishment is not AWS or anything like that but 2 financial accomplishments: first, avoid sales tax, second, avoid paying anything to investors. Whatever business Amazon is in is nothing but a tool for that financial engineering.
The difference between a fermentation system and software is that right now, software changes fast enough that five years is a long time.
While there are software that are still in use from five years ago, there are plenty of obsolete software no one is still using made five years ago.
The tax code accounts for that by providing different depreciation schedules for different kinds of assets. For software the catch-all depreciation schedule is 3 years: https://www.irs.gov/publications/p946.
Is 3 years reasonable?
If we are making say, a point-of-sale software rolled out in a fast food franchise (let’s take Chick-fil-A since they have edge Kubernetes deployments), is it reasonable that we won’t add features to that software in 3 years? Perhaps.
What about bug fixes? Is that expense or should we expect time spent on bug fixes to also be depreciated in 3 years?
What about configuration? Does configuring that POS for new menu items count as software development, and therefore needs to be depreciated over the next 3 years?
Chick-fil-A has edge Kubernetes. Does the install and implementation itself counts as “R&D”? If we argue that configuration can be expensed, then would writing manifests be depreciable or not? What if we use “infrastucture as code” tools such as Chef?
What about say, excel sheets and macros? Or forget macros — just basic use of a spreadsheet. Some manager add in a summation to a column to compute totals. Very basic stuff. Is that software development? If it is, would that be depreciated over 3-years?
If we argue that this is normal use of excel and should not be depreciated, then why wouldn’t my normal use of a compiler and editor also count as normal use and should not be depreciated?
Whether it is 5 years or 3 years, the point is that unlike physical capital goods, software changes very fast, even if the underlying hardware wasn’t changing that fast. It is not always that expert designers build them — software can also be written in a way where end users modify them. We also use software to make software, and can rapidly change our tooling in a way that we cannot with physical capital equipment.
I see the merit in categorizing software as capital, from an economic theory point of view, but software also has its own dynamic that is distinct from physical capital equipment. A tax code that does not acknowledge that can bring more overall harms to the society.
Software engineering is not just about building new things. I'd propose that by far the majority of the time of software engineers is spent on maintenance, bug fixing, minor incremental improvements, etc. Almost all software is either sold directly as a service or as a product with a servicing agreement.
> most software development is creating an asset that pays off over time
This is a fantasy.
Yeah this is the most plausible interpretation.
Software engineers being taxed similar to brewery design engineers seems reasonable, not the person literally brewing each batch of beer.
What about oncall? What about fixing bugs, or KLO, or security patches, or devops, or tweaking feature flags, or dealing with customers?
If you're 100% allocated to a greenfield project that's behind closed doors until 2027, sure. But it doesn't seem like most software engineers are in that bucket. If anything, the industry has been consistently moving further away from that, with more agile methods, tighter feedback loops, etc.
Right, many software jobs are more like being a janitor or repairman. Or even more of a personal assistant or retail worker who is providing ephemeral service to another participant in the whole organization.
Though put that way, it seems hard to rationalize high salaries for software roles where this tax deduction would apply. Granted, supply-and-demand, but still.
Why? Just because it's mostly maintenance doesn't mean it isn't a high skill job.
Good point. One could say a doctor is the same job as a mechanic, but that doesn't capture the whole story.
I don't understand the reasoning behind this, however. Why depreciate anything over multiple years vs just deducting it in the current year? Does it not all come out to the same amount to the IRS in the end?
The usual thinking is that a business wants an asset’s upfront expense spread over the years that asset earns income to reduce taxable profit in future years. In other words, the IRS receives more upfront but less total in the end.
The problem is that R&D and software development behave more like recurring annual expenses, not upfront investments in something like a building or industrial equipment. Small VC-funded startups may not exist long enough to reap the long-term benefits of depreciation.
> In other words, the IRS receives more upfront but less total in the end.
Assuming positive inflation, the IRS receives more total, because the taxes they get paid now are worth more than the same amount of dollars they give back in later years. And if the company goes out of business, the IRS never has to give those taxes back.
> In other words, the IRS receives more upfront but less total in the end.
How so?
this change was a timebomb used for CBO engineering purposes: to make a particular budget appear to have a specific delayed deficit behavior.
The tax code strives to minimize distortions (except insofar as they are deliberately introduced). That is, it seeks to minimize how much the existence of the income tax changes people’s economic conduct.
To minimize distortion, the income tax must accurately compute “income”—the actual increase in wealth. Depreciation is part of that. To compute income, the net increase in wealth, you need to subtract costs from revenue. When you buy an asset, your wealth doesn’t immediately increase or decrease—it simply changes form (from cash to an asset). The actual cost is the depreciation on the asset, which occurs over time.
Say you buy a delivery vehicle for $50,000. In the first year, you make $100,000 in revenue and have $20,000 in operating expenses. What’s your income after one year—the actual change in wealth? You have $80,000 in cash after operating expenses, plus a vehicle that you can sell for maybe $40,000. So you have $100,000+$40,000 in cash and assets in minus $20,000+$50,000 in cash and assets out, for a $70,000 increase in wealth.
Calculated another way, you have $100,000 in revenue-$20,000 in operating expenses-$10,000 in depreciation = $70,000 in income. Now, over say 5 years, you’ll depreciate the full $50,000 cost, and the total dollar amount the IRS gets will be the same. But it will get more taxes in the first year, which due to the time value of money is worth more than getting the money in subsequent years.
For clear, fixed assets this is a quite reasonable approach, although in some categories the depreciation rate isn't an accurate model of reality.
The problem is those of us who deal with code only rarely are actually just building a vehicle. It's an ongoing activity that more resembles maintenance than the outright purchase of an asset.
Look at how much software is going to a subscription model. That only makes sense if there is ongoing improvement to the software.
If I hire a bunch of people to build me an apartment building, I deduct the full cost of their salaries in the year I pay them, even though once they build the apartment building, I get the value of that work over the following years.
How is that any different from hiring a bunch of people to write some software, that I then get the value of over the following years?
> If I hire a bunch of people to build me an apartment building, I deduct the full cost of their salaries in the year I pay them
That’s not how it works in general (there are exceptions though): https://www.law.cornell.edu/cfr/text/26/1.263A-1
How are other kinds of engineers such as automotive engineers treated at companies like Ford, or aerospace engineers such as at Boeing?
This wasn't my first impression of this, but the more I heard this dicussed the more I'm forming an opinion that there might be some intentional parts of this that while maybe not being good, make sense from a certain narrow perspective.
My assumption is, if tax folks in the US were looking Jealously at US companies with large Multinational presence declaring a lot of their profits abroad. They might have noticed that some of them have large dev presence in US, but through complex accounting, IP transfers, licensing and other actions are able to claim that majority of the value is generated outside of the US.
If a company had, say, 100k software devs, 50k in the US, and 50k scattered across other countries, but claimed the value of it's software was primarily in Puerto Rico and Ireland... In that case, I'd expect questions around the 50k devs in the US.
Is software dev the only activity where this is possible - no, but is currently by the far the largest and the largest growth industry.
If the issue is with general tax compliance of large multinationals, then congress should have done something about that. This tax rule has hit small software businesses particularly badly, so much so that it'll practically strengthen the quasi-monopoly of established players.
> strengthen the quasi-monopoly of established players.
When are we going to break the majors up already? Google should be like seven different companies. YouTube is bigger than Netflix for Christ's sake.
Demand antitrust enforcement!
There's so much value pent up and wasted in Google today that it'll be worth more as divisible parts. They're practically giving half of the value away for free and wasting it on implementing the same thing four times before cancelling it.
And Apple and Amazon...
These giants are basically stifling the US startup ecosystem and putting a valuation cap on innovation. They're also ripping apart other industries by moving in and undercutting costs with subsidized offerings detached from the underlying economics. They're like invasive species destroying the ecosystem, eating up everything, completely immune to competition. And if that's not reason enough for you, they're putting massive wage pressure on our profession.
Small business software has largely been offshoring their development teams for years anyway.
For a long while now, every small US-based company I look at hiring engineers have their teams in South America or Eastern Europe.
Unfortunately by trying to "fix" this, they've caused massive US software developer layoffs. So even less tax revenues. And an even weaker economy.
Has this tax change been mentioned in any earnings calls as a reason for layoffs. Perhaps if that evidence could be found it would bolster the argument being made here. Didn't someone have all earnings call transcripts in a large database - perhaps an AI can find evidence of this?
While this modification may contribute to layoffs, the general declining economy is the real culprit — the layoffs started long before the tax code change.
There is some sense to this: It's a stealth tax increase done for budgetary reasons.
Since we tried to go to a pay-as-you-go model on bills the tax code has turned into an absolute shambles as the congresscritters look at how to tweak things to "produce" (look at the IRA withdrawals--it produced nothing, just moved some money forward one year while creating a trap that many have fallen into) the desired revenue to cover whatever the bill costs without "increasing taxes."
> One could argue in the future, for example, that those who operate machines to produce tooling dies, should not have their labor treated as regular expenses, but instead as capital assets because their labor output is captured in assets,
In the future? That's how it works!
> just as Sec 174 treats the labor of software developers as assets.
[I was wrong about the following. I misread the text - and the submission title.] That's not what 174 does.
Fair enough, that was not the best example.
But I'd also observe that since business owners have to capitalize the wages of the machine operators producing injection molds, then there is an advantage to outsource the whole operation.
Comparing a procurement manager and a CNC operator [the person running the milling machine making a mold] paid the same amount, the CNC operator has a bigger negative impact on the businesses' bottom line, because the business can't expense most of the CNC operator's wages in the current tax year, whereas the procurement manager is generally accepted as fully deductible expense.
Of course, the labor that went into making the mold is effectively built into the acquisition price of the mold, so you haven't gotten rid of it by outsourcing it.
But, by building it into the price of an outsourced mold, one can delay the purchase of the mold to next year to improve the P&L this year, but you can't similarly delay the wages of the tooling operator to a later date.
So, when a CFO is looking for a way to improve the P&L in a given calendar year, there's an incentive to cut operators who build factories, tools, and other assets that have to be amortized, and replace them with more flexible outsource options.
Of course, part of the reason mold making left the US is wages are lower outside the US. But I'd say the current situation with software engineers is a datapoint that demonstrates the impact of expensable versus amortizeable labor on employee retention. It could be that if the tax code is not fixed, the same "CFO logic" would lead to more and more software being outsourced over time, as management is an immediate expense, but software engineers are not.
I suppose one can then argue, why should software engineers get special treatment compared to tooling operators; but then I would counter-argue that perhaps tooling operators should have gotten better treatment so we could have retained more of them in the US.
>as management is an expense, but software engineers are not.
is manager of AI agents (especially when they become more productive and capable than people) going to be a manager or software engineer?
IF they are a manager, then they are managing people. Are you paying appropriate salaries and benefits to your AI agents? Does HR have them in the system?
...no, not a manager.
Aircraft are also more productive and capable than people in specific activities, and useless wastes of money in others.
>IF they are a manager, then they are managing people.
Not really. For example for L1, a visa for managers and executives, managing people isn't a hard requirement, instead it may be "employee’s ability to manage an essential function of the organization at a high level, without direct supervision of others", and thus project managers and architects and even senior engineers make the cut.
Handling capable AI agents would seem to fit if those AI agents perform "an essential function of the organization" and you manage them "at a high level, without direct supervision of others".
source?
https://www.law.cornell.edu/cfr/text/26/1.263(a)-2
Example 4. Acquisition or production cost. D purchases and produces jigs, dies, molds, and patterns for use in the manufacture of D's products. Assume that each of these items is a unit of property as determined under § 1.263(a)-3(e) and is not a material and supply under § 1.162-3(c)(1). D is required to capitalize under paragraph (d)(1) of this section the amounts paid to acquire and produce the jigs, dies, molds, and patterns.
which applies for the part of the work producing a tangible asset; it was an option for software development before. Now all software is considered such an asset, which is a huge change and distinct from how other labor works
You asked for a source for https://news.ycombinator.com/item?id=44233155
I thought it was for the first paragraph.
But I was wrong about 174, maybe you meant that.
Taxes on income or capital inherently reduce income and capital. Ditto for sale taxes, which reduces transaction volume.
This is bad for the economy and ultimately reduce our tax base.
About the only thing that doesn't happen is for non-reproducible privileges such as land, intellectual properties, the electromagnetic spectrum, etc.
Taxes reduces taxes?
So are you saying that 0% rate taxes would capture the most tax?
> Taxes reduces taxes?
Yes. It’s a second-order effect. Imagine if there were a 100% tax: the government would probably get no taxes, because there would be no economy.
> So are you saying that 0% rate taxes would capture the most tax?
No. There’s a sweet spot. Everyone argues about where it is, but obviously 0% and 100% tax rates would both be problems.
It all depends on where you apply the taxes.
If you tax inputs but not outputs, then a 100% tax rate increases the cost of goods and services but does not necessarily kill the business.
If you tax income, then a 100% tax rate kills all income. However, income taxes are usually progressively, so a 100% marginal tax rate places a cap on income, but income below that can exist.
If you tax profit, a 100% tax rate leads to shifting profits to reinvestment and salaries and benefits.
> If you tax profit, a 100% tax rate leads to shifting profits to reinvestment and salaries and benefits.
There wouldn't be any money to reinvest into salaries and benefits, because capital would not be deployed on a risky, potentially money-losing venture without the possibility of profit.
There are taxes on things which generally don't have this kind of effect on supply such as land, because land is an inelastic supply because it cannot be destroyed.
However if the tax is too high then it would cause land abandonment.
Notice I note categories where it is fine to levy taxes without seeing a reduction in supply.
If you tax the usage of the electranetic spectrum too much, you would get no usage but the electromagnetic spectrum would still be there.
Not all taxes are in income or capital. Some are e.g. on consumption (gas, cigarettes, carbon, etc). There’s an argument that in place of corporate income taxes, we should let companies reinvest freely (or pay dividends), and then recoup the taxes elsewhere. The Planet Money podcast has a classic episode about this and other aspects of a presidential platform most economists could agree on.
I'm heartened to see this downvoted, since it's basically tax-trolling.
Yes, there are people who think tax==bad. Most people (and for a century or so) have understood that taxes are ultimately spent, and normally with a "multiplier". That is, on something which actually stimulates further economic activity.
Corporate profit, OTOH, normally just satisfies the rent-seeking economy, which is not productive in any natural definition. For instance, dividends and stock buybacks. Yes, some corporate profit feeds entrepreneurship, but that's simply not a large fraction of the corporate economy.
It's simply pointing out that taxation of economic activity is detrimental to the state, not that taxes are evil. This should be avoided as much as possible unless truly necessary.
The state can still tax in two ways, taxes on undesirable negative extremity such as products that give you long cancer, and unreproducible privileges. I listed those examples. There may be ground for taxing extreme wealth but I want to see extreme inequality fixed first.
I am not even disputing that the government spending encourages economic activity, but we should at least not shoot ourselves in the foot only to heal the foot with another hand.
I am advocating for the interest of the state.
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.
Just to drive the point home very explicitly:
That means, in the given example above, you are able to deduct $180k that first year instead of $900k.
That gives you a profit, from a tax perspective, of $820k.
But you only have $100k of actual dollars.
Good luck paying your taxes!
This seems like the biggest reason behind the mass layoffs, not the end of ZIRP.
With ZIRP it would be relatively easy to borrow the float required to make up for the amortization timeline.
How do you land on likely causality here?
It sure seems like it could be related, but I don't know where to begin finding what actually caused layoffs across multiple companies.
Only if you assume that the 900k in costs is exclusively the salary of 5 engineers. Realistically you will employ other people and have overhead costs like rent, etc., and I assume that other non-salary costs (health insurance, etc.) aren't included (b/c I assume health insurance, like rent, is a company-wide overhead cost and that companies aren't expected to carve out what portion of that is going to the software folks but what do I know?).
But if we more realistically assume it's 3 software folks at 200k, then the taxable profit is 580k (100 profit + 3*(200k salary - 40k ammortized))
1M eng salaries, 5m revenue, 4M other costs.
Today I am cash flow neutral at 5m revenue, but with this I'm paying taxes on 800k "profits", which don't exist anywhere but on paper. But I have to pay the taxes in real dollars.
This is going to sound silly but you paid 800k in profits, but now have 4 years of banked costs you can use to _reduce_ your profit margin.
So you pay taxes on 800k profits, but then each subsequent year you reduce you profit by 200k, even though you don't have 200k leaving the door.
If 1M eng salaries was your stable state, then after several years you're... going to have 1M in costs to subtract from your profit! The stable state is the same!
I'm not going to argue about the capex change being "good", I do think it's worth highlighting that for large enough companies you're now looking at a different flavor of tax flow. Amortizing your costs over 5-10 years is something people like doing for other costs after all.
A few large companies with big cash stockpiles and profit can eat this the first couple years, not so for startups and companies with thin margins.
This is why it's bad. Large incumbents can manage this and then in steady state it's the same.
But for any new entrants that need to rapidly grow their engineering teams, it's a huge disadvantage.
We don't need more things in the tax code that protect large incumbents at the expense of new entrants.
It becomes a cashflow issue for startups. While the stable state is the same (not really the same, because of how companies evolve etc), cashflow issues in early days means $$$ from the VC money that I could've used to grow the company, now goes towards taxes for 5 years. That could be make or break for small companies.
If you have a pile of cash that you have no apparent use for, or can live without, yes, it makes no difference.
The point is that if your revenue covers their salaries/contract costs, you will owe tax on 80% of their salary in the first year.
> That gives you a profit, from a tax perspective, of $820k.
> But you only have $100k of actual dollars.
> Good luck paying your taxes!
a lot of people here are conflating "taxable income" and "the amount owed in taxes" for some reason.
if I earn $100/year, and I can deduct $50 of that, my tax bill is not $50. It is some percentage of $50, usually a low number for businesses. (Amazon regularly pays $0/year in taxes.)
depending on the tax rates and the locality of that business, the amount owed on tax is going to be anywhere from $0 to $50, and it is going to heavily favor the low end of that spectrum. I don't think any business pays 100% of its taxable income in taxes unless they have been heavily fined.
$100k is likely far more than enough to pay the tax on $820k of taxable income for a business. It could be enough to pay that tax bill 10 times over, it's hard to say.
my point is that taxable income != tax owed.
(Not a tax professional) The federal corporate tax rate is 21% and for states it ranges from 0 to about 9%.
So generally you're going to pay at least 21% or $170k for those "profits."
LLCs pay 37%, not 21%. Plus state plus local. This can reach 50% in high-tax areas like CA or NY.
> Amazon regularly pays $0/year in taxes.
They *were* able to, because they *were* able to offset the cost of developers instead of having to amortize it out over 5 years.
For Amazon, this just costs two years on the taxes. They'll still be able to claim depreciation of this year's dev work for the next four, though.
> if I earn $100/year, and I can deduct $50 of that, my tax bill is not $50. It is some percentage of $50, usually a low number for businesses. (Amazon regularly pays $0/year in taxes.)
It’s not that low. Federal corporate tax rate is 21%. So you would be on the hook for $10 in taxes.
My taxes (flow through LLC) are significantly higher than my income for 2024 (like hundreds of k).
That's nuts, since a payroll should never be considered an asset. That's trying to put a material value on software, and doing it based on the salaries of developers is as crazy as valuing it in lines of code.
The value of software could be based on something more realistic, like a percentage of actual revenue, but I suppose tech giants would be against that.
> That's trying to put a material value on software, and doing it based on the salaries of developers is as crazy as valuing it in lines of code.
Software clearly has material value. For software that is built, not bought, the company building it clearly values it exactly enough to pay the salaries of the software developers building it. What other estimate of its material value is better than the one that the company purchasing it is demonstrably willing to pay?
The argument I’ve heard is it specifically makes investing in speculative software (new product lines, new features, etc) more expensive.
If you’re doing new drug discovery at a bio-lab, treating all your failures as depreciating “assets” seems bonkers. The same seems true of much software development where the work product ends up thrown away.
How does this compare to a machine that breaks and is thrown away before its amortization is complete? For the machine can you immediately deduct the remaining amount or is it required to continue to spread the value over the original time period?
I would imagine software that is thrown away should be similar?
Generally speaking, yes, you can immediately deduct the non depreciated value. Most machines will be scraped, giving them a "scrape value". You would immediately deduct the difference.
In fact, sometimes when you dispose of an asset, you get more for the scrape than you have left in depreciation- and you have to take that difference as a profit.
I don't get this. You speculative spend 1 million dollars on a new thing. It fails. In one universe you get to deduct 1M from your profit in year 1. In another you get to deduct 1M from your profit, but over 5 years.
I understand the pain for small companies and it's a strain on cash flow, but for larger companies with "real" revenue streams and profitability is this that much worse?
The cynical thing might be that this helps out big corps by preventing smaller corps from spending their way to success.
It increases the real cost of engineers. The government is keeping that money interest free, which means the company is losing the time value of money.
In addition, it gives companies less flexibility to manipulate their tax burden and cash flow, which makes engineering a less appealing investment to the bean counter.
Yes, this hurts smaller companies with less capital/cash flow more than larger companies.
The answer to this seems obvious to me: let the company publish all code and documentation pertaining to failed experiments and release it into the public domain to be allowed to fully depreciate it immediately. If it is actually worthless, they should be happy to do so.
That doesn’t follow. Code can contain extremely sensitive and/or valuable IP independent of the value of the code as an asset. Reduction to practice frequently fails to produce usable software.
That's why I didn't just include code; if you produced valuable design docs as part of your work, that was part of your research too. I'm generally skeptical of the societal utility to offering any protections or special treatment for trade secrets though (the entire point of patents/copyright is to incentivize people to share these things; it's insane to also protect their secrecy), so that no doubt affects my thinking. If you want the deduction for having spent money on R&D that you didn't think was valuable, prove it by giving it up. If it's entangled in other secrets you don't want to share, you get no deduction. Seems fair to me.
That is making assumptions that aren’t based in reality. Serious software R&D stopped relying on patents and copyrights years ago because they are effectively non-enforceable in many cases.
A significant percentage of algorithm and foundational computer science R&D in software is now protected exclusively via trade secrets. There are no other practical options. This wasn’t always the case but all other forms of protection have steadily eroded over the last couple decades.
Weaponizing the tax code because you have an ideological aversion to trade secrets doesn’t seem fair to me.
It's not really "weaponizing the tax code because of an ideological aversion"; it's more:
* It makes sense to tax capital assets as such.
* If companies do R&D and think the results are valuable enough to be kept secret, then obviously they're an asset.
* Depreciation is because real-world assets actually require ongoing maintenance or become worthless over time, but information does not.
* Finite-term IP grants (e.g. copyrights/patents) do become worthless over time, so a depreciation schedule makes sense.
* Trade secrets never expire, so it doesn't make sense to depreciate them. If they never get out, they remain an asset forever. So their development shouldn't be deductible. If they do get out, the company could release all of their (now presumably useless) info on it then for the deduction from their development.
The point about finding trade secrets to be dubious is that it seems natural to tax them as an everlasting capital asset (since that's what they are), and I don't see why we wouldn't do that since society doesn't eventually get the benefit of that knowledge, so incentivizing it runs counter to the purpose of IP law. Why would a knowledge economy provide a tax deduction for developing knowledge we don't eventually get?
As long as the same is held true about car designs that never went to production, drug design that were not deemed profitable etc. Why pick on just software?
Yes, clearly the same reasoning applies to any copyright, patent, or trade secret (and we should stretch out the depreciation schedule to match the durations of those things. It follows that development of trade secrets would not be deductible. Perhaps a new category of escrowed expiring trade secrets could be created to make it deductible). We could all benefit from companies publishing research that didn't pan out, and it should come at little to no cost to them!
As much as I like this Utopia, this will unfortunately never happen in a capitalistic country.
By that logic so does an accounting book by an accountant, so does an inventory log by a factory hand, ...
It's not a question of what its material value is.
It's a question of whether it is a capital expense that is required to be amortized over 5 or 15 years, or a regular expense that can be deducted in the year in which it is incurred.
The price at which it sells the said software? Aka profits after expenses?
> The price at which it sells the said software? Aka profits after expenses?
A vanishingly small percentage of software is sold.
If we are being pedantic, sold or rented. I think the issue is on how the concept asset depreciation is applied blindly, as if dev salaries every year is the asset value every year. Unlike other asset classes, there is no easy to way value software beforehand, because you are not buying it from some market.
> software that is built, not bought, the company building it clearly values it exactly enough to pay the salaries of the software developers building it
Even in the absence of the Trump tax rule, a software company values the software they are building a lot more in financial terms than the cost of building it. Any project where value=cost should be cut, when the value is taking into account the value it brings to the rest of the company.
This is the entire point of the business, after all: take labor, land, and capital and make something that's worth a lot more to the world than the sum of the components.
You're advertising your rose-colored glasses strongly, my friend. In a perfect world, of course—you're correct. But hiring, project management, and resource allocation are messy endeavors, so your point only rings true under ideal circumstances. The real effect this will have on industry is a chilling effect on hiring as businesses now have to risk-mitigate because of the additional taxation burden. Further, I see this hurting small and less-well resourced companies relatively more so, as they now need to be more scrupulous over hiring.
Not at all, this is a fundamental difference in pricing and costs. The value of an asset is its price, not its cost. When a firm sets out to buy something for X from a different firm, they value it at X. When they build something with internal resources for a cost of Y, they do not value that asset at its cost Y.
how about all the projects that fail all over the world, all the time? what is the material value of those?
That's trying to put a material value on software, and doing it based on the salaries of developers is as crazy as valuing it in lines of code.
I'm not sure if depreciation is the same concept as we call amortización in my country: capital that counts as investment instead of expenses because you're expected to keep extracting value from it over the years, so you can't get a deduction for the whole expense when you first pay for it.
If that's what this is about, it's absurd not for the reason you say (salaries are not a bad proxy for value, since you expect the profit will be greater) but because you'll probably keep paying for maintenance and evolving the software.
Exactly. We would love software development to be as simple as: you pay $1m to engineers to develop a software machine; you now have a $1m software machine that you can pay nonengineers to operate and crank out revenue.
In practice software machines need constant tending and operation by engineers in order to keep them pumping out money.
In the context of live software systems, a lot of software engineering - even engineering that involves innovation and creative research and problem solving - is done in service of making the machine continue to operate; it is operational expense.
It’s like: Buying some filing cabinets is clearly a capital expenditure. But paying an office administrator to come up with and keep modifying the filing system you use in those filing cabinets to make sure it continues to serve your business is not capital investment, it’s business operational costs.
Many people use depreciation and amortization interchangeably. From an accounting perspective one uses depreciation for tangible assets (can be touched and seen e.g. machinery) and amortization for intangible assets (e.g. trademarks and R&D). Depreciation and amortization behave the same way - they decrease an asset by expensing a portion of it on a regular basis.
If you buy a building, it is a capital expense that depreciates over years, even though you absolutely have to keep paying for maintenance. Why should software be different?
if I pay a bunch of employees to take the cloth I buy and cut and sew into shirts, that's an expense some directly out of my revenue and isn't taxed as profit or forced to be amortized. Why should software be different?
I suppose it depends. Are you making shirts to sell, or to use in your business? One is inventory, one is a capital expense.
Unlike a building—where you might find one for sale and simply buy it—most companies don’t "buy one software" from a vendor and amortize it like a purchased asset. Instead, they hire full-time teams to build, maintain, and evolve software as a core, continuous function of the business. And most companies don’t "sell one software" either—they lease it to others, as software-as-a-service.
In your analogy, when a company constructs and sells a building, labor costs are deductible as part of the cost of goods sold. Only the profit—when the finished product is sold—is taxable. But under the new Section 174 rules, software R&D labor is treated like the purchase of a capital asset, even though the company is leasing a service, not selling a final, tangible product.
The flaw? Software isn’t a static, finished asset you walk away from. It’s a living system. One update might fix a bug, introduce a feature, and improve long-term architecture all at once. Is it maintenance? Innovation? Infrastructure? The answer is usually “all of the above.” So how does anyone report that cleanly on a tax form? What’s the IRS’s standard test for sorting that out?
Before TCJA, some companies may have stretched R&D definitions to claim Section 41 credits. But after the TCJA change, the incentive flipped. Now, companies are penalized for doing real R&D—the very thing we should be encouraging. Startups are now paying painfully high tax bills simply for building something they cannot lease out en masse yet.
We should want to incentivize invention, not suppress it. We need more startups, not fewer. Software—especially with generative AI—is one of the few options for us left that can create new markets, expand GDP, and drive compounding national growth. The upside is limitless. This is hammering our economy and it’s strangling startups at the exact moment we need them most.
Congress, do the right thing; restore the rules we had pre-TCJA.
Timeline:
- 1981: Section 41 introduced — provides tax credits for qualified R&D activities.
- Pre-2018: Under Section 174, R&D expenses (including software) were fully deductible; Section 41 credits could be claimed.
- 2017 (Dec): TCJA passed by the 115th Congress and signed by President Trump; Section 174 expenses to be amortized over 5 years starting in 2022.
- 2022: Amortization rule takes effect. Companies must now capitalize and amortize R&D expenses.
- 2025: Section 174 amortization remains in effect; Section 41 credits still exist but now come with a steep tradeoff.
But the idea behind capitalizing research and development is to eliminate the difference in financial presentation between buying and building software. In both cases, one pays cash to acquire the software then uses it over a period of time to generate revenue. Purchased software is clearly capitalizable. It is then amortized over the expected useful life of the software. Annual maintenance fees are not capitalizable as they are not expected to extend the useful life of the software. Allowing R&D to be capitalized just evens the playing field.
If R&D were not allowed to be capitalized, then a company would have an incentive to create a specific entity to develop its internally used software, then sell that software to parent company. If it set up the entities properly, it would capitalize the software as purchased software rather than R&D. Many firms with international development teams do this to manage in what country they pay taxes - the goal being to derive no value in high-tax countries and high value in low/no tax countries.
> That's nuts, since a payroll should never be considered an asset.
That's because it's not "a payroll". When a payrolled resource builds a combustion engine that powers the office where the rest of the payrolled resources work every day and that engine lasts 15 years, then its a very clearly a capital expense and an asset.
Under these rules no. If the "machine" is software, payroll is considered a capital expense and an asset. If it's an actual machine, payroll for building it is fully deductible, like most other payroll.
Software used to work like other payroll until fairly recently. If you want to understand this figure out why that changed and what the actual motivation behind it was
> If it's an actual machine, payroll for building it is fully deductible, like most other payroll.
Not if the machine is used as an integral part of manufacturing, production, or extraction, or an integral part of furnishing transportation, communications, electrical energy, gas, water, or sewage disposal services by a person engaged in a trade or business of furnishing any such service, or is a research or storage facility used in connection with any of the foregoing activities.
> That's trying to put a material value on software, and doing it based on the salaries of developers is as crazy as valuing it in lines of code.
We all do this at the conclusion of every successful job interview. And performance review. And budget review. IMO it's a reasonable floor on the value engineers produce: if you produced an asset worth less than your salary you should be concerned for your career.
On what time scale? In a year, sure. But there are certainly days (weeks?) where the actual value produced by any one engineer is zero, or negative.
This whole discussion is sort of orthogonal to the real point, though. The state (or the IRS, or Congress, or whatever) has decided that for some reason, if Jim gets paid $100k his boss can deduct $100k in expenses, but if Jane gets paid $100k her boss can only deduct $20k, because she's typing different things into a different box the computer.
This is a categorically stupid thing to assert. It's a stupid thing to say and it's a stupid thing to believe. Payroll is an immediate cost, paying for the development of software is not remotely the same thing as purchasing a capital asset, and this is exactly what we get when we keep electing nonagenarian plutocrats to office year after year, decade after decade, who think the internet is a series of tubes.
> On what time scale? In a year, sure. But there are certainly days (weeks?) where the actual value produced by any one engineer is zero, or negative.
Well, that's what I had in mind, but the concept is why agile focuses on shipping early and often. Well, mostly it's to get in more feedback iterations, but engineer hours are not immune to time-value of money analysis.
> This is a categorically stupid thing to assert. It's a stupid thing to say and it's a stupid thing to believe. Payroll is an immediate cost, paying for the development of software is not remotely the same thing as purchasing a capital asset
But it's also not like paying a janitor to clean toilets and empty wastebins where we know there's no residual value accruing to the employer. Companies do buy and sell intellectual property in the form of copyrighted code, and in the form of patents. Heck, ARM basically makes a living licensing out the cores it designs.
This obviously isn't perfect and the disparate impact has unintended consequences that could make things worse overall, but the accusations against the senate are a non-sequitor given the power of the purse lies in the House.
Why is software special? Why is all other payroll not treated like this?
In reality, this is something made up to balance a budget while pushing the consequences beyond the next election. It isn't a well intentioned accounting principle
It’s not just software. Software developers are just the most vocal people talking about it. I worked a company that owned nuclear power plants. We did R&D on how to make the power plants work more efficiently and safely. Some of the work we did qualified as R&D and could be capitalized. This mattered as the US government gave tax credits for eligible R&D. The tax credits directly reduced your tax bill.
Out of curiosity, why were software engineers carved out? Was this a punishment against the tech industry? With 45/47's administration there is always some either profit angle for his friends or retribution angle for something.
Forgive the naive question, but is this different than other payrolled employees? So for normal employees you get the deduct the year it's paid, but for some reason for software developers you have to amortize it?
Theoretically it’s the same with any asset you pay someone to make.
If you pay someone to make a chair, you don’t deduct the salary. Instead you create an asset valued at what you paid to build it, then depreciate it over time.
The arguement for this is that it would be inconsistent to do otherwise. After all, why should buying a chair from someone else be different than paying an employee to do it?
It’s worth noting that this change brings the USA in line with international financial reporting standards, so it’s not like it’s some crazy unique idea or anything.
> Theoretically it’s the same with any asset you pay someone to make.
No, it's not.
Sec. 174 explicitly and specifically refers only to software development.
Also, this:
> If you pay someone to make a chair, you don’t deduct the salary. Instead you create an asset valued at what you paid to build it, then depreciate it over time.
is also incorrect. For most tax filers, and for most things, under current law, you have a choice whether to deduct the expense in the year in which it incurred or to amortize it.
If you pay an employee to make a chair, you 100% deduct their salary, immediately. The chair is only a capital expense if you buy it from a company that sells chairs. The company selling the chairs isn't forced to amortize the salaries of their carpenters, so implying that it's normal for companies to be forced to amortize the salaries of their software engineers is, in the most generous possible interpretation, a gross misunderstanding of the law.
> this change brings the USA in line with international financial reporting standards
Which ones?
If you pay people to make 1000 chairs that are just sitting there, do you really think that you don’t have an asset on your books at all? This is called Inventory. It’s certainly an asset.
And an asset doesn’t come into existence out of nowhere. It comes into existence because you paid money for it. And the money you pay for it is indeed the persons salary.
Now sure, it’s possible to get away with not doing this, but it’s not correct by accounting standards to do so.
As for which standards, International Financial Reporting Standard (IFRS)
What other country in the world doesn't allow you to deduct the full salary you pay your employees in one year? I've never heard of this.
>If you pay someone to make a chair, you don’t deduct the salary.
If they make the chair. What if they only draw up blueprints for a chair that isn't manufactured? What if the chair is never manufactured, or won't be manufactured for two years? Until the software is licensed and installed at a customer site, how is this at all like making a chair?
> The arguement for this is that it would be inconsistent to do otherwise. After all, why should buying a chair from someone else be different than paying an employee to do it?
Probably exposing how little I know of accounting... If you buy a chair you have to track it and deduct it over the course of X years?! It's not just an expense the year you bought it?
Most of the time you can decide what you want to do. There are exceptions but for most capital expenses (which salary is not despite what proponents of this change would argue), you can choose to either deduct all of it or amortize it. It also depends how you categorize expenses.
A $100 chair is unlikely to get amortized, but a $100 chair as part of $450k office remodel might.
> It’s worth noting that this change brings the USA in line with international financial reporting standards, so it’s not like it’s some crazy unique idea or anything.
Can you be more specific?
"Other payroll employees" is doing a lot of lifting.
The question is really, payroll is made up of builders, vs nonbuilders.
Are devs different from other builders? The dirty secret is that they are not.
Ford engineers, P&G food researchers, and architect salaries are capitalized just like Software development costs.
But, in the case of software development, only those builders are getting a nice subsidy.
A world where we treat all workers as expenses is not likely since it means the end of US GAAP. So, we must treat all builders like builders . There shouldn't be special favors for some any specific builder group.
>But, in the case of software development, only those builders are getting a nice subsidy.
This is why I can't support re-implementing Section 174. Software engineers are now being treated in the tax code like everybody else, and they don't like that change.
>Ford engineers, P&G food researchers, and architect salaries are capitalized just like Software development costs.
I'd say the majority of the posters on this thread who are answering questions (as opposed to asking questions) believe this is not the case. What is a good source for learning more about which categories of employee salaries are amortized? Besides becoming a CPA.
You can easily check that architects follow the same rules. When they work towards creating a new building their salaries are amortized
I wonder if most of the people in this thread should then change their minds on this topic, since the #1 reason seems to be that software development is being singled out.
The logic outlined in other posts is that this is because software is seen as an asset that nets dividend. As such, like with houses you can’t deduct all the costs at once because you keep extracting value out of it.
I’m not sure whether I understand why that now applies only to software and not other things.
Those arguments fall short when considering the fact that that the construction company deducted the wages of the workers that built the house. The software development firm is the builder not the home owner.
If you’re building software to use or sell to other people you are definitely the owner.
If you’re a body shop lending out devs to build software for other people, that would be different
> In the case of the $200k engineer, you deduct the first $40k in the first year, then you can expense another $40k from that first year in the second year, the third $40k in the third year, and so on through the fifth year. So eventually you get to expense the entire first year of the engineer's pay, but only after five years.
This actually understates the issue slightly. The amortization is calculated from the midpoint of the first tax year, so actually you only take 10% in the first year. Meaning it takes six years to get back to square one. In your example, you would only capitalize $20k in the first year, $40k for the subsequent four years, and then another $20k in the final year.
Normally when a business spends money producing a valuable asset, it is required to depreciate the cost to acquire the asset over the useful life. If a business pays people to create a new building, that is depreciated over 20 years. Even if it was paid for as salaries of employees, it isn't a special situation unique to software engineering.
I don't think that's quite right? The value of the asset itself is depreciated over years, sure, but the payroll itself for the employees is just an immediate expense.
But isn't the reasoning there that you could turn around and sell that building right away?
The reasoning behind depreciation is matching the income produced by the valuable asset, not really about resale value.
Presumably the value for tax purposes is based on the cost because the cost is harder to manipulate for something like software. Like some big box stores argue under the "dark store" theory they should be valued for much less because they have restrictive covenants banning competitors from using the property if sold, or that vacant property should be used as comparables.
The reasoning here is completely flawed. You don't buy a software dev, you rent him. His salary is an operational expense, that should be deductible in a year it was paid.
Now, let's imagine a company buys a slave. It's one time capital investment, like buying a car or a machine, and you need to depreciate the cost over multiple years.
The only way it makes sense to treat software developers as a capital investment instead of an operational cost is if they were treated legally as slaves. And slavery is not legal any more. Or is it?
Exactly. That’s why when a company builds a factory it’s considered a capital investment. Because it’s built by slaves. It’s not like the workers are being paid for their labor or anything.
This description is misleading (as many of them seem to be), because you're only describing the first year.
After 5 years of constant expenses, the deductions match the costs. If expenses diminish, deductions exceed costs.
-> this is bad (in the short term) for companies that are growing.
Or any company in its first 5 years of operation. (Or any company, period, within the first 5 years of the law being introduced.)
It takes 5 years to fill the pipeline, so even if the steady state would be fine, getting to that state might be impossible.
> Or any company in its first 5 years of operation.
No! Any company (with software development expenses) for the first 5 years after Sec 174 went into effect!
Most startups won’t make it five years especially if they have to raise or borrow money to pay taxes on phantom profit.
There is no rational basis for this tax change it was a vindictive attack on blue states in the first Trump admin and an attack on California and SV in particular along with the SALT tax changes.
For startups that don’t make it five years the issue is moot. Expensing the software developers compensation in year 1 rather than over years 1-5 simply creates a larger taxable loss which creates a Net Operating Loss on the balance sheet which could be used in a future, profitable year. As NOLs can expire and have rules regarding how quickly they can be used and whether they can be sold, capitalizing the R&D could be a better answer for some firms.
This. They hate CA and will do anything to try to make them look bad because we call out their BS. See Los Angeles right now as an example.
It's also bad because of the time value of money (deductions in the future are worth less than deductions now).
But I agree that much of the outrage seems due to a confusion that 80% of the deduction is lost completely (vs deferred).
Slight amendment. It's actually a little worse than you describe. Like a machine, if this is amortized over 5 years, it's subject to the "half-year convention" - the assumption is made (to keep things simple) that the engineer is hired at the exact midpoint of the year.
So for your example of a $200k salary amortized over 5 years, you can only deduct $20k the first year, then $40k, $40k, $40k, $40k, and then the final $20k in the sixth year.
> Normally, when you have expenses, you deduct them off your revenue to find your taxable profit. If you have $1 million in sales, and $900k in costs, you have $100k in profit [..]
I'm not sure it's helpful to simplify quite that much, doesn't this usually depend on whether we're talking about operating expenses (typically rent, utilities, salaries, supplies) or capital expenditures (typically buildings, land, intangibles...)?
It found it helpful that it was presented that simply. The point isn’t what else is or isn’t deductible, it’s that engineering salaries went from being deductible to being amortized.
Businesses don't get to say they're claiming "$900k in costs" ... it depends on what kind of costs... EDIT: and in this instance, it depends on what kind of software engineering.
But why is software engineering treated specially, here? Does Disney have to pay taxes on film animators the same way, given that they're developing a capital asset?
Probably that is a large, rich field, and when you crunch the numbers, collecting corporate income taxes on 80% of essentially all s/w developer salaries in the first year after it goes into effect was a nice push to the CBO numbers related to Trump's 2017 tax cuts.
This is what's happened at my workplace. We account for time spent working on developing new products differently that development time maintaining legacy applications. Because they are reported for tax purposes differently.
> Because they are reported for tax purposes differently.
For software that used to be an option.
Sec 174 removes the option.
Doesn’t this also unfairly penalize bootstrapped companies? VC track companies seldom have taxable profits.
It may result in an outsized penalty to bootstrapped companies but being VC funded doesn't make you immune to this. VC funded companies with revenue will not be able to offset their revenue by reinvesting in R&D (software development) expenses, so in some cases they may be seen as having a profit when they previously wouldn't have. In those cases they'd have a tax burden.
> you have to depreciate that over several years (5 in this case).
15 years in the case of foreign developers.
If true, that's a very convincing explanation of why this new rule is wrong.
I'm not a US taxpayer so my opinion really is irrelevant, but I was so far in the camp of "there's no reason to make a special case for big tech".
But if what happened is actually the reverse, ie, the rule makes a special case of tech/developers and pretends their salary is not a cost but an investment, that's clearly absurd and indefensible.
Tax authorities tend to look at income side rather than expense as you are. If this thing has a useful life and gives benefit over 5 years thus you get tax deductions over 5 years.
So comes down to whether you view a software engineer as something that has value only in the moment (like HR person) or as creating an enduring asset (code base).
A good code base obviously has long term value and there is no raw material input, just engineer time.
Either way you end up with awkward mismatches somewhere & the deferred version as you say has undesirable chilling effects, but I don't think it is entirely without merit either. Think of it from tax man perspective: They're being asked to hand out 100% of the tax credit today while receiving the income over years time. Switching this back to old model doesn't make the mismatch go away - just shifts it to taxman.
So the 2017 tax cuts that introduced this change were a massive boon to US companies, particularly the tax holiday on repatriated foreign profits.
So why do we need to give these large, very profitable companies another tax cut?
Or maybe we should be asking, what of the 2017 tax cuts are they willing to give up to pay for this change?
Remember that after a few years, none of this matters. You might be paying $200k in salary to an engineer and can only deduct $40k, but you're also making deductions "earned" in previous years?
Basically, I reject the argument that this change is responsible for layoffs. It is not. And changing it won't lead to a hiring binge. Layoffs exist to suppress wages in these largest employers.
Maybe we should allow a 100% software development tax deduction if the company hasn't fired more than 1-2% of its workforce in the last calendar year. Or maybe only if the workforce is unionized.
This whole thing is so anti-worker. It doesn't have to be this way.
for the big companies, this makes enough sense, but theres been new businesses opened since 2017, who did not benefit from that tax holiday. why should they be dealimg with this tax hike for everytime they grow their business?
i dont know how this is anti-worker? it's an extra cost to growing the number of people youre hiring, where you need them for 5 years. i guess businesses should start witholding RSUs and starting bonuses until youve been there for 5 years to match your tax ammortization?
ELI5: why is this blowing up on HN this particular week in 2025. Is there a trigger? As it has been known about for a while.
It's actively being discussed in Congress and is a part of OBBBA.
" H.R.1990 - American Innovation and R&D Competitiveness Act of 2025 "
https://www.congress.gov/bill/119th-congress/house-bill/1990...
> A bipartisan bill reintroduced in Congress last month could offer long-awaited relief to small tech companies hit hardest by an obscure federal tax change — one that many founders say is threatening their survival.
> Industry groups from the Small Software Business Alliance to the National Venture Capital Association and TECNA are backing the bill, which sits in committee. Over 100 House members have signed on. The bill would reverse the changes not just going forward, but also retroactively.
https://technical.ly/startups/r-d-tax-change-reversal-startu...
> On May 13, the House Ways and Means Committee passed “The One, Big Beautiful Bill.” This bill includes several provisions that, if enacted, will be important to businesses claiming research and development incentives:
> The bill would suspend the current amortization requirement for domestic R&D expenses and allow companies to fully deduct domestic research costs in the year incurred for tax years beginning January 1, 2025 and ending December 31, 2029.
https://www.crowell.com/en/insights/client-alerts/house-comm...
> The OBBBA suspends required capitalization of domestic research and experimental expenditures for amounts paid or incurred in taxable years beginning after December 31, 2024, and before January 1, 2030. Under the OBBBA, at the taxpayer’s election, such expenditures can be: deducted as paid or incurred under new Section 174A(a),
https://www.skadden.com/insights/publications/2025/05/the-on...
So is the idea here that the tech community should support the Big Beautiful Bill ?
Because that would be just typical.
I'm confused. The requirement to amortize software engineer expenses was introduced in Trump's first term, but now he wants to revoke it in OBBBA? But only for 5 years?
Besides "kicking the can" to another administration, the 5 year thing is a hack to get budget legislation past the CBO.
The CBO calculates costs over 10 years, so if you introduce a tax cut that sunsets after 5 years it looks much less bad (for the deficit) than it really is. Then you hope that in 5 years some other legislation comes along to renew it for another 5 years...
It was passed in 2017 to go into effect in 2023. Trump now wants to suspend it until 2029. You may notice that in both cases it is being passed under a Republican-controlled executive but goes into effect under the next administration. This is the point.
> Normally, when you have expenses, you deduct them off your revenue to find your taxable profit. If you have $1 million in sales, and $900k in costs, you have $100k in profit, and the government taxes you on that profit.
This is an incomplete description. The ordinary rule depends on the nature of the expenditure. If your expense is for building an asset that generates recurring revenue—including paying people to build such an asset—then you cannot immediately deduct that expense. Instead, you must depreciate it over the lifetime of the asset.
The issue here is that software development is sometimes genuine R&D and other times more like building an income producing asset. E.g. if you spend money building infrastructure software to move bits from one place to another, that’s more like a factory building a conveyer belt than it is like investing in fundamental pharmaceutical research.
See also this long-time tax discrimination against software engineers
https://www.taxnotes.com/research/federal/other-documents/tr...
Maybe this is a dumb question, but if you only deduct part of their salary in the first year, what happens if you have a software developer for several years?
And then what happens after five years if they are still around?
> Maybe this is a dumb question, but if you only deduct part of their salary in the first year, what happens if you have a software developer for several years?
Not dumb at all! In the second year, you get to deduct ⅕th of the previous year’s salary and ⅕th of the current year’s salary; likewise, in the third year you get to deduct ⅕th of the first year’s salary, ⅕th of the second year’s salary and ⅕th of the third year’s salary.
The key thing is that in the fifth and following years, a business would deduct a fifth of each of the previous five year’s engineering payrolls. This is not great for a growing business, but it’s murder on a startup trying to grow from zero.
After five years you are back to the status quo. It is a short term problem, long term there is no difference between the two. It primarily hurts young companies that don't take VC money, and shortens the runway of those who do.
It also affects hiring growth because every net new dev starts a new 5-year runway.
It is much worse for young companies for sure, but it’s not great for any company.
You’re forgoing returns on .1 * salary * tax rate for 5 years, .2 * salary * tax rate for 4 years… for every software dev in the company.
Let's be honest. At a bunch of shops the engineers hired in year 2 will never be properly recouped because the company will be out of business in less than 7 years.
Start ups are hard, most fail. But what rational national policy makes is several orders of magnitude harder to succeed during the riskiest period by adding tax provisions on pretend profits?
Seems like the incentive is to make as little profits as possible at the start to avoid being killed by taxes. I would have expected an exclusion for companies that make below X dollars or are less then Y years old.
This rule is actually desired by most (non-startups) businesses, software being an investment over a long run it makes sense to amortize the cost over several years.
It is indeed detrimental to startups though, as they can end up paying taxes even when not profitable and when cash is the key issue (which isn't the case that much for most businesses).
I agree this sounds like bad policy, but what's the logic for doing this with actual capital goods then? Doesn't that have exactly the same problem of limiting corporate investment?
The reasoning is that the deductions for expenses should be applied for the same year as the income they bring in. For expenses that will cover multiple years, they are spread out over those years.
The only logic was to make the Trump 2017 tax cuts look "revenue neutral". They were cooking the books so the CBO would give the tax cuts a passing grade.
https://americansfortaxfairness.org/ways-means-trump-tax-law... Quote: Corporations have traditionally been allowed to deduct all of their research expenses in the year incurred, even though a lot of research pays off slowly so its costs should similarly be written off over time. Adopting this position, and as a way to partially pay for its big corporate-rate cut, the Trump-GOP tax law decreed that starting in 2022 companies would have to write off research and experimentation expenses gradually: over five years for domestic research, 15 years for foreign. This requirement to “amortize” the expense over time reduces the value of the deduction, increasing corporations’ taxable income and requiring them to pay more in income taxes upfront. The Ways & Means legislation proposes to retroactively reverse this provision.
Accounting likes to recognize expenses with revenues. If an asset will be producing revenue for five years, its cost is recognized over that same time span.
So...don't you get value from the newly created software for ~5 years?
That's going to heavily depend on the type of software and whether it's sold as a shrinkwrap product or a subscription.
For example: your average AAA game will likely produce the vast majority of its value inside the first year upon its release.
At the extreme opposite end you have things like enterprise software using subscriptions, whereby the software continues to produce value year over year, but you're generally also paying developers' salaries to maintain and enhance the softare year over year. That, too, makes little sense in spreading out salaries as a cost over 5 years.
I can't really think of any cases where a piece of software is sold as shrinkwrap software, requires no ongoing maintenance/updates, and is expected to continue earning revenue for many years afterward. That just isn't the industry we live in.
> At the extreme opposite end you have things like enterprise software using subscriptions, whereby the software continues to produce value year over year, but you're generally also paying developers' salaries to maintain and enhance the softare year over year. That, too, makes little sense in spreading out salaries as a cost over 5 years.
There's also a ship-of-theseus problem here. How much change has to happen to a codebase before it's not the same software anymore?
The answer to that question can only be reliably answered in 5 years.
Actual honest valuation of software is something that requires actual evidence.
Software returns have extremely high variance. From a lot, to none, to high negative (For projects that don't complete, or worse, deploy to negative effect.)
Yep, some software systems become money pits. You end up having to pay more people to keep them running.
Only now if those people you have to pay to keep them running are software developers, you have to act like the money you’re spending on them is helping make new value, not merely paying interest on technical debt. Fun!
Mmh
If I paid salary of 100k, and invested 100k. Then I made 0 profit regardless, actually I would have a loss of 100k?
I guess the difference comes in if I made 200k, so I would have a profit of 100k.
Not sure how it affects the pnl, but is it fair to say it doesn't affect total tax, just distributes it more evenly across years?
What happens if you outsource all that to an "offshore" company? Is it considered an expense?
Wouldn’t this make the $200k drop below EBIT and thus increase accrual accounting profitability? Sure it could be less cash efficient but generally capitalizing expenses is net favorable.
Why not claim them as: admins, devops, analysts, testers, technicians, managers? Probably few more. Its really about precisely software development roles? Don't we anyway do some of that other stuff regardless?
But if you are correct that is supremely dumb, especially in place like US.
https://www.law.cornell.edu/uscode/text/26/174
> (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.
Strictly speaking every single one of those jobs falls under that role. If you "develop" any software, which arguably includes even making or maintaining excel spreadsheets (as excel is a graphical array lang inspired by APL), then you seem to fall under this umbrella.
Wouldn't "in connection" make this actually extremely broad? For example I doubt C-level executives have 0 connection to software development during the year. They likely make official or unofficial feature requests or give feedback. And if we really push that definition, if the software collected telemetry automatically from the user interactions and this data was then used to improve the software, wouldn't just using the software be connected with the development of the said software?
> Strictly speaking every single one of those jobs falls under that role
Q: Isn't this about whether you're doing "R&D" or not?
No, it classifies all software development as R&D by definition.
> it classifies all software development as R&D by definition
We may need to argue about the word "development", but in any case, do you have a reference for that?
https://www.thomsonreuters.com/en-us/posts/tax-and-accountin...
"In the United States, to help spawn innovation as part of the Economic Recovery and Tax Act of 1981, the Research & Experimentation Tax Credit was introduced. Although it was initially supposed to last three years as a specific incentive to encourage companies to invest in R&D, Congress recognized its value in helping businesses create more products and services.
However, it was quickly realized that this tax code made calculations for R&D complicated, especially for small businesses, which led the government to create other iterations of tax codes in order to help clarify the situation. However, not until 2017 and the enactment of Section 174 of the TCJA has there been such a comprehensive change to R&D accounting.
Indeed, before the TCJA’s enactment, businesses deducted the total amount of R&D expenditures as an expense in the taxable year. Beginning in 2022, all costs related to R&D must now be amortized over five years for US-based companies or 15 years for non-US companies."
I'm struggling to understand why we think R&D expenditure - including software development - should not be amortised?
People think R&D expenditure shouldn't be amoritized because it hurts startups.
For example, if you're a first-year startup and you make a software product with $1 million in revenue but pay $900,000 in software dev salaries, and the tax rate is 25%, without amoritization you pay (1,000,000-900,000)*0.25 = $25,000 in tax and make a profit, but with 5-year amoritization you pay (1,000,000-900,000/5)*0.25 = $205,000 in tax and take a loss.
But since established companies aren't affected as much, they are advantaged by the amoritization rule.
> People think R&D expenditure shouldn't be amoritized because it hurts startups
(Not trying to be deliberately obtuse but) which people "think this"? Startups and their investors, obviously, but who else?
If world+dog has to amortize their R&D expenditure, why should startups be exempt, essentially "because software dev salaries"?
> But since established companies aren't affected as much, they are advantaged by the amoritization rule.
Q: Why should startups get a specific tax carve-out for "R&D"?
> It was passed by Congress during the first Trump administration in order to offset the costs of other corporate tax rate cuts, due to budgeting rules.
Wow, so there isn’t really a good faith steel man for this? They were just like, hey, we need to offset other cuts so let’s arbitrarily pick a high paying profession that, not so coincidentally doesn’t have a lot of influence in government, and let them take the hit?
I think it was more along the line that R&D had been formally encouraged with special expensing rules and in 2017 they removed the special treatment.
>Depreciating means that if you pay an engineer $200k in a year, in tax-world you only had $40k of real expense that year, even though you paid them $200k.
what happens if an engineer leaves after the first year, or at any other time?
what happens to the calculations then?
Nothing. The calculation has nothing to do with people. It’s about what the company spends - and some kind of spending is capitalized depending on what activity it was related to and what the output was. That doesn’t change if the employee that you paid a salary to leaves, or the company that you bought materials from disappears, etc.
Wow, initially I thought this was the typical libertarian thing to pay less taxes. But thanks to your explanation, I see that the scheme is absolutely crazy. Software devs salaries, as any other employee, should be considered an expense.
But, in a second thought, if you sell a software that you hand crafted to a single customer, in Spain, the software enterprise currently deducts all salaries, while the customer has to depreciate the cost. Think about that in the likes of building an expensive machine: the manufacturer deducts all costs while the customer has to depreciate the machine cost over 20 years.
So the question is, how should a software development piece be considered when it's used internally? Why if you sell that software to others have a tax implication different than if you yourself use it?
That's a very difficult question to answer with too many edges.
So, after 5 years, they can deduct the entire salary.. this just seems like an incentive to promote long-term employment. Doesn't seem like a bad incentive.
No, this is not how it works. They can still deduct the entire first year of salary even if the person is let go, as that salary is considered a capital expense. There is no incentive to keep the person on payroll because of this policy.
The idea that this is leading to mass developer layoffs is an overstatement.
The total amount spent will ultimately be expensed, whether immediately or over five years. The sole impact is on the time value of money, which I don't believe warrants the current scale of developer dismissals.
Also, the claim that taxes are levied even during a deficit seems incorrect. While I'm not familiar with US tax law, it's typically possible to carry forward losses.
For example, if a developer is hired for five years at $100 annually, the expensed amount in the fifth year would still be $100, even after any legal changes.
It means you need more money early, to pay taxes on theoretical future profits. That means it costs more. That means you can afford less on the same money. That means that you need to lay off people to maintain the same costs.
I don't want to downplay what you're saying but many of these costs are eligible for R and d credits unlike most other employees salaries.
Does it apply to solo companies that provide software consulting to others? I guess it doesn't for S-Corps, because of passthrough, but might for C-Corps?
Section 174 just brings the treatment of software engineers in line with the way that manufacturing labor is treated in all other industries. If tech hadn't exploited this loophole so hard to invade other industries, the GOP probably wouldn't have tried to close the loophole in 2017.
That being said...the current version of the bill would temporarily pause the current version of section 174 (capitalization of software labor costs). There's no way for them to make the original treatment permanent without adding another trillion or so to the cost of their mega bill.
However, the original reason for that temporary reprieve was that Musk was still Trump's best buddy at the time. Right now, it's the most likely target for getting cut in the reconciliation negotiations between the House and the Senate. Thus, YC reaching out to its readers to support this abomination of legislation.
They are just product managers and the development is being done by AI agents.
You jest, but you’ve also touched upon something interesting. Is this exactly what companies are trying to do? To the IRS: “We employ zero software engineers—only AI ranch hands to wrangle the AI in the right direction.”
How do we restore only the tax deduction and not pass the rest of the BBB?
You contact your representatives in Congress (mail, phone, in person at town halls and such) and say "hey, stop passing giant omnibus bills". You encourage others to do the same. That's all you can do, as a citizen.
Unfortunately it won't make a difference because the vast majority of Americans simply do not care. So very few people will be putting pressure on their representatives, and nothing will change.
You don't. That's how bills are passed: everyone adds a little of what they want. To the extreme, it's called "pork barrel politics", but there's a whole continuum between that and a basic compromise.
> It was passed by Congress during the first Trump administration in order to offset the costs of other corporate tax rate cuts, due to budgeting rules.
Small correction, it was a vindictive move to negatively impact companies and regions that Trump didn't like (at the time).
If you’re building software that is intended to be used for longer than a year then it should be capitalized.
The argument on HN is always just complaining that it’s unfavorable to devs; but it’s perfectly reasonable with regards to actual tax principles.
Exactly. The issue isn't whether capitalizing salaries is "humane" or "inhumane," as some comments suggest. It's about matching expenses to their corresponding revenue. When you develop software that contributes to revenue over a period, those expenses should be spread out. Capitalized items are simply deferred expenses. For example, when you construct a building, construction workers' salaries are capitalized and added to the building's book value, which is then depreciated over time.
Almost all other payroll is deductible. Why is salary for someone building a house deductible, but salary for someone building a for loop a capital expense
Look into when this started and why and you might understand it
> Why is salary for someone building a house deductible, but salary for someone building a for loop a capital expense.
If the “house” (or the for loop) is sold and gone, it’s not an asset and the cost of the goods sold — salaries included - is an expense.
If the “house” (or the for loop) is kept and used, it’s an asset and the cost of producing the asset — salaries included - is capitalized.
(There are differences betweeen the “house” and the for loop but not at the extremes which are clear. I imagine by “house” you mean some building that makes sense in a commercial or industrial context like a warehouse.)
Salary for building assets generally are capitalizable. Construction companies have a special carve out because they typically are hired to build the assets for someone else and are paid for the completion of the construction work.
A factory worker building a product to be sold is capitalized into inventory
Software engineers hired for custom, in house work are not building a fixed piece of software with the intention of letting it loose unchanged for the next five years.
Software engineers hired to build product are not exclusively building a finished product, and are increasingly necessary as part of the expense of operating that product long term. Industry trends have gone towards combining and blending developement, security, operations, and design.
There are businesses that will build a big custom piece of machinery. Think a factory or a mine. That may last for 20 years, but require workers to operate, maintain, etc.
This is handled in existing tax law; building or improving a capital asset is amortized, repairing or maintaining it is expensed. It can be a pain in the butt, this is why accounting is not a trivial profession.
We could (and I think should) treat software the same. Some software engineer work is absolutely creating a capital asset. Some is absolutely high-priced janitor work. It makes sense to allow for both with your tax code.
> Think a factory or a mine. That may last for 20 years, but require workers to operate, maintain, etc.
Before Sec 174, s/w development costs were subject to a choice: amortization as if they were a capital expense, or regular deduction as a normal operating expense. Companies could decide which category to put costs into depending on the nature of the work (and presumably to suit their own interests).
Sec 174 removes that option. Or rather, it narrows it significantly. You must be absolutely confident that you paid developer X for ONLY maintainance work before deducting their salary.
Oh, I didn't realize - I knew 174 made it "must amortize", I didn't realize it could be done either way previously. Very silly indeed how they've done this.
The idea that the software must not be changed over the next five years is irrelevant
The important bit is that it will be used for longer than one year
say I work for a company for 5 years as a software developer, at $200k/yr the entire time. is this how it works:
year 1: company deducts $40k: 1/5 of the salary for year 1.
year 2: company deducts $80k: 1/5 of the salary for year 2, and 1/5 of the salary of year 1.
year 3: company deducts $120k: 1/5 of the salary for year 3, 1/5 of the salary for year 2, and 1/5 of the salary for year 1.
year 4: company deducts $160k: 1/5 of the salary for year 4, 1/5 of the salary for year 3, 1/5 of the salary for year 2, and 1/5 for year 1.
year 5: company deducts $200k: 1/5 of each of my 5 years of employment. I leave the company after year 5. Year 1 of my employment is fully deducted.
year 6: company deducts $160k: 1/5 of years 5, 4, 3, and 2. Year 2 of my employment is fully deducted.
year 7: company deducts $120k: 1/5 of years 5, 4, and 3. Year 3 of my employment is fully deducted.
year 8: company deducts $80k: 1/5 of years 5 & 4. Year 4 of my employment is fully deducted.
year 9: company deducts $40k: 1/5 of year 5. Year 5 of my employment is fully deducted.
what is the corporate tax rate? It's not 100%, so you're deducting a fraction developer's salary from your income, right, you're not saving that much on your tax bill each year. you're paying tax on the income you used to pay the developer.
I dunno man. In a world where places like Amazon pay $0 in income tax each year, I kinda feel like companies should be paying more taxes. companies get all kinds of deductions that employees don't get themselves, and will never get. businesses have a whole heap of unfair advantages already.
I'm sure the capitalists among you will want me dead for saying this, but: pay your fair share. I don't care what the law says, pay enough that no one can say that you're a lamprey on society, please.
You're bringing up the question of "what is a fair tax rate," which is reasonable.
The questions of this legislation, though, are different:
Should we incentivize companies to hire corporate executives instead of engineers?
Should we favor trillion dollar companies over startups? (It is much cheaper for Amazon to loan money to the government than three people starting a new venture from scratch, so this favors concentration.)
If you agree that we should discourage hiring engineers in favor of management, that concentration is good, and that low corporate tax rates are good, then this legislation is perfect.
I say that it's good if you believe in low corporate tax rates because this legislation was passed to pay for overall corporate tax cuts, which primarily benefits the largest companies. Amazon actually pays $11.3 billion in income taxes a year (not zero), so on net, even though they have a lot of software engineers, they benefit from this legislation, because they effectively traded having to float money to the government in exchange for lower tax rates.
Big companies care about tax rates more than liquidity, because their borrowing rates are cheap, whereas small companies care more about liquidity (they effectively cannot borrow, or it is very expensive) and their profits are low. So this effectively subsidizes big companies at the cost of small companies.
I think ultimately your interpretation is correct in your last paragraph, but I do wish someone in government would explain what they were trying to incentivize with the change.
Maybe they felt like software companies were too heavily incentivized by the tax code to invest in unproven, unsustainable businesses and would structure their businesses in a way that meant they’d never end up paying taxes.
Startups would blow a bunch of money on R&D for unprofitable moonshot ideas for a few years then the company would fail most of the time, with the government missing out tax revenue where workers could have been allocated to more profitable ventures.
Still, I think that the more cynical take is more likely (big companies lobbying to make it more difficult for small companies to disrupt their businesses)
> I do wish someone in government would explain what they were trying to incentivize with the change.
They were cutting taxes for the very richest people in the US and paying for it in ways like this.
That's not really the issue (and I say this as a socialist). The issue is that it's a weak and very leaky definition that attempts to redefine anyone that touches "software development" away from being taxed like employees into being taxed like machines that produce assets at the same value as their cost of operating.
This punishes small businesses and new businesses more than any large org because it massively increases the cost of operating for the first few years.
And importantly it just doesn't do so consistently.
Orgs should have a higher tax burden. This just doesn't do that, instead this is punishing orgs for trying to do new things and rewarding existing momentum (i.e. the large corporations that already have a profitable revenue stream and a long trail of employment history).
> it massively increases
that depends entirely on how much the business is taxed. every $1 deducted from taxable income is NOT $1 saved in that business' tax payment. It's much more like $0.10-$0.30 saved in taxes.
Sure but for a startup/new business with little to no existing product, that is a massive amount. Especially as any software that is abandoned (ex: due to a pivot, etc) forfeits the amortised deductions that contributed to it.
The only businesses this hurts are small or young businesses that have yet to develop an established product and reliably revenue stream.
For them in the best case scenario they make so little that they can't even deduct but otherwise this means taxes being paid pulling away from the runway that a young business has before it builds up a stable income stream.
Whether it is $1 or $0.10, it is non existent for young software companies. If I'm penniless (after real expenses), where will I get those 10 cents to pay the taxes?
And I'm not making this up. We are about to get cash flow neutral in our company, and this law will literally kill us and make 20 US citizens unemployed.
It is unjust. It is destructive. It actively impoverishes all of us. This is where they trot out the cold, detached assertion of Robespierre that one has to break a few eggs to make an omelet.
As far as I know, this law has been a thing for a couple of years now. How has your company been dealing with it so far? You say "this law WILL" but if it's already in effect, then it means that you would have already had to find a way to pay taxes for the last few years right?
Our other expenses offset it. (That is, we were making losses - typical VC funded company)
Well, same as any other expense. You find a way to pay for it, or you go out of business. If the number is 10%; you need either 10% more revenue or 10% less costs.
Except its a fabricated expense by law. Of course we can say "it is what it is, deal with it" for pretty much anything.
Sorry, I thought you were asking a question. I misread, didn't realize it was rhetorical.
From a more left-wing perspective, it certainly doesn’t feel like a coincidence that Section 174 kneecaps anyone who’d try to compete with the FANG trusts. I’m sure an oligarch paid good money to insert this rubbish into the tax code. Well, relatively good money. American politicians are shockingly cheap to pay off. Probably only took $10k each, to convince them to destroy billions in economic value.
It’s a rare thing these days: a law everyone can hate, regardless of ideology. You don’t have to be a Laffer curve believer to recognize that you can design tax schemes that would destroy competition and/or cause excessive deadweight loss. After all, if all taxes were created equal, we could just replace them with a money printer.
Hopefully it doesn’t take three years to reach a consensus on these moronic tariffs, which are far more destructive to the overall economy.
While I totally agree this is a ridiculous way to tax corporations, to my (probably very limited) understanding, it looks like this might actually be less bad for growing startups, because they don't make much money during their first years.
So a startup that's paying $200k in its first year but only making $40k in that year, they still get to deduct the labour costs over the next 4 years.
But of course this is only true as long as revenue is less than labour costs. Eventually you do want to make money, and it feels like you can only do that when you stop hiring more people.
But regardless of its effects on different types of companies, I don't understand how anyone could pretend that this way of handling labour costs makes any kind of sense.
I'd definitely say it smells like oligarchical fuckery but the more mundane reality is that it was an easy change that would produce enough revenue to balance first term trump tax cuts so they could pass congress. I doubt anyone really thought too much past that and the underlying rationale was probably just "we hate woke social media, this hurt woke social media".
I haven't looked at the tax rule in detail, but it looks like the "half year convention" for amortization applies.
The "half year convention" means that when you amortize a purchase, it's assumed you purchased it exactly halfway through the year, so you can only deduct half the amortization in the first year that you would normally (and the other half is in the year after the depreciation period).
So it looks like
year 1: 1/10
year 2: 1/5 + 1/10
year 3: 1/5 + 1/5 + 1/10
year 4: 1/5 + 1/5 + 1/5 + 1/10
year 5: 1/5 + 1/5 + 1/5 + 1/5 + 1/10
year 6: 1/5 + 1/5 + 1/5 + 1/5 + 1/5 (the last 1/5 being the other half from year 1 and the 1/10 from year 6).
I agree Amazon should pay taxes. But this bill is not the way to make such companies pay taxes. It will kill competition and startups along the way. That is the crux of the issue.
Edit: Looks like Amazon did indeed pay 15B+ federal taxes in 2024 (excluding sales tax etc)
Here are some charts and tables showing Amazon income taxes:
https://www.macrotrends.net/stocks/charts/AMZN/amazon/total-...
Incidentally, should we really count "income taxes" as something "Amazon pays"? Amazon doesn't pay income taxes. Amazon employees do. The fact that Amazon conducts the transaction via withholding seems irrelevant. It's the employee losing the money.
You are confusing income taxes paid by employees with the corporate income tax paid by companies:
https://en.wikipedia.org/wiki/Corporate_tax_in_the_United_St...
i generally think they should be counted to the company as a sales tax. amazon is losing the money, because theyre paying it to the government and not the employee, ao they need to increase the pay accordingly if they want the employee to have a certain amount.
modulo accounting shenanigans company like amazon is ~ unaffected by this rule since its capable of amortizing salaries anyways
Even if Amazon pays no corporate income tax (only one category out of many), they pay much more in taxes per year than you would in several lifetimes.
The phrase “fair share” is political, which is to say meaningless. The people who have earnestly invoked this phrase in my experience have resisted requests to define the term and have sometimes launched personal attacks for daring to raise the question. Will you break this streak? What in concrete terms is Amazon’s fair share? Your fair share? If they differ materially, why?
I’m a capitalist and therefore wish zero ill toward you. Cronyists, authoritarians, and collectivists may want to abuse you, and that is a contemptible way to treat one’s fellow humans. Both parties to a free exchange benefit. Both sides can win because it is not a zero-sum game. As a matter of fact, you are advocating for a game that your side cannot possibly win. Consider that Amazon has enormous incentive to hire the very tippy-top best accountants and tax attorneys to find every crack in the tax code that middling staffers and nepo hires can barely scribble. It does create some benefit to society in the form of the incomes that these highly paid tax pros generate, the comforts it affords them, and the downstream jobs demand for those comforts creates. But in the big picture, it’s adversarial rather than constructive. Certainly we can come up with a more peaceful and constructive arrangement.
Just to give you some perspective...this comment:
> I'm sure the capitalists among you will want me dead for saying this, but: pay your fair share.
Is the equivalent of a finance person saying to a developer "can't you just hire more developers and we can build our product faster". In other words, it's not that simple.
> what is the corporate tax rate?
21%
> It's not 100%, so you're deducting a fraction developer's salary from your income, right, you're not saving that much on your tax bill each year. you're paying tax on the income you used to pay the developer.
Which is a problem if you don’t have the money to pay the tax.
Let’s combine your and the parent’s examples: 1 principal engineer @ $300,000/year; 3 engineers @ $200,000/year = $900,000/year. $1,000,000 in sales.
year 1: Company makes $1,000,000 and pays $900,000 to engineers for a $100,000 cash profit; it deducts $180,000 from $1,000,000 for a $820,000 paper profit, and owes $172,200 in taxes. Since $172,000 > $100,000, it has a $72,000 cash loss for the year. There is not year 2.
Or maybe it raises enough capital to have a cash cushion. A similar thing happens in year 2: it makes $1,000,000 and pays $900,000 to the engineers for a $100,000 annual cash profit, deducts $360,000 from $1,000,000 for a $640,000 paper profit and owes $134,400 in taxes, still more than the cash profit. The cumulative cash losses are now $106,400.
Once again in year 3 it makes $1,000,000 and pays $900,000 to the engineers for a $100,000 annual cash profit, deducts $540,000 from $1,000,000 for a $460,000 paper profit and owes $96,600 in taxes. Hey, it doesn’t owe more than it made in taxes! On the other hand, its cumulative cash losses are now $103,000. Three years, three million in revenue, 2.7 million in expenses but it’s in the hole by $103,000, still more than its annual profit.
In year 4 it makes $1,000,000 and pays $900,000 to the engineers for a $100,000 annual cash profit, deducts $720,000 from $1,000,000 for a $280,000 paper profit and a $58,800 tax bill. It still has a cumulative $61,800 cash loss.
In year 5 it makes $1,000,000 and pays $900,000 for a $100,000 annual cash profit, deducts $900,000 from $1,000,000 for a $100,000 paper profit and a $21,000 tax bill. Good news, the company now has a cumulative cash gain! At the end of five years and $5,000,000 in sales the capital owners have made … $17,200. The engineers made $4,500,000 and the government made $483,000.
In year 6 it makes $1,000,000 and pays nothing (this is very unrealistic, because in the real world every product requires maintenance …) for a $1,000,000 cash profit, deducts $720,000 from $1,000,000 for a $280,000 paper profit and a $58,800 tax bill. People complain that it’s only paying a 5.88% tax rate, ignoring the years of amortised losses. But hey, after $6,000,000 in sales the owners finally have $958,400. They take it as a dividend and it gets taxed at the top marginal rate, so they pay an additional $354,608 in taxes.
In the real world, of course, sales may or may not cover salaries, sales may increase or decrease from year to year, markets may change and so forth.
> I don't care what the law says, pay enough that no one can say that you're a lamprey on society, please.
That’s an impossible target. Any random person can say, unreasonably, that someone else is a ‘lamprey on society.’
It seems like the amortizing over the lifetime of a capital asset is what is tricky for software, not that some businesses operate with very small profit margins. For the example given, that must have been a hyper-competitive area; continued yearly improvements of $900,000 was not enough to increase sales. So at year 6 the owners got rid of the engineering staff. What happens to revenue? Did all the competitors die at year 5, and so years 6 through 25 still have $1 million in revenue? Or with no continuous improvements, did sales and revenue drop to $0? In one case it seems like the right asset lifetime for the software could be 20 years, and the other case, 1 year.
I really liked the suggestion someone else posted in a discussion, that IP-encumbered assets should require amortisation of expenses over the lifetime of the IP (and of course the owner can always immediately write them off by releasing the IP instead).
But I do wonder what the effect on smaller shops would be.
> I'm sure the capitalists among you will want me dead for saying this, but: pay your fair share. I don't care what the law says, pay enough that no one can say that you're a lamprey on society, please.
They’re gonna lobby to get as low taxes as they can. Why would they do anything else? That people think they are “lamprey” is (or would be) a minuscule problem in a country like America.
> If you pay a software engineer, that's not "really" an "expense", regardless of the fact that you paid them.
If I pay for ... pretty much anything whatsoever ... I cannot write it off my personal income tax here in Canada. Not housing, not food. Medical expenses will come off the bottom not off the top.
Corporate income taxes are treated differently than personal income taxes. You absolutely can deduct corporate expenses in Canada.
I didn't mention Canada in order to nonsensically compare corporate taxes in the USA versus personal income tax in Canada, but because it's a good idea to mention where you are if you're writing about taxes.
Yes, corps get all kinds of tax breaks, whereas individuals don't.
As a Canadian I still don’t understand what the point of your original comment was. We already know this thread is about a US rule.
this is not entirely true and i’ve seen the exact same comment regurgitated with the same exact numbers for the past two years. I am not in really in favor of section 174 but i’m tired of seeing misinfo. I have discussed this with a CPA multiple times and its simplified and blown out of proportion in a way that you can’t actually have a conversation about it
Your comment would be much more helpful if you explained how op is wrong or linked to another resource or prior comment that did so.
…could you expand on what part is inaccurate?
One example:
"What they've actually done, congress said, is bought a capital good, like a machine."
Replace "like a machine" with "like software"
How is that profound?