Hacker News Reader

Comment by jncfhnb | Hacker News Reader

If you’re building software that is intended to be used for longer than a year then it should be capitalized.

The argument on HN is always just complaining that it’s unfavorable to devs; but it’s perfectly reasonable with regards to actual tax principles.

View on HN

Exactly. The issue isn't whether capitalizing salaries is "humane" or "inhumane," as some comments suggest. It's about matching expenses to their corresponding revenue. When you develop software that contributes to revenue over a period, those expenses should be spread out. Capitalized items are simply deferred expenses. For example, when you construct a building, construction workers' salaries are capitalized and added to the building's book value, which is then depreciated over time.

Almost all other payroll is deductible. Why is salary for someone building a house deductible, but salary for someone building a for loop a capital expense

Look into when this started and why and you might understand it

> Why is salary for someone building a house deductible, but salary for someone building a for loop a capital expense.

If the “house” (or the for loop) is sold and gone, it’s not an asset and the cost of the goods sold — salaries included - is an expense.

If the “house” (or the for loop) is kept and used, it’s an asset and the cost of producing the asset — salaries included - is capitalized.

(There are differences betweeen the “house” and the for loop but not at the extremes which are clear. I imagine by “house” you mean some building that makes sense in a commercial or industrial context like a warehouse.)

Salary for building assets generally are capitalizable. Construction companies have a special carve out because they typically are hired to build the assets for someone else and are paid for the completion of the construction work.

A factory worker building a product to be sold is capitalized into inventory

The product can be capitalised into inventory. The factory worker's salary is just a cost.

The key thing here is that while you generally are expected to and allowed to consider a produced good an asset, it's not assumed that paying someone salary translates immediately into an asset... unless it's software under this new rule for some reason

Software engineers hired for custom, in house work are not building a fixed piece of software with the intention of letting it loose unchanged for the next five years.

Software engineers hired to build product are not exclusively building a finished product, and are increasingly necessary as part of the expense of operating that product long term. Industry trends have gone towards combining and blending developement, security, operations, and design.

There are businesses that will build a big custom piece of machinery. Think a factory or a mine. That may last for 20 years, but require workers to operate, maintain, etc.

This is handled in existing tax law; building or improving a capital asset is amortized, repairing or maintaining it is expensed. It can be a pain in the butt, this is why accounting is not a trivial profession.

We could (and I think should) treat software the same. Some software engineer work is absolutely creating a capital asset. Some is absolutely high-priced janitor work. It makes sense to allow for both with your tax code.

> Think a factory or a mine. That may last for 20 years, but require workers to operate, maintain, etc.

Before Sec 174, s/w development costs were subject to a choice: amortization as if they were a capital expense, or regular deduction as a normal operating expense. Companies could decide which category to put costs into depending on the nature of the work (and presumably to suit their own interests).

Sec 174 removes that option. Or rather, it narrows it significantly. You must be absolutely confident that you paid developer X for ONLY maintainance work before deducting their salary.

Oh, I didn't realize - I knew 174 made it "must amortize", I didn't realize it could be done either way previously. Very silly indeed how they've done this.

The idea that the software must not be changed over the next five years is irrelevant

The important bit is that it will be used for longer than one year

Reply on news.ycombinator.com