Comment by patmcc
6 months ago
They're still expenses, they just now need to be amortized.
Buying a truck is an expense, as is buying gas for the truck. But the former you have to amortize over x years, the latter you can expense immediately.
The law used to be "employee salaries for software are like buying gas" and now it's "employee salaries for software are like buying a truck".
The critical difference is that the business owns the truck but not the employee. The amortization assumes that the asset can be sold for value. An employee can quit at any time for any reason. You don’t retain the right to their labor for five years.
If they're producing a capital asset, you do retain the right to the fruits of their labor, even if they quit.
The rationale behind amortization isn't exactly the idea that the asset can be sold, it's that the asset is producing revenue over multiple years. For software, the asset is the codebase.
Let's say you hire a single software dev, for one year, and they write Excel++, which you can sell for the next ten years. It would be entirely appropriate to amortize the cost of creating that software over those ten years, based on the matching principle (a fundamental idea of accounting, matching expenses with revenue).
The issue in the real world is that's not how the software industry actually works, 99% of the time.
> The issue in the real world is that's not how the software industry actually works, 99% of the time.
What would be a more appropriate model from accounting perspective?
1 reply →
As anyone that has ever sold software IP knows, most of the value is vested in the person that wrote the code, not the code itself. The code is not a factory, it is the output of the factory.
5 replies →
the company owns the IP that the employee made though.
if anything, the amortization should match copyrights or patent lengths