Comment by OneDeuxTriSeiGo

The IRS released guidance back in 2023: https://www.irs.gov/pub/irs-drop/n-23-63.pdf

It starts on page 23.

Plenty of analysis online by tax firms but I'll quote from this one: https://insightplus.bakermckenzie.com/bm/attachment_dw.actio...

> Generally, activities treated as software development for section 174 purposes include, but are not limited to, the following.

• planning the development of the computer software

• designing the computer software

• building a model of the computer software

• writing source code and converting it to machine-readable code

• testing the computer software (up to the point that a taxpayer places the computer software into service or determines that the computer software is ready for sale or licensing to others)

• producing product master(s), if the taxpayer develops the computer software for sale or licensing to others.

> Activities that are not treated as software development vis-à-vis software developed by a taxpayer for use in its trade or business are as follows:

• training employees and other stakeholders that will use the computer software

• maintenance activities after the taxpayer places the computer software into service

• data conversion activities, except for activities to develop computer software that facilitate access to existing data or data conversion

• installing the computer software and other activities relating to placing the computer software into service

> under what definition of software engineer?

Probably a broad enough definition to net the US Government the greatest tax revenue possible for the effort to enact this.

The answer to all these questions is yes, i don't see the point in trying to obfuscate this with artificial complexity.

What about HR, etc who use excel documents?

IF they are using it rather than developing it, no. If they put in 5 hours a week writing code, yes for those 5 hours. This isn't hard.

> For purposes of this section, any amount paid or incurred in connection with the development of any software shall be treated as a research or experimental expenditure.

For me that sounds like everyone and everything in a company that develops software of any kind, including low-/no-code stuff, accounting, HR, travel costs, massages. Like who is not "in connection with the development of any software" in a company that develops software? Without further definitions this is even worse then just software engineering costs.

> This [1] is the only definition the code actually give.

Like most of our tax code, its overly complicated by unclear or incomplete codes.

The IRS will give guidance with examples, but those examples are still incomplete.

Ultimately our tax code always comes down to the filer doing whatever they (a) think they can get away with or (b) are willing to defend if they get audited.

I’m a solo founder and sometimes outsource projects. How does that work if I pay a contractor a few thousand for a project? Are contractors allowed to be deducted fully at 100% expense?

Yes, this is an insane policy that reflects a complete ignorance of the on-ground realities. It was almost certainly only passed to help the 2017 tax bill's legislative scoring by the CBO.

I posted about this on Reddit the other day. https://www.reddit.com/r/Economics/comments/1l3lo7j/the_hidd...

> Yeah, it's pretty much completely insane. Although in your example I think you accidentally picked numbers that actually work out precisely to zero dollars in taxable income. The company (if US-based) would have zero taxable income in the first year because they can deduct 1/5th of the salaries (because there is a five year amortization for US companies, and 15 year for foreign companies), so they would have $1m in gross income and $1m in deductions resulting in $0 in taxable income. But you can tweak the numbers a bit to get the result you intended, e.g., $1m in revenue and $2.5m in salary would result in $500,000 additional taxable income under the TCJA's version of Section 174 over the previous version of the code, even though in reality the company operated at a net loss. (edit, just looked this up and actually the amortization is dated from the midyear of the tax year in which the expense is incurred, which is also just fucking bonkers, but that means I was incorrect and your example does yield a taxable income, because the first year in your example would have $500k in deductions rather than the full 20% of the $5m expense, resulting in $500k taxable profit)

> All of which means that we treat R&D salaries less favorably than ordinary salaries, which are fully deductible in the year they are incurred. So our tax code now not only fails to incentivize R&D as under the previous R&D tax credit regime, it actively treats R&D employee salaries worse than non-R&D salaries. Even though R&D jobs are generally the highly skilled, well compensated, white collar careers we want to keep in this country.

