Tell HN: Submit comments to IRS re tax treatment of software dev expenses

https://news.ycombinator.com/item?id=38120388

by mNovak • 3 years ago

461 225 3 years ago

news.ycombinator.com

Public comments can be submitted regarding IRS Notice 2023-63 "Guidance on Amortization of Specified Research or Experimental Expenditures under Section 174," here: https://www.regulations.gov/document/IRS-2023-0040-0003/comm...

The guidance in question can be found here: https://www.irs.gov/pub/irs-drop/n-23-63.pdf

There was previous discussion of these rules on HN here: https://news.ycombinator.com/item?id=35614313

To very briefly summarize, these rules force certain research expenses to be treated under Section 174 and thus capitalized and amortized over a period of 5 years, instead of under Section 162 (ordinary and necessary business expenses) which are immediately deducted in the year they occur.

Part of the issue is the extremely broad classification of "research expenses". Notably, it classifies virtually all software development as research, as well as the proportional share of all overhead/fringe expenses. It also changes the treatment of contracted research activities (note that includes software). This has a hugely negative impact for early-stage startups, contract research firms (i.e. SBIR companies), and independent software developers.

To construct a basic example:

  Revenue:  $100k 
  Expenses: $100k (developer salaries)
  Net operating income:  $0
  Taxable income: $100k - 0.1x100k = $90k (first year deduction is 10% of SREs)

Come tax time, you now owe the government $18-30k taxes on your $0 real income.

tldrthelaw• 3 years ago

I wrote about it here: https://news.bloombergtax.com/tax-insights-and-commentary/ne...

Please do submit comments.

Kon-Peki• 3 years ago

I had forgotten about this, it's hard to believe that it still hasn't been fixed.

I've read through a number of the comments, and I guess I shouldn't be too surprised to see that most are asking the IRS to do the job of the US Congress. This fills me with despair.

hn_throwaway_993• 3 years ago

That's the problem with basically the entire federal government these days. The US Congress is as near to non-functional as one could imagine. This, actual rule-making has been "delegated by dysfunction" to other entities like the Supreme Court, Executive Orders, and federal agencies.

I really wonder how long this can go on. Our system of checks-and-balances only works when rational actors believe that compromise is necessary to get things done. When you have actors that believe that shutting things down completely is a benefit because it gets them more media time and rabid followers, the whole thing breaks down. Perhaps at some point we'll be able to move more towards a Westminster parliamentary model, where the party in power at any particular time basically controls both the executive and legislative branches simultaneously.

gustavus• 3 years ago

Perhaps at some point we'll be able to move more towards a Westminster parliamentary model, where the party in power at any particular time basically controls both the executive and legislative branches simultaneously

This for me always been one of the most frightening aspects of the parliamentary model. There aren't checks and balances, instead the party in power, as long as they have enough power can rule with absolute authority.

You fail to understand that the US constitution was not created to provide for an efficient government it was designed to protect individual rights.

The much bigger problem in my mind is that we only have 435 representatives and so each congressman represents far too many people, which allows the loudest and craziest vocies to dominate. Instead if we doubled or tripled the size of congress we'd have quite a bit more nuance and the government would be more representative.

amanaplanacanal• 3 years ago

Yes. Notice that of all the nation building the US has indulged in over the years, essentially all of it sets up a parliamentary model rather than the one the US has. I wonder why that is?

creer3• 3 years ago

Yes! It's horrible the lack of understanding of our most basic institutions in this country. It's a fundamental problem. And not helped by either education system or the press currently - both more interested in punchy headlines.

jppittma• 3 years ago

My only hope is that when our republic finally does follow in the footsteps of Rome and become an empire that we at least have a decent administration.

hesdeadjim• 3 years ago

Section 174 hit my company hard, it’s such bullshit.

ezekg• 3 years ago

Clickable link: https://www.regulations.gov/document/IRS-2023-0040-0003/comm...

tikkun• 3 years ago

There are 43 comments so far. I was expecting thousands of comments.

Comments can be with your name, company name, or anonymous.

There's no required info you need to give other than the comment, no account required. Submitting a comment takes 'time to write comment + 5 seconds' - it was very easy.

The comments have been open for 58 days, and they close in 20 days.

Side note: Which of our reps should we call about this, how do we find which rep applies to us, and how can we contact them and what to say? It'd be nice if someone made something like Resistbot for this.

