Comment by PaulDavisThe1st
2 years ago
To try to clarify for anyone reading about this for the first time ...
this all hinges on whether language in the tax code is interpreted one way or another.
Way #1: companies often try to claim many deductions on R&D expenditures, and the changed language makes it clear that all software development expenses can be claimed as R&D expenditure (which was not necessarily clear before).
Way #2: all software development expenses MUST be treated as R&D expenditures which requires claiming them as an amortized deduction (over 5 or 15 years depending on where they happen).
Neither the IRS nor Congress has clarified the intent of the change, and there are solid arguments for both interpretations. Way #2 is supported by the use of "shall" in the language used. Way #1 is supported by the fact that Way #2 is batshit crazy.
It seems that a lot of people are convinced that Way #2 is the intended one, despite its catastrophic implications for many software-based companies.
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.
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.
This is a fantastic point that I think the IRS needs to consider. Have you thought about how this reality interfaces with the seemingly incoming new regulations? How could they be made more fair, in other words more reflective of this reality you identify?
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.
> The productive life of any particular blob of source code is an awfully complicated thing to talk about
The IRS does this all the time. Code isn’t some special magic enigma, businesses depreciate property, trucks, aircraft..all of these are equally as complex as code or significantly more complex to value over time. Usually it’s simplified to some degree for practicality, as I’m sure this will be.
1 reply →
I understand :)
So you think software development costs should not be capitalized, right? What makes you say that?
6 replies →
> 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.
If you read the entire document they make it clear it is now required to amortize SRE expenditures and the majority of software development activities (as I previously quoted) are now considered SRE expenditures.
"(3) Software development. Section 13206(a) of the TCJA added new § 174(c)(3) to require that any amount paid or incurred in connection with the development of any software in taxable years beginning after December 31, 2021, be treated as a research or experimental expenditure (and thus an SRE expenditure to the extent paid or incurred by the taxpayer during the taxable year in connection with the taxpayer’s trade or business)."
and
".02 Requirement to capitalize and amortize SRE expenditures. Taxpayers are required to capitalize SRE expenditures (as defined in section 4.02(2) of this notice) and amortize such expenditures ratably over the applicable § 174 amortization period beginning with the midpoint of the taxable year in which such expenditures are paid or incurred."
1 reply →
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.
6 replies →
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.
4 replies →
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...
In the military, they made it very clear to use how to read "shall", "must", "should", etc.
https://www.plainlanguage.gov/guidelines/conversational/shal...
1 reply →
> 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?
12 replies →
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'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.
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.
9 replies →
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.
2 replies →
In other words, businesses need to explain to the IRS that software engineers are really, really bad at engineering.
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.
* IF YOU READ THE ABOVE, PLEASE READ THIS TOO *
Another commenter alterted me to this guidance document from the IRS:
https://www.irs.gov/pub/irs-drop/n-23-63.pdf
This makes it absolutely clear that "Way #2" is the IRS interpretation of the law after the TCJA passed. That is, any software-development related expenditures MUST be treated as capital expenditure and be amortized over 5 years (or 15 for foreign based work). The document explicitly states that such expenditures CANNOT be treated as ordinary expenses under Section 162 (the section that would normally allow for business expense deductions).
Having read the whole document (which I should have done before), it is absolutely clear that this is totally batshit crazy.