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?
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?
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...
> As a law prof once told me, "shall" can end up being ambiguous in court, despite the common understanding.
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?
Agreed. Their analysis inappropriately conflates the syntactical subject of a sentence with the semantic agent of the sentence.
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."
I think that in the first (ambiguous) phrasing there is an implicit (common-sense?) understanding of: the employee shall be reimbursed for all expenses if the employee asks for it or wants it, ie the employee has the right to ask for and only then the employer has the obligation to reimburse all expenses.
No, there is no reason to appeal to "common sense." It is the plain and unambiguous meaning of the text itself.
I think you may have been reading too many IETF documents.
Legal text doesn't come with a list of definitions that attempt to lock e.g. "shall" down in stone.
I rarely read IETF documents. But as a practicing lawyer for about 15 years, I've read, interpreted, drafted, advised on, and litigated countless uses of the word "shall" in agreements (as well as in statutes and regulations). In fact my first pro bono case in BigLaw, on behalf of a nonprofit in a corporate election case, hinged on it. Shall is not this mysterious ambiguous beast the link makes it out to be.
I will absolutely defer to your judgement then.
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?
> 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.
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.
> 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.
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 [...]
The crux here is: what are "the purposes of this section" ?
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.
Here's another article with possibly better legal citations: https://www.lexology.com/library/detail.aspx?g=aeee1c5f-28d7...
(I'm not saying it's good or bad, just passing on information.)
In the military, they made it very clear to use how to read "shall", "must", "should", etc.
https://www.plainlanguage.gov/guidelines/conversational/shal...
Military SOPs and case law are not the same thing.
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.
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).
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
> unless they aren't deducting software development at all
What business does not deduct salaries from their income when reporting taxes?
I'm open to a counter-example where this makes sense.
if you have enough other expenses that already nullified that year’s tax, and it is complex to file a certain remaining kind of expense then you don't need to do it
Wouldn’t that basically always mean you’re in the red already though?
not every tax deduction uses cash so no.
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
There are special deductions you can elect to take for R&D expenses. If you choose to deduct R&D expenses, you must include software development there.
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.
It may make sense, but your interpretation (one I happen to agree with) is what I called #1 above. It is still unclear whether the IRS regards the rules as requiring interpretation #2 (in which paying someone to do software development MUST be treated as an amortized, capitalized R&D expense) or not.
I think the only difference between what I said and your #1 is that it is more than just a statement that "all software development expenses can be claimed as R&D".
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 is the whole crux of the matter. interpretation #2 says that the law now says that you MUST ("shall") consider all software development expense as R&D expenditures that are amortized over 5/15 years.
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.
that’s interesting well the IRS is going to get gutted anyway, I don’t see this particular issue being looked at with any scrutiny that requires litigation
chance of IRS being gutted: not zero but close to it. that bill from the house is incredibly unlikely to even get a hearing in the senate, and even if it did and it passed, somehow, biden will veto it (and that veto will not be overridden.
if not now, itll happen in the NDAA, or a budget reconciliation bill, or similar government shutdown averting action, or change of president
IRS expansion is on life support and is the first target with any little bit of leverage against the President
The problem is that the CBO has been entirely clear that cutting IRS funding increases the deficit, and there's plenty of senators and a white house staff eager to point this out.
Can you explain to someone not familiar with US tax law why #2 is batshit crazy?
#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.
Veering into a slightly off topic and controversial opinion, but I always thought it was kind of unfair that corporations could deduct so many of their expenses and not pay taxes on them, but I as an individual cannot deduct most of my major expenses. I don't understand the rationale. Why can corporations deduct their cost of raw materials they use to make products, but I cannot deduct the food I need to eat in order to live? Why can corporations deduct the cost of the office in which they operate, but I cannot deduct rent on an apartment I live in? Why can corporations deduct the cost of company jets, but I cannot deduct the cost of my car? What is the moral justification?
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.
People are taxed on income (with only certain deductions), corporations are taxed on profits. If corporations were taxed on income, lots of industries would become unviable, creating huge distortions in the economy. However, people generally have the same expenses (food for example), so at least it’s somewhat fair. It gets unfair and distortive, for example, when health insurance bought for you buy a company is deductible (to the company) but health insurance you buy on your own isn’t.
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.
> People are taxed on income (with only certain deductions), corporations are taxed on profits.
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?
Tax systems need to be fair, they need to avoid creating distortions that are negative. Taxing corporate income (revenue) is non-viable, taxing personal income is viable.
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.
Well the simple argument is that those corporate expenses ultimately benefit other people (customers) while your own expenses only benefit you. The corporation would just mark up prices to reflect tax expenses which would be paid by customers. So taxing corporate expenses would amount to taxing end-users twice.
I could see the argument for perennial still falling under #2: usually in perennial software, you're still building on top of that base you already developed. Basically any SAAS makes sense under #2 to me, despite how much it may suck.
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.
If your contracting work is "company X hired me to write software Y" then any of your expenses (salaries, etc.) are normal expenses. For company X, Y is probably R&D (or a capital asset) and need to be amortized, as #2.
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.
> usually in perennial software, you're still building on top of that base you already developed.
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.
In other words, businesses need to explain to the IRS that software engineers are really, really bad at engineering.
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.
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.
I understand :)
So you think software development costs should not be capitalized, right? What makes you say that?
I think it's more complicated than that. Some software is developed and then provides value to the company that owns it in a way that is clearly comparable to other capital investment. But lots of other software just isn't. There's also the problem of differentiating between ongoing work that is supposed to just be "maintenance" and essentially identical work that is "updates" and "new features". Even at the code level it is not always easy to tease these apart.
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.
> 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 lot of software has a Ship of Theseus character. The code base may be 5+ years old but all of the actual code is significantly younger and is completely turned over on a much more frequent basis. The practice of CI/CD, which is spreading across software domains that would have been unthinkable a decade ago, is only encouraging it.
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.
It's not so much that the software does serve as a long term asset, it's that it isn't a static long term asset - it only maintains its value by being maintained, updated, extended. The work that was done on it 5 years ago, or 10 years ago, laid the groundwork for the value it has today, but that value would be zero or close to it without continued work.
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.
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.
> 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)."
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.
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.
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.
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.
> 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.
Well, I would hope you are right, but that's not what the accountants were saying.
No accountant is saying you'd have to pay at literally zero revenue, unless they're very badly misinformed.
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.
I know several people who are being advised by accountants that they have to pay for startups with net zero profit.
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
Accounting (and taxes) does not match one-to-one with cash flow. It is very critical for any business to understand this. This bites many businesses, sometimes very badly. It's especially difficult when the rules change, as they have in this case with R&D/software expenses.
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.
>But there's a very critical misunderstanding happening in a lot of comments here -the IRS taxes profit (net income), not revenue
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.
>>>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.
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.
You are right, it has to do with how the irs defines profit. Invest 100k in a big truck, that's capital expense. Spend 100k on gas and goods to make deliveries, that's operating expense.
Obviously, the question is then which one makes more sense for software development.
Exactly. And I do think the truth lies somewhere in the middle - some software development creates capital assets, but lots does not.
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.
agreed. It is quite backbreaking if you dont have a huge bucket of money.
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.
> 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).
And that will be the case for me next year, so yes, this matters to me.
Sure, it's reasonable to worry about that. But it's still not the case that you'd need to pay taxes on 0 revenue.
This is what the parent means by "batshit crazy".
What parent?
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.
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.
That’s a common misconception that isn’t correct in practice. LLCs don’t protect you from your own personal negligence. Meaning that in the vast majority of lawsuits a single owner LLC isn’t going to do much. As a software developer you’re unlikely to be sued over anything that can’t be classified as personal negligence or malpractice.
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.
I wasn't talking about negligence.
> 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 doesn’t matter if a client’s definition is malicious. If they win the lawsuit, an LLC isn’t going to protect you.
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.
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.
That's not true... There is a brief window for switching your LLC to a different tax classification, typically at the beginning of the year. It does not change the previous year.
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.
> 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.
So if the IRS audits me, they'll say that my work is worth something and therefore, I have to pay taxes on it?
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.
> 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.
No, the problem is that many comments here are simply making false claims about how the tax situations work using bad math.
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.
The S Corp is better for the accountant because it means a higher fee to get taxes done.
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."
If you have zero revenue, how are you paying yourself a salary from the S Corp?
I don't have an S Corp.
My general question is: how are you paying yourself money from a business woth zero revenue? The type of business is irrelevant.
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.
I'm not paying myself yet, nor will I pay myself in the classical sense when I get 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.
Distributions from what? If you're making zero revenue, how is there money in the account for the business?
I'm having a tough time understanding how there's money going out of an LLC without money first going in the LLC.
Such a complete misreading of your comment has to be deliberate
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.
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.
What’s the argument on making software not being an investment
Aside from “it’s bad for my startup”
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.
Why?
I think the obvious implication is that software development is expensive, ongoing and tends to result in relatively short term ROI, and therefore the amortization schedule of 5 years increases the likelihood smaller business will never collect most of it, while larger business that can absorb more up-front costs will be able to collect it pretty easily.
That is not an argument for tax treatment of whether something is an asset
I wasn’t trying to make that argument, but I were I would argue that software itself is more like a liability, or, at the most, a current asset[0]. Source code has no inherent value, and in fact the more you have the more expensive it is.
That interpretation is deeply removed from how accounting works, but even if it were a current asset it would still not be an expense
Yeah, I agree it doesn’t fit well in any of the usual accounting boxes. But I think that’s the point, right?
Because most software devs don’t stick around long enough to write software that can stand the test of time. It requires a few things: like don’t use libraries unless they are well funded (includes frameworks) or have already stood the test of time (like bootstrap for the FE or React, etc); don’t hide logic deep in the code, put logic as high level as possible (like in controllers, which is the exact opposite of short-lived software; and many other little things.
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.
You can be changing the code every day and it’s still the same asset yhough
Because the world changes.
If/when software goes out of use, it can be written down and deducted immediately. The 5 years is a maximum, not a minimum.
I don't think that is true. From what I'm reading there is no acceleration.
What happens when changing broken parts on a machine that's amortizing, or repairs
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.
But how much of the development effort for those took place in the last 5 years, even if the codebase is much older?
Survivorship bias?
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.
But this is also kind of making the opposite point: Hank wrote that thing 15 years ago, it wasn't even a large proportion of your long-term development expenses, and now all the other developers are actually doing maintenance work to keep the old code compliant with regulatory changes or integrated with external moving targets, none of which has long-term value because there will soon be other regulatory changes and the moving targets will move again.
I guess you could say this new tax treatment incentivizes writing more stable, longer-lasting software artifacts?
No, you don't get any extra benefit from the software lasting. The tax treatment is the same if it lasts 1 day or 10 years.
The incentive is to write software that is immediately profitable, and investing in long term projects becomes more costly.
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.
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.)
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.
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.
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.
This blank file has a lot of bugs.
What kind of software maintenance work does not create new software? Are you only deleting lines of code from the existing software?
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.
The disadvantage is not just to early startups. I have ownership in a 9-year old small software company that has never taken investments and has managed to break even or be slightly profitable every year while growing. We reinvest revenue into a team that keeps improving the product.
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.
"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?
Yes, I would. Open-source doesn't mean "not intellectual property." It means "intellectual property open to everyone."
Lol! What even is property?
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.
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.
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.
(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.
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.
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.
> 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.
> You fail to understand that the US constitution was not created to provide for an efficient government it was designed to protect individual rights.
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.
To add a bit to this, the common American misimpression that a parliamentary model is somehow going to result in mythical German efficiency of government authority is comical.
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).
> 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.
> 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
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.
>There are plenty of other nations with parliamentary systems that protect individual rights just fine
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?
not to mention we semi-divorced (and I think in some cases totally divorced) state politics from federal politics when we started voting directly for Senators in the other house.
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
The Westminster model is precisely less frightening because of that. In such a model, regional parties and single-issue parties would have some room to at least get into parliament. This allows for more diversity of opinions, a plethora of options, and a reduction of the powers of the individual parties. It's impossible for a parliamentary government to devolve into absolutism in a country with a strong democratic tradition like the USA.
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.
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?
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.
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.
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?
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?
> 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.and the other developed country is?
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.
Entire consulting firms exist to twist regular software development into “research and development” for tax purposes.
Or at least they did.
> 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?
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)
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)
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.
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.
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.
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.
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.
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.
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)
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...
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.
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.
> "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.
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.
Exactly. The guidance from Microsoft is to literally stop using a version of windows ideally before and definitely no later than it stops getting security updates.
> 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.
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.
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...
This is MS shifting profits to avoid paying taxes though.
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.
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?
"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.
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.
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.
> 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.
Except that for software this is so much more complex than for any other type of products.
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?
Yes and yes
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?
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?
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.
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.
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?
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.
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.
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.
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?
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.Please provide a template for quick customization and submission. This will help scale with the remaining time left.
I wrote about it here: https://news.bloombergtax.com/tax-insights-and-commentary/ne...
Please do submit comments.
I strongly believe that the IRS should consider more favorable tax treatment for software development expenses. Encouraging innovation in this field will benefit the economy and promote technological advancements. https://simplified.com/text-summarizer/
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.
> 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.
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!
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:
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...
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.
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.
Section 174 hit my company hard, it’s such bullshit.
> 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.
Clickable link: https://www.regulations.gov/document/IRS-2023-0040-0003/comm...
Can I get a tax refund on $0 revenue for deleting code?
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.
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.
Oh good golly, don't forget the $19,000ish for federal self employment taxes
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.
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.
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.