> Section 174 also specifically designates all software development as R&D, so there's no way to develop software while claiming it is not R&D. I'm sure accountants have been jumping through hoops in their efforts to reclassify other kinds of product development jobs as not R&D, which is the exact opposite of what R&D tax studies used to do, which was to label as much employee compensation as R&D expenses as possible, because §174 and the related, intersecting provisions of §41 (the R&D tax credit itself), treated R&D salaries more favorably than other salaries. To a certain extent, the OP article understated how much of a swing this revision to the tax code is. It isn't just that we are treating R&D salaries worse than we used to, but that we are treating them even worse than we treat other kinds of salaries. Which is bizarre in a world where the policy objective is to retain R&D jobs in the US.

> The purpose of capitalization is to match expenses to benefits over multiple tax years. So that the tax payer can't take a huge tax deduction up front to generate an economically fictional loss in the short term on an asset that will generate income over the many years. Amortization forces them to deduct the expense of the asset over time as the benefit accrues over time.

> This model is a poor fit for software. Construction workers produce an asset with a generally predictable and known useful lifetime and long-term stable value that is independent of the business. You can always sell a building.

> Software, however, does not generally create value for very long if it is not subject to continuous development and improvement. It also decays very rapidly when not maintained (e.g. security patches), yet there is no distinction in the tax code between new development and production support/maintenance software development. Nor would any such distinction make any sense in reality, because unlike a physical asset software is subject to continuous change and there is little distinction between adding new features and maintaining existing features. This approach to capitalizing salaries contrasts with other capitalized assets like buildings, where most ordinary maintenance costs are deducted in the current year, not capitalized.

> The value of software can be much harder to predict than other capitalized assets. Both in terms of the demand, but also in terms of the technical capability to deliver the desired product. Which is why it's considered R&D in the first place: there is inherent technical risk in many if not most software projects which is not present in other kinds of economic activities that produce capitalized assets.

> Software is often so specialized that it cannot be sold on to a third-party without selling the entire business around the software, including existing customers, distribution and sales channels, and supporting software engineering staff. It's not a liquid, fungible, alienable asset the way other capitalized assets typically are. There is no real market for the source code to Reddit, for example, because there is nothing technically special about Reddit. The company's value derives from the user base, the community, and the data, not anything particularly special about its software.

> The tax code also confuses the output of the software development process with the value software can generate. Software developers produce code. Some of that code is valuable, much is not. Unlike with other capitalized assets, you can't know in advance whether the software you produce actually works 100% of the time, even with robust testing and QA. Whereas you can be quite certain that a building will continue to function as a building if it is built correctly. Many software engineers actually regard code as a liability rather than an asset. The more you have to maintain, the more work you have to do to maintain the code base and the harder it is to add new features or debug issues with existing features. So if you can deliver the same capability to your customers with less code, then that is preferable. Which is to say, the output of the software development process is much more loosely tied to predictable economic value than other capitalized assets.

> Software is also frequently delivered as a service, which highlights the inanity of treating software as a fixed, long-term asset. The team maintaining a SaaS will handle day-to-day site reliability engineering work, which is never a stable output but needs to be constantly tweaked to match actual usage patterns.

> Last, and this is implicit in much of the above, but unlike other capitalized assets, software is never really complete. There are always more features, more optimizations, more bug fixes. Software development is never steady state. Either the software isn't being developed actively and quickly loses nearly all value due to code rot, or it is being actively maintained and improved and is producing value. Buildings don't stop functioning as buildings when you stop paying the construction workers. Thus, software development does not produce a long-term fixed asset but rather is a continuous service delivery process, where the revenue produced in any given year was produced by the same year expenses to maintain the software. Thus, software expenses and revenues are mostly naturally aligned in a single tax year, and therefore software is not suitable for amortization.

From the wording, it sounds like it applies to contracting non-US resident software development as well.

> Is an FPGA or ASIC engineer still considered a software engineer if they are writing in HDLs?

Of course not. The Glorious Leader is rescuing the american hardware sector.

There is a substantially more definition, but the tl;dr is this an R&D expense, or COGS expense?

R&D is amortized, COGS is not.