If Ford builds a car factory, that's a capital asset - the costs should be amortized against the useful life of the factory. So if it costs $10 million and lasts for 10 years, they can expense $1 million a year. Those costs will include the salary of the workers to build the factory. The workers inside the factory making the cars though, that's a cost that matches to the revenue from selling those cars, so their salaries are an expense, and they can be claimed in that year. For most businesses, most of the time, they're producing work product (or supporting that) to be sold as quickly as possible.
Now - when Microsoft writes Windows or Excel, or Epic makes Unreal Engine, I think there's certainly an argument that it's a capital asset they're making, and maybe costs should be amortized over the useful life. I wouldn't even be surprised if their accountants have claimed the same thing. Is that universal across software dev? No. The problems with this change are:
a) It allows no nuance. If I worked for 4 months on a game that I expected to have zero sales outside the first year, I think it's silly to call that a capital asset in any real way. Not all software dev work makes capital assets. The janitor at the Ford factory doesn't get his salary expense amortized, nor should the bug fixer.
b) It's all taking effect in this year. Could have switched it gradually over 10 years or something (you need to amortize x% in year 1, 2x% in year 2, etc)
c) It's especially tough on small businesses. Microsoft can borrow the cash and make it clear in financial statements that this is a weird tax rule, but according to GAAP/accounting rules it's fine. But a sudden big tax bill is really tough for years 1, 2, 3 of a small business.
Also with the factory analogy - unreal is the car factory and you are like the worker who built the factory. (Asking out of ignorance) The workers wages are not treated as a capital to be amortized right?
Nifty3929 explains this well, let me just add that good accounting rules try to minimize how much you can tweak by "build" vs "buy". Like building a $1b factory or buying one, if you intend to keep and use it to make cars, should be treated broadly the same way.
If you bought a 10-year license to use Unreal Engine, you'd amortize that out. If you instead built it (to use it!), the same rules should (generally) apply to the expenses you incur. If you build it to sell it...well, that gets complicated, especially as it's tough to estimate the useful life of software, and it's tough to say whether certain costs are improvements or maintenance (which are treated differently), etc.
Doing a sudden switch from salary costs being 100% expensed to 100% amortized (over 5 years for domestic, 15 years for foreign) is really bad, it's legitimately harmful for a ton of small businesses in this space. But honestly having it as 100% expensed is pretty silly. Hopefully this gets fixed with a middle ground and a gradual switchover.
For the factory - yes, your wages as a worker building the factory would be treated as a capital expense to be amortized, at least from the perspective of the factory owner. But in the usual case where the owner is hiring an outside contractor to build the factory, then from the perspective of the contractor, your wages would not be a capital expense.
The company that pays for the factory would basically just pay $1B of capex for a factory. The contractor doesn't get the factory - they get income. And your wages from them are just an operating expense. The contractor is not making a capital investment - they are just doing a job for money.
It depends. If you have a truck - capital asset - the oil changes are probably opex, but replacing the transmission is probably capex. Regular sweeping and cleaning of a building is likely opex, upgrading the wiring capex. Software I can certainly see getting tricky here - is updating dependancies an oil change or a transmission?
"Betterment, restoration or adaptation" is the usual test for something being capex.
Hot take: not one person on earth could make a good/useful distinction between "bug" and "feature" in software development. Some times that's clear, usually it's not. Making tax law depend on the idea that there is a distinction is pretty terrible.
The current US tax law is flipping (with no rollout period) between dev salaries being 100% expensed (over 1 year) and 100% amortized (over 5 or 15 years). You actually could make some distinction between those two poles without being able to perfectly categorize every line of code.
A number of things the government could do:
1) Split it between the two. Need to amortize x% but can expense the rest. Maybe that % is mandated, maybe it depends on industry (i.e. if you make games vs an OS vs a SAAS vs embedded software for cars).
2) Tie it to company size, either headcount or revenue.
3) Allow different categorizations for e.g. R&D, product support, building internal tools, building SAAS for sale, whatever.
4) Roll out any changes gradually over x years.
Tax law, over and over again, uses the idea that there's a distinction between CapEx and OpEx. It's not magically impossible to do the same for software.
In a world where all software actually has a comprehensive spec, I think the distinction could be made pretty easily, but the line is definitely fuzzy in this one.
Yeah I don't think that has happened even in (say) the most extreme niches like some project with an embedded 8 bit microcontroller in a space/military setting....
If Ford builds a car factory, that's a capital asset - the costs should be amortized against the useful life of the factory. So if it costs $10 million and lasts for 10 years, they can expense $1 million a year. Those costs will include the salary of the workers to build the factory. The workers inside the factory making the cars though, that's a cost that matches to the revenue from selling those cars, so their salaries are an expense, and they can be claimed in that year. For most businesses, most of the time, they're producing work product (or supporting that) to be sold as quickly as possible.
Now - when Microsoft writes Windows or Excel, or Epic makes Unreal Engine, I think there's certainly an argument that it's a capital asset they're making, and maybe costs should be amortized over the useful life. I wouldn't even be surprised if their accountants have claimed the same thing. Is that universal across software dev? No. The problems with this change are:
a) It allows no nuance. If I worked for 4 months on a game that I expected to have zero sales outside the first year, I think it's silly to call that a capital asset in any real way. Not all software dev work makes capital assets. The janitor at the Ford factory doesn't get his salary expense amortized, nor should the bug fixer.
b) It's all taking effect in this year. Could have switched it gradually over 10 years or something (you need to amortize x% in year 1, 2x% in year 2, etc)
c) It's especially tough on small businesses. Microsoft can borrow the cash and make it clear in financial statements that this is a weird tax rule, but according to GAAP/accounting rules it's fine. But a sudden big tax bill is really tough for years 1, 2, 3 of a small business.