681–690 of 957 posts
A lot of people don't know what this Section 174 is about, so here's a brief explainer. Normally, when you have expenses, you deduct them off your revenue to find your taxable profit. If you have $1 million in sales, and $900k in costs, you have $100k in profit, and the government taxes you on that profit. Section 174 says you can't do this for software engineers. If you pay a software engineer, that's not "really" a…
A lot of people don't know what this Section 174 is about, so here's a brief explainer. Normally, when you have expenses, you deduct them off your revenue to find your taxable profit. If you have $1 million in sales, and $900k in costs, you have $100k in profit, and the government taxes you on that profit. Section 174 says you can't do this for software engineers. If you pay a software engineer, that's not "really" a…
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.
Earlier quoted context omitted.
> One could argue in the future, for example, that those who operate machines to produce tooling dies, should not have their labor treated as regular expenses, but instead as capital assets because their labor output is captured in assets, In the future? That's how it works! > just as Sec 174 treats the labor of software developers as assets. [I was wrong about the following. I misread the text - and the submission t…
source?
Example 4. Acquisition or production cost. D purchases and produces jigs, dies, molds, and patterns for use in the manufacture of D's products. Assume that each of these items is a unit of property as determined under § 1.263(a)-3(e) and is not a material and supply under § 1.162-3(c)(1). D is required to capitalize under paragraph (d)(1) of this section the amounts paid to acquire and produce the jigs, dies, molds, and patterns.
Earlier quoted context omitted.
That's nuts, since a payroll should never be considered an asset. That's trying to put a material value on software, and doing it based on the salaries of developers is as crazy as valuing it in lines of code. The value of software could be based on something more realistic, like a percentage of actual revenue, but I suppose tech giants would be against that.
> That's nuts, since a payroll should never be considered an asset. That's because it's not "a payroll". When a payrolled resource builds a combustion engine that powers the office where the rest of the payrolled resources work every day and that engine lasts 15 years, then its a very clearly a capital expense and an asset.
Software used to work like other payroll until fairly recently. If you want to understand this figure out why that changed and what the actual motivation behind it was
Earlier quoted context omitted.
That's nuts, since a payroll should never be considered an asset. That's trying to put a material value on software, and doing it based on the salaries of developers is as crazy as valuing it in lines of code. The value of software could be based on something more realistic, like a percentage of actual revenue, but I suppose tech giants would be against that.
> That's trying to put a material value on software, and doing it based on the salaries of developers is as crazy as valuing it in lines of code. We all do this at the conclusion of every successful job interview. And performance review. And budget review. IMO it's a reasonable floor on the value engineers produce: if you produced an asset worth less than your salary you should be concerned for your career.
In reality, this is something made up to balance a budget while pushing the consequences beyond the next election. It isn't a well intentioned accounting principle
Earlier quoted context omitted.
Forgive the naive question, but is this different than other payrolled employees? So for normal employees you get the deduct the year it's paid, but for some reason for software developers you have to amortize it?
Theoretically it’s the same with any asset you pay someone to make. If you pay someone to make a chair, you don’t deduct the salary. Instead you create an asset valued at what you paid to build it, then depreciate it over time. The arguement for this is that it would be inconsistent to do otherwise. After all, why should buying a chair from someone else be different than paying an employee to do it? It’s worth noting…
Earlier quoted context omitted.
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 (u…
> (3) is valued at the exact cost of all inputs to it, including salaries (uh oh). Thanks, that really gets at the heart of the issue. Are any other business processes and elements — e.g. accounting mechanisms, print design, sales funnels — valued this way?
A lot of people don't know what this Section 174 is about, so here's a brief explainer. Normally, when you have expenses, you deduct them off your revenue to find your taxable profit. If you have $1 million in sales, and $900k in costs, you have $100k in profit, and the government taxes you on that profit. Section 174 says you can't do this for software engineers. If you pay a software engineer, that's not "really" a…
> you have to depreciate that over several years (5 in this case). 15 years in the case of foreign developers.