7 ms·

So it applies to software engineers but under what definition of software engineer? This [1] is the only definition the code actually give. > (3) Software dev

• teeray 1y ago
  > under what definition of software engineer? Probably a broad enough definition to net the US Government the greatest tax revenue possible for the effort to enact this.
  • abeppu 1y ago
    IDK if that's right. Oddly, the current administration has gutted the IRS and seems pretty ambivalent about collecting taxes that are on the books. I wonder if there will be an inconsistent definition of who is a software engineer, based on how friendly the company is with the administration, whether the company still has someone with a DEI title, etc.
    • teeray 1y ago
      > the current administration… seems pretty ambivalent about collecting taxes that are on the books. I wonder if there will be an inconsistent definition of who is a software engineer, based on how friendly the company is with the administration, whether the company still has someone with a DEI title So basically the same situation that we have with bullshit speed limits everywhere.
      • ethbr1 1y ago
        If we had specifically defunded highway patrol that was net-revenue-positive, yes. Republican defunding of the IRS is literally insane: reform by cutting enforcement. - It rewards people who cheat on their taxes. - It costs the government more money that it saves, because IRS investment is net revenue positive. But then, the modern Republican party seems more concerned with being the party of 'law(s I agree with) and order (for people who aren't me).'
        • jandrewrogers 1y ago
          People greatly overestimate the amount of material cheating that happens, especially among large companies and the wealthy. I used to work for a Federal audit organization and almost all of the recoveries had a root cause in sloppy compliance and record-keeping practices rather than intentional malfeasance. It is broadly recognized as optimal that the recovered money should be several-fold the direct costs spent to recover it because this activity incurs a lot of non-obvious indirect costs. It is a variation on the principle that the optimum amount of fraud is non-zero. Most of the blatant tax fraud is much lower down the economic ladder because below a certain threshold recovery doesn’t justify the cost and people know this. The amount you can get away with is far below the threshold where it would be worth the risk for wealthy parties. The best ROI for auditors in many of these cases is to make regular object lessons at random to discourage it rather than systematically prosecute it. AFAIK, the increased spending at the IRS did not lead to concomitant offsetting recoveries. This is a predictable outcome, the amount of enforcement activity has been pretty finely tuned for decades to optimize ROI. Most of the recoveries come from changing focuses on compliance to areas that haven’t seen much enforcement activity in many years. Fighting entropy basically. If you assume that most large recoveries are from sloppiness rather than systematic tax fraud, it changes what is going to be an effective strategy.
  • sailfast 1y ago
    They want the change to _seem_ like it will bring in revenue so the CBO number adding to the deficit is lower. The folks advocating for this could care less about the deficit, but they need to act like they care.
  • sh34r 1y ago
    A sufficiently idiotic tax scheme such as Section 174 can destroy far more income tax revenue than it collects, by destroying jobs and small businesses, and knocking high earners down a tax bracket or three. Section 174 isn’t doing much to tax FANG companies. Apple has all their profits in their Double Irish Dutch Sandwich racket. Amazon cooks the books to appear unprofitable on paper, in a manner that would make Hollywood accountants blush. This really only hurts the competition, who is completely unprofitable in every sense of the word. And all for what? Left-shifting the collection of a 21% income tax by a couple years? I think many of us would’ve done terrible things in 2021 to only have an effective tax rate of 21%. The government mugged Peter the payroll tax man to pay Paul the corpo tax man, but they disemboweled Peter in the process, and most of the money had to be disposed of as a biohazard. I don’t believe Section 174 was an honest attempt to manage the deficit. I think Zuck, the PayPal Mafia, and the blood-boy cabal bribed some Congresscritters to kill off what remained of their competition.
    • robocat 1y ago
      > I think Zuck, the PayPal Mafia, and the blood-boy cabal bribed some Congresscritters to kill off what remained of their competition. What's with the craze for finding conspirational incentives? There's a repeatable pattern where commenters hallucinate an unreasonable incentive for everything. Motivations are difficult to discern (see courtrooms), and it is a modern vice to try and analyse incentives, but too often the cause-and-effect imaginations are not even reasonable guesses, but are just pure fiction. My best guess (based off word choices made) is that we all love to create new stories/narratives, that fit into our personal tribal stories.
      • sh34r 1y ago
        My best guess is that legalizing corruption has made everyone a bit more deranged. Some more than others. I don’t think it’s such a huge leap that a policy with such unanimous opposition was put in place by the select few special interests who benefit from it. It helps (or doesn’t help?) when they all got together for that photo op at the inauguration.
      • pigeonhole123 1y ago
• normie3000 1y ago
  > Is an FPGA or ASIC engineer still considered a software engineer if they are writing in HDLs? Of course not. The Glorious Leader is rescuing the american hardware sector.