(Though, after checking out the updated version of Resistbot, it seems like Resistbot will in fact work for this. https://resist.bot)

mNovak2• 3 years ago

I was also surprised how few comments there are. It has been making the rounds in the SBIR community, (you'll see that if you read a few public comments) but I saw almost no one mentioning the software side of it. I submitted one on behalf of my company. Others should too, it's really very easy to do.

pclmulqdq5• 3 years ago

Total number of comments also doesn't usually matter in these government comment periods (or at least not in the way you think it does). They are looking for new arguments to support a position one way or the other, not 10000 people commenting with the same take. If 10000 people say "this rule change is bad because my tax bill is higher," that's confirmation that it's a revenue driver, not an indication that it's a bad rule.

NullPrefix• 3 years ago

Laffer curve says that increasing tax rate doesn't necessarily increase total tax revenue. If the tax is too high, business becomes unprofitable and goes bust. A closed shop is bringing in 0 taxes. Even the Mafia understood that you can't squeeze the shops too hard or they'll just stop paying.

csomar2• 3 years ago

Welcome to the world where these “disruptive” changes gives executives ideas how to weaken the “adversary” even if it means it is going to damage the industry. Everyone is probably looking to how to re-adjust in this new environment. Big companies will certainly like since they have liquidity. At the end of the day, the tax pressure will be the same. This is just a liquidity event and it will kill small players with no capital connections.

quinncom• 3 years ago

I don’t see a campaign for this in Resistbot. Do you have a link to it?

jncfhnb10• 3 years ago

What’s the argument on making software not being an investment

Aside from “it’s bad for my startup”

joebob42• 3 years ago

Very few pieces of software in my experience are doing anything 5 years later. 5 years seems like an extremely long time to be amortizing over.

jncfhnb10• 3 years ago

Why?

libraryatnight• 3 years ago

Removing the financial aspect for a moment, since I'm not informed enough to comment, I would like to say lots of companies are essentially running on software way older than five years and a lot of their employees don't even realize it because the 'new' development has mostly been repurposing the old software into apis and services that they then consume for their new stuff, but that old thing is still down at the bottom running the stuff, and the team doesn't understand it enough to do more than consume it, and there's always an ugly moment when something goes wrong and someone on an incident call asks "I thought that was retired?"

And then the devs do the "Well uh, it is, but we still uh, consume...uh...apis...endpoints... umm yeah it's not retired. Hank the ancient that now does dev finance built what we're using, we should get his help" And then hank gets on the phone with a sigh and fixes it.

I initially thought this was something exclusive to where I've worked, but after some years it seems to be true more frequently than I'm comfortable. When it's really bad you realize the entire company was built by Hank and maybe one other dude who got laid off and everybody else has just been making bootstrap wrappers of their tool for 15 years between the bare minimum to keep the servers compliant.

When I meet a software engineer that gives me the impression they're an engineer and not their clan's webmaster, it's kind of a cool day.

jfk13• 3 years ago

True; though for a counterexample, may I introduce you to TeX? Over 4 decades, and still in wide use.

Sure, there's been maintenance over the years, one significant version update (TeX 3.0 in 1990) and an ever-evolving ecosystem around it, but the core engine has been incredibly stable.

fritzo2• 3 years ago

I guess you could say this new tax treatment incentivizes writing more stable, longer-lasting software artifacts?

fdasava5• 3 years ago

If/when software goes out of use, it can be written down and deducted immediately. The 5 years is a maximum, not a minimum.

PaulDavisThe1st19• 3 years ago

Every DAW except Bitwig, every non-browser based image editing tool, almost every web browser, every OS, half(?) the apps in any app store, every IDE I can think of, every text editor and word processor and spreadsheet ...

all far, far older than 5 years.

creer3• 3 years ago

At some point, accounting and the tax code have to recognize business reality. It could be an "investment" and taxed in a way that makes sense.

The problem is that "at some point" can drag for decades and do a lot of damage (ie transform the economy and not in a deliberate manner.)

VirusNewbie• 3 years ago

What is "making software?" Is google search something they 'made' in 2004 and now everything since then is maintaining it? is it making software to support new hardware types, even if the old ones become unavailable? Is fixing a security issue 'making' software or maintaining it?

jncfhnb10• 3 years ago

Yes that is all making software

boredumb• 3 years ago

Trailing off a week of thinking about the executive order on AI research, i'm finding it harder to not think there is an active effort to stifle innovation and progress among little folks.

toomuchtodo• 3 years ago

Please provide a template for quick customization and submission. This will help scale with the remaining time left.

CoastalCoder• 3 years ago

Anyone have a sense of how much this has contributed to the past year's layoffs?

The only factor I usually hear about is raised interest rates.

lgleason3• 3 years ago

I was wondering the same thing. Granted if interest rates were low they could just take on more debt or almost no cost, but with hight interest rates it makes our industry even more rate sensitive.

pclmulqdq5• 3 years ago

Most of the arguments from startup people about these rules come down to "this change costs me a lot of money" rather than "this change is bad accounting." Does anyone know what the arguments are to support the latter?

When this rule was changed, it was framed as eliminating a tax loophole: R&D work is basically a capital investment, since you are effectively buying and improving intellectual property during the R&D process. That suggests that this sort of expense really is a capex that should be depreciated over the life of the intellectual property rather than an opex. I personally think that this is a compelling line of reasoning.

I think there's a good argument that a forced 5-year amortization schedule is far too long for something like a random SaaS, but I'm not sure if I have a good argument that this is bad accounting otherwise. I don't expect that the IRS will be all that sympathetic to Silicon Valley complaining that one of their favorite loopholes is gone otherwise.

1123581321• 3 years ago

The accounting argument is that not all software development is R&D work or creating an asset with long-term value. A lot of it is operational work or closely tied to the revenue that pays for it (so analogous to COGS.)

There is also an accounting and tax principle that small/solo businesses should be able to maintain simpler books that let them reliably feed their families year-to-year; an sudden upfront tax burden for a solo dev impedes that.

pclmulqdq5• 3 years ago

As I understand it, under the current rules, you can classify maintenance work as an opex. You just can't argue that development of new software is an opex.

AnthonyMouse4• 3 years ago

There is also plenty of "R&D" that has only short-term value.

If you make a spam filter, you have to spend resources making sure it can defeat the spammers, but the lifetime of your countermeasures is often measured in months or weeks rather than years.

You may have to pay developers to integrate your product with a third party product, but there is a new version of the third party product released every year so every year you have to do it over again.

There is also an accounting and tax principle that small/solo businesses should be able to maintain simpler books that let them reliably feed their families year-to-year; an sudden upfront tax burden for a solo dev impedes that.

And the correct accounting period to amortize a particular expenditure may not be known in advance. If you build a product and it has unanticipated flaws that require you to start over, the lifetime of the original R&D is trivial. Or it could be a success and generate revenue for decades.

The IRS gets their money either way, whether it's now or tomorrow, but if in cases of ambiguity they insist on now, the disadvantage is primarily to early startups. Large corporations with a stable R&D budget will be deducting their full R&D expense every year because they'll have R&D expenses from five years ago to deduct this year, but anyone just starting out won't. That's a poor choice as a matter of policy.

mNovak2• 3 years ago

For me personally, the 'bad accounting' comes into play with contract work. You build some widget for customer, and if it's anything less than work-for-hire (i.e. you give customer a commercial license but retain copyright or some right to reuse your code in the future), that was research and gets amortized. Think like building or just modifying a Bootstrap template -- is that really "research"?

Maybe it's not concrete, but it feels like there's a difference between investing capex into a planned future product, and retaining some rights in the work you create for others.

jtchang• 3 years ago

I don't think the issue is bad accounting. I think it comes down to software being uniquely different than a factory or piece of equipment. Amortization schedules that are even don't make any sense. Neither does anything measure in years. It's because we make improvement to software on a day by day basis. We don't necessarily add on to a factory every day.

krupan2• 3 years ago

"Intellectual property" is a huge misnomer and it should not indicate that software development is a "capital" investment.

If you disagree, I'm curious what you think about this: if the software you develop is all open source would you still call it a capital investment? Maybe it could be classified as a charitable contribution?

pclmulqdq5• 3 years ago

Yes, I would. Open-source doesn't mean "not intellectual property." It means "intellectual property open to everyone."

patmcc7• 3 years ago

I think it's bad accounting to treat all software development as creating capital assets; some of it clearly is, and should be treated as such, although maybe 5 or 15 years is not the right amortization schedule for software.

I like to use the factory analogy - if you're Ford, and you build a big factory to build cars, that's a capital asset, you need to amortize the costs. But the workers inside, making each car? Their wages are expenses, tracked against the revenue of the cars they make. So - if you make a game engine, that'll be used over the next decade or two, that's a capital asset. If you make a game, that'll see 95% of its revenue in the first year, you should be able to expenses the costs (including salaries) of making it.

avsteele4• 3 years ago

(1) Capitalization is for tangible assets with a useful life and some liquid value. You can't meaningfully monetize the R&E of every engineer.

(2) If you analysis held at all you could pull forward the deprecation if you abandon the research, which might be viewed like disposing of the asset. You cannot do this under this law.

(3) This increases the total cost of R&E work substantially. It is a disincentive to innovation.

See also my other post above.

merritt911• 3 years ago

If I'm not mistaken, the amortization period is 5 years for domestic 'research expenses', but 15 years for non-domestic (foreign). 15 years is a long time...

hn_throwaway_993• 3 years ago

I really, really believe the guidelines for software capitalization are totally outdated (even before this change) and absolutely need to be updated to reflect how software companies actually work today.

The amortization guidelines basically come from old-school packaged software and waterfall development cycles, where software was first built, and then it was a "finished product", and then it was shipped to end users. In a SaaS world, where CI/CD is commonplace and things like A/B testing are everywhere, and it's basically impossible to distinguish "new development" from "maintenance", the whole capex vs. opex for modern software companies is a total joke that can easily be gamed in either direction. For example, I previously worked for an e-commerce company that wanted us to categorize as much dev time as possible as CapEx, because it made our bottom line look better. The whole thing was a total sham, and it's not that the company was at fault, but it's that the accounting guidelines think, wrongly, that software development for most web companies can be neatly divided into "research and development" vs. "maint", and that is just absolutely not possible given how devs at most companies work.

Unless it's basically "shrink-wrapped" software, which largely doesn't exist anymore, software that is delivered by a company that provides that product online and continuously improves/monitors it (i.e. basically all SaaS companies), all software dev should be treated as OpEx, period. Anything else is just a silly game that doesn't reflect reality. The only possibility I can see arguing for CapEx treatment is when there is dev before any product actually has been made available yet.

fdasava5• 3 years ago

Unless it's basically "shrink-wrapped" software, which largely doesn't exist anymore, software that is delivered by a company that provides that product online and continuously improves/monitors it (i.e. basically all SaaS companies), all software dev should be treated as OpEx, period.

You sure about that? If code written 3 years ago is still in production, that's not an operating expense, that's a capital expense. Kind of by definition. In a mature product, you'd expect expenses to shift to opex. But adding features and improvements are all classic capex. Just like any other industry.

rrrix12• 3 years ago

"shrink-wrapped" software, which largely doesn't exist anymore

Except every commercial operating system, any enterprise network or security appliance (physical or virtual), software for hardware (firmware, drivers), or pretty much any other software that isn't implicitly on or connected to the internet.

A few companies who might find this tax paradigm beneficial come to mind: Microsoft, Apple, IBM, Cisco, Intel, NVIDIA... Just to name a few.

I generally agree with the overall sentiment; except the ways in which software is being built and delivered is changing by expansion, but not necessarily changing by replacement.

GeneralMayhem• 3 years ago

Every commercial operating system, and the driver for many consumer components (especially video cards), receives - and are expected by consumers to receive - regular updates for a number of years, and requires constant attention to detect and address security flaws. For the average user, Windows is not all that much less of a SaaS than any web app at this point.

koolba• 3 years ago

Am I to understand from the example that in the simplistic case of a single employee C corp in the field of software, one cannot deduct the full salary of the one and only employee if any of the employee's time is spent working on future initiatives (i.e. "research")?

If so, does this still apply to companies operating on a cash basis?

1auralynn• 3 years ago

Yes and yes

qaq2• 3 years ago

Large companies will work around this by putting some entity in a jurisdiction with different rules and that entity licensing IP to US entity. Small companies will get screwed.

fritzo2• 3 years ago

The SEC and IRS have penalized this sort of IP gerrymandering, e.g. Microsoft's $28Billion fine https://techcrunch.com/2023/10/12/microsoft-faces-28-9-billi...

AnthonyMouse4• 3 years ago

The problem with these rules is that they're unwilling to actually provide any principles because of what it would do.

If hiring engineers in California required you to declare your global profits in California, companies would prefer to hire engineers in another state or another country that doesn't do that, so tax authorities aren't willing to say that's required because of what it would do to the local labor market. But if they don't say that then companies declare their profits in Puerto Rico or Ireland.

You can't have it both ways. Governments have to choose what they actually want to tax, and then take the consequences of companies avoiding doing that in their jurisdiction.

qaq2• 3 years ago

This is MS shifting profits to avoid paying taxes though.

ianbicking2• 3 years ago

I feel like I'm kind of bullshitting here because I haven't looked into this much or thought about it before reading this post, but I left this comment:

Under the logic of this rule, a firm making a software product could invest money in software development, produce the necessary software, then get income from the software without further investment in software development.

In practice this is never the case; revenue gained from software needs to be met with further software development to maintain, update, secure, etc. the software. Firms that invest in capital often have large startup costs that go down as the firm becomes fully capitalized. Software development costs seldom go down, but instead expand with the firm's success. This is counter-evidence to the idea software is capital.

The software produced is also of unclear value and is not fungible. If a firm buys manufacturing equipment and the enterprise is unsuccessful they can sell the equipment. In the case of an unsuccessful enterprise the software almost always is of zero resulting value. Given these rules if a firm invests money in software development, makes some revenue, but ultimately doesn't create a sustainable enterprise, 100% (or more!) of the profits could go to taxes with no ability to recoup the overtaxing when the firm is dissolved.

Additionally, a firm buying durable goods will be able to buy those goods on credit, using the durable good as collateral. The tax laws encourage this process and amortization makes sense. Software cannot be produced on credit, and in practice can never be used as collateral on a loan.

fdasava5• 3 years ago

It's not really that black and white. The production of new software would be capitalized, just like the production of basically any other product. Resources/developer time spent on maintence would be deducted immediately, however.

And... if you have to write down an intangible asset you can... and that will reduce taxes accordingly. You can also get loans for intangible assets, use them as collateral, etc. I don't understand what you're saying about not producing software on credit-- of course you can produce it on credit like anything else. You can hire out a firm. Even if you hire a w2 dev you typically have 2 weeks to pay them for work done.

ianbicking2• 3 years ago

Yes, I should have been clearer that it's not that you can't make it on credit, but you can't use it as collateral. Firms usually buy capital, they don't build it with their own hands; this both means different financial instruments are available to them, and they can liquidate that capital.

(But as I said, my comment is kind of made up)

singron• 3 years ago

It's also illegal to acquire a company primarily to assume it's future negative tax obligations when the capital is depreciated [0], so there really is no way to recoup those costs.

0: https://www.journalofaccountancy.com/issues/2021/feb/tax-ben...

aaronschroeder2• 3 years ago

This is one of the best arguments I've heard. SaaS is valuable because it's Software as a SERVICE. More often than not, the software by itself doesn't have much value without the team with deep domain knowledge supporting, maintaining, and constantly improving it.

Racing0461• 3 years ago

One more of the "regulations" that even though they hurt big companies, they can shoulder the cost but small companies/startups can't do the big companies will support it in order to reduce competition.

PumpkinSpice• 3 years ago

How does this interact with the R&D tax credit? Historically, companies actively sought to classify a portion of software engineering expenses as research, because you received pretty generous tax rebates for that in addition to this naturally offsetting your income:

https://www.adp.com/resources/articles-and-insights/articles...

This looks like an attempt to reduce that second part without touching the first, right? So effectively an administrative action to reduce the R&D tax credit passed by the Congress a while back?

dboreham4• 3 years ago

This seems like the most reasonable interpretation of the rule: if you're going to use development work done to claim the tax credit, then (and only then) you have to amortize said work for taxable income purposes.

gavinhoward12• 3 years ago

This rule is the reason I did not file to make my LLC an S Corp. (If that's the right term.)

A regular single-member LLC, such as mine, is treated as one entity with its owner for tax purposes. The LLC's income is my income, and I just file a personal return for it. This can be bad because it puts you in a higher tax bracket.

An S Corp is a way around that. You have the LLC "pay" you a "wage," and you pay personal taxes on that, while the LLC pays whatever corporations have to pay.

But if your LLC does software, like mine, congratulations! You can only deduct 20% of that "wage."

I've been developing my software for years, and I am not done yet. I don't have revenue.

So if I went the S Corp route, I'd actually have to pay taxes on 0 revenue.

But as a regular LLC, my own work (as the owner) does not count as anything taxable, so I'm safe.

If you are going into freelance, perhaps as a consultant, keep this in mind. And do submit a comment.

Also, beware of accountants that will try to get you to do something that is not in your best interests. I had one or two try to encourage me to file as an S Corp, even though they admitted this could be a problem.

chatmasta2• 3 years ago

So if I went the S Corp route, I'd actually have to pay taxes on 0 revenue

You'd only pay taxes if your revenue were more than your deductible payroll expenses (which as you say, you estimate to be 20% of your salary, which in an s-corp must be a "reasonable salary" for work performed).

There's no case where this law causes you pay tax on zero revenue. The problems require some revenue before they affect you, which might actually be another argument against it - you're disincentivized to create revenue from your early product if it's not going to be enough to cover your tax obligations.

gavinhoward12• 3 years ago

Well, I would hope you are right, but that's not what the accountants were saying.

dboreham4• 3 years ago

Ianaa (I do own an LLC, an S-corp and a C-corp doing software though), but this sounds fishy. Besides some details at the margin such as payroll taxes, tax treatment (how much tax $y is owed on revenue $x) should be roughly the same regardless of the legal entity type.

gavinhoward12• 3 years ago

The accountant explained it this way: did money change "hands"?

If money went from the LLC into a "wage," it changed "hands." The IRS wants in on that.

If work went from the owner into an LLC, no money changed hands, and the IRS doesn't care.

But the very fact that people do S Corps shows that there is different tax treatment though.

SkyPuncher• 3 years ago

Single member LLC should really be its own business type in most states. Lots of special rules apply to them and only them.

The benefits of S and C corps don’t really come into play with single member LLC

rrrix12• 3 years ago

Awesome. Thank you for this post. I've recently been stuck on this very topic as I begin to explore both consulting and building commercial products. I'll be following you!

For the short term (contracting) I'm simply working as a Sole Proprietor, but I don't really have much work or significant income yet.

chatmasta2• 3 years ago

You don't need to decide whether to file as an S-Corp or LLC or C-Corp until tax time. Don't hesitate to open an LLC if you're worried about getting it wrong. It's worth opening an LLC immediately just so you can get a business bank account. You don't need to worry about the tax implications until you actually file them and have to decide which elections to make.

gavinhoward12• 3 years ago

Good luck!

If I may make one suggestion: even if you want to be a sole proprietor, look into getting an LLC.

If you run into trouble with a client, a properly-done LLC can save your house or other large assets.

With a sole proprietorship, all of your personal stuff can be on the hook too.

It's essentially the same advice as keeping separate devices for work and for personal use.

gamblor9564• 3 years ago

The accountants are not lying to you; you are misunderstanding what they are saying.

A single-member LLC and a single-member S-Corp are both essentially flow-through entities for a solo entrepreneur. However, they are ultimately taxed quite differently: with an S-Corp once you exceed the SSI threshold for the essentially mandatory portion of revenue you must repatriate to yourself as a salary, the remaining income can be repatriated as qualified dividend which is taxed at a significantly lower rate than directly passed-through income. With an LLC, it's all self-employment income subject to regular income taxation, meaning that in any realistic scenario, you're paying a higher effective tax rate with the solo LLC form.

So if I went the S Corp route, I'd actually have to pay taxes on 0 revenue.

This is false. The income tax on $0 revenue (meaning no revenue, not no profits) is the same: $0. (Note, however, that many states have "fees" assessed on business entities like S-Corps and LLCs, even single-member LLCs, and in such cases a minimum fee is owed regardless of revenue.)

But as a regular LLC, my own work (as the owner) does not count as anything taxable, so I'm safe.

This is also false. The work you provide to the entity as an owner is still an R&D expenditure. The difference is that with the S-Corp, the expenditure cost is clearly documented, while with the LLC you're pretending that the number is $0 and gambling on not getting audited. This only matters once you start generating revenue...

Either way, not all of your salary would be subject to capitalization. If you have revenue, you clearly spent at least some time and work on marketing and business development, and expenses for those non-R&D activities are not capitalized.

With the S-Corp, your salary offsets up to [your salary assigned to non-R&D tasks less 1/10 [see note] of your current-year salary assigned to R&D plus carried-over capitalization from R&D from prior years] in revenue each year, and after an appropriate amount of salary (generally the SSI contribution threshold for the year) the rest of that annual revenue can be repatriated to yourself as a dividend at lower tax rates. With the LLC form, since you aren't paying yourself a salary, you owe tax on 100% of the revenue arising from the software you develop without any deductions.

TLDR: If you actually care about tax, S-Corps are almost always the better option for the solo entrepreneur, and they're still the better option here.

NOTE: Capitalization is on a mid-year convention, so the first and last year you only capitalize 1/10th of the cost; and in the middle 4 years you capitalize 1/5th of the cost. So, for Y2, if you paid yourself $100 in salary both years, your total capitalization deduction would be $30: $10 capitalization for the Y2 salary and $20 for Y1 capitalization.

gavinhoward12• 3 years ago

The difference is that with the S-Corp, the expenditure cost is clearly documented, while with the LLC you're pretending that the number is $0 and gambling on not getting audited.

So if the IRS audits me, they'll say that my work is worth something and therefore, I have to pay taxes on it?

Sounds awful.

But I and the accountants I talked to don't think that's the case.

Also, I'm not going to take R&D credits, nor claim deductions from salary, so why would they care?

And I did the math: yes, an S Corp is technically better. But at the revenue levels I plan on seeing, the difference isn't that much (a few thousand), and any revenue gets taxed right away, which is more convenient for me. I'll take that instead of complicating my taxes.

antasvara3• 3 years ago

If you have zero revenue, how are you paying yourself a salary from the S Corp?

gavinhoward12• 3 years ago

I don't have an S Corp.

fdasava5• 3 years ago

This has a hugely negative impact for early-stage startups, contract research firms (i.e. SBIR companies), and independent software developers.

Yeah, but that doesn't make it unfair, no? The whole "develop it today, pay taxes on it later" effect SaaS used to have was just a loophole software enjoyed for a long time. Developing anything is investment, and tax code generally requires that to be amortized so you can't deduct it all year 1. Congress just closed the loophole for software.

Apreche• 3 years ago

The thing that I hate most about this rule, as a developer, is that employers keep trying to get me to track all my hours of work. They do this to figure out what portion of my wages they can claim as capitalized expenses.

That would make sense if I was a consultant, or working for a consultancy, and billing someone else for those hours. As a full time salaried employee, time tracking is just a pain in my ass.

To make things worse, I believe that few, if any, companies doing this time tracking are doing it with any amount of rigor. If an auditor really wanted to check, they would find that the claimed capitalized expenses are overinflated, and are technically tax fraud.

Just remove the rule altogether. A company paying a wage to a software engineer shouldn't be taxed any differently than any other kind of employee.

fdasava5• 3 years ago

Just remove the rule altogether. A company paying a wage to a software engineer shouldn't be taxed any differently than any other kind of employee.

In most other industries, product development is capitalized and amortized over the life of the product for tax purposes. It requires lots of estimation and log-keeping (X% spent on develpoment, 100-X% spent on maintenance). Which is exactly what your employer is doing... taxing you just like every other kind of employee.

The change just removed the specific loophole for software.

spac2• 3 years ago

Except that for software this is so much more complex than for any other type of products.

PaulDavisThe1st19• 3 years ago

To try to clarify for anyone reading about this for the first time ...

this all hinges on whether language in the tax code is interpreted one way or another.

Way #1: companies often try to claim many deductions on R&D expenditures, and the changed language makes it clear that all software development expenses can be claimed as R&D expenditure (which was not necessarily clear before).

Way #2: all software development expenses MUST be treated as R&D expenditures which requires claiming them as an amortized deduction (over 5 or 15 years depending on where they happen).

Neither the IRS nor Congress has clarified the intent of the change, and there are solid arguments for both interpretations. Way #2 is supported by the use of "shall" in the language used. Way #1 is supported by the fact that Way #2 is batshit crazy.

It seems that a lot of people are convinced that Way #2 is the intended one, despite its catastrophic implications for many software-based companies.

dboreham4• 3 years ago

Thanks for posting this clear explanation. Every time this comes up it's frustrating to see commenters assume that it's certainly intended to be way #2.

dataflow3• 3 years ago

If it's so crazy that people think "shall" couldn't have possibly been meant to be taken literally, (why) is there no court case about it? Is that not possible at this stage in the process?

martinflack2• 3 years ago

As a law prof once told me, "shall" can end up being ambiguous in court, despite the common understanding.

I'm sure this isn't the best tutorial on the topic but it gives you a taste: https://www.barandbench.com/columns/shall-shocked-the-use-of...

anon373839• 3 years ago

I think the issue is different. It’s not whether “shall” means something other than “must”; rather the issue concerns the scope of the code section containing this language. For example, in the California Rules of Court, you can find a rule that that briefs “must” use 13-point type. (Rule 8.204(b)(4).) That provision is located within the title on appellate procedure, so it has no effect on trial briefs. Even if it said “absolutely shall with no exceptions whatsoever and under penalty of death,” it would have no effect in a trial proceeding.

pclmulqdq5• 3 years ago

I'm pretty sure way #2 is the letter of the law, but doesn't apply to a lot of kinds of software development that fit into the general sphere of "maintenance," only to new development.

PaulDavisThe1st19• 3 years ago

I should add that's there is also vaguely middle-ground interpretation, which goes something like:

Way #1.5: if a company chooses to take R&D expenditures of any type as a deduction (which it is not required to do) then it MUST include software development expenses (which in turns means they will be amortized).

yieldcrv5• 3 years ago

unless they aren't deducting software development at all

there is no obligation to take a deduction. if you find yourself in a circumstance where its more favorable to not take a deduction then you don't have to report that transaction

Ldorigo• 3 years ago

Can you explain to someone not familiar with US tax law why #2 is batshit crazy?

PaulDavisThe1st19• 3 years ago

#2 would imply that anyone who chooses to engage in software development (either personally, or contracting others to do the work) cannot consider the expenses to be regular (non-amortized) deductions.

This means that you cannot, for example, pay yourself a salary and have that treated like the salary you would receive if, for example, you had chosen to be a builder or an artist or a massage therapist.

Another commenter here touched upon what I assume would be the justification for this: with software you spend Y years and C money to develop it, then you sit back and collect revenue, therefore the C money you put it at the beginning is a capital expenditure. But that's rarely the case with any software. Either it is a perennial, on-going process that never stops, or it ceases to be a revenue source. There are exceptions (especially since the dawn of mobile apps) but they are not the rule.

It's also not clear precisely what the difference is between working as a self-employed software developer and a self-employed architect is. They are not exactly the same, but why the former should not be able to take a regular salary from the revenue available, and the latter can doesn't seem clear, let alone equitable.

If anyone has actually thought about things this way, they seem to have a model in their mind that all software development is done following a process of "build first, sell later". This just isn't an accurate reflection of how a lot (most?) s/w development takes place.

keepamovin7• 3 years ago

One could argue that the tax approach outlined in Way #2 rightly adjusts for the longstanding discrepancy where software development costs, particularly salaries, have been treated as immediate expenses rather than capitalized investments in software IP—an asset with enduring value. The explicitness in software development and employment contracts about the creation of IP suggests this capitalization is a reflection of actual business transactions, making the tax treatment more aligned with economic reality.

This change might not be as much an undue burden as it is a logical extension of tax principles applied across various industries. From this perspective, the software industry's ability to immediately expense these costs could be viewed by other sectors as an inequitable advantage, one that is now being corrected.

While the apprehension around these changes is understandable due to the added complexity and potential for increased tax liabilities, it's worth considering that some of the more intense reactions could be driven by a concerted effort from larger entities aiming to generate grassroots resistance against the new rules. It’s conceivable that the IRS, aware of the potential burden on smaller companies, might enforce these rules with a revenue threshold, thus sparing smaller enterprises from the need to capitalize software costs.

Moreover, it's crucial to recognize the benefits of capitalizing software expenses: it affords companies the opportunity to match tax deductions more closely with the productive life of the software. This can lead to a smoother tax liability schedule and cash flow, particularly advantageous for companies with consistent earnings and those that stand to gain from representing their software development efforts as capital assets on their balance sheets.

PaulDavisThe1st19• 3 years ago

I agree that you could argue all these points.

I have to agree, because I don't agree with any of them :)

While the actual duration of software value is neither the day it was created nor "forever", the idea that a fixed amortization schedule is appropriate seems clearly wrong to me. Even crazier that it would depend on the geographic location of the person who did the work.

The productive life of any particular blob of source code is an awfully complicated thing to talk about, and the idea that the tax code should attempt to incorporate such a concept into a relatively simplistic rule (or pair of rules) seems faintly ludicrous to me.

jandrewrogers2• 3 years ago

A major issue is that in many cases most of the software asset value is explicitly conditional on the continued involvement of the people that created it. The value of the code base is orthogonal to its existence. I’ve seen this pattern many times in software IP licensing (or startup acquihires).

There are many instances where companies buy the team that created software rather than the software itself because so much of the value resides there. For obvious and good reasons, a company has no ability to claim a team as an asset because they have little control over its disposition since people are free to work when and where they want.

The continued erosion of enforceability of non-competition in employment contracts, which I agree with as a matter of policy, aggravates this situation in that the company has few levers to ensure that software development has asset-like characteristics. Large companies with many revenue producing software products can amortize the risk but the great many small shops with a single software product cannot.

nodamage2• 3 years ago

Neither the IRS nor Congress has clarified the intent of the change, and there are solid arguments for both interpretations.

Not true anymore, the IRS guidance linked above in Notice 2023-63 specifically indicates they are adopting interpretation #2:

"Section 5.03 - Activities that are treated as software development. Activities that are treated as software development for purposes of § 174 generally include but are not limited to:

(1) Planning the development of the computer software (or the upgrades and enhancements to such software), including identification and documentation of the software requirements;

(2) Designing the computer software (or the upgrades and enhancements to such software);

(3) Building a model of the computer software (or the upgrades and enhancements to such software);

(4) Writing source code and converting it to machine-readable code;

(5) Testing the computer software (or the upgrades and enhancements to such software) and making necessary modifications to address defects identified during testing, but only up until the point in time that:

(a) In the case of computer software developed for use by the taxpayer in its trade or business, the computer software is placed in service; and

(b) In the case of computer software developed for sale or licensing to others, technological feasibility has been established, product masters(s) have been produced, and the computer software is ready for sale or licensing to others; and

(6) In the case of computer software developed for sale or licensing to others (or the upgrades and enhancements to such software), production of the product master(s)." ‎‎

PaulDavisThe1st19• 3 years ago

This doesn't differentiate between #1 and #2. It clarifies what is and what is not software development (for the purposes of Sec 174).

The question remains open: is the intent that all software development expense MUST be treated an amortized capital investment, or that all software development (fitting the description above) CAN be treated in that way.

PaulDavisThe1st19• 3 years ago

* IF YOU READ THE ABOVE, PLEASE READ THIS TOO *

Another commenter alterted me to this guidance document from the IRS:

https://www.irs.gov/pub/irs-drop/n-23-63.pdf

This makes it absolutely clear that "Way #2" is the IRS interpretation of the law after the TCJA passed. That is, any software-development related expenditures MUST be treated as capital expenditure and be amortized over 5 years (or 15 for foreign based work). The document explicitly states that such expenditures CANNOT be treated as ordinary expenses under Section 162 (the section that would normally allow for business expense deductions).

Having read the whole document (which I should have done before), it is absolutely clear that this is totally batshit crazy.

codazoda• 3 years ago

Does this rule encourage off-shoring? Meaning that contract developers just invoice you and you write that off as any other expense, or does it apply equally there?

creer3• 3 years ago

"Just as any other expense" meaning that it's a software development expense. I don't think it matters much in US tax whether you do it in house or not.

It might matter if you buy finished software modules and integrate and resell them.

PaulDavisThe1st19• 3 years ago

If the interpretation that all software development expenses MUST be treated as R&D expenditure and claimed as a deduction is correct (which it might be, but it might not be), then it's worse for off-shoring because the amortization period is 15 years. That is, you paid off-shore contract developers $100k, you can only deduct $6667 of that in any given year, over the next 15 years.

ImPostingOnHN• 3 years ago

This is also a problem facing recipients of government grants. The government will give you the 100k you ask for, let you spend it on what you planned to, then tax 80k in revenue (100k with 1/5 years amortized), asking you to give some of it right back to them (like the post says, you are forced to amortize your expenses over 5 years, even if they were all in year 1). Why?

Now academic research needs to consult on tax implications and have some set aside.

mijustin• 3 years ago

If you’re the owner of a small software company, there’s a group of us that have been petitioning congress.

You can sign the letter and send it to your representative here:

https://ssballiance.org/

iusuallylurk• 3 years ago

I believe there are only 43 because they require "review" before being posted officially.

It is likely that they do not approve the majority of comments, I submitted one but it has not yet been approved.

burroisolator• 3 years ago

Does it help to submit duplicative arguments? I see some pretty strong arguments in the comments already. I wish there was a way to just upvote an existing comment.

devoutsalsa• 3 years ago

Can I get a tax refund on $0 revenue for deleting code?

riku_iki2• 3 years ago

Revenue: $100k Expenses: $100k (developer salaries) Net operating income: $0 Taxable income: $100k - 0.1x100k = $90k (first year deduction is 10% of SREs)

And idea is that your deductions you lost here will be applied in next 5 years.

mjwhansen• 3 years ago

To add to this: please contact your Representative and Senators and tell them to tell Congressional leadership to fix R&D spending by the end of the year.

Congressional staff are required to keep tabs on everyone who calls in about an issue, so your time is well-spent.

The November 17 continuing resolution is our best chance to get this fixed, but only if enough members of Congress hear from their constituents about it!

spac2• 3 years ago

I have submitted a comment to the Notice, as well emailed my Represenatives and state Governor. I urge every one to do the same, this is absolutely bonkers and I agree that it will severely affect the startup ecosystem.

dv_dt• 3 years ago

Do you actually need software salaries to be treated as R&D vs a more regular salary expense? (I'm not an accountant so I'm not even sure I'm using proper terminology) I understand there maybe be other non-salary sw-dev expenses too...

Does an R&D classification give different tax accounting options at least for the salary part?

sb8244• 3 years ago

That's my big question here. If I don't claim an r&d tax credit, does the salary still get treated as r&d?

avsteele4• 3 years ago

This is about way more than software.

Bear in mind that the way it is written all research and experimentation costs would be amortized. So if you have a chemist, biologist, physicist or even an engineer it plausibly is the case that if you are paying them to develop a new product that carries technical risk then their *salary* needs to be capitalized!

Good luck coming up with the cash to pay a tax bill on 90% of their annual salary. You can't even pull forward the depreciation if you abandon the research! Sure, it mostly stabilizes after about 6 years if your R&E budget is flat, but even in this case there is a huge cost in that you only get to deduct their salary in the far future. It is huge disincentive to developing anything new.

This is a total nightmare and cost many business like mine an absurd amount of money this year. Everyone just filed for extension in April assuming this insanity would be reversed before the late filing deadline... NOPE!

(NB: it is NOT necessarily tied to R&D, or the R&D tax credit. The calculation of this is subject to different rules.)

I don't even know how large companies found the cash to pay this bill. How can a biotech or software company whose annual expenses I'd guess are largely salary have had the money to pay taxes on 90% of their salary budget?

onlyrealcuzzo• 3 years ago

Do any other countries do this?

And if not, why would anyone push for this - unless your intention is to make sure no R&D happens inside the US.

Who's pushing for this?

avsteele4• 3 years ago

US treatment under the old rule was constant from the 1950's.

I don't know about other countries.

I haven't found anything credible on 'why' this was added, but...I'd hazard a cynical guess that it was put in as a way to reduce the apparent cost of the TCJA. You look for ways of raising revenue in your bill so you can claim it costs less. You do this do this even if you expect that (unpopular) change will be undone later.

A second possibility is that it was added to reduce the benefits of the R&D tax credit, which in fairness a lot of companies probably abuse.

walterbell2• 3 years ago

Do any other countries do this?

Nov 2023 letter signed by Y Combinator, https://news.ycombinator.com/item?id=38145699

  As a result of this change, the U.S. is now one of two developed countries requiring the amortization of R&D expenses.

sokoloff• 3 years ago

You can't even pull forward the depreciation if you abandon the research!

Why would that not be a write-down as a result of impairment of a capitalized asset?

avsteele4• 3 years ago

Practically speaking its because there is no asset, unlike other CapEx.

The law specifically does not permit this. You just can't deduct the expenditure except as over 60 months (and only 6 months in the first year)

walterbell2• 3 years ago

2023-11-02 letter signed by trade associations and companies (incl. AMD, Cisco, Dropbox, HP, Intel, Nvidia, Qualcomm, Y Combinator), covers three points including R&D expenses, https://documents.nam.org/TAX/2023%20Tax%20Priorities%20Sign...

   1. For nearly 70 years, the tax code recognized the importance of R&D by allowing businesses to fully deduct their R&D expenses in the same year they were incurred. Unfortunately, starting in 2022, the tax code has required businesses to amortize (or deduct over a period of years) their R&D expenses, making R&D more costly to conduct in the U.S. ... tens of thousands of jobs are at risk if the harmful R&D amortization requirement remains in place. As a result of this change, the U.S. is now one of two developed countries requiring the amortization of R&D expenses.

  2. Prior to Jan. 1, 2022, businesses' interest expense deductions were limited by section 163(j) to 30% of their earnings before interest, tax, depreciation and amortization (EBITDA). Interest deductions are now limited to 30% of earnings before interest and tax (EBIT). 

  3. Over the past several decades, the tax code has provided businesses with varying degrees of first-year expensing (i.e., accelerated depreciation). A 100% deduction for the purchase of equipment and machinery in the tax year purchased was in place from 2017 through 2022 ... full expensing began to phase out at the beginning of 2023 and will be eliminated completely by 2027.

Xorakios• 3 years ago

Oh good golly, don't forget the $19,000ish for federal self employment taxes

zharknado• 3 years ago

Call me crazy, but…

4.03(2)(d)

Cost to input content into a website.

Listed as an excluded cost (not SRE).

So… if hypothetically my IDE is in a browser, and I spend my whole day coding there, I’m just inputting content into a website, aren’t I?

How about an Electron app?

mariodiana• 3 years ago

According to the government, if it involves "tubes," it's the Internet.

lgleason3• 3 years ago

For people doing contract software development in a work for hire type of fashion, at this point it looks like this will not directly affect you or a business that does that. But your your client is going to have a bigger tax bill which may mean less money to pay you for development.

bunnie2• 3 years ago

Seems like somewhere in all of this there is an assumption that one writes software to profit from its sales.

However, in some cases people contribute software to open source projects that are not only Libre but also "Free as in Beer". Sometimes they get donations or grants to work on such projects. Heck, they might even have a contract from a company that uses this free-as-in-beer software, but, once the contributions are made, the code is free for everyone to take.

In this model, there is explicitly no forward looking profit to be had. All parties contractually agree that the value of the work, after it is done, is $0.

In this case I don't see how it would even make sense then to amortize donations/grants/contract money on a 5-year schedule when the asset value of the deliverable is $0?

I would think in this case that the person doing the development is providing a bona-fide "service industry" activity, and not doing an R&D activity. Thus the wages of that person should be as deductible as any other service-industry worker: There is as much expectation for future profits from writing this code as the person painting your house has future expectations of profits from the higher resale value of your place because of the improved paint job.

So at least for individuals being paid to work on free-to-download code, the entity paying you to do the coding may have to write off your contract as an R&D expense, but the individual contractor should still be able to depreciate that payment as a wage within the tax year because they are providing "coding services", and not doing R&D.

This logic has precedent if you consider how capital assets work. Let's say a shop purchases a donut machine. The purchaser of the donut machine has to depreciate that purchase over several years. However, the individuals who were paid to assemble the donut machine are paid wages as factory labor, and their expenses are deducted by the donut machine marker that tax year.

In this case the donut shop is whoever is paying you to write the code, and the coding contractor is the donut machine assembly technician. So long as the donut assembly technician doesn't have a stake in the donut shop's future-looking profits, I think it's quite clear who is providing a service and who owns a capital asset.

I think this logic would also mean that individual contractors who work on proprietary, for-profit code bases but assign all value of their work product immediately to the contracting body would also be a service provider and thus can depreciate their own wages within the tax year. But, the example is not as clear-cut as a work product that explicitly has a $0 expected market value.

bunnie2• 3 years ago

I see now that Section 6.04 explicitly states that if a provider retains any right to use the developed software, they are not allowed to deduct their expenses:

"However, even if the research provider does not bear financial risk under the terms of the contract with the research recipient, if the research provider has a right to use any resulting SRE product ... costs paid or incurred by the research provider that are incident to the SRE activities performed by the research provider under the contract are SRE expenditures of the research provider for which no deduction is allowed ..."

Thus, the rule as written would make it such that contractors who write Windows drivers could deduct their expenses (as they would have no rights to Windows), but contractors who write Linux drivers may not (as they would have some rights to Linux).

In effect, the tax rules would explicitly double-tax open source software development, due to its over-broad test of whether you could have any right to the code base you've written, irrespective of whether the code you wrote actually has any practical residual value to the author.

Tell HN: Submit comments to IRS re tax treatment of software dev expenses

Related Stories