Live data from Hacker News

Thousands of small businesses are struggling because of R&D amortization

twitter.com

361–369 of 369 posts

Re: Thousands of small businesses are struggling because of R&D amortization

#361
post #272
post #261

To be fair, accelerated R&D amortization (immediate full expensing in the year the expense was incurred) is a tax loophole . Essentially, the default tax treatment of expenses is basically to take the expense same as you would treat it under GAAP, but some people (I am one of them BTW) think that we should put a finger on the scales for the case of legitimate R&D. Now though I happen to think accelerating it is a goo…

I don’t understand why businesses can’t just say that their engineering department is a cost center (COGS) instead of classifying engineer salaries as R&D expenditures. I guess one downside would be not qualifying for the R&D tax credit. The majority of software engineering is the equivalent of janitorial work… keeping servers online, fixing bugs, maintaining services, upgrading and refactoring code, etc. It’s diffic…

> I don’t understand why businesses can’t just say that their engineering department is a cost center (COGS) instead of classifying engineer salaries as R&D expenditures.

I spent a bunch of time on this last week with my experts-for-hire, as well as reading IRS guidance and 3rd party analyses. My understanding is:

- Previously you could decide whether to capitalize/amortize your R&D expenses or not. Now you must capitalize/amortize.

- Previously, you could choose to take the R&D credit for R&D activities, or not, regardless of whether you capitalized/amortized. That is still true.

- Previously, software development was only considered an R&D activity in certain circumstances. Now, the IRS has "clarified" that they consider the process of software development to be so similar to the process of traditional R&D that it should nearly always be considered an R&D activity and therefore should be capitalized/amortized.

One thing that's been frustrating is how, in discussions about this issue, software development is being spoken of nearly exclusively in the context of businesses developing software for themselves, either for internal use or resale. Left universally unmentioned are all the contractors, development shops, etc. who are developing software on a work-for-hire basis. How these companies should classify their engineers' work is not particularly clarified by the IRS guidance, but my understanding is that a consensus of "big" accounting firms is that these salaries should continue to be deducted as they were before.

Re: Thousands of small businesses are struggling because of R&D amortization

#362

Earlier quoted context omitted.

No. TCJA requires all software development costs to be treated as r&d, and capitalized over 5 years (or 15 years). Guidance from pre-2022 no longer applies. https://www.grantthornton.com/insights/alerts/tax/2023/flash...

My reading of this document is that certain software development activity (e.g., “corrective maintenance to debug, diagnose, and fix programming errors”) is not SRE. This seems to contradict your statement that “all software development costs [are] to be treated as r&d,” but my experience is that you know what you’re talking about. What am I missing here?

I would suggest reading notice 2023-63. That provision is very limited, and may not be available to you at all depending on the software you're developing, and/or the stage of the development that those steps occur in.

For example, for a new feature: if you plan (SRE), design the interface (SRE), write the feature (SRE), run it through QA (SRE), and then discover a bug and correct it -- that's still SRE.

If you put the software into prod, then discover a bug, then fix it (without improving performance or adding any functionality), then it might not be SRE.

But if you sell software, and you sell or install a release to a customer, and they (or you, under a support contract) discover a bug and fix it... but then you include the fix in your next release, probably SRE.

Or, if you put the software into prod, discover it breaks with a large data set, and you fix it by improving the performance of that section of code, probably SRE.

The expenses falling under that provision aren't going to make a significant change to the impact of TCJA on software development.

Re: Thousands of small businesses are struggling because of R&D amortization

#363

Earlier quoted context omitted.

Are we talking "startups" or "small businesses" here? I could see this blowing up startups for sure, but the conversation was about small businesses and I'm not sure I see the connection there. In my conception of the universe, you're not rolling out multiple hundreds of thousands of salary when you're hanging out your small-business shingle. You might grow to it, but that'll be over a long period of time.

Not quite. Plenty of startups pull 6-7 figures. We did 6 figure revenue on year 1 of our dev agency startup in past.

I assume you meant "plenty of small businesses". On what margin?

Re: Thousands of small businesses are struggling because of R&D amortization

#364

Earlier quoted context omitted.

My reading of this document is that certain software development activity (e.g., “corrective maintenance to debug, diagnose, and fix programming errors”) is not SRE. This seems to contradict your statement that “all software development costs [are] to be treated as r&d,” but my experience is that you know what you’re talking about. What am I missing here?

I would suggest reading notice 2023-63. That provision is very limited, and may not be available to you at all depending on the software you're developing, and/or the stage of the development that those steps occur in. For example, for a new feature: if you plan (SRE), design the interface (SRE), write the feature (SRE), run it through QA (SRE), and then discover a bug and correct it -- that's still SRE. If you put t…

Third to last paragraph: if I sell software, a third party bug bounty type guy finds an exploit, notifies me, I patch the vuln, and release the patch as a hot fix: you figure all of that is SRE, probably?

(Disclaimer: not seeking tax advice or legal advice, we’re just two dudes casually discussing section 174 like normal people do all the time).

That notice was a helpful read. I think what I may have been missing was section 5 of Rev. Proc. 2000-50, whereunder non-SRE software dev was also afforded some similar protection. I’ll read that after work but I’d still love you to answer the foregoing.

Re: Thousands of small businesses are struggling because of R&D amortization

#365
post #228