• EnderWT 1y ago
  The IRS released guidance back in 2023: https://www.irs.gov/pub/irs-drop/n-23-63.pdf https://www.irs.gov/pub/irs-drop/n-23-63.pdf It starts on page 23. Plenty of analysis online by tax firms but I'll quote from this one: https://insightplus.bakermckenzie.com/bm/attachment_dw.action?attkey=FRbANEucS95NMLRN47z%2BeeOgEFCt8EGQJsWJiCH2WAWuU9AaVDeFgmRFq5vwNmVN&nav=FRbANEucS95NMLRN47z%2BeeOgEFCt8EGQbuwypnpZjc4%3D&attdocparam=pB7HEsg%2FZ312Bk8OIuOIH1c%2BY4beLEAex6zXXvxYhr0%3D&fromContentView=1 https://insightplus.bakermckenzie.com/bm/attachment_dw.actio... > Generally, activities treated as software development for section 174 purposes include, but are not limited to, the following. • planning the development of the computer software • designing the computer software • building a model of the computer software • writing source code and converting it to machine-readable code • testing the computer software (up to the point that a taxpayer places the computer software into service or determines that the computer software is ready for sale or licensing to others) • producing product master(s), if the taxpayer develops the computer software for sale or licensing to others. > Activities that are not treated as software development vis-à-vis software developed by a taxpayer for use in its trade or business are as follows: • training employees and other stakeholders that will use the computer software • maintenance activities after the taxpayer places the computer software into service • data conversion activities, except for activities to develop computer software that facilitate access to existing data or data conversion • installing the computer software and other activities relating to placing the computer software into service
  • OneDeuxTriSeiGo 1y ago
    > • data conversion activities, except for activities to develop computer software that facilitate access to existing data or data conversion ex: linking excel spreadsheets or setting up excel to ingest data from a sharepoint or network drive would still fall under the definiton of software developer > • maintenance activities after the taxpayer places the computer software into service So a sysadmin or a DB admin writing scripts or a DB admin writing queries and adding new reports would be considered software development It just seems way too easy for arbitrary employees to get pulled in under this definition because it just fundamentally misunderstands how widespread programming is.
• anigbrowl 1y ago
  The answer to all these questions is yes, i don't see the point in trying to obfuscate this with artificial complexity. What about HR, etc who use excel documents? IF they are using it rather than developing it, no. If they put in 5 hours a week writing code, yes for those 5 hours. This isn't hard.
  • jandrese 1y ago
    So now every engineer has to record how many hours each day were spent doing "software development" vs. "software maintenance"/"overhead"/"etc..."?
    • deleted 1y ago
      [deleted]
    • joquarky 1y ago
      In my experience, at least contractors at a major ISP have to.
    • Muromec 1y ago
      You just add a row to spreadsheet at the end of the month. 30% maintenance, 70% development or whatever
      • RajT88 1y ago
        My last company required timesheets to be submitted daily.
        • mikepurvis 1y ago
          This is common in Canada for companies claiming SR&ED credits: https://www.canada.ca/en/revenue-agency/services/scientific-research-experimental-development-tax-incentive-program.html https://www.canada.ca/en/revenue-agency/services/scientific-...
      • jchanimal 1y ago
• ManBeardPc 1y ago
  > For purposes of this section, any amount paid or incurred in connection with the development of any software shall be treated as a research or experimental expenditure. For me that sounds like everyone and everything in a company that develops software of any kind, including low-/no-code stuff, accounting, HR, travel costs, massages. Like who is not "in connection with the development of any software" in a company that develops software? Without further definitions this is even worse then just software engineering costs.
• paulddraper 1y ago
  There is a substantially more definition, but the tl;dr is this an R&D expense, or COGS expense? R&D is amortized, COGS is not.
