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.
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.
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 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.
So you think software development costs should not be capitalized, right? What makes you say that?
Also, the change to Sec 174 is related to R&D expenditures. This is also another aspect of trying to fit a multiheaded hydra into a small sphere: yes, some software development does share many similarities with R&D activities, but lots of software development does not (unless you label R&D in a way that is so broad as to encompass just about anything).
If the US wants to force amortization on software development expenses, I think that should be stated more explicitly, and with a much more detailed rationale. Just tacking it onto the "R&D" category really serves no-one very well at all.
Well, it is called Research and Development. Perhaps that is the right place for it? :)
But your point about it being tacked on is well taken. However, I don’t think this problem is unique to this instance. It’s similar to updating software. When you update the law, you often have to tack things on and find a way to make it fit.
To their credit, the IRS has taken pains to define what constitutes software, as well as to differentiate between what is merely maintenance—including bug fixes and so on—and what constitutes upgrades and enhancements. They’ve specified this quite clearly in the guidance, which perhaps addresses your concern about distinguishing these different activities.
You acknowledge that there is certainly software that companies create and then use or license to others, providing them with long-term value, much like an asset. However, you also suggest there’s a lot of software that doesn’t serve as a long-term asset.
I’d be interested in examples of the type of software that doesn’t provide that long-term value.
Not true anymore, the IRS guidance linked above in Notice 2023-63 specifically indicates they are adopting interpretation #2:
"Section 5.03 - Activities that are treated as software development. Activities that are treated as software development for purposes of § 174 generally include but are not limited to:
(1) Planning the development of the computer software (or the upgrades and enhancements to such software), including identification and documentation of the software requirements;
(2) Designing the computer software (or the upgrades and enhancements to such software);
(3) Building a model of the computer software (or the upgrades and enhancements to such software);
(4) Writing source code and converting it to machine-readable code;
(5) Testing the computer software (or the upgrades and enhancements to such software) and making necessary modifications to address defects identified during testing, but only up until the point in time that:
(a) In the case of computer software developed for use by the taxpayer in its trade or business, the computer software is placed in service; and
(b) In the case of computer software developed for sale or licensing to others, technological feasibility has been established, product masters(s) have been produced, and the computer software is ready for sale or licensing to others; and
(6) In the case of computer software developed for sale or licensing to others (or the upgrades and enhancements to such software), production of the product master(s)."
The question remains open: is the intent that all software development expense MUST be treated an amortized capital investment, or that all software development (fitting the description above) CAN be treated in that way.
"(3) Software development. Section 13206(a) of the TCJA added new § 174(c)(3) to require that any amount paid or incurred in connection with the development of any software in taxable years beginning after December 31, 2021, be treated as a research or experimental expenditure (and thus an SRE expenditure to the extent paid or incurred by the taxpayer during the taxable year in connection with the taxpayer’s trade or business)."
and
".02 Requirement to capitalize and amortize SRE expenditures. Taxpayers are required to capitalize SRE expenditures (as defined in section 4.02(2) of this notice) and amortize such expenditures ratably over the applicable § 174 amortization period beginning with the midpoint of the taxable year in which such expenditures are paid or incurred."
Which is, as many have noted, absolutely batshit crazy.
The only scenario that remains unaffected by this absolutely batshit crazy SNAFU is the case of a self-employed software developer who incurs zero costs related to their work. They simply collect all revenue as salary, pay normal tax on it, and they are done.
Anyone with any expenditures at all (contractors, employees, equipment) must treat these as capital expenditures, amortized over 5 (or 15 years for foreign based work).
It really is as bad as it could possibly be.
Way #1.5: if a company chooses to take R&D expenditures of any type as a deduction (which it is not required to do) then it MUST include software development expenses (which in turns means they will be amortized).
there is no obligation to take a deduction. if you find yourself in a circumstance where its more favorable to not take a deduction then you don't have to report that transaction
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 do not chose to deduct R&D expenses, you can deduct software salaries as normal.
I personally think this makes a lot of sense.
My reading is that it isnt just permission to claim all development as R&D, but an obligation to do so if you claim it all if you claim any. That is to say, no splitting it.
This is actually pretty common in other parts of the tax code, where you have discretion in how to treat costs, but different treatments come with different requirements. Selecting one treatment is what triggers the associated requirements.
Many people struggle to understand that the tax code is not just a set of rules, but also a set of choices.
As an aside, this is why the government cant simply calculate your taxes for you in many instances. Doing so involves several choices based on your long term strategy. A simple example is to take losses in the given tax year or carry them forward (when permitted). The IRS can't decide that for you, and your decision might depend on factors like if you think your tax rate will be higher or lower in the future.
Perhaps a more relatable example is when to take a IRA/401K withdrawal. Ideally you would want to do this in years in a year where you have a lower marginal tax rate.
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
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.
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...
https://www.plainlanguage.gov/guidelines/conversational/shal...
Perhaps it can be can be made ambiguous in some context if you try hard enough, but that doesn't mean it commonly is so, or that it is here.
> I'm sure this isn't the best tutorial on the topic but it gives you a taste: https://www.barandbench.com/columns/shall-shocked-the-use-of...
Thanks, but the only thing that link gave me a taste for is terrible strawman arguments. (Or a severe lack of understanding of basic English.)
If you have "shall be" in a sentence, then that phrase is the verb of interest whose ambiguity (or lack thereof) you must examine, not the "shall" on its own. Claiming "shall" is ambiguous because it changes meaning when you put "be" after it makes no sense. It comes across as the kind of argument a first-grader would make.
They write: If the substitution rule is applied in the sentence: “The employee shall be reimbursed all expenses”, you would get: “The employee has a duty to be reimbursed all expenses”. This created ambiguity for the simple reason that the intent appeared to state an entitlement of the employee and not to impose a duty on the employee.
Do they lack common sense when reading this, or do they struggle with English? It's like claiming "I have a carrot" is somehow ambiguous because "I have been a carrot" means something entirely different. Does that sentence need disambiguation with "I possess a carrot" or "I have a carrot, but have not existed, as a carrot"? Are these serious arguments?
It also violates the fundamental rule that changing a sentence into the passive voice does not effect a semantic change.
"The employee shall be reimbursed [by the employer] for all expenses." must necessarily mean the same as "The employer shall reimburse the employee for all expenses."
But it's the same ambiguity, isn't it? Essentially whether "shall" creates an obligation for the taxpayer to claim it as R&D expense or an obligation for the IRS to accept it as R&D expense if the taxpayer so claims it, the equivalent of whether "shall" applies to the employee or the employer.
And in both cases the existence of the ambiguity is bolstered by the fact that the overly literal interpretation leads to a ridiculous result.
What? No. How are you reading "the taxpayer shall do X" to mean "the IRS must do X"?
The text is incredibly straightforward: https://www.law.cornell.edu/uscode/text/26/174
> (1) except as provided in paragraph (2), no deduction shall be allowed for such expenditures, and
> (2) the taxpayer shall—
> (A) charge such expenditures to capital account, and
> (B) be allowed an amortization deduction of such expenditures ratably over the 5-year period [...]
Does it
(a) define the rules and conditions under which a taxpayer may claim a deduction on R&D expenditure
or
(b) define the obligations of the taxpayer with respect to anything that Sec 174 defines as R&D expenditure (i.e. you must report it as such, charge it to a capital account, claim an amortization deduction)
AFAIK, nothing the IRS or Congress has said thus far has clarified this.
(I'm not saying it's good or bad, just passing on information.)
This means that you cannot, for example, pay yourself a salary and have that treated like the salary you would receive if, for example, you had chosen to be a builder or an artist or a massage therapist.
Another commenter here touched upon what I assume would be the justification for this: with software you spend Y years and C money to develop it, then you sit back and collect revenue, therefore the C money you put it at the beginning is a capital expenditure. But that's rarely the case with any software. Either it is a perennial, on-going process that never stops, or it ceases to be a revenue source. There are exceptions (especially since the dawn of mobile apps) but they are not the rule.
It's also not clear precisely what the difference is between working as a self-employed software developer and a self-employed architect is. They are not exactly the same, but why the former should not be able to take a regular salary from the revenue available, and the latter can doesn't seem clear, let alone equitable.
If anyone has actually thought about things this way, they seem to have a model in their mind that all software development is done following a process of "build first, sell later". This just isn't an accurate reflection of how a lot (most?) s/w development takes place.
If my salary is $80,000 and my expenses to survive are $70,000, I pay taxes on "$80,000 minus the weak sauce standard deduction."
If I'm a corporation and my revenue is $80,000 and my expenses are $70,000, I pay taxes on $10,000.
Not fair.
If corporations could be taxed on income without creating bad distortions, they probably would be. Even taxing profits creates a distortion (profits become double taxed as (1) profit and (2) dividends), leading to behavior like stock buy backs that wouldn’t exist otherwise.
Thanks, but you’re just restating the problem. Income is not analogous to profit. We agree on that. Why can’t people be taxed on some measure of disposable income? Income After Necessities or something more analogous to net profit?
But they are capped. Otherwise, many folks might get expensive things instead of paying taxes.
But the contracting work I've done (custom, one-off software) wouldn't make sense under #2, and I don't know how it actually works under this change.
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.
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.
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.
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.