Comment by ndriscoll 8 days ago
I would be surprised if nearly all software companies wouldn't consider their code to be a valuable capital asset. For example, do you think your company would be okay with releasing commits/snapshots of their source code and design docs into the public domain once they hit 5 years old? Or do they currently depreciate too quickly?
There could be a distinction between creating new value (greenfield), and maintaining existing value (brownfield). Most of my work is green field and I do consider it to be a capital asset, it's sweat equity as I don't pay myself, but I can't deduct my non-salary either. Others estimate the most of the software work is 95% brownfield.
An other issue is competitiveness with other jurisdictions that don't have these tax laws, but even if that were normalized there are jurisdictions that are far lower tax in general regardless of the classification.
Imagine if secretaries' salaries were applied to the "capital asset" of the well-organized file cabinets they create. Or if janitors' salaries were applied to the "capital asset" of a clean workspace. This whole quagmire is far more insane than anyone is giving it credit for.
Straight no. That’s why they had to put in line 3, “clarifying” the intent, because it’s not done anywhere else.
> This is unlike how capital assets are valued for any other industry!
Is your dismay that it's unfair compared to other industries or that the policy doesn't reflect reality that software is a capital asset that has a lifetime longer than 6 years for many companies?
It's that it doesn't reflect the reality that the value of software is not remotely correlated with the salaries that were spent building it. It could be valued much higher or much lower, spanning a huge range.
Using salaries as a proxy for value of the asset encourages only the safest shovelware bets, discouraging risk taking lest your asset be taxed at substantially higher than it's worth.
Avoiding that risk-adverse dynamic is why Section 174 was written the way it was since the 50s to encourage R&D, and it's paid off in spades.
Well, a larger issue seems to be that this whole idea is premised on taxing an unrealized gain. If I create a painting, I don't owe any taxes on it until I sell it. If the world decides that I'm Picasso and my sneezing on a canvas means it's worth $50 million, it still won't be true that, after I sneeze without covering my mouth and some spittle lands on one of my blank canvases, a government official shows up to my house to force me to sell it so that I can pay the taxes I owe for creating it.
Shorter is better here — it means you’re able to take the deduction up-front. The issue is that salaries should not be included as part of a capital asset, as this precludes any other deduction for the same salary. You don’t do this for accountants or lawyers, even at a software firm, but you now have to for your developers. It makes a particular role of employee more expensive!
It’s this absurdity I’m upset about. Six year vs five year is weird but meaningless. Internal software not being sold can be a capital asset, or at least I can point to examples of it (MSFT Hyper-V, ex). But the valuation process is both arbitrary in both directions, and discourages companies from hiring software developers as a policy effect.
Software just isn't a "capital asset" in the traditional sense. It might have a multi decade depreciation in real life, or it might be worthless shortly after writing. I mean, we live in a tax regime where a jet is 100% depreciable in the year its purchased. Srsly.
> you do not own your employees
Well, that framing is just wrong. The companies are paying taxes over what those employees created, not over the employees. Does the company own the software?
> The IRS is using a theory of value where...
Notice that all of your 3 points are exactly like any other kind of capital.
Most countries exclude salaries from the income calculation because it has good practical consequences (both on making accounting cheaper and on incentivizing companies to hire), not because of any theoretical problem.
If you're ripping off a competitor, sure, the salaries of your engineers roughly translates to the value of the resulting capital asset. But the most valuable work that software engineers do is the stuff that has never been done before. The salaries of your developers and designers and your product managers go first towards figuring out what a valuable capital asset would look like. Only after that can you start investing in the actual asset.
The same is true for all true R&D, which is why historically the government has tried to provide protections for R&D work to incentivize people to not just churn out the safe bet over and over again. Patents fall into this category, but software patents are (rightly) hard to come by. Through 2022, the risk of software development was offset by the ability to expense the costs and avoid a tax bill, and this was good policy if your aim is to encourage innovation.
The capital asset theory could still work if there were some way to appraise the value of the actual asset you created. But absent such a way, this thinking is deeply flawed for all but the most shovelware of jobs.
> If you're ripping off a competitor, sure, the salaries of your engineers roughly translates to the value of the resulting capital asset.
I don't think this comes close to being true. It would make ripping off a competitor pointless.
I don't think that framing really tells us much, because there could be many reasons not to release that code that don't indicate it's an asset, such as (A) worries it might have still-relevant security issues, (B) costs of scrubbing other information like employee PII, or (C) the code is too useless to be worth the effort.
If the goal is to measure retained value, I'd ask how much a competitor would pay to acquire your 5-year-old code (for direct use, not for hacking you) without feeling cheated afterwards.
Even if true, a small fraction of engineering time on a project is actually developing that asset. The rest is maintenance and support. The tax code does allow for this distinction, but only if you track hours associated with each kind of work, which basically no one does. And even if they tried, it's difficult because that line is blurry. Tasks are rarely 100% one or the other. Ever fixed a bug by refactoring to make something better? Which kind of engineering is that? Can you justify that to the IRS accountant auditing you?
Salaries are not generally considered “capital” - HR wording aside, you do not own your employees. It’s an immediate expense that may, or may not, produce something of value.
The IRS is using a theory of value where software (1) is a capital asset (okay, sure), (2) has a six-year deprecation schedule (uhhh why not 5 like everything else?), and (3) is valued at the exact cost of all inputs to it, including salaries (uh oh).
This is unlike how capital assets are valued for any other industry! And it has the effect that hiring a second lawyer is “cheaper” (for five years anyway) than hiring a second developer.