• stult 1y ago
  Yes, this is an insane policy that reflects a complete ignorance of the on-ground realities. It was almost certainly only passed to help the 2017 tax bill's legislative scoring by the CBO. I posted about this on Reddit the other day. https://www.reddit.com/r/Economics/comments/1l3lo7j/the_hidden_time_bomb_in_the_tax_code_thats/mw34jna/ https://www.reddit.com/r/Economics/comments/1l3lo7j/the_hidd... > Yeah, it's pretty much completely insane. Although in your example I think you accidentally picked numbers that actually work out precisely to zero dollars in taxable income. The company (if US-based) would have zero taxable income in the first year because they can deduct 1/5th of the salaries (because there is a five year amortization for US companies, and 15 year for foreign companies), so they would have $1m in gross income and $1m in deductions resulting in $0 in taxable income. But you can tweak the numbers a bit to get the result you intended, e.g., $1m in revenue and $2.5m in salary would result in $500,000 additional taxable income under the TCJA's version of Section 174 over the previous version of the code, even though in reality the company operated at a net loss. (edit, just looked this up and actually the amortization is dated from the midyear of the tax year in which the expense is incurred, which is also just fucking bonkers, but that means I was incorrect and your example does yield a taxable income, because the first year in your example would have $500k in deductions rather than the full 20% of the $5m expense, resulting in $500k taxable profit) > All of which means that we treat R&D salaries less favorably than ordinary salaries, which are fully deductible in the year they are incurred. So our tax code now not only fails to incentivize R&D as under the previous R&D tax credit regime, it actively treats R&D employee salaries worse than non-R&D salaries. Even though R&D jobs are generally the highly skilled, well compensated, white collar careers we want to keep in this country. > Section 174 also specifically designates all software development as R&D, so there's no way to develop software while claiming it is not R&D. I'm sure accountants have been jumping through hoops in their efforts to reclassify other kinds of product development jobs as not R&D, which is the exact opposite of what R&D tax studies used to do, which was to label as much employee compensation as R&D expenses as possible, because §174 and the related, intersecting provisions of §41 (the R&D tax credit itself), treated R&D salaries more favorably than other salaries. To a certain extent, the OP article understated how much of a swing this revision to the tax code is. It isn't just that we are treating R&D salaries worse than we used to, but that we are treating them even worse than we treat other kinds of salaries. Which is bizarre in a world where the policy objective is to retain R&D jobs in the US. > The purpose of capitalization is to match expenses to benefits over multiple tax years. So that the tax payer can't take a huge tax deduction up front to generate an economically fictional loss in the short term on an asset that will generate income over the many years. Amortization forces them to deduct the expense of the asset over time as the benefit accrues over time. > This model is a poor fit for software. Construction workers produce an asset with a generally predictable and known useful lifetime and long-term stable value that is independent of the business. You can always sell a building. > Software, however, does not generally create value for very long if it is not subject to continuous development and improvement. It also decays very rapidly when not maintained (e.g. security patches), yet there is no distinction in the tax code between new development and production support/maintenance software development. Nor would any such distinction make any sense in reality, because unlike a physical asset software is subject to continuous change and there is little distinction between adding new features and maintaining existing features. This approach to capitalizing salaries contrasts with other capitalized assets like buildings, where most ordinary maintenance costs are deducted in the current year, not capitalized. > The value of software can be much harder to predict than other capitalized assets. Both in terms of the demand, but also in terms of the technical capability to deliver the desired product. Which is why it's considered R&D in the first place: there is inherent technical risk in many if not most software projects which is not present in other kinds of economic activities that produce capitalized assets. > Software is often so specialized that it cannot be sold on to a third-party without selling the entire business around the software, including existing customers, distribution and sales channels, and supporting software engineering staff. It's not a liquid, fungible, alienable asset the way other capitalized assets typically are. There is no real market for the source code to Reddit, for example, because there is nothing technically special about Reddit. The company's value derives from the user base, the community, and the data, not anything particularly special about its software. > The tax code also confuses the output of the software development process with the value software can generate. Software developers produce code. Some of that code is valuable, much is not. Unlike with other capitalized assets, you can't know in advance whether the software you produce actually works 100% of the time, even with robust testing and QA. Whereas you can be quite certain that a building will continue to function as a building if it is built correctly. Many software engineers actually regard code as a liability rather than an asset. The more you have to maintain, the more work you have to do to maintain the code base and the harder it is to add new features or debug issues with existing features. So if you can deliver the same capability to your customers with less code, then that is preferable. Which is to say, the output of the software development process is much more loosely tied to predictable economic value than other capitalized assets. > Software is also frequently delivered as a service, which highlights the inanity of treating software as a fixed, long-term asset. The team maintaining a SaaS will handle day-to-day site reliability engineering work, which is never a stable output but needs to be constantly tweaked to match actual usage patterns. > Last, and this is implicit in much of the above, but unlike other capitalized assets, software is never really complete. There are always more features, more optimizations, more bug fixes. Software development is never steady state. Either the software isn't being developed actively and quickly loses nearly all value due to code rot, or it is being actively maintained and improved and is producing value. Buildings don't stop functioning as buildings when you stop paying the construction workers. Thus, software development does not produce a long-term fixed asset but rather is a continuous service delivery process, where the revenue produced in any given year was produced by the same year expenses to maintain the software. Thus, software expenses and revenues are mostly naturally aligned in a single tax year, and therefore software is not suitable for amortization.
• nodesocket 1y ago
  I’m a solo founder and sometimes outsource projects. How does that work if I pay a contractor a few thousand for a project? Are contractors allowed to be deducted fully at 100% expense?
• ivankelly 1y ago
  From the wording, it sounds like it applies to contracting non-US resident software development as well.
• _heimdall 1y ago
  > This [1] is the only definition the code actually give. Like most of our tax code, its overly complicated by unclear or incomplete codes. The IRS will give guidance with examples, but those examples are still incomplete. Ultimately our tax code always comes down to the filer doing whatever they (a) think they can get away with or (b) are willing to defend if they get audited.