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 good idea, everybody thinks their particular loophole is a good idea. To say that removing the special treatment is a policy mistake is a reasonable position to take, though opponents have a reasonable position as well (as I said I'm in favor of the special benefit). But to call this change unfair is, IMHO, unreasonable.
It's also bogus to plead ignorance as the twitter poster did: "as they'd never had to amortize software development before, and didn't think of the work they do as R&D." Their accountants sure did, because otherwise it would not have qualified for the R&D exemption. And their accountant would have to tell them what to do to make it qualify.
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 difficult for me to tell how much of this issue is just people making a fuss about the literal interpretation of the tax code compared to how it will, in practice, impact their business.
Nearly all accountants try to operate in the gray, in that accountants know how to tweak the numbers just enough to not get in big trouble with the IRS but enough that the business can slide through various loopholes. I have a feeling most accountants would just say “reclassify your engineers as maintenance workers, COGS” as a solution.
> 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.
I’ve many years of experience over a variety of companies and none of my jobs were janitorial work. You’re describing SRE or intern work. Many many many Software engineers build things, especially in startups which is the focus of the discussion.
> 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.
They used to be able to. Then Trump and the Republicans came into power and changed it in 2017; the first year to be effective is 2022.
Before the 2017 change you could and should have if they were not engaged in actual R&D. But people used to lump them into R&D anyway because of the preferential tax treatment (you also used to get special treatment for NOL, which you can't any more).
Software development doesn't generally follow GAAP's model because unless you're IBM or Oracle the same people sometimes fix bugs and sometimes develop new features.
The GAAP rules aren't insane: if your company buys a HQ building it's assumed to last 40 years. And since each year you "get some value" (e.g. you don't pay rent to someone else) you split the value of that purchase over 40 years. If you buy a computer you amortize it over 3 years because you're likely to "use it up" and replace it after that.
And so if you're a car mfr you might have some people developing a new automatic transmission. You expect to then put those things into new cars for some time to come. So GAAP says the R&D that went into the new transmission is amortized while the cost of making one and sticking it into a car you sell is indeed COGS.
If you're an early stage pharma startup almost all you do is R&D for quite a long time. For a software startup you can say the same thing: even if you ship your MVP, every bug you fix is turning it into the "real thing" (unlike Oracle, above, who can split maintenance and development into two buckets).
So I favor accelerated recognition of R&D costs for startups. Not sure about established companies.
All of payroll is lumped into 1 line item when submitted to the IRS. (I’m only somewhat simplifying for sake of argument)
We would have to go out of our way to split out R&D.
When you win $500 at a casino, do you go out of your way to claim the gain on your taxes? Absolutely not. Are you supposed to? Absolutely, but you don’t. And the IRS doesn’t much care.
I feel like we’re talking past each other. The vast majority of companies won’t be paying more taxes because of this rule change.
Do you not keep your books according to GAAP either?
If you make up your own accounting rules and it seems to work for you, well, more power to you.
I like to have a clear understanding of where my business is going and the GAAP rules are pretty reasonable and align with other companies and what they do.
We do. We also have professional accountants who manage all this for us.
It’s interesting that HN is more concerned about the rules changes than the person filing our company’s taxes (or our CFO). This is a topic that is basically glossed over as a non-event between us and those professionals.
(Unlike the wayfair ruling which sent everyone, including our accountants, up in arms about sales tax and how to decide nexus)
Maybe I have a bad accountant and CFO? Or HN is extrapolating this to mean more than it does.
> It’s interesting that HN is more concerned about the rules changes than the person filing our company’s taxes (or our CFO). This is a topic that is basically glossed over as a non-event between us and those professionals.
You are the one who originally asked why engineers can't be considered a cost center. There is a reason; the R&D tax credit.
> Maybe I have a bad accountant and CFO? Or HN is extrapolating this to mean more than it does.
I am guessing you just do not qualify for the R&D tax credit or it just not worth the paperwork at your scale. For larger companies (and profitable, fast-growing startups that do a lot of the 'develop' part of R&D, which are rare these days, I guess) there is a benefit.
Considering even the tax foundation claims would bring in less than 20k jobs, maybe Congress made the right decision to bring in amortization even if I disagree with what it funds. I do not have numbers for how much it brings it to the federal government but the credit was already known for being difficult for small businesses to use.
i don't know enough about tax codes and how business works to comment on the actual policy, but it sure does seem to me that changes that result in immediate and massive new liabilities are unfair.
> changes that result in immediate and massive new liabilities are unfair.
Congress knows this: the law was passed in 2017 but only took effect for tax year 2022. This very issue was widely discussed at the time.
That was five years to figure out what to do and your CFO (or at the very least your tax accountant) should have been warning you. I mean, if your tax accountant doesn't know the tax law that's a bad thing.
I think the big problem with this is just the accounting burden: now even salaried programmers have to track hours between greenfield and maintenance development.
I suspect you could use your infrastructure ti give you a pretty good idea of where the split is as you have tools like your bug tracing system, different branches on repos etc to figure out adequately how much time goes where. Much better than time cards unless you’re a government contractor.
I respectfully disagree. By these arguments, literally every deduction from revenue to calculate taxable income is a "loophole". How far does that go?
What's more absurd than life itself is that you can deduct 100% of a 6000GVWR truck which you financed for 7 years, but my engineers salaries aren't deductible because I'm "building some product" so that's "development".
Now though I happen to think accelerating it is a good idea, everybody thinks their particular loophole is a good idea. To say that removing the special treatment is a policy mistake is a reasonable position to take, though opponents have a reasonable position as well (as I said I'm in favor of the special benefit). But to call this change unfair is, IMHO, unreasonable.
It's also bogus to plead ignorance as the twitter poster did: "as they'd never had to amortize software development before, and didn't think of the work they do as R&D." Their accountants sure did, because otherwise it would not have qualified for the R&D exemption. And their accountant would have to tell them what to do to make it qualify.