The guidance in question can be found here: https://www.irs.gov/pub/irs-drop/n-23-63.pdf
There was previous discussion of these rules on HN here: https://www.hackerneue.com/item?id=35614313
To very briefly summarize, these rules force certain research expenses to be treated under Section 174 and thus capitalized and amortized over a period of 5 years, instead of under Section 162 (ordinary and necessary business expenses) which are immediately deducted in the year they occur.
Part of the issue is the extremely broad classification of "research expenses". Notably, it classifies virtually all software development as research, as well as the proportional share of all overhead/fringe expenses. It also changes the treatment of contracted research activities (note that includes software). This has a hugely negative impact for early-stage startups, contract research firms (i.e. SBIR companies), and independent software developers.
To construct a basic example:
Revenue: $100k
Expenses: $100k (developer salaries)
Net operating income: $0
Taxable income: $100k - 0.1x100k = $90k (first year deduction is 10% of SREs)
this all hinges on whether language in the tax code is interpreted one way or another.
Way #1: companies often try to claim many deductions on R&D expenditures, and the changed language makes it clear that all software development expenses can be claimed as R&D expenditure (which was not necessarily clear before).
Way #2: all software development expenses MUST be treated as R&D expenditures which requires claiming them as an amortized deduction (over 5 or 15 years depending on where they happen).
Neither the IRS nor Congress has clarified the intent of the change, and there are solid arguments for both interpretations. Way #2 is supported by the use of "shall" in the language used. Way #1 is supported by the fact that Way #2 is batshit crazy.
It seems that a lot of people are convinced that Way #2 is the intended one, despite its catastrophic implications for many software-based companies.
This change might not be as much an undue burden as it is a logical extension of tax principles applied across various industries. From this perspective, the software industry's ability to immediately expense these costs could be viewed by other sectors as an inequitable advantage, one that is now being corrected.
While the apprehension around these changes is understandable due to the added complexity and potential for increased tax liabilities, it's worth considering that some of the more intense reactions could be driven by a concerted effort from larger entities aiming to generate grassroots resistance against the new rules. It’s conceivable that the IRS, aware of the potential burden on smaller companies, might enforce these rules with a revenue threshold, thus sparing smaller enterprises from the need to capitalize software costs.
Moreover, it's crucial to recognize the benefits of capitalizing software expenses: it affords companies the opportunity to match tax deductions more closely with the productive life of the software. This can lead to a smoother tax liability schedule and cash flow, particularly advantageous for companies with consistent earnings and those that stand to gain from representing their software development efforts as capital assets on their balance sheets.
There are many instances where companies buy the team that created software rather than the software itself because so much of the value resides there. For obvious and good reasons, a company has no ability to claim a team as an asset because they have little control over its disposition since people are free to work when and where they want.
The continued erosion of enforceability of non-competition in employment contracts, which I agree with as a matter of policy, aggravates this situation in that the company has few levers to ensure that software development has asset-like characteristics. Large companies with many revenue producing software products can amortize the risk but the great many small shops with a single software product cannot.
I have to agree, because I don't agree with any of them :)
While the actual duration of software value is neither the day it was created nor "forever", the idea that a fixed amortization schedule is appropriate seems clearly wrong to me. Even crazier that it would depend on the geographic location of the person who did the work.
The productive life of any particular blob of source code is an awfully complicated thing to talk about, and the idea that the tax code should attempt to incorporate such a concept into a relatively simplistic rule (or pair of rules) seems faintly ludicrous to me.
The IRS does this all the time. Code isn’t some special magic enigma, businesses depreciate property, trucks, aircraft..all of these are equally as complex as code or significantly more complex to value over time. Usually it’s simplified to some degree for practicality, as I’m sure this will be.
So you think software development costs should not be capitalized, right? What makes you say that?
Also, the change to Sec 174 is related to R&D expenditures. This is also another aspect of trying to fit a multiheaded hydra into a small sphere: yes, some software development does share many similarities with R&D activities, but lots of software development does not (unless you label R&D in a way that is so broad as to encompass just about anything).
If the US wants to force amortization on software development expenses, I think that should be stated more explicitly, and with a much more detailed rationale. Just tacking it onto the "R&D" category really serves no-one very well at all.
Not true anymore, the IRS guidance linked above in Notice 2023-63 specifically indicates they are adopting interpretation #2:
"Section 5.03 - Activities that are treated as software development. Activities that are treated as software development for purposes of § 174 generally include but are not limited to:
(1) Planning the development of the computer software (or the upgrades and enhancements to such software), including identification and documentation of the software requirements;
(2) Designing the computer software (or the upgrades and enhancements to such software);
(3) Building a model of the computer software (or the upgrades and enhancements to such software);
(4) Writing source code and converting it to machine-readable code;
(5) Testing the computer software (or the upgrades and enhancements to such software) and making necessary modifications to address defects identified during testing, but only up until the point in time that:
(a) In the case of computer software developed for use by the taxpayer in its trade or business, the computer software is placed in service; and
(b) In the case of computer software developed for sale or licensing to others, technological feasibility has been established, product masters(s) have been produced, and the computer software is ready for sale or licensing to others; and
(6) In the case of computer software developed for sale or licensing to others (or the upgrades and enhancements to such software), production of the product master(s)."
The question remains open: is the intent that all software development expense MUST be treated an amortized capital investment, or that all software development (fitting the description above) CAN be treated in that way.
"(3) Software development. Section 13206(a) of the TCJA added new § 174(c)(3) to require that any amount paid or incurred in connection with the development of any software in taxable years beginning after December 31, 2021, be treated as a research or experimental expenditure (and thus an SRE expenditure to the extent paid or incurred by the taxpayer during the taxable year in connection with the taxpayer’s trade or business)."
and
".02 Requirement to capitalize and amortize SRE expenditures. Taxpayers are required to capitalize SRE expenditures (as defined in section 4.02(2) of this notice) and amortize such expenditures ratably over the applicable § 174 amortization period beginning with the midpoint of the taxable year in which such expenditures are paid or incurred."
Which is, as many have noted, absolutely batshit crazy.
The only scenario that remains unaffected by this absolutely batshit crazy SNAFU is the case of a self-employed software developer who incurs zero costs related to their work. They simply collect all revenue as salary, pay normal tax on it, and they are done.
Anyone with any expenditures at all (contractors, employees, equipment) must treat these as capital expenditures, amortized over 5 (or 15 years for foreign based work).
It really is as bad as it could possibly be.
Way #1.5: if a company chooses to take R&D expenditures of any type as a deduction (which it is not required to do) then it MUST include software development expenses (which in turns means they will be amortized).
there is no obligation to take a deduction. if you find yourself in a circumstance where its more favorable to not take a deduction then you don't have to report that transaction
What business does not deduct salaries from their income when reporting taxes?
I'm open to a counter-example where this makes sense.
If you do not chose to deduct R&D expenses, you can deduct software salaries as normal.
I personally think this makes a lot of sense.
i personally believe that the intended/appropriate interpretation is #1 - you MAY consider software development expense as R&D and include in an R&D deduction if you choose to take one.
but it is far from clear what was intended and/or how the IRS interprets it.
I'm sure this isn't the best tutorial on the topic but it gives you a taste: https://www.barandbench.com/columns/shall-shocked-the-use-of...
https://www.plainlanguage.gov/guidelines/conversational/shal...
Perhaps it can be can be made ambiguous in some context if you try hard enough, but that doesn't mean it commonly is so, or that it is here.
> I'm sure this isn't the best tutorial on the topic but it gives you a taste: https://www.barandbench.com/columns/shall-shocked-the-use-of...
Thanks, but the only thing that link gave me a taste for is terrible strawman arguments. (Or a severe lack of understanding of basic English.)
If you have "shall be" in a sentence, then that phrase is the verb of interest whose ambiguity (or lack thereof) you must examine, not the "shall" on its own. Claiming "shall" is ambiguous because it changes meaning when you put "be" after it makes no sense. It comes across as the kind of argument a first-grader would make.
They write: If the substitution rule is applied in the sentence: “The employee shall be reimbursed all expenses”, you would get: “The employee has a duty to be reimbursed all expenses”. This created ambiguity for the simple reason that the intent appeared to state an entitlement of the employee and not to impose a duty on the employee.
Do they lack common sense when reading this, or do they struggle with English? It's like claiming "I have a carrot" is somehow ambiguous because "I have been a carrot" means something entirely different. Does that sentence need disambiguation with "I possess a carrot" or "I have a carrot, but have not existed, as a carrot"? Are these serious arguments?
It also violates the fundamental rule that changing a sentence into the passive voice does not effect a semantic change.
"The employee shall be reimbursed [by the employer] for all expenses." must necessarily mean the same as "The employer shall reimburse the employee for all expenses."
But it's the same ambiguity, isn't it? Essentially whether "shall" creates an obligation for the taxpayer to claim it as R&D expense or an obligation for the IRS to accept it as R&D expense if the taxpayer so claims it, the equivalent of whether "shall" applies to the employee or the employer.
And in both cases the existence of the ambiguity is bolstered by the fact that the overly literal interpretation leads to a ridiculous result.
(I'm not saying it's good or bad, just passing on information.)
This means that you cannot, for example, pay yourself a salary and have that treated like the salary you would receive if, for example, you had chosen to be a builder or an artist or a massage therapist.
Another commenter here touched upon what I assume would be the justification for this: with software you spend Y years and C money to develop it, then you sit back and collect revenue, therefore the C money you put it at the beginning is a capital expenditure. But that's rarely the case with any software. Either it is a perennial, on-going process that never stops, or it ceases to be a revenue source. There are exceptions (especially since the dawn of mobile apps) but they are not the rule.
It's also not clear precisely what the difference is between working as a self-employed software developer and a self-employed architect is. They are not exactly the same, but why the former should not be able to take a regular salary from the revenue available, and the latter can doesn't seem clear, let alone equitable.
If anyone has actually thought about things this way, they seem to have a model in their mind that all software development is done following a process of "build first, sell later". This just isn't an accurate reflection of how a lot (most?) s/w development takes place.
If my salary is $80,000 and my expenses to survive are $70,000, I pay taxes on "$80,000 minus the weak sauce standard deduction."
If I'm a corporation and my revenue is $80,000 and my expenses are $70,000, I pay taxes on $10,000.
Not fair.
If corporations could be taxed on income without creating bad distortions, they probably would be. Even taxing profits creates a distortion (profits become double taxed as (1) profit and (2) dividends), leading to behavior like stock buy backs that wouldn’t exist otherwise.
But they are capped. Otherwise, many folks might get expensive things instead of paying taxes.
But the contracting work I've done (custom, one-off software) wouldn't make sense under #2, and I don't know how it actually works under this change.
Just like if Ford hires you to build a factory - the amount you pay the plumber is a regular expense, but the bill to Ford is for a capital asset.
Sure, but is revenue tied to work already done, or ongoing work? I.e. are you leveraging prior capital expenditure to realize current revenue, or are you in fact building new stuff right now (updates, features) that will generate right now (or at least, well within the 5/15 year amortization schedules) ?
The fact that the current work relies on earlier work is not in itself an argument that the earlier work was obvious done as a capital investment.
Another commenter alterted me to this guidance document from the IRS:
https://www.irs.gov/pub/irs-drop/n-23-63.pdf
This makes it absolutely clear that "Way #2" is the IRS interpretation of the law after the TCJA passed. That is, any software-development related expenditures MUST be treated as capital expenditure and be amortized over 5 years (or 15 for foreign based work). The document explicitly states that such expenditures CANNOT be treated as ordinary expenses under Section 162 (the section that would normally allow for business expense deductions).
Having read the whole document (which I should have done before), it is absolutely clear that this is totally batshit crazy.
Bear in mind that the way it is written all research and experimentation costs would be amortized. So if you have a chemist, biologist, physicist or even an engineer it plausibly is the case that if you are paying them to develop a new product that carries technical risk then their *salary* needs to be capitalized!
Good luck coming up with the cash to pay a tax bill on 90% of their annual salary. You can't even pull forward the depreciation if you abandon the research! Sure, it mostly stabilizes after about 6 years if your R&E budget is flat, but even in this case there is a huge cost in that you only get to deduct their salary in the far future. It is huge disincentive to developing anything new.
This is a total nightmare and cost many business like mine an absurd amount of money this year. Everyone just filed for extension in April assuming this insanity would be reversed before the late filing deadline... NOPE!
(NB: it is NOT necessarily tied to R&D, or the R&D tax credit. The calculation of this is subject to different rules.)
I don't even know how large companies found the cash to pay this bill. How can a biotech or software company whose annual expenses I'd guess are largely salary have had the money to pay taxes on 90% of their salary budget?
And if not, why would anyone push for this - unless your intention is to make sure no R&D happens inside the US.
Who's pushing for this?
Nov 2023 letter signed by Y Combinator, https://www.hackerneue.com/item?id=38145699
I don't know about other countries.
I haven't found anything credible on 'why' this was added, but...I'd hazard a cynical guess that it was put in as a way to reduce the apparent cost of the TCJA. You look for ways of raising revenue in your bill so you can claim it costs less. You do this do this even if you expect that (unpopular) change will be undone later.
A second possibility is that it was added to reduce the benefits of the R&D tax credit, which in fairness a lot of companies probably abuse.
Or at least they did.
Why would that not be a write-down as a result of impairment of a capitalized asset?
The law specifically does not permit this. You just can't deduct the expenditure except as over 60 months (and only 6 months in the first year)
Under the logic of this rule, a firm making a software product could invest money in software development, produce the necessary software, then get income from the software without further investment in software development.
In practice this is never the case; revenue gained from software needs to be met with further software development to maintain, update, secure, etc. the software. Firms that invest in capital often have large startup costs that go down as the firm becomes fully capitalized. Software development costs seldom go down, but instead expand with the firm's success. This is counter-evidence to the idea software is capital.
The software produced is also of unclear value and is not fungible. If a firm buys manufacturing equipment and the enterprise is unsuccessful they can sell the equipment. In the case of an unsuccessful enterprise the software almost always is of zero resulting value. Given these rules if a firm invests money in software development, makes some revenue, but ultimately doesn't create a sustainable enterprise, 100% (or more!) of the profits could go to taxes with no ability to recoup the overtaxing when the firm is dissolved.
Additionally, a firm buying durable goods will be able to buy those goods on credit, using the durable good as collateral. The tax laws encourage this process and amortization makes sense. Software cannot be produced on credit, and in practice can never be used as collateral on a loan.
And... if you have to write down an intangible asset you can... and that will reduce taxes accordingly. You can also get loans for intangible assets, use them as collateral, etc. I don't understand what you're saying about not producing software on credit-- of course you can produce it on credit like anything else. You can hire out a firm. Even if you hire a w2 dev you typically have 2 weeks to pay them for work done.
(But as I said, my comment is kind of made up)
0: https://www.journalofaccountancy.com/issues/2021/feb/tax-ben...
Comments can be with your name, company name, or anonymous.
There's no required info you need to give other than the comment, no account required. Submitting a comment takes 'time to write comment + 5 seconds' - it was very easy.
The comments have been open for 58 days, and they close in 20 days.
Side note: Which of our reps should we call about this, how do we find which rep applies to us, and how can we contact them and what to say? It'd be nice if someone made something like Resistbot for this.
(Though, after checking out the updated version of Resistbot, it seems like Resistbot will in fact work for this. https://resist.bot)
A regular single-member LLC, such as mine, is treated as one entity with its owner for tax purposes. The LLC's income is my income, and I just file a personal return for it. This can be bad because it puts you in a higher tax bracket.
An S Corp is a way around that. You have the LLC "pay" you a "wage," and you pay personal taxes on that, while the LLC pays whatever corporations have to pay.
But if your LLC does software, like mine, congratulations! You can only deduct 20% of that "wage."
I've been developing my software for years, and I am not done yet. I don't have revenue.
So if I went the S Corp route, I'd actually have to pay taxes on 0 revenue.
But as a regular LLC, my own work (as the owner) does not count as anything taxable, so I'm safe.
If you are going into freelance, perhaps as a consultant, keep this in mind. And do submit a comment.
Also, beware of accountants that will try to get you to do something that is not in your best interests. I had one or two try to encourage me to file as an S Corp, even though they admitted this could be a problem.
You'd only pay taxes if your revenue were more than your deductible payroll expenses (which as you say, you estimate to be 20% of your salary, which in an s-corp must be a "reasonable salary" for work performed).
There's no case where this law causes you pay tax on zero revenue. The problems require some revenue before they affect you, which might actually be another argument against it - you're disincentivized to create revenue from your early product if it's not going to be enough to cover your tax obligations.
The absolute worst case scenario would be having to pay taxes as if your revenue was nearly all profit - as if you had no expenses (or very few). As always, you only pay taxes on 'net income' - revenue minus expenses - this whole mess comes about by tweaking how expenses are calculated.
And that will be the case for me next year, so yes, this matters to me.
It is literally backbreaking for a friend who is self funding a team of engineers. The money to pay taxes literally doesnt exist. It was paid as salary.
I told him to ignore the accountants and simply not pay. Let the IRS come after him
For the short term (contracting) I'm simply working as a Sole Proprietor, but I don't really have much work or significant income yet.
If I may make one suggestion: even if you want to be a sole proprietor, look into getting an LLC.
If you run into trouble with a client, a properly-done LLC can save your house or other large assets.
With a sole proprietorship, all of your personal stuff can be on the hook too.
It's essentially the same advice as keeping separate devices for work and for personal use.
LLCs also generally aren’t useful for protecting you from creditors, because any lender will require you to give a personal guarantee.
If you are really worried about protecting your assets, you can purchase liability insurance.
> As a software developer you’re unlikely to be sued over anything that can’t be classified as personal negligence or malpractice.
Unlikely doesn't mean never. And a client's definition of negligence might also be malicious.
It is difficult for a company to successfully show that your LLC was at fault for some large dollar amount of damages, but that you the sole decision maker running that LLC, weren’t at fault through negligence or malpractice.
My point is not that you shouldn’t bother to protect yourself if you are worried about the risk, but that insurance, not an LLC is the best way to do it. By all means start an LLC too if you want.
The common advice of that every tiny business setup an LLC because it will save your house is wrong because it is only applicable to very specific circumstances that don’t apply to most sole proprietors. It’s also dangerous because most people that take this advice take it face value. Then they go online, start an LLC, and believe they are protected from all personal liability related to their business. When in fact they are protected from a very small fraction of likely potential liability.
An LLC can protect your personal assets from enforcement of contractual obligations. Say for example you agree to indemnify your client against patent infringement, and then through no fault of your own some of your code coincidentally happens to violate someone’s patent (and the patent holder finds out and successfully sues or settles with your client).
But don’t sign contracts like that in the first place. And it’s a good idea for contracts to have a clause allowing both parties to terminate the contract and to not make promises in your contract you can’t guarantee.
If money went from the LLC into a "wage," it changed "hands." The IRS wants in on that.
If work went from the owner into an LLC, no money changed hands, and the IRS doesn't care.
But the very fact that people do S Corps shows that there is different tax treatment though.
The benefits of S and C corps don’t really come into play with single member LLC
And yes, I know you don't have an S Corp. I was wondering how you would pay yourself from such a corporation, considering you have zero revenue.
When you have a single-member LLC, you take "distributions," which basically means you withdraw money from the company and put it into your personal account. It's technically a dividend.
I'm having a tough time understanding how there's money going out of an LLC without money first going in the LLC.
A single-member LLC and a single-member S-Corp are both essentially flow-through entities for a solo entrepreneur. However, they are ultimately taxed quite differently: with an S-Corp once you exceed the SSI threshold for the essentially mandatory portion of revenue you must repatriate to yourself as a salary, the remaining income can be repatriated as qualified dividend which is taxed at a significantly lower rate than directly passed-through income. With an LLC, it's all self-employment income subject to regular income taxation, meaning that in any realistic scenario, you're paying a higher effective tax rate with the solo LLC form.
So if I went the S Corp route, I'd actually have to pay taxes on 0 revenue.
This is false. The income tax on $0 revenue (meaning no revenue, not no profits) is the same: $0. (Note, however, that many states have "fees" assessed on business entities like S-Corps and LLCs, even single-member LLCs, and in such cases a minimum fee is owed regardless of revenue.)
But as a regular LLC, my own work (as the owner) does not count as anything taxable, so I'm safe.
This is also false. The work you provide to the entity as an owner is still an R&D expenditure. The difference is that with the S-Corp, the expenditure cost is clearly documented, while with the LLC you're pretending that the number is $0 and gambling on not getting audited. This only matters once you start generating revenue...
Either way, not all of your salary would be subject to capitalization. If you have revenue, you clearly spent at least some time and work on marketing and business development, and expenses for those non-R&D activities are not capitalized.
With the S-Corp, your salary offsets up to [your salary assigned to non-R&D tasks less 1/10 [see note] of your current-year salary assigned to R&D plus carried-over capitalization from R&D from prior years] in revenue each year, and after an appropriate amount of salary (generally the SSI contribution threshold for the year) the rest of that annual revenue can be repatriated to yourself as a dividend at lower tax rates. With the LLC form, since you aren't paying yourself a salary, you owe tax on 100% of the revenue arising from the software you develop without any deductions.
TLDR: If you actually care about tax, S-Corps are almost always the better option for the solo entrepreneur, and they're still the better option here.
NOTE: Capitalization is on a mid-year convention, so the first and last year you only capitalize 1/10th of the cost; and in the middle 4 years you capitalize 1/5th of the cost. So, for Y2, if you paid yourself $100 in salary both years, your total capitalization deduction would be $30: $10 capitalization for the Y2 salary and $20 for Y1 capitalization.
So if the IRS audits me, they'll say that my work is worth something and therefore, I have to pay taxes on it?
Sounds awful.
But I and the accountants I talked to don't think that's the case.
Also, I'm not going to take R&D credits, nor claim deductions from salary, so why would they care?
And I did the math: yes, an S Corp is technically better. But at the revenue levels I plan on seeing, the difference isn't that much (a few thousand), and any revenue gets taxed right away, which is more convenient for me. I'll take that instead of complicating my taxes.
Well, no...since you're not claiming to be making any revenue from that work, it doesn't matter. Whether you deduct 100% or 20% of your salary from $0 business income you still have $0 of taxable business income (and as an individual you don't get NOL carryovers so that amount is lost to you forever).
In fact, in the event of an audit, you'd likely get a refund since the IRS would determine that you're incorrectly calculating your tax liability by failing to capitalize your R&D expenditure (i.e., your flow-through revenue which is entirely treated as self-employment income). But, because this error affects other years' returns, which means that a one-return audit can turn into a multi-return audit. It also means you get put on a very special list of taxpayers subject to increased scrutiny (meaning, significantly more likely to be audited again in a future year).
But at the revenue levels I plan on seeing, the difference isn't that much (a few thousand), and any revenue gets taxed right away, which is more convenient for me. I'll take that instead of complicating my taxes.
Yes, the LLC is much simpler when it's a disregarded (single-owner flow-through) entity. But it's more complicated once you add other members or any employees. And as you've pointed out, you're already paying more in taxes.
My issue isn't with you choosing to use the LLC form because it's simpler, my issue is with you claiming that it's better for tax purposes on a numerical basis when it is clearly not.
The problem is, as this whole comment section shows, is that is it not clear.
Because it isn't, I decided to go with the simpler option because I don't plan on having employees.
When this rule was changed, it was framed as eliminating a tax loophole: R&D work is basically a capital investment, since you are effectively buying and improving intellectual property during the R&D process. That suggests that this sort of expense really is a capex that should be depreciated over the life of the intellectual property rather than an opex. I personally think that this is a compelling line of reasoning.
I think there's a good argument that a forced 5-year amortization schedule is far too long for something like a random SaaS, but I'm not sure if I have a good argument that this is bad accounting otherwise. I don't expect that the IRS will be all that sympathetic to Silicon Valley complaining that one of their favorite loopholes is gone otherwise.
There is also an accounting and tax principle that small/solo businesses should be able to maintain simpler books that let them reliably feed their families year-to-year; an sudden upfront tax burden for a solo dev impedes that.
If you make a spam filter, you have to spend resources making sure it can defeat the spammers, but the lifetime of your countermeasures is often measured in months or weeks rather than years.
You may have to pay developers to integrate your product with a third party product, but there is a new version of the third party product released every year so every year you have to do it over again.
> There is also an accounting and tax principle that small/solo businesses should be able to maintain simpler books that let them reliably feed their families year-to-year; an sudden upfront tax burden for a solo dev impedes that.
And the correct accounting period to amortize a particular expenditure may not be known in advance. If you build a product and it has unanticipated flaws that require you to start over, the lifetime of the original R&D is trivial. Or it could be a success and generate revenue for decades.
The IRS gets their money either way, whether it's now or tomorrow, but if in cases of ambiguity they insist on now, the disadvantage is primarily to early startups. Large corporations with a stable R&D budget will be deducting their full R&D expense every year because they'll have R&D expenses from five years ago to deduct this year, but anyone just starting out won't. That's a poor choice as a matter of policy.
In 2022 our reported "taxable income" to the IRS skyrocketed because of this rule change. Despite a small profit, we are paying tax on essentially 50% or more of our REVENUE. And because we are a pass-through entity, it pushes us into tax brackets that are quite ae bit higher than corporate tax rates of C-Corps.
2 or 3 years into this we will either have to take a loan to pay taxes, find a way to cut expenses, or (hopefully) grow enough in revenue while not increasing expenses to cover the additional tax.
It really is insanity. Our accounting firm and everyone they spoke with was convinced it would be "fixed" by congress before the final extension deadline a couple months ago. So we waited to the last minute to file, which, of course, resulted in significant late fees and interest on top of everything else.
I like to use the factory analogy - if you're Ford, and you build a big factory to build cars, that's a capital asset, you need to amortize the costs. But the workers inside, making each car? Their wages are expenses, tracked against the revenue of the cars they make. So - if you make a game engine, that'll be used over the next decade or two, that's a capital asset. If you make a game, that'll see 95% of its revenue in the first year, you should be able to expenses the costs (including salaries) of making it.
(2) If you analysis held at all you could pull forward the deprecation if you abandon the research, which might be viewed like disposing of the asset. You cannot do this under this law.
(3) This increases the total cost of R&E work substantially. It is a disincentive to innovation.
See also my other post above.
Maybe it's not concrete, but it feels like there's a difference between investing capex into a planned future product, and retaining some rights in the work you create for others.
If you disagree, I'm curious what you think about this: if the software you develop is all open source would you still call it a capital investment? Maybe it could be classified as a charitable contribution?
That would make sense if I was a consultant, or working for a consultancy, and billing someone else for those hours. As a full time salaried employee, time tracking is just a pain in my ass.
To make things worse, I believe that few, if any, companies doing this time tracking are doing it with any amount of rigor. If an auditor really wanted to check, they would find that the claimed capitalized expenses are overinflated, and are technically tax fraud.
Just remove the rule altogether. A company paying a wage to a software engineer shouldn't be taxed any differently than any other kind of employee.
In most other industries, product development is capitalized and amortized over the life of the product for tax purposes. It requires lots of estimation and log-keeping (X% spent on develpoment, 100-X% spent on maintenance). Which is exactly what your employer is doing... taxing you just like every other kind of employee.
The change just removed the specific loophole for software.
I've read through a number of the comments, and I guess I shouldn't be too surprised to see that most are asking the IRS to do the job of the US Congress. This fills me with despair.
I really wonder how long this can go on. Our system of checks-and-balances only works when rational actors believe that compromise is necessary to get things done. When you have actors that believe that shutting things down completely is a benefit because it gets them more media time and rabid followers, the whole thing breaks down. Perhaps at some point we'll be able to move more towards a Westminster parliamentary model, where the party in power at any particular time basically controls both the executive and legislative branches simultaneously.
This for me always been one of the most frightening aspects of the parliamentary model. There aren't checks and balances, instead the party in power, as long as they have enough power can rule with absolute authority.
You fail to understand that the US constitution was not created to provide for an efficient government it was designed to protect individual rights.
The much bigger problem in my mind is that we only have 435 representatives and so each congressman represents far too many people, which allows the loudest and craziest vocies to dominate. Instead if we doubled or tripled the size of congress we'd have quite a bit more nuance and the government would be more representative.
In fact, I'd argue that a parliamentary government has a greater chance to fall into dysfunction in some cases. Just look at the Israeli Knesset before the war.
Before that, your governor would choose who the senator was via whatever the process the state had for this. It had a knockoff effect of people caring a lot more about their state and local politics and keeping some governing power in the states leadership. Both I sincerely believe were worthwhile goals, as many people get caught up in federal politics and there is far less population participation in state / local politics as a result.
I do believe quite strongly that we need a bigger House of Representatives too. I 100% agree on that. I don’t think the founders foresaw a world with 300 million people living in the US
Take your BS condescending tone elsewhere. I don't "fail to understand" anything. There are plenty of other nations with parliamentary systems that protect individual rights just fine, arguably much better than the US does.
> There aren't checks and balances, instead the party in power, as long as they have enough power can rule with absolute authority.
Except, again, plenty of functioning governments with parliamentary systems show that if a government overreaches, they are still responsible to the will of the voters, who can (and do) kick them out at the next election. I think it's much better to say "OK party X, we'll try your ideas for the next few years, and if you f it up you're gone." rather than have nothing get done for years, where each side can blame the problems on the other for why they couldn't achieve their agenda.
Try telling that to Belgium, which took just short of a year to even form a government, or to Liz Truss in the UK, if we're going to compare it with another country with a FPTP election system.
It actually tends to result in the opposite of that, the executive is relatively neutered, because they know they can be dismissed at the pleasure and whims of parliament.
The American executive gets to be comparatively authoritarian, as once you elect a president they're guaranteed to be able to enact their executive agenda for the next 4 years (the theoretical threat of impeachment being a non-issue in practice).
Exactly. A far greater proportion of countries that elect a President based on the American democratic model have devolved into dictatorships, than have countries with parliamentary systems.
Can you name another nation where people have as strong a right to free speech as the US, let alone as much of a right to bear arms?
it just means government didn't manage to overreach far enough. Countries like Russia and China also have parliaments, its just happen that ruling party obtain monopoly on violence which they apply on any possible competitor.
You can sign the letter and send it to your representative here:
https://ssballiance.org/
Please do submit comments.
The amortization guidelines basically come from old-school packaged software and waterfall development cycles, where software was first built, and then it was a "finished product", and then it was shipped to end users. In a SaaS world, where CI/CD is commonplace and things like A/B testing are everywhere, and it's basically impossible to distinguish "new development" from "maintenance", the whole capex vs. opex for modern software companies is a total joke that can easily be gamed in either direction. For example, I previously worked for an e-commerce company that wanted us to categorize as much dev time as possible as CapEx, because it made our bottom line look better. The whole thing was a total sham, and it's not that the company was at fault, but it's that the accounting guidelines think, wrongly, that software development for most web companies can be neatly divided into "research and development" vs. "maint", and that is just absolutely not possible given how devs at most companies work.
Unless it's basically "shrink-wrapped" software, which largely doesn't exist anymore, software that is delivered by a company that provides that product online and continuously improves/monitors it (i.e. basically all SaaS companies), all software dev should be treated as OpEx, period. Anything else is just a silly game that doesn't reflect reality. The only possibility I can see arguing for CapEx treatment is when there is dev before any product actually has been made available yet.
You sure about that? If code written 3 years ago is still in production, that's not an operating expense, that's a capital expense. Kind of by definition. In a mature product, you'd expect expenses to shift to opex. But adding features and improvements are all classic capex. Just like any other industry.
Except every commercial operating system, any enterprise network or security appliance (physical or virtual), software for hardware (firmware, drivers), or pretty much any other software that isn't implicitly on or connected to the internet.
A few companies who might find this tax paradigm beneficial come to mind: Microsoft, Apple, IBM, Cisco, Intel, NVIDIA... Just to name a few.
I generally agree with the overall sentiment; except the ways in which software is being built and delivered is changing by expansion, but not necessarily changing by replacement.
Aside from “it’s bad for my startup”
And then the devs do the "Well uh, it is, but we still uh, consume...uh...apis...endpoints... umm yeah it's not retired. Hank the ancient that now does dev finance built what we're using, we should get his help" And then hank gets on the phone with a sigh and fixes it.
I initially thought this was something exclusive to where I've worked, but after some years it seems to be true more frequently than I'm comfortable. When it's really bad you realize the entire company was built by Hank and maybe one other dude who got laid off and everybody else has just been making bootstrap wrappers of their tool for 15 years between the bare minimum to keep the servers compliant.
When I meet a software engineer that gives me the impression they're an engineer and not their clan's webmaster, it's kind of a cool day.
all far, far older than 5 years.
Most of the development effort for such things happened in the past 5 years? That sounds unlikely.
Expansions and improvements would generally be capitalized.
The incentive is to write software that is immediately profitable, and investing in long term projects becomes more costly.
Sure, there's been maintenance over the years, one significant version update (TeX 3.0 in 1990) and an ever-evolving ecosystem around it, but the core engine has been incredibly stable.
I have several projects running in prod, at several companies, for over a decade. They are easy to maintain, easy to extend and build on, and easy to understand.
The problem is that "at some point" can drag for decades and do a lot of damage (ie transform the economy and not in a deliberate manner.)
The only factor I usually hear about is raised interest rates.
https://www.adp.com/resources/articles-and-insights/articles...
This looks like an attempt to reduce that second part without touching the first, right? So effectively an administrative action to reduce the R&D tax credit passed by the Congress a while back?
However, in some cases people contribute software to open source projects that are not only Libre but also "Free as in Beer". Sometimes they get donations or grants to work on such projects. Heck, they might even have a contract from a company that uses this free-as-in-beer software, but, once the contributions are made, the code is free for everyone to take.
In this model, there is explicitly no forward looking profit to be had. All parties contractually agree that the value of the work, after it is done, is $0.
In this case I don't see how it would even make sense then to amortize donations/grants/contract money on a 5-year schedule when the asset value of the deliverable is $0?
I would think in this case that the person doing the development is providing a bona-fide "service industry" activity, and not doing an R&D activity. Thus the wages of that person should be as deductible as any other service-industry worker: There is as much expectation for future profits from writing this code as the person painting your house has future expectations of profits from the higher resale value of your place because of the improved paint job.
So at least for individuals being paid to work on free-to-download code, the entity paying you to do the coding may have to write off your contract as an R&D expense, but the individual contractor should still be able to depreciate that payment as a wage within the tax year because they are providing "coding services", and not doing R&D.
This logic has precedent if you consider how capital assets work. Let's say a shop purchases a donut machine. The purchaser of the donut machine has to depreciate that purchase over several years. However, the individuals who were paid to assemble the donut machine are paid wages as factory labor, and their expenses are deducted by the donut machine marker that tax year.
In this case the donut shop is whoever is paying you to write the code, and the coding contractor is the donut machine assembly technician. So long as the donut assembly technician doesn't have a stake in the donut shop's future-looking profits, I think it's quite clear who is providing a service and who owns a capital asset.
I think this logic would also mean that individual contractors who work on proprietary, for-profit code bases but assign all value of their work product immediately to the contracting body would also be a service provider and thus can depreciate their own wages within the tax year. But, the example is not as clear-cut as a work product that explicitly has a $0 expected market value.
> "However, even if the research provider does not bear financial risk under the terms of the contract with the research recipient, if the research provider has a right to use any resulting SRE product ... costs paid or incurred by the research provider that are incident to the SRE activities performed by the research provider under the contract are SRE expenditures of the research provider for which no deduction is allowed ..."
Thus, the rule as written would make it such that contractors who write Windows drivers could deduct their expenses (as they would have no rights to Windows), but contractors who write Linux drivers may not (as they would have some rights to Linux).
In effect, the tax rules would explicitly double-tax open source software development, due to its over-broad test of whether you could have any right to the code base you've written, irrespective of whether the code you wrote actually has any practical residual value to the author.
4.03(2)(d)
> Cost to input content into a website.
Listed as an excluded cost (not SRE).
So… if hypothetically my IDE is in a browser, and I spend my whole day coding there, I’m just inputting content into a website, aren’t I?
How about an Electron app?
Now academic research needs to consult on tax implications and have some set aside.
Congressional staff are required to keep tabs on everyone who calls in about an issue, so your time is well-spent.
The November 17 continuing resolution is our best chance to get this fixed, but only if enough members of Congress hear from their constituents about it!
Yeah, but that doesn't make it unfair, no? The whole "develop it today, pay taxes on it later" effect SaaS used to have was just a loophole software enjoyed for a long time. Developing anything is investment, and tax code generally requires that to be amortized so you can't deduct it all year 1. Congress just closed the loophole for software.
Does an R&D classification give different tax accounting options at least for the salary part?
If so, does this still apply to companies operating on a cash basis?
And idea is that your deductions you lost here will be applied in next 5 years.
It is likely that they do not approve the majority of comments, I submitted one but it has not yet been approved.
If hiring engineers in California required you to declare your global profits in California, companies would prefer to hire engineers in another state or another country that doesn't do that, so tax authorities aren't willing to say that's required because of what it would do to the local labor market. But if they don't say that then companies declare their profits in Puerto Rico or Ireland.
You can't have it both ways. Governments have to choose what they actually want to tax, and then take the consequences of companies avoiding doing that in their jurisdiction.
It might matter if you buy finished software modules and integrate and resell them.