It depends. If you have a truck - capital asset - the oil changes are probably opex, but replacing the transmission is probably capex. Regular sweeping and cleaning of a building is likely opex, upgrading the wiring capex. Software I can certainly see getting tricky here - is updating dependancies an oil change or a transmission?
"Betterment, restoration or adaptation" is the usual test for something being capex.
Hot take: not one person on earth could make a good/useful distinction between "bug" and "feature" in software development. Some times that's clear, usually it's not. Making tax law depend on the idea that there is a distinction is pretty terrible.
The current US tax law is flipping (with no rollout period) between dev salaries being 100% expensed (over 1 year) and 100% amortized (over 5 or 15 years). You actually could make some distinction between those two poles without being able to perfectly categorize every line of code.
A number of things the government could do:
1) Split it between the two. Need to amortize x% but can expense the rest. Maybe that % is mandated, maybe it depends on industry (i.e. if you make games vs an OS vs a SAAS vs embedded software for cars).
2) Tie it to company size, either headcount or revenue.
3) Allow different categorizations for e.g. R&D, product support, building internal tools, building SAAS for sale, whatever.
4) Roll out any changes gradually over x years.
Tax law, over and over again, uses the idea that there's a distinction between CapEx and OpEx. It's not magically impossible to do the same for software.
In a world where all software actually has a comprehensive spec, I think the distinction could be made pretty easily, but the line is definitely fuzzy in this one.
Yeah I don't think that has happened even in (say) the most extreme niches like some project with an embedded 8 bit microcontroller in a space/military setting....
It depends. If you have a truck - capital asset - the oil changes are probably opex, but replacing the transmission is probably capex. Regular sweeping and cleaning of a building is likely opex, upgrading the wiring capex. Software I can certainly see getting tricky here - is updating dependancies an oil change or a transmission?
"Betterment, restoration or adaptation" is the usual test for something being capex.
Fixing bugs sounds like betterment to me.
Hot take: not one person on earth could make a good/useful distinction between "bug" and "feature" in software development. Some times that's clear, usually it's not. Making tax law depend on the idea that there is a distinction is pretty terrible.
The current US tax law is flipping (with no rollout period) between dev salaries being 100% expensed (over 1 year) and 100% amortized (over 5 or 15 years). You actually could make some distinction between those two poles without being able to perfectly categorize every line of code.
A number of things the government could do:
1) Split it between the two. Need to amortize x% but can expense the rest. Maybe that % is mandated, maybe it depends on industry (i.e. if you make games vs an OS vs a SAAS vs embedded software for cars).
2) Tie it to company size, either headcount or revenue.
3) Allow different categorizations for e.g. R&D, product support, building internal tools, building SAAS for sale, whatever.
4) Roll out any changes gradually over x years.
Tax law, over and over again, uses the idea that there's a distinction between CapEx and OpEx. It's not magically impossible to do the same for software.
In a world where all software actually has a comprehensive spec, I think the distinction could be made pretty easily, but the line is definitely fuzzy in this one.
Yeah I don't think that has happened even in (say) the most extreme niches like some project with an embedded 8 bit microcontroller in a space/military setting....
My guess is a reported bug is opex, since it's fixing a defect on something that exists. But adding an API would be capex.