Comment by ASalazarMX 7 days ago
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.
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.
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.
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?
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?
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.
> 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?