Tell HN: Submit comments to IRS re tax treatment of software dev expenses
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)
238 comments
[ 4.8 ms ] story [ 265 ms ] threadPlease do submit comments.
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.
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.
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.
Before that, your governor would choose who the senator was via whatever the process the state had for this. It had a knockoff effect of people caring a lot more about their state and local politics and keeping some governing power in the states leadership. Both I sincerely believe were worthwhile goals, as many people get caught up in federal politics and there is far less population participation in state / local politics as a result.
I do believe quite strongly that we need a bigger House of Representatives too. I 100% agree on that. I don’t think the founders foresaw a world with 300 million people living in the US
Take your BS condescending tone elsewhere. I don't "fail to understand" anything. There are plenty of other nations with parliamentary systems that protect individual rights just fine, arguably much better than the US does.
> There aren't checks and balances, instead the party in power, as long as they have enough power can rule with absolute authority.
Except, again, plenty of functioning governments with parliamentary systems show that if a government overreaches, they are still responsible to the will of the voters, who can (and do) kick them out at the next election. I think it's much better to say "OK party X, we'll try your ideas for the next few years, and if you f it up you're gone." rather than have nothing get done for years, where each side can blame the problems on the other for why they couldn't achieve their agenda.
it just means government didn't manage to overreach far enough. Countries like Russia and China also have parliaments, its just happen that ruling party obtain monopoly on violence which they apply on any possible competitor.
Try telling that to Belgium, which took just short of a year to even form a government, or to Liz Truss in the UK, if we're going to compare it with another country with a FPTP election system.
It actually tends to result in the opposite of that, the executive is relatively neutered, because they know they can be dismissed at the pleasure and whims of parliament.
The American executive gets to be comparatively authoritarian, as once you elect a president they're guaranteed to be able to enact their executive agenda for the next 4 years (the theoretical threat of impeachment being a non-issue in practice).
Exactly. A far greater proportion of countries that elect a President based on the American democratic model have devolved into dictatorships, than have countries with parliamentary systems.
Can you name another nation where people have as strong a right to free speech as the US, let alone as much of a right to bear arms?
In fact, I'd argue that a parliamentary government has a greater chance to fall into dysfunction in some cases. Just look at the Israeli Knesset before the war.
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)
Aside from “it’s bad for my startup”
[0] https://www.investopedia.com/terms/c/currentassets.asp
I have several projects running in prod, at several companies, for over a decade. They are easy to maintain, easy to extend and build on, and easy to understand.
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.
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.
The incentive is to write software that is immediately profitable, and investing in long term projects becomes more costly.
Expansions and improvements would generally be capitalized.
all far, far older than 5 years.
Most of the development effort for such things happened in the past 5 years? That sounds unlikely.
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.)
The only factor I usually hear about is raised interest rates.
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.
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.
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.
In 2022 our reported "taxable income" to the IRS skyrocketed because of this rule change. Despite a small profit, we are paying tax on essentially 50% or more of our REVENUE. And because we are a pass-through entity, it pushes us into tax brackets that are quite ae bit higher than corporate tax rates of C-Corps.
2 or 3 years into this we will either have to take a loan to pay taxes, find a way to cut expenses, or (hopefully) grow enough in revenue while not increasing expenses to cover the additional tax.
It really is insanity. Our accounting firm and everyone they spoke with was convinced it would be "fixed" by congress before the final extension deadline a couple months ago. So we waited to the last minute to file, which, of course, resulted in significant late fees and interest on top of everything else.
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.
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?
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.
(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.
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.
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.
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.
If so, does this still apply to companies operating on a cash basis?
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.
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.
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.
(But as I said, my comment is kind of made up)
0: https://www.journalofaccountancy.com/issues/2021/feb/tax-ben...
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?
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.
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.
The absolute worst case scenario would be having to pay taxes as if your revenue was nearly all profit - as if you had no expenses (or very few). As always, you only pay taxes on 'net income' - revenue minus expenses - this whole mess comes about by tweaking how expenses are calculated.
And that will be the case for me next year, so yes, this matters to me.
It is literally backbreaking for a friend who is self funding a team of engineers. The money to pay taxes literally doesnt exist. It was paid as salary.
I told him to ignore the accountants and simply not pay. Let the IRS come after him
But there's a very critical misunderstanding happening in a lot of comments here -the IRS taxes profit (net income), not revenue. Anyone with zero revenue is safe. Anyone with SOME revenue will potentially owe some taxes, and potentially in a very surprising (and unfair, I think) way. The basic example in the submission is quite correct.
>>>I told him to ignore the accountants and simply not pay. Let the IRS come after him.
This is a great way to end up both out of business AND in jail. It is not the smart play.
Not in this case, which is the challenge and pain. You can have a company with negative profit, and have to pay income taxes on revenue.
>This is a great way to end up both out of business AND in jail. It is not the smart play.
Strongly disagree, and this is how I run my business. There is sufficient ambiguity and debate on the topic to support an ambiguous reading. Nobody is going to jail. Worst case scenario you get a nastygram from the IRS in a year or two, provided the issue hasn't been clarified in YOUR favor.
If your company is living hand to mouth with expenses above revenue, the money the IRS wants literally doesnt exit.
Incorrect; you can have a company with negative cash flow and have to pay income taxes on profit - as the IRS defines it. And you can certainly disagree and argue with them about it, but they're likely to win.
>>>If your company is living hand to mouth with expenses above revenue, the money the IRS wants literally doesn't exit.
"I don't have the money I legally owe you because I spent it" is not a claim the IRS is going to care deeply about.
Here's the same situation, for not software. I buy a big fancy truck for my trucking business. It's 100k, capital asset, needs to be amortized over 10 years. I make $100k in revenue that year. No other expenses. What do I need to pay tax on in year 1? The $90k in net income that I have. I can't say to the IRS "but I spent all my cash on the truck" - they'll say "tough, pay us".
edit: as an aside - the above is why businesses usually like to lease or finance - the cash flow matches better.
Obviously, the question is then which one makes more sense for software development.
And either way it's very painful to change the rules entirely in a single tax year, especially for small businesses. FAANG companies will weather this either way, but it could kill small software businesses.
One alternative if it must be treated as a capital asset is to allow accelerated/immediate depreciation for small firms and individuals.
I can see the point that for large firms like with diversified R&D portfolios, development, on average, results in creation of capital assets.
For small firms, it is absolutely unclear that the product has any durable value at all.
Hyperbole. IRS doesn’t lift a finger for amounts such as these. They will send a letter of what they think you owe and offer a payment plan if you don’t have it immediately.
How would IRS get “their” money with you in jail? They’d also have to provide you with room and board.
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.
The benefits of S and C corps don’t really come into play with single member LLC
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.
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.
LLCs also generally aren’t useful for protecting you from creditors, because any lender will require you to give a personal guarantee.
If you are really worried about protecting your assets, you can purchase liability insurance.
> As a software developer you’re unlikely to be sued over anything that can’t be classified as personal negligence or malpractice.
Unlikely doesn't mean never. And a client's definition of negligence might also be malicious.
It is difficult for a company to successfully show that your LLC was at fault for some large dollar amount of damages, but that you the sole decision maker running that LLC, weren’t at fault through negligence or malpractice.
My point is not that you shouldn’t bother to protect yourself if you are worried about the risk, but that insurance, not an LLC is the best way to do it. By all means start an LLC too if you want.
The common advice of that every tiny business setup an LLC because it will save your house is wrong because it is only applicable to very specific circumstances that don’t apply to most sole proprietors. It’s also dangerous because most people that take this advice take it face value. Then they go online, start an LLC, and believe they are protected from all personal liability related to their business. When in fact they are protected from a very small fraction of likely potential liability.
An LLC can protect your personal assets from enforcement of contractual obligations. Say for example you agree to indemnify your client against patent infringement, and then through no fault of your own some of your code coincidentally happens to violate someone’s patent (and the patent holder finds out and successfully sues or settles with your client).
But don’t sign contracts like that in the first place. And it’s a good idea for contracts to have a clause allowing both parties to terminate the contract and to not make promises in your contract you can’t guarantee.
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.
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.
Well, no...since you're not claiming to be making any revenue from that work, it doesn't matter. Whether you deduct 100% or 20% of your salary from $0 business income you still have $0 of taxable business income (and as an individual you don't get NOL carryovers so that amount is lost to you forever).
In fact, in the event of an audit, you'd likely get a refund since the IRS would determine that you're incorrectly calculating your tax liability by failing to capitalize your R&D expenditure (i.e., your flow-through revenue which is entirely treated as self-employment income). But, because this error affects other years' returns, which means that a one-return audit can turn into a multi-return audit. It also means you get put on a very special list of taxpayers subject to increased scrutiny (meaning, significantly more likely to be audited again in a future year).
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.
Yes, the LLC is much simpler when it's a disregarded (single-owner flow-through) entity. But it's more complicated once you add other members or any employees. And as you've pointed out, you're already paying more in taxes.
My issue isn't with you choosing to use the LLC form because it's simpler, my issue is with you claiming that it's better for tax purposes on a numerical basis when it is clearly not.
The problem is, as this whole comment section shows, is that is it not clear.
Because it isn't, I decided to go with the simpler option because I don't plan on having employees.
There is no dispute amongst tax advisors about whether a single-owner S-Corp is better than a single-member LLC for tax purposes: the S-Corp is better. Hands down.
But the LLC is simpler because a one-person LLC doesn't exist for tax purposes, it's just an extension of its owner. The cost of this simplicity is significantly higher taxes once you make enough money for taxes to matter.
Whether the S Corp is better than a plain LLC is up to the business owner, and it doesn't just have to be about money.
You are just wrong that an S Corp is better for me. I've done the math, I know the difference, I made the choice with other factors in mind as well.
> There is no dispute amongst tax advisors about whether a single-owner S-Corp is better than a single-member LLC for tax purposes: the S-Corp is better. Hands down.
Funny thing is that one of the three accountants I went to disagreed with this, so it's definitely not "hands down."
The LLC is only better so long as it remains a disregarded tax entity with no employees, because once either of those happens, it becomes significantly more complex than an S-Corp. So if you're fine not ever having partners or employees, and paying more in taxes for the sake of slightly more simplicity, then yes, the LLC is better.
But if you want partners, or employees, or saving money on your taxes, then the S-Corp is better. And if an accountant is telling you otherwise, then it's only because you make so little money that it doesn't matter whether you have a legal entity or not.
And yes, I know you don't have an S Corp. I was wondering how you would pay yourself from such a corporation, considering you have zero revenue.
When you have a single-member LLC, you take "distributions," which basically means you withdraw money from the company and put it into your personal account. It's technically a dividend.
I'm having a tough time understanding how there's money going out of an LLC without money first going in the LLC.
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.
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.
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.
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.
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...
Perhaps it can be can be made ambiguous in some context if you try hard enough, but that doesn't mean it commonly is so, or that it is here.
> 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...
Thanks, but the only thing that link gave me a taste for is terrible strawman arguments. (Or a severe lack of understanding of basic English.)
If you have "shall be" in a sentence, then that phrase is the verb of interest whose ambiguity (or lack thereof) you must examine, not the "shall" on its own. Claiming "shall" is ambiguous because it changes meaning when you put "be" after it makes no sense. It comes across as the kind of argument a first-grader would make.
They write: If the substitution rule is applied in the sentence: “The employee shall be reimbursed all expenses”, you would get: “The employee has a duty to be reimbursed all expenses”. This created ambiguity for the simple reason that the intent appeared to state an entitlement of the employee and not to impose a duty on the employee.
Do they lack common sense when reading this, or do they struggle with English? It's like claiming "I have a carrot" is somehow ambiguous because "I have been a carrot" means something entirely different. Does that sentence need disambiguation with "I possess a carrot" or "I have a carrot, but have not existed, as a carrot"? Are these serious arguments?
It also violates the fundamental rule that changing a sentence into the passive voice does not effect a semantic change.
"The employee shall be reimbursed [by the employer] for all expenses." must necessarily mean the same as "The employer shall reimburse the employee for all expenses."
Legal text doesn't come with a list of definitions that attempt to lock e.g. "shall" down in stone.
Which leaves the problem of intent ... is what I termed "way #2" above what was intended? Or is this just sloppy use of language with unintended side effects?
(I'm not saying it's good or bad, just passing on information.)
But it's the same ambiguity, isn't it? Essentially whether "shall" creates an obligation for the taxpayer to claim it as R&D expense or an obligation for the IRS to accept it as R&D expense if the taxpayer so claims it, the equivalent of whether "shall" applies to the employee or the employer.
And in both cases the existence of the ambiguity is bolstered by the fact that the overly literal interpretation leads to a ridiculous result.
What? No. How are you reading "the taxpayer shall do X" to mean "the IRS must do X"?
The text is incredibly straightforward: https://www.law.cornell.edu/uscode/text/26/174
> (1) except as provided in paragraph (2), no deduction shall be allowed for such expenditures, and
> (2) the taxpayer shall—
> (A) charge such expenditures to capital account, and
> (B) be allowed an amortization deduction of such expenditures ratably over the 5-year period [...]
Does it
(a) define the rules and conditions under which a taxpayer may claim a deduction on R&D expenditure
or
(b) define the obligations of the taxpayer with respect to anything that Sec 174 defines as R&D expenditure (i.e. you must report it as such, charge it to a capital account, claim an amortization deduction)
AFAIK, nothing the IRS or Congress has said thus far has clarified this.
https://www.plainlanguage.gov/guidelines/conversational/shal...
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).
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
i personally believe that the intended/appropriate interpretation is #1 - you MAY consider software development expense as R&D and include in an R&D deduction if you choose to take one.
but it is far from clear what was intended and/or how the IRS interprets it.
IRS expansion is on life support and is the first target with any little bit of leverage against the President
What business does not deduct salaries from their income when reporting taxes?
I'm open to a counter-example where this makes sense.
between using borrowed funds, other tax credits, in-kind donations, carry forwards or carry backs from other tax years, you should be able to get it to zero or near zero without spending all cash/profits on hand
and then the corporation can have one financial circumstance that has nothing to do with your financial circumstance improved by payment from the corporation
theyre conduits, it depends on how much authority you have over the corporation
If you do not chose to deduct R&D expenses, you can deduct software salaries as normal.
I personally think this makes a lot of sense.
My reading is that it isnt just permission to claim all development as R&D, but an obligation to do so if you claim it all if you claim any. That is to say, no splitting it.
This is actually pretty common in other parts of the tax code, where you have discretion in how to treat costs, but different treatments come with different requirements. Selecting one treatment is what triggers the associated requirements.
Many people struggle to understand that the tax code is not just a set of rules, but also a set of choices.
As an aside, this is why the government cant simply calculate your taxes for you in many instances. Doing so involves several choices based on your long term strategy. A simple example is to take losses in the given tax year or carry them forward (when permitted). The IRS can't decide that for you, and your decision might depend on factors like if you think your tax rate will be higher or lower in the future.
Perhaps a more relatable example is when to take a IRA/401K withdrawal. Ideally you would want to do this in years in a year where you have a lower marginal tax rate.
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.
If my salary is $80,000 and my expenses to survive are $70,000, I pay taxes on "$80,000 minus the weak sauce standard deduction."
If I'm a corporation and my revenue is $80,000 and my expenses are $70,000, I pay taxes on $10,000.
Not fair.
If corporations could be taxed on income without creating bad distortions, they probably would be. Even taxing profits creates a distortion (profits become double taxed as (1) profit and (2) dividends), leading to behavior like stock buy backs that wouldn’t exist otherwise.
Thanks, but you’re just restating the problem. Income is not analogous to profit. We agree on that. Why can’t people be taxed on some measure of disposable income? Income After Necessities or something more analogous to net profit?
Figuring out what corporate income is is near impossible if it’s considered income after past and future investments because companies are constantly turning over money to make more. At some point, they get to declare a “profit”, but it’s a very artificial thing. Investment is already indirectly (all those Amazon R&D investment goes to pay SWEs), so it’s not like the government is losing out on revenue.
Since most people don’t employ people directly for personal tasks, it doesn’t make sense to do the same for personal income. Of course we are also just turning around money to increase the value of our lives, and in the end when would we ever declare a profit as well? We have no shareholders to return a dividend to anyways.
But they are capped. Otherwise, many folks might get expensive things instead of paying taxes.
But the contracting work I've done (custom, one-off software) wouldn't make sense under #2, and I don't know how it actually works under this change.
Sure, but is revenue tied to work already done, or ongoing work? I.e. are you leveraging prior capital expenditure to realize current revenue, or are you in fact building new stuff right now (updates, features) that will generate right now (or at least, well within the 5/15 year amortization schedules) ?
The fact that the current work relies on earlier work is not in itself an argument that the earlier work was obvious done as a capital investment.
Just like if Ford hires you to build a factory - the amount you pay the plumber is a regular expense, but the bill to Ford is for a capital asset.
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.
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.
So you think software development costs should not be capitalized, right? What makes you say that?
Also, the change to Sec 174 is related to R&D expenditures. This is also another aspect of trying to fit a multiheaded hydra into a small sphere: yes, some software development does share many similarities with R&D activities, but lots of software development does not (unless you label R&D in a way that is so broad as to encompass just about anything).
If the US wants to force amortization on software development expenses, I think that should be stated more explicitly, and with a much more detailed rationale. Just tacking it onto the "R&D" category really serves no-one very well at all.
Well, it is called Research and Development. Perhaps that is the right place for it? :)
But your point about it being tacked on is well taken. However, I don’t think this problem is unique to this instance. It’s similar to updating software. When you update the law, you often have to tack things on and find a way to make it fit.
To their credit, the IRS has taken pains to define what constitutes software, as well as to differentiate between what is merely maintenance—including bug fixes and so on—and what constitutes upgrades and enhancements. They’ve specified this quite clearly in the guidance, which perhaps addresses your concern about distinguishing these different activities.
You acknowledge that there is certainly software that companies create and then use or license to others, providing them with long-term value, much like an asset. However, you also suggest there’s a lot of software that doesn’t serve as a long-term asset.
I’d be interested in examples of the type of software that doesn’t provide that long-term value.
A major source of short-term-ism in software value is the blurring or outright erasure of the boundary between development and operations, and the reality that more software is architected under these assumptions. Unlike features, operations is a constantly moving target, and it can reach pretty deeply into your software stack.
Anecdotally, for the types of software I work on, probably half of the development work exists to satisfy an operations rather than product feature need. These are often chasing exogenous metrics like improving opex. A lot of this work becomes irrelevant or dead code in much less than five years as the sands shift or we need to do things differently.
I am old enough to remember when software components almost always reached a state of “done”. That is rarely the case anymore. Testing has massively improved since then so the threshold above which companies will replace working code has been greatly reduced since the risk of doing so is much lower. We do forklift upgrades now that would have been unthinkable 20 years ago because of how thorough modern testing and tooling is.
One thing that strikes me is how this is similar to how a factory operates. While the existing tooling certainly is used for mass production, it is also regularly retooled for new requirements. These might be small changes, involving only a few minor molds or stages, or very large ones, involving complete replacement of whole sections. These operations also face the shifting sands of obsolescence and modernization, as well as changing market requirements.
It seems reasonable that all the expenditure to create the current tooling of the manufacturing plant is a capital expenditure, even tho, like software, it is never "Done", but rather in a constant state of progress and development. All of these iterative changes are likewise much akin to a form of research, albeit incredibly practical and occuring right where the rubber meets the road.
The modern picture of software development and operations you very clearly layout makes this capex framing more imperative and reasonable than before, despite not producing "done" assets. While it's certainly true that installation costs, bug fixing, and testing during production are not easily seen as capital expenses, it sounds reasonable that the other work to produce these production assets really is capex.
It also seems as if the IRS guidance already specifies this distinction, with the former category being specifically excluded from the proposed rule changes. Thank you for this very engaging and informative discussion! :)
That happens for a variety of reasons, including but not limited to: changing platform requirements, deeper understanding of user requirements, changes in user requirements, new external interaction possibilities.
As a small example from my own little world of digital audio workstations: ardour version 2 (from around 2002) was pretty good at doing all the things it did back then. But in 2023, that list of features in a DAW barely gets in the door for consideration as a tool for most potential or actual DAW users. That codebase (the v2.0 one) in and of itself is of close to zero value at this point [0], the only reason the project as a whole continues to have value is that it gets updated and extended to meet the expectations (to whatever extent it can) of users in 2023.
So, is the work I and others did in 2001 (pre v2.0) sensibly treated as a capital expenditure, or was it just "work" ? Further, when an architect designs one house for a client, then another for another client, then another for another client, why is that not treated in the same way? Each house is essentially and R&D project from which the architect carries forward a bunch of acquired knowledge and skills. I think the answer is reasonably obvious: we regard the project as each individual house, not the capabilities of the architect (which hopefully grow over time). With software, it's not clear quite why v2.0 and v3.0 and v4.0 etc. are considered to be "merely" updates rather than distinct projects similar to an architectural project.
Another point I would make about R&D: one of the justifications (I suspect) for having a deducation for such expenditure is that you don't really know if it is going to work out in terms of resulting in a new, or improved, item or service; because we officially want to encourage "innovation" we want to provide a bit of incentive to do the spend anyway ("you can claim it as a deduction").
I just don't see this as true with software work, particularly not software work on existing projects. Uncertainty levels are low - the chances are overwhelming that an attempt to add feature X to an existing project will be successful. And there are, as I described above, more than adequate motivations to do the work - no tax deduction is going to drive adding new features to an existing project in any sane world.
Again, I do acknowledge that there are software development and distribution models that are closer "work, work, work, work for N years, sit back and sell the result for M years, with a bit of maintenance work on the side". It seems much more appropriate to treat that as capitalization. The IRS allows people/companies to make a choice between cash-based expensing and amortized expensing of many costs - I'd prefer it if they acknowledged the difference for this purpose too, and allowed software development to be "cash basis" or "capital". Obviously, a set of returns that shows years of revenue with very little expense and that claimed "cash basis" would be seen as fraudulent.
I'd also note that the lawyer who posted a link to his Bloomberg article on this matter did not concur that the IRS has "quite clearly" defined maintenance vs. upgrades.
[0] and of course, as pointed out by a sibling comment, not very much remains of that codebase either, further underscoring the non-capital-like nature of software, at least over much shorter time frames than, say, a building or a piece of manufacturing equipment.
Thanks for your comprehensive comment! There's a lot for me to digest there, please allow me some time to read and comprehend it all! I may comment more later.
The IRS does this all the time. Code isn’t some special magic enigma, businesses depreciate property, trucks, aircraft..all of these are equally as complex as code or significantly more complex to value over time. Usually it’s simplified to some degree for practicality, as I’m sure this will be.
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.
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)."
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.
"(3) Software development. Section 13206(a) of the TCJA added new § 174(c)(3) to require that any amount paid or incurred in connection with the development of any software in taxable years beginning after December 31, 2021, be treated as a research or experimental expenditure (and thus an SRE expenditure to the extent paid or incurred by the taxpayer during the taxable year in connection with the taxpayer’s trade or business)."
and
".02 Requirement to capitalize and amortize SRE expenditures. Taxpayers are required to capitalize SRE expenditures (as defined in section 4.02(2) of this notice) and amortize such expenditures ratably over the applicable § 174 amortization period beginning with the midpoint of the taxable year in which such expenditures are paid or incurred."
Which is, as many have noted, absolutely batshit crazy.
The only scenario that remains unaffected by this absolutely batshit crazy SNAFU is the case of a self-employed software developer who incurs zero costs related to their work. They simply collect all revenue as salary, pay normal tax on it, and they are done.
Anyone with any expenditures at all (contractors, employees, equipment) must treat these as capital expenditures, amortized over 5 (or 15 years for foreign based work).
It really is as bad as it could possibly be.
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.
It might matter if you buy finished software modules and integrate and resell them.
Now academic research needs to consult on tax implications and have some set aside.
You can sign the letter and send it to your representative here:
https://ssballiance.org/