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....
They're lumped in with Research and Development, which in another more traditional context might make a bit of sense.
If you build a factory or apartment building, you don't get to expense it all at once because it's a capital good and instead you depreciate it over time, taking the expense little-by-little. This kinda makes sense, because it's assumed that you started with (often borrowed) all the money to build the factory, but it's just a one-time expenditure. Then you get ongoing revenue from it, which is offset by the ongoing depreciation. It all works out.
In the IP world, you could think of drug development the same way. We spend $1B to develop a drug, and then get income from that drug down the line. Same deal, conceptually.
The main point is that there are two clear phases: 1. spend a big pile of money to build something, then 2. get income from it. In phase 1, you have a plan for how to fund all that from the get-go. Often just a huge loan. And there is no income to pay taxes on. By the time you get income and need to pay taxes you'll have plenty, because you're not still paying to build the thing.
But then with software it starts to break down. Following the same model, you'd raise enough money to hire a bunch of devs to build your software ALL THE WAY DONE, finish it (like a factory), FIRE ALL THE DEVS because it's done, and then start collecting income from the software. You funded all the development up-front, and then by the time you're getting revenue there's plenty for profit and taxes. In some ways, LARGE companies do roughly do this.
But of course we know that's not how startup software really works. For the most part, development is an ongoing effort that never stops, and in the startup world you don't get funding all at once up-front, you raise money as you need it, as you go along. You're not going to raise $1B up-front to build an ml-blockchain-chrome-extension thing. You spend a little, see how it goes, maybe raise a little more and get a few more customers, add a couple of features, raise a little more, etc.
If in your example you hired the construction workers as employees and, for what ever reason, kept them on the payroll, wouldn't you still be able to deduct the salaries you pay them each year ?
If not it seems like a colassal disincentive to employment, which is the opposite of the result usually sought by government policies.
How you raise money doesn't make a difference. What matters is how fast you can utilize your "engineering assets". More often than not startups don't sell anything (let's say "anything" is > 20% of developers' cost) in the first year, or even in the first 3 years. So for them it's not a problem, you simply carry forward losses until you start getting revenue, and at that point you have enough losses to offset those 80%. It doesn't work for companies which are lucky enough to make substantial (comparable to the salary) sales in the first year. It's like Ford built a new factory, made 600,000 F-150 and sold them and the factory is basically gone in one year, there is nothing left. Doesn't happen with real factories though and usually doesn't happen with startups, but there might be exceptions.
The argument is that the software developers are producing an asset (the software) that will produce revenue over time. There is an accounting principal to match revenue with expenses, so if the software will produce revenue in the future, the expense of developing the software should be delayed into the future to match.
Companies don't have a choice. The law now requires amortization of software development expenses. Even companies that don't claim R&D tax credits are affected.
I'm not a CPA but I'm pretty sure companies have a choice whether to claim Software Development as R&D expense, or as regular payroll. It sounds like this change is only affecting employers who were previously "saving" payroll tax by classifying employee cost as R&D, and claiming "R&D credits" which can no longer be amortized [0]. That is not the default tax strategy of every tech company. There is no law requiring companies to file for R&D credits. The relevant changes under discussion only affect companies who chose to file for R&D credits.
They should have known they were taking a risk by adopting that strategy. At our company, we got a bunch of spam emails offering to help us file for R&D credits - we just ignored them and continued to pay normal payroll tax.
Searching my inbox for "R&D," it seems that Gusto was the most prolific spammer in this regard - they sent dozens of emails enticing us to save tens of thousands of dollars by talking to their R&D tax specialists. They even included case studies naming specific companies and how much they "saved." In retrospect, that looks like a big oof.
2. R&E expenses (IRC 174 https://www.law.cornell.edu/uscode/text/26/174) which as of 2022 can no longer be fully deducted, but must be amortized over 5 or 15 years. IRC 174 (c)(3) explicitly states "any amount paid or incurred in connection with the development of any software shall be treated as a research or experimental expenditure." This applies whether or not the company was treating software development as R&D under IRC 41.
I'm not a lawyer nor a CPA, but my reading of that Cornell link is that the definition only applies to expenditures that the company deducts from their return as R&D expenses, which, again - is not the default strategy of every company.
Note this would also only affect profitable companies (i.e., not most VC-funded startups), since there's nothing to deduct if you didn't make enough profit to owe tax in the first place (modulo some change in definition of "profit" based on how software development must be categorized - but still, this would only affect companies with fairly significant revenue; it's not like hiring a software developer suddenly costs 120% more than it did last year.)
