HN has had many discussions about this, including The time bomb in the tax code that's fueling mass tech layoffs - https://news.ycombinator.com/item?id=44180533 - (927 comments) a few days ago. Other threads are listed at https://news.ycombinator.com/item?id=44203869.
There's currently a major effort to get this change reversed. One of the people working on it is YC's Luther Lowe (https://news.ycombinator.com/user?id=itsluther). Luther has been organizing YC alumni to urge lawmakers to support this reversal. I asked him if we could do that on Hacker News too. He said yes—hence this thread :)
If you're a US taxpayer and if you agree that software dev expenses should be deductible like they used to be, please sign this letter to the relevant committee members: https://docs.google.com/forms/d/1DkRGeef2e_tU2xf3TyEyd2JLlmZ....
(If you're not a US person, please don't sign the letter, since lawmakers will only listen to feedback from taxpayers and we don't want to dilute the signal.)
I'm sure not everyone here agrees with us—HN is a big community, there's no total agreement on anything—but this issue has as close to a community consensus as HN gets, so I think it makes sense to add our voices too.
Luther will be around to answer questions and hopefully HN can contribute to getting this done!
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.
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]
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.
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.
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.
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.
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.
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
Probably a broad enough definition to net the US Government the greatest tax revenue possible for the effort to enact this.
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.
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.
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 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.
Of course not. The Glorious Leader is rescuing the american hardware sector.
R&D is amortized, COGS is not.
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!
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))
> 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.
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.
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?
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.
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.
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.
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.
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.
I’m not sure whether I understand why that now applies only to software and not other things.
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.
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.
It takes 5 years to fill the pipeline, so even if the steady state would be fine, getting to that state might be impossible.
Deleted Comment
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.
But I agree that much of the outrage seems due to a confusion that 80% of the deduction is lost completely (vs deferred).
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?
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.
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...)?
15 years in the case of foreign developers.
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.
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.
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?
" 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 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.
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.
https://www.taxnotes.com/research/federal/other-documents/tr...
And then what happens after five years if they are still around?
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.
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.
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).
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?
Deleted Comment
But if you are correct that is supremely dumb, especially in place like US.
> (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.
what happens if an engineer leaves after the first year, or at any other time?
what happens to the calculations then?
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?
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.
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.
No.
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.
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.
Small correction, it was a vindictive move to negatively impact companies and regions that Trump didn't like (at the time).
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.
Look into when this started and why and you might understand it
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.
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.
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.
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).
Edit: Looks like Amazon did indeed pay 15B+ federal taxes in 2024 (excluding sales tax etc)
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).
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.
> 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.
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.’
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 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.
The FASB accounting rules drive the capitalization of software expenses, not the tax rules. The FASB definition of GAAP (Generally Accepted Accounting Principals) for US firms is very specific and requires significant detailed tracking to comply.
As noted in one of the other posts, many companies want to capitalize as much software engineering expense as possible as that leads to higher operating income and net income. Bonuses, option grants and stock prices tend to be tied to those metrics. The argument is that building a piece of software should be treated like purchasing it off the shelf. If a firm pays $1M to implement SAP, it does not have to expense it all in one year, but rather depreciates it over its “expected life.” Since “expected life” is difficult to define for every piece of software, there are default lifetimes (similar to saying motor vehicles default to a 5 year depreciation schedule).
Tax then generally follows the GAAP accounting except when the government intervenes to try and increase capital spending. Periodically the government will allow accelerated depreciation which increases operating expenses for tax purposes only which reduces current period cash taxes. Note total taxes do not change, only when they get paid.
The Section 174 under discussion here is simply the same idea then applied to software development in an effort to juice hiring.
For the people discussing whether the IRS is effectively tracking and enforcing this - the IRS really does not matter. A companies auditors enforce it. Without all of the necessary paperwork/digital audit trail, a firm in not permitted by the auditors to capitalize the expense. The same auditors have to sign off on the tax treatment as well. Finally, with respect to maintenance, the idea is meant to be similar to the treatment for machinery ( i.e. traditional capital expenditures). When a firm puts gas in the company truck or replaces tires or fixes a windshield, they do not capitalize those expenses. The idea is the expense do not fundamentally improve the item or meaningful extend the life beyond the initial expectations. Following that line of thought, maintenance releases are not thought to extend the life of the software while significant improvements to the software do and therefore can be capitalized.
DISCLAIMER - while I was a CFO, I was not a Certified Accountant. What I have described above is what the accountants and my audit firms described to me as I worked through this issue in preparing financial statements.
How does it 'juice hiring' by removing the ability to deduct 100% of an employee's cost in one year? Who would be incentivized to hire more people when less is deductible?
It's an IRS code change, not FASB. FASB doesn't oversee taxation at all. Section 174 is strictly a tax issue.
When viewed through this lens, are growing companies trying to have their cake and eat it too - get the boost to GAAP net income for stock comp purposes etc, but defer the cash tax to future years. This perspective ties everything together for me, in terms of understanding the incentives of the players here.
I think the other piece mentioned elsewhere is the very real cash flow implications for fast growing companies, in particular those that might be smaller and with more limited access to financing (which also isn't free...). And the idea that it's a pretty blunt tool... 5 yrs for all development... every product is different and as others point out lifecycles are often much shorter.
While one of the biggest differences between GAAP and tax is the depreciation schedules for various assets, the definition of the items is generally the same.
https://ssballiance.org/about/engage/
And Michelle Hansen was an early organizer https://x.com/mjwhansen
If you work at all in energy, the Clean Energy Business Network is also proactive in fighting for change. A couple of years ago they put me touch with Ron Wyden's staff. The Democrats are almost universally opposed to what was added to Section 174.
https://www.cebn.org/media_resources/house-republicans-advan...
Fight this thing - it is terrible. Not just for software but any innovative business in the USA.
Dead Comment
My current favorite theory as to why there hasn't been more of an outcry is that many companies ignored the rule change (either out of ignorance or as an alternative to going out of business), and are forced to remain silent.
How does that even work? You’re saying many companies committed tax fraud by ignoring the law change and continued to deduct software developer salaries as they had in the past?
I find that hard to believe.
It snuck up on a LOT of people, including CPAs, and represented tax bills for businesses that were multiples of the previous year's tax bill, and sometimes _multiples_ of their actual cash profit.
It's also so counter-intuitive that you can't deduct software dev salaries, that many people still don't believe it works the way the law says it works. If you read the comments here and in other threads where this has been mentioned, on Hacker News or elsewhere, years into this fiasco, you'll see widespread doubt and misunderstanding. Many people equate this to the same R&D rules for the older tax _credit_ or will argue that it can't possibly work the way the articles say it works. People don't magically begin to understand section 174 just because they run a business, and it's not in their financial interest _TO_ understand how it works. Many can't afford to.
Deleted Comment
The traditional capital asset treatment applied to software leaves a lot to be desired. Some software is a capital asset, but much just isn’t. Or at least should be considered to depreciate rapidly.
The IRS is using a theory of value where software (1) is a capital asset (okay, sure), (2) has a six-year deprecation schedule (uhhh why not 5 like everything else?), and (3) is valued at the exact cost of all inputs to it, including salaries (uh oh).
This is unlike how capital assets are valued for any other industry! And it has the effect that hiring a second lawyer is “cheaper” (for five years anyway) than hiring a second developer.
The same is true for all true R&D, which is why historically the government has tried to provide protections for R&D work to incentivize people to not just churn out the safe bet over and over again. Patents fall into this category, but software patents are (rightly) hard to come by. Through 2022, the risk of software development was offset by the ability to expense the costs and avoid a tax bill, and this was good policy if your aim is to encourage innovation.
The capital asset theory could still work if there were some way to appraise the value of the actual asset you created. But absent such a way, this thinking is deeply flawed for all but the most shovelware of jobs.
If the goal is to measure retained value, I'd ask how much a competitor would pay to acquire your 5-year-old code (for direct use, not for hacking you) without feeling cheated afterwards.
Dead Comment
It's technically correct that tax is levied on "net income", but that's an accounting term which means something different from "money_in - money_out" when there are capital assets.
One justification for this is, although you spent the cost, you received equivalent value in the form of the asset itself.
This means if it costs $100k in salary to make software this year, and you get $30k in income from the software this year, your bank balance will lose $70k (which is expected) and you'll have negative income in the ordinary way of thinking, but you'll be charged income tax (which is new) despite losing money, as if you gained (almost) $30k instead of losing $70k.
Your tax accounts will show an increase in net assets, despite the decrease in your bank balance, because they will show the software as being "worth" (almost) $100k, regardless of what it's really worth right now.
This is particularly hard if you're a small company or (non-VC-funded) startup that's already stretching to cover the cost of speculative software development. Being charged income tax even while you're losing money developing software (in the ordinary way of thinking about money) is what's new in the tax code. It makes it harder than before to do speculative developments, making some kinds of development non-viable that were viable before.
If you start the year with 0$ in your bank. After the end of the year you have made $200k in revenue. However you "spent" $200k on software salaries. However, because these are software costs, they must be depreciated over 5 years, so only 20% of that $200k software cost can be applied as depreciation cost which is considered an expense. So your net income for this year is $200k revenue - $20k depreciation expense = $180k. Your 15% tax on this is $27k.
So you made $200k and spent all of it on software, so your bank account is 0, but you owe $27k in taxes.
Deleted Comment
---
I'm writing to express my urgent concern regarding the negative impact of the 2022 Section 174 tax code changes on small businesses like mine. As owner of Rietta, Inc., a small cybersecurity firm, I still do much of the technical work. My wife and I have three young children under 6. My family and I have been directly negatively impacted by these changes from the 2017 act.
Previously, the tax code helped us afford open-source and experimental work that benefited customers. For example, modernizing applications to run on Docker improved testing and deployment. Our State government clients now benefit, but this was once experimental. Now we're largely back to just work-for-hire consulting, treated as cost of goods sold. I don't have the cash to pay for experimental software development only to then amortize it over five years. If I have $100k revenue and spend $100k, the current code allows only a $20k deduction. I owe taxes on the other $80k despite no cash or documented asset value. Experimental software doesn't work like that in this field.
I started this business 26 years ago. We provide important long-term custom programming and update work for private sector and State government clients ("STATE A" and "STATE B" judicial branches). Often, we work with code we didn't originally write.
As a professional computer scientist and business owner, I rely on my CPA for tax compliance. If I've erred in my example, that's on me. But I can tell you this amortization requirement particularly cripples small businesses like Rietta, Inc., where cash flow is critical, severely limiting the quality of services I can afford to provide. I support undoing this tax change.
- A business is usually taxed on its profits: you deduct your revenue from the cost of producing that revenue, and the delta is what you are taxed on.
- In software businesses, this usually means if you spend $1M in software development to develop a web app, and it makes $1.1M in that year, you'd get taxed on the $100K profits.
- However, a few years ago, the IRS stopped allowing the $1M to be deducted in the year it was incurred. Instead, the $1M was to be amortized over 5 years, so now the business can only count $200K as the deductible expense for that year. So now it's going to be taxed on "profits" of $900K. Assuming the tax rate is 20%, that means the business owes $180K in taxes, even though it has a total of $100K in the bank after the actual expenses were paid. So it would have to either borrow to pay taxes or raise venture capital, meaning that VC-funded companies would be advantaged over bootstrapped ones!
- The letter's goal is to bring things back to how they were (and how they are for all other businesses): let businesses deduct their actual expenses from their actual revenue, and tax that actual profit.
I am neither a lawyer nor an accountant, this is just my understanding of this issue.
Edit: Switched the tax rate to 20%. The logic is still the same.
> even though it has a total of $100K in the bank after the actual expenses were paid.
People running a business can perfectly understand the concept of liquidity. And yes, just because you transform money to something else, then it doesn't mean that you should not be taxed on it.
The extreme example is a company that buys gold on the last trading day of the year - now there is no profit! On the first day they sell the gold again and does tax eviction.
The core question is to what extend software constitutes an asset or consumption.
(Personally, I do not believe that software constitutes an asset in any meaningful way, but a practical tradeoff could be that software is a 10% asset)
Isn't part of the problem with our industry that, even it is an asset, its value can be hard to determine even for a long time after you've written it, and it may be pretty weakly related to how much you paid to build it?
- you might have spent a lot on developers last year but next year you find out that you're the new Quibi and no one wants to use your product
- you might have had a small, tight team and what you built turns out to be hugely valuable (like instagram or whatsapp)
- ... and to the degree that the software is part of a valuable business, how do you really assign value to the software as versus the go-to-market plan, the partnership/distribution agreements, etc that helped make the business succeed?
In this example, it seems like you're assuming that the revenue from the sale of the gold would not be taxable, but I don't see why that should or would be the case.
ETA: also, gold is far, far more fungible than any particular software
Maybe we can finally deduct all that technical debt.
And it's transferable -- if your company fails, there are companies out there that will buy the rump of your company to realize the unrealized tax refunds.
Which is why it's usually fairly straightforward to get a factor loan to pay those $450K in taxes -- it's backed by an asset.
Factor loans are usually expensive with a high interest rate. Because you can get a factor loan, the taxes are not going to immediately bankrupt the company in the short term, but the high interest rates are going to hurt in the long term.
Not a lawyer nor an accountant. Not even an American.
Which is not(?). According to https://en.wikipedia.org/wiki/Corporate_tax_in_the_United_St... , federal corporate income tax rate is 21%, + additional <10% for state level, not sure about local level.
Some big tech companies affected have laid off teams around the world, perhaps in order to mitigate the numbers looking bad to investors; so in a way, this adversely affected tech employees globally.
Every country should have such a rule for software businesses, which is an industry where all the cost has to be upfronted, so that bootstrapping is facilitated. There are plenty of smaller markets where the VC model is not the most appropriate funding instrument.
It was Trump's 2017 Tax Cuts and Jobs Act, which amended IRS code.
> It was Trump's 2017 Tax Cuts and Jobs Act, which amended IRS code.
And took effect in 2022 (per what I've read elsewhere, and other comments on this post; could be off by a year)
(just clarifying that the effect was "a few years ago", but I agree that it's important to know the origin of it, which you were pointing out)
But it's still useful to know the real rate is 21%, thanks.
In my example, the tax rate isn't the point though, it was used just to illustrate the math.
The main point is that it makes no sense to require amortization of software development expenses. The idea that this letter is an attempt to restore rationality in the tax code.