Hacker News new | ask | show | jobs
by wdaher 374 days ago
Here's a toy example that hopefully makes this clear:

In 2024, your business has $1m in revenue and has $2m in expenses. 100% of these expenses are R&D salaries (engineers you hire.)

Your company loses $1m/year. (You brought in $1m and spent $2m.)

Under the old rules, you'd owe no tax because you were unprofitable.

After Sec 174, what the IRS now says is:

You had revenues of $1m. But you only had $400k in expenses (because you now have to spread that $2m in R&D expense over 5 years).

So actually you had a profit of $600k! And you owe tax on that $600k profit (~$120k)

So you now have an additional $120k tax expense, making your business even more cash-flow negative.

.

Amusingly, if you're pre-revenue, none of this matters (you have no income at all, so it doesn't matter what your expenses are.) You get hardest hit by this change when you have some revenue and when you do a fair bit of R&D.

6 comments

> Amusingly, if you're pre-revenue, none of this matters (you have no income at all, so it doesn't matter what your expenses are.)

https://youtu.be/BzAdXyPYKQo

There is so much gold in that show. Just rewatching it now. Fucking billionaires...
Wait - they are saying that employee salaries are not expenses?

That is surely wrong? Just because those salaries are for R&D?

I could understand if there was some additional tax break for R&D which was being removed. I can't see how basic operating costs cease to be expenses.

They're still expenses, they just now need to be amortized.

Buying a truck is an expense, as is buying gas for the truck. But the former you have to amortize over x years, the latter you can expense immediately.

The law used to be "employee salaries for software are like buying gas" and now it's "employee salaries for software are like buying a truck".

The critical difference is that the business owns the truck but not the employee. The amortization assumes that the asset can be sold for value. An employee can quit at any time for any reason. You don’t retain the right to their labor for five years.
If they're producing a capital asset, you do retain the right to the fruits of their labor, even if they quit.

The rationale behind amortization isn't exactly the idea that the asset can be sold, it's that the asset is producing revenue over multiple years. For software, the asset is the codebase.

Let's say you hire a single software dev, for one year, and they write Excel++, which you can sell for the next ten years. It would be entirely appropriate to amortize the cost of creating that software over those ten years, based on the matching principle (a fundamental idea of accounting, matching expenses with revenue).

The issue in the real world is that's not how the software industry actually works, 99% of the time.

> The issue in the real world is that's not how the software industry actually works, 99% of the time.

What would be a more appropriate model from accounting perspective?

Honestly it'd depend a ton of the particular industry/company/programmer. Some are definitely creating capital assets and should be amortized, others are "repairs and maintenance" which can be expenses. I'd probably defer to treating them as expenses, but allow for amortization if the company desires, and maybe have some audit possibility on that if it looks like the big players are gaming that somehow.

Part of the complication here is companies generally really like amortizing stuff. It lets you smooth your profit across years which is usually better both for tax purposes and for your financial reporting for the market. So this kind of change is fine or even good for a company like Google, but can really suck for a small bootstrapped SAAS. This is why I'd allow companies to pick, with some degree of latitude.

As anyone that has ever sold software IP knows, most of the value is vested in the person that wrote the code, not the code itself. The code is not a factory, it is the output of the factory.
> ...most of the value is vested in the person that wrote the code, not the code itself.

You must have misphrased what you intended to say. If what you wrote was true, a software company's most valuable asset would be the specific programmers in its employ. If true, average tenure of a programmer would be way longer than 1.5->2 years as companies worked really, really hard to keep their most valuable assets from walking out the door into the doors of another company just to get reasonable pay increases.

Perhaps your opinion is influenced by doing post-collapse-sales of a whole bunch of software houses that built just plain bad software? I can't see why else you'd be selling "software IP" independently of the rest of the business.

Anyway. Given that information, how should you have phrased what you wanted to say?

the company owns the IP that the employee made though.

if anything, the amortization should match copyrights or patent lengths

Based on my exchange with wdaher, who seems to understand this well, it's a bit more subtle than that:

The salaries are of course expenses, but they are exactly offset by the value of the IP created by the R&D activities.

It's a bit as if you spent money on buying some materials. As long as the material doesn't degrade, the cash is gone but the value is the same and therefore won't reduce your taxes.

If that IP is amortized over a single year, it does not contribute to taxation, but it does if it is amortized over a longer period.

They are expenses, but amortized over 5 years. So if you spent $2m on employee salaries, you would then deduct $400k from your revenue every year for 5 years.

If your employee expenses remained constant, then by year 5 you would be deducting $2m from your revenue since you'd be accumulating the deductions from the previous four years.

So in steady state it wouldn't necessarily be a big problem. But for a startup which is hiring many new employees and whose revenue is growing it's a huge problem.

This was my first reaction when I heard about it before it passed. I was horrified.
>Wait - they are saying that employee salaries are not expenses?

>That is surely wrong? Just because those salaries are for R&D?

The same would be true if you hired a bunch of scientists/engineers and got them to do R&D.

Would it also be true if you hired a bunch of construction workers and got them to build a stadium?
Buildings have to be depreciated, so probably? If you have to depreciate a building if you buy it, why should you get a free pass just because you built it yourself?
What other cost do you think goes into software development? Companies are not spending that much money on IDE licenses. The vast, vast majority of software/R&D costs are labor
So? They are all costs, whatever their source.

In the UK, business gets taxed on profit, which is what is left from revenue after subtracting costs.

Is this true even if you don't capitalize the immaterial IP asset generated by the R&D salaries on the balance sheet? Is that required in the US?

Otherwise I'm quite amazed that salaries can be carried forward as future expenses.

This is what the Sec 174 change said: it says that you do have to capitalize it.
Elsewhere in the world (under IFRS accounting rules) capitalization of R&D costs has been a firm requirement for a while. The US has been somewhat unique in allowing them to be expensed instead, until recently.
Taxes are calculated according to tax accounting rules, not IFRS, though?

I know of at least two Western European countries where you don't have to do that. Don't worry, we pay enough taxes either way ;)

Yeah, seems I was wrong about that. Apparently most IFRS countries allow expensing R&D for tax purposes, regardless of accounting. Many even have an R&D superdeduction nowadays.

Sorry for the noise :(

I was confused and has to double check. In Australia you can deduct them https://www.ato.gov.au/businesses-and-organisations/income-d...
Came here to ask about the Aussie RDTI. So, if I spend $10M on R&D and make $5M, what's the difference between US and Aussie net?
Some countries have uniform accounting where the tax accounting rules closely follow IFRS.
I own a small SaaS and the numbers you presented are similar to my situation in 2023. I owed over $100k in Taxes and I’ve literally never had over $100k in my business or personal bank account.
so you are okay, if you start getting revenue when you're five years in?
You can deduct 100% of salaries paid 5 years ago, but only 20% of salaries last year (etc.), and since companies tend to hire more people over time, most of your expenses will have been in the last few years that are still amortizing. You might have enough losses to carry forward in your first year of revenue, but 6 years in that could run out. It depends on the exact circumstances.
But nobody’s forcing you to classify software developers as R&D.
No, that's literally the Section 174 change. You now must count them as R&D.

The relevant paragraph from Section 174:

> (3) Software development

> For purposes of this section, any amount paid or incurred in connection with the development of any software shall be treated as a research or experimental expenditure.

https://www.law.cornell.edu/uscode/text/26/174

So that would include everything? - cloud/hosting expenses - system administrators/devops engineers and their laptops, workstations - project management software, office software, support, etc - project managers, designers, technical writers, qa engineers - software licenses, domain names, certificates, etc - internet bandwidth, data-centers, HVAC, backups
What "in connection with" means is vague. I think a reasonably competent tax attorney could probably argue that the costs of running your production cloud serving existing customers don't count, but IANAL.
What if some executive tweaks a "no code" tool? Technically, the name says that there's no coding involved.
Presumably that still counts as "developing software"- the regulation doesn't mention "coding" at all.
A fair point.

Or is it "using software"?

A person typing an essay with a word processor in doing more work than many of the users tweaking no code software.

A person typing an essay with a word processor is producing an essay. A person using a no-code tool to modify a software process is producing software processes.

The nature of the tweak involved probably determines the classification of the effort, but for tax purposes and R&D expense amortization, it is a percentage of time basis.

If the executive tweaks the code once, the percentage is so small it won't count as far as anyone cares.

If 20% of the executive's time is tweaking the tool, then odds are the company cannot expense 20% of the executive's salary and instead must claim that portion as R&D over five years.

Back before 174, I worked for a company that did claim R&D but only for one of the projects I worked on. As such, I had to be careful filling out my timesheet because they wanted an accurate accounting of what was salary expense and what was R&D.

what if you don't call it "software development"?

how about "business process mechanization"?

At that point you’re so into tax fraud that you light as well call them “postage and shipping”
OMG, I can't believe how prudish HN commenters are!

Have you seen who's leading the most powerful orgs these days?

Have you seen what's going on?

"business process mechanization" is a fair description of what we do and probably would be just fine, tax-wise

Then you risk going to jail.
I mean sometimes fraud works, sometimes it doesnt.
How would that help? R&D developers helped saving taxes, now they don’t.

Classifying them as non R&D doesn’t help saving taxes again.