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
> maintenance activities after the taxpayer places the computer software into service
This is the part that I think makes this whole jig of treating software development like a purely capitalizable expense so nuts.
I previously worked at a public company that wanted software developers to treat as much work as possible as CapEx - it makes you look more profitable than you actually are, which is bad for taxes but good for your stock price. Developers hated it. The problem with it is that with modern web based software, CI/CD, A/B testing, etc. that the line between "new software" (i.e. CapEx) and "maint" (i.e. OpEx) is so blurred as to be pointless. E.g. many times I'd be fixing a bug (technically OpEx) but that would often lead to some new features ideas, or ways to structure the software to make it easier to add new features (technically CapEx). Software is fundamentally different from capital expenditures in other areas, and assuming a 5 year straightline depreciation schedule for software is laughably absurd.
What other sort of capital expenditure has you do releases every day, or requires 24/7 monitoring? I would argue that the business of software has changed so drastically over the past 20 or so years that it makes much more sense just to categorize it as OpEx by default (for both tax and GAAP purposes), and only have it be capitalized as CapEx for very small and specific reasons.
Your Honor, here printed on paper is what the Prosection calls "software". Actually as anyone can see on the paper, what is there is just ordinary typing A-Z and 0-9 with a lot of the typing in English. Businesses have been doing typing for many decades. E.g., this typing is much like instructions to a delivery truck driver to deliver goods to customers. And it's the same if a drone reads those instructions and makes the delivery. Prosecution has yet to show what of this paper is other than business typing ~100 years old.
It runs on a computer. It tells a computer how to do things. You can type once and have the same instructions run again and again on the same computer or on different computers. It can run on many computers simultaneously. No human intervention is required for all of the above.
> What other sort of capital expenditure has you do releases every day, or requires 24/7 monitoring?
Quite a lot of them actually. If I spend $$$$ setting up a car factory with a big production line, I'm going to have people monitoring it 24/7. If I build an airport, I'm going to have air traffic controllers working 24/7. And so on.
Of course, the air traffic controllers didn't build the runway, and the construction crew don't direct air traffic, so the whole situation is much less ambiguous.
How exactly does the construction of an airport (runway, terminals, parking, etc.) satisfy "releases every day" during the construction? I could see if it were adding a runway or a terminal, but until at least some of the infrastructure is there it's not exactly usable to the end user, the public, as say a stand-in definition for "released."
> I'm going to have people monitoring it 24/7. If I build an airport, I'm going to have air traffic controllers working 24/7. And so on.
> Of course, the air traffic controllers didn't build the runway, and the construction crew don't direct air traffic, so the whole situation is much less ambiguous.
That is precisely why those salaries are NOT capex
Your example was quite good actually. Even in sw the people that build the system is not necessarily the people that monitor, maintain and use it, even for systems used only inside a company. I used to work in a telco and we had 3 separate departments, plus a 4th one for testing. And yet all of them seem to be subject to section 174, builders, maintainers, testers.
A country wide power grid or telecommunications network are other examples that come to my mind. They are never complete, they get more features every day (new cables?), they are monitored 24/7. The owner companies also use them.
> And yet all of them seem to be subject to section 174, builders, maintainers, testers.
Do they?
Upthread one can read: > 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: […] • maintenance activities after the taxpayer places the computer software into service
You are right. I also read other comments pointing at that. Nevertheless it's often debatable what's maintenance and what's a new feature. Hopefully nobody is looking at it in too much detail.
Example: a one line change to ignore non Unicode codepoints in PDF files loaded in a web app (I did it yesterday.) Is that a new feature? Is that a bug fix? And if it's a bug fix, is that part of a feature that we should have developed before putting the sw into service? Is that maintenance? And what if that particular code point that triggered the issue did not even exist when we released the sw years ago (the code around it is from 2021)?
I believe that nobody has the time to dig the (tens of?) thousands of issues that a company opens and completes every year but there are a lot of gray areas to exploit if somebody has any reason to be pedantic.
> Nevertheless it's often debatable what's maintenance and what's a new feature.
The same is true for many capital assets. There are people who have time to look into these things because that’s their job.
What we do is enforce that everyone keeps one ticket in JIRA as in progress and use a timekeeping add on. The tickets role up to epics and initiatives. I review each top level initiative and epic with finance and they deem it capitalizable or not. Then we add a haircut. It’s really not that much work. We have an hour meeting monthly to work it out but I make sure to exclude my mainline engineers. They don’t need that
How many engineer-hours are lost amongst the whole company each semester to report all these mindless tickets?
A lot.
It also warps outcomes towards a metric which "is only used for tax purposes" but which also is reported ritualistically with an expectation of compliance.
The entire thing is nuts.
And no one thinks it was sensible.
The only reason it exists is for political games by Trump 1.
Now imagine all the nonsense that’s gonna go into the much bigger Trump 2 tax cut bill.
> • data conversion activities, except for activities to develop computer software that facilitate access to existing data or data conversion
ex: linking excel spreadsheets or setting up excel to ingest data from a sharepoint or network drive would still fall under the definiton of software developer
> • maintenance activities after the taxpayer places the computer software into service
So a sysadmin or a DB admin writing scripts or a DB admin writing queries and adding new reports would be considered software development
It just seems way too easy for arbitrary employees to get pulled in under this definition because it just fundamentally misunderstands how widespread programming is.
You missed the paragraph saying that maintenance activities are not considered development activities
But that's the rub right? What is the definition of maintenance activities? And for what software? If you are writing a new script to automate something or updating an existing script, is that not software development?
If that's considered maintenance activities then would maintaining a software codebase not be considered maintenance activities then?
In my simple mind, if software has been "released" it is no longer R&D, and "bug fixes" (which should include continuous improvements such as your example) are not research.
I may be way, way wrong though.
That seems too exploitable to pass muster in the court. If you release Beta 0.0.1 of your software after 2 months of development then spend the next 5 years getting it up to version 1.0 that's clearly a development effort not a maintenance effort.
> such as marketing and promotional activities, maintenance activities that do not give rise to upgrades and enhancements, distribution activities
If it leads to a new release, then its software dev. Meaning anything more than a minor patch is going to count.
That's the reason we have courts, to cut through those gray areas.
No. That is why you have auditors who must sign off on your financial books and records. There are fairly strict rules about capitalization of software development. If it is a meaningful number for your firm, then the auditors will review in detail.
The IRS Guidance says this in 5.05(2), which is most relevant to software startups:
(2) Computer software developed for sale or licensing to others. In the case of
computer software that is developed for sale or licensing to others (or upgrades
and enhancements to such software), activities that occur after such software (or
upgrades and enhancements to such software) is ready for sale or licensing to
others, such as marketing and promotional activities, maintenance activities that
do not give rise to upgrades and enhancements, distribution activities (for
example, making the software available via remote access), and customer support
activities.
Has the IRS actually dinged anyone for fucking with how they categorise software expenses?
They have, but they’ve fired everyone. Literally. I have a relative who was fired while testifying in court, he ended up stranded in some flyover shithole.
The real issue is the auditors will flag it.
The concept and determining factor is how it relates to revenue. Is it an activity that supports or contributed to current revenue generation, or is it something that is expected to only contribute to future revenue generation.
So if you’re just maintaining a software, that’s already used then you’re good.
I used to support this change because I thought that it would fairly make the software industry like many other industries who have to pay this kind of amortization for R&D and I believe that there would be carve outs for small organization so that really large ones are the only ones who bear the cost.
I also believed it unlikely that this would be enforced or audited before there were such corrections or refinement to the original language.
So the way I viewed it was it’s basically a higher tax for giant software companies, but everyone else will be unaffected by it so we shouldn’t worry.
However, I also now support repealing or changing it because whether or not it has ever or was ever gonna be enforced or audited, it’s ended up causing a lot of disruption across the entire software industry. So much so that it actually looks more like an unfair penalty against software development than anything else now unfortunately.
So I’ll definitely be signing that little petition under my US corporation.
What a wonderful sales pitch for a timesheet software feature. Track non-software-related work for expensing in the current tax year.
Any decent sized company already does this. You’ll see a field on things like Jira tickets for whether something is maintenance or capital improvement. And presumably that information can be used to infer the percentage of a given workers time that can be attributed to deductible vs depreciable expenses.
Exactly. Everywhere I’ve worked, this was a quick and non-intensive collaboration between engineering management and like one finance person. It’s baked into a ton of tools already (like you mentioned, Jira) so the percentages are usually just there and eng leaders review it with FP&A twice a year.
Real innovators can’t stand this sort of noise and so it is a direct shot against their bow
This is fairly standard for a lot of larger companies and for companies where your work is contract work (see defense contractors, legal firms, architecture and civil engineering firms). You have to do line item billing on costs for a given contract so you have to track how many hours are spent to do whatever labor needs done.
The issue is that this is a lot of unnecessary complexity for orgs that aren't doing that kind of work.