Earlier quoted context omitted.

As a SMB, if your salary expense is $500k and your revenue is $500k, you are absolutely struggling, no matter the tax situation. In this case you "just" need another $100k in revenue. After all, you are throwing out theoretical revenue numbers anyway. So it just moves the needle somewhat for you to still break even. You could game it just a little if there's revenue at end of year that you can book in the following q…

This is wrong because you are speaking on an accrual basis but you have to consider cash. The cash (salaries and taxes) is paid out in year 1 regardless of what year you try to book it in your p&l statements

i'm suggesting that as an early startup, in year 1 where this has the most impact (you aren't now bringing in previous years expense), your employees may be flexible enough that you pay out the cash 31 days delayed (example) instead of paying anything in December.

obviously if you pay salary in December, you paid in December and you have to book it that way.

Re: Thousands of small businesses are struggling because of R&D amortization

#366

Earlier quoted context omitted.

As a SMB, if your salary expense is $500k and your revenue is $500k, you are absolutely struggling, no matter the tax situation. In this case you "just" need another $100k in revenue. After all, you are throwing out theoretical revenue numbers anyway. So it just moves the needle somewhat for you to still break even. You could game it just a little if there's revenue at end of year that you can book in the following q…

Companies don’t do “this all the time”. In your hypothetical example, you”d have to essentially forge the quarterly 941 reports to shift the salary R&D expenses. Also ‘gaming’ which quarter revenue occurred is technically tax fraud, certainly if one is on an accrual basis. And it doesn’t mean one is ‘caught up’ by year five. Any time a company increases R&D expenditures, it will have an impact.

Have you never bought anything? There is always a push at end of quarter and end of fiscal year, to sign the agreement NOW. so that it can be booked in that quarter. even though delivery won't happen until next ...

incentivized by quota but the incentive is there to get it on the books.

there is no forgery involved.

Yes, of course as you increase spend you increase the impact (in the year that you actually spent), but the context here is specifically very early SMBs, and more so, ones that would only be running break even under previous rules.

Re: Thousands of small businesses are struggling because of R&D amortization

#367

Earlier quoted context omitted.

I would suggest reading notice 2023-63. That provision is very limited, and may not be available to you at all depending on the software you're developing, and/or the stage of the development that those steps occur in. For example, for a new feature: if you plan (SRE), design the interface (SRE), write the feature (SRE), run it through QA (SRE), and then discover a bug and correct it -- that's still SRE. If you put t…

Third to last paragraph: if I sell software, a third party bug bounty type guy finds an exploit, notifies me, I patch the vuln, and release the patch as a hot fix: you figure all of that is SRE, probably? (Disclaimer: not seeking tax advice or legal advice, we’re just two dudes casually discussing section 174 like normal people do all the time). That notice was a helpful read. I think what I may have been missing was…

I re-read the section of the notice that scenario would apply to, and I actually think its pretty clear that is not SRE. Correcting defects discovered after the software is put into production, or discovered in released version of software, and not considered SRE. See section 5.03(5)(b) of the notice. Pre-release bug fixes are still SRE though.

Definitely ask your CPA though. I'm not an accountant.

Re: Thousands of small businesses are struggling because of R&D amortization

#368

This is going to wipe out a lot of small businesses, including innovative software dev startups. Here’s a simplified example of this works: Let’s say you’re a four person software dev startup. Everybody is making, say, $125K to get by. That’s $500K in salary expense which normally you can write off as expenses against revenue/funding. For this example, let’s say somehow you also generated $500K in revenue/funding, i.…

As a SMB, if your salary expense is $500k and your revenue is $500k, you are absolutely struggling, no matter the tax situation. In this case you "just" need another $100k in revenue. After all, you are throwing out theoretical revenue numbers anyway. So it just moves the needle somewhat for you to still break even. You could game it just a little if there's revenue at end of year that you can book in the following q…

I think you're arguing against the wrong point.

It doesn't matter if $500k/$500k is good or bad. They're only numbers that simplify the point without misrepresenting the situation.

Re: Thousands of small businesses are struggling because of R&D amortization

#369

Earlier quoted context omitted.

As a SMB, if your salary expense is $500k and your revenue is $500k, you are absolutely struggling, no matter the tax situation. In this case you "just" need another $100k in revenue. After all, you are throwing out theoretical revenue numbers anyway. So it just moves the needle somewhat for you to still break even. You could game it just a little if there's revenue at end of year that you can book in the following q…

I think you're arguing against the wrong point. It doesn't matter if $500k/$500k is good or bad. They're only numbers that simplify the point without misrepresenting the situation.

I think I am being fair. The numbers $500k/$500k were picked arbitrarily to demonstrate how it would kill a business. If you were at $500k/$400k you would be similarly dead. "back then", $500k/$500k was enough to stay afloat. Now you "just" need to be at $500k/$600k, that's all. ie, your revenue needs to be somewhat higher (20% I guess? too lazy to math it) to pay the taxes. Assuming the business stays afloat, you'll eventually break even on the taxes, it's not forever lost like paying AMT for stock options that never become liquid, or RSUs that go well underwater before a lockup expires.

It does suck that a quirk in accounting means you were profitable on the books, no question there. But it "just" means you can't run so close to the bone. I don't think it's the world ender everyone is making it out to be. It means you need more operating capital up front.

Post reply on HN