Is Software Development Tax Deductible? OBBBA Restored Expensing — What Changed in 2025

I went down a tax code rabbit hole last month, and honestly I didn’t expect to come back excited. The question was simple: is software development tax deductible? I kept getting conflicting answers online, the same way people juggling savings accounts in different countries run into confusion over the tax on interest income. Half of what ranks says the answer changed with the 2017 tax bill and that’s it, story over, no restoration legislation passed.

Except that’s stale. The One, Big, Beautiful Bill (OBBB) restored immediate expensing for domestic research costs starting 2025, and a lot of the top results still haven’t caught up.

So here’s the corrected 2026 picture, and it’s actually a two-track story. Track one is the deduction, and it’s governed by IRC Section 174: do you write off dev costs this year, or spread them over years? Track two is the R&D credit under IRC Section 41, the Credit for Increasing Research Activities, which is a completely separate mechanism. The credit is a dollar-for-dollar reduction of federal tax owed, it covers commercial products and the internal tooling you build for yourself, it carries forward up to 20 years if you owe no tax, and it’s been permanent since the PATH Act of 2015 after existing as a temporary credit since 1981.

This isn’t a gimmick that vanishes next year. The deduction answers “when can I write it off.” The credit answers can I get money back even before I turn a profit. Most articles answering this question are only running one of those tracks, and a lot of them are running it with last year’s map.

The direct answer: deductible, but the timing rules decide when

Yes, software development costs are deductible as a business expense. What Section 174 controls is timing: do you deduct them the year you spend the money, or capitalize and amortize them over time? Since 2022, the Tax Cuts and Jobs Act regime has required R&E expenditures, software development included, to be amortized over 5 years for domestic work and 15 years for foreign work. Before 2022, these costs were simply deducted in the year incurred, which is why older content (and older threads, and older advice) sounds so different. The One, Big, Beautiful Bill restored immediate expensing for domestic Section 174 costs starting 2025, while foreign costs stay on the 15-year schedule.

Here’s the part that trips people up: these two tracks don’t cancel each other. Costs sitting in an amortization schedule can still generate R&D credits in the year they’re incurred. But the cash flow changes. A dollar you’d have deducted immediately is now trickling back over five years, and the credit, while real, isn’t a promise that it offsets the full deferral. So the honest answer is: yes, deductible, and the timing rules, elections, and your credit position together decide how much lands when.

Section 174: expensing vs. amortizing, and what OBBBA changed

Section 174 is the rule that, since 2022, has required R&E expenditures including software development to be capitalized and amortized rather than deducted as you go: 5 years for domestic costs, 15 for foreign. Before the TCJA took effect on this front, you deducted these costs in the year you incurred them. That’s the whole before/after contrast, and it’s why a 2021 return and a 2023 return treat identical engineering spend completely differently.

Yes, the One, Big, Beautiful Bill restored immediate expensing for domestic Section 174 R&E costs. Starting 2025, domestic R&E costs (including software development) can be expensed in the year they’re incurred again. Foreign costs remain on 15-year amortization, and that asymmetry matters if your team is distributed: the same commit can hit the books differently depending on where the work was performed.

The three OBBBA transition elections

What about the 2022, 2023, and 2024 costs you already amortized? You’ve got three paths for the unamortized domestic remainder:

• Deduct it all immediately in 2025.
• Deduct it ratably over 2025 and 2026.
• If you’re a small business taxpayer, defined as under $31 million in gross receipts per Section 448(c) and not a tax shelter, amend your 2022-2024 returns to remove the domestic R&D capitalization entirely.

Red flag: If your 2022-2024 returns show strange amortization schedules, don’t assume preparer error — correct application of the old TCJA rules looks exactly like that.

One pattern tax preparers reported seeing over and over: founders convinced their 2022-2024 amortization schedules were preparer errors, when the preparer had actually applied the TCJA rules correctly. The math looked weird because the law was weird.

Should you expense or amortize in 2025?

That depends on your elections, your loss position, and how the choice interacts with your credit and other provisions. There’s no universal answer, which is exactly why the closing advice of this whole article is: model the numbers before picking an option. It’s the same instinct as benchmarking before a rewrite. Don’t guess at the fast path; measure it.

Freelance developers and MVP spend under Section 174

Contractor development payments count toward the R&D credit at 65 cents on the dollar, but the payments themselves must now be capitalized under Section 174, and your deductions don’t start until the asset is placed in service. That’s the answer, and it’s a two-sided one: the credit survives, the deduction timing doesn’t.

The classic setup: a tech startup founder asks a CPA about the Section 174 treatment of MVP development spend, the minimum viable product, that first stripped-down version of the software you build to test whether the idea works. Small team, hiring freelance developers through Upwork or Fiverr, booking it all as ordinary labor like they did in years past. Then at filing they discover it’s a capitalized cost, and deductions only begin when the thing actually ships. That was the gut-punch for bootstrappers when the TCJA rules kicked in.

Two honest reassurances here. First, pre-revenue companies in heavy development usually don’t have much revenue, so large capitalized costs rarely create a big tax liability. The scary scenario mostly doesn’t apply to you yet. Second, not everything on the invoice is development spend: maintenance and installation costs for purchased software don’t necessarily count as development costs, and anything built or upgraded with major costs has to be treated as an asset.

Big builds are assets now. Deal with it, but with a CPA helping, not alone.

What software work qualifies: broader than most companies assume

Okay, this is the “wait, really?” section, because the list of qualifying work is wider than almost anyone expects. Three facts up front: incremental improvements qualify, the software only needs to be new to your company (not new to the world), and a failed project doesn’t disqualify you. Failed experiments still count. Qualification hinges on technical uncertainty and systematic experimentation, not on whether the thing shipped and worked.

The buckets, roughly:

• Product and engineering. New software architectures, AI/ML models, mobile apps, IoT firmware prototyping, SaaS features that force you to actually solve multi-tenancy, access control, or performance problems. The gnarly problems count, not the CRUD screens.
• Infrastructure and DevOps. Cloud migration, CI/CD pipeline design, automated testing frameworks, performance optimization. Plenty of teams mid-migration right now don’t realize that work can qualify.
• Security and integration. Cybersecurity engineering, custom API integrations, large-scale analytics data platforms.

And here’s the one that makes cloud-native teams sit up: cloud computing costs feed the QRE bucket. I’ll explain the math in the calculation section, but yes, your infrastructure bill can feed a credit.

Whether routine-looking work qualifies hinges on the four-part test, which is the next section. Hold that thought.

The four-part test: how the IRS decides if your project qualifies

Your software project qualifies for the R&D tax credit four-part test if all four prongs pass for each business component, permitted purpose, technological in nature, eliminating uncertainty, and process of experimentation. The R&D tax credit for software development applies per business component, meaning each version or module gets evaluated on its own. You qualify at the feature level, not the company level. There’s no partial credit, think CI pipeline: one failing check and the build doesn’t ship. And heads up: eliminating uncertainty and the process of experimentation get the most IRS scrutiny, so that’s where your documentation matters most.

The counterintuitive part, and the reason this section exists: “did it work?” is irrelevant. A CI/CD redesign that hit real unknowns can qualify while a no-uncertainty feature cannot. Also note the per-component evaluation isn’t just trivia; it becomes literal reporting in 2026, which we’ll get to in the documentation section.

Permitted Purpose

The work has to relate to a new or improved business component, targeting quality, function, reliability, or performance. In one breath: you’re making the thing actually better, measurably, for your product or your tooling. Both count.

Technological in Nature

The work relies on hard-science principles: computer science, engineering, and the like. For anyone reading a dev blog, this prong is basically free. And the techniques only need to be new to you, even if similar solutions exist elsewhere. Reinventing a wheel your company hasn’t built yet still counts.

Eliminating Uncertainty

This is the prong where the IRS leans in hardest. The uncertainty has to be technical, in methodology, capability, or design. Engineering unknowns count; market unknowns don’t. “Will customers like it” is a product question, not a research question. This is where audits get spicy, so keep receipts.

Process of Experimentation

You evaluated alternatives by prototyping, simulating, modeling, or running a systematic trial-and-error process. Which is just… how devs already work. If you’ve ever A/B’d two implementations or thrown out a prototype, you’ve done this prong.

Since uncertainty and experimentation draw the most scrutiny, those are the two your documentation should be loudest about.

Internal use vs. external use software: the HTI test hurdle

Here’s the fork that decides how hard your claim is: software you sell, lease, or license to third parties faces only the standard four-part test. Software built for internal use, the HR portal, the accounting tool, the customer support dashboard, has to pass that test plus the high threshold of innovation (HTI) test. Bonus boss fight.

Internal-use software covers the boring-but-necessary admin builds: HR, accounting, financial reporting, customer support. For those, HTI has three parts. The software has to be innovative, carry significant economic risk, and lack a commercially available equivalent without substantial modification. “Significant economic risk” in plain English: you committed real resources and genuinely weren’t sure you’d recoup the investment within a reasonable time. The practical gut-check questions are exactly what you’d expect: could you realistically recoup the build cost in a reasonable time, and does a vendor already sell this?

The guidance document is TD 9786, name it like you’d link the relevant RFC, and know that the IRS has increased scrutiny of internal-use claims. That’s a keep-your-docs-tight warning, not a reason to avoid claiming writing off dev costs is legitimate when you follow the actual rules rather than the crowd’s myths. Mixed internal/external software is the hybrid case where you should slow down and classify carefully. There’s a fuller breakdown in our piece on internal use software R&D credit rules.

What doesn’t qualify: the exclusions, and the line that decides them

The exclusion list, straight up: social science and humanities research, market surveys, work performed outside the U.S. (this one bites distributed teams), research someone else funded, routine upkeep and bug fixing, rolling out off-the-shelf software, and cosmetic tweaks. The full list lives in the IRS Form 6765 instructions.

Now the reframe, because the list alone misleads people. The dividing line isn’t activity type; it’s technical uncertainty. The same bug fix can qualify or not depending on whether an unknown existed going in. Treadmill work doesn’t count.

Climbing work does. From the outside, your sprint might look like maintenance or research. Doesn’t matter. What matters is whether you were eliminating a technical unknown.

Quick test: Before classifying any sprint task, ask whether a technical unknown existed going in. If yes, it may qualify; if it was routine execution, it likely doesn’t.

How the R&D credit is calculated: QREs, the regular method, and the ASC

The ASC, the Alternative Simplified Credit, is 14% of qualified research expenses (QREs) exceeding 50% of your prior three-year average QREs; if you had no QREs in the prior three years, it’s 6% of current-year QREs. Most companies pick this method, and once you see the alternative you’ll understand why.

What counts as a QRE

Four buckets: employee wages for qualified research, supplies, rental/lease cost of computers (yes, that’s your cloud computing bill), and 65% of contract research. Say the haircut explicitly: contractor work counts at 65 cents on the dollar, not 100. And because developer salaries are QREs, a huge chunk of a software team’s costs feed the credit. Your payroll is doing double duty.

The regular method (and why most people skip it)

The regular credit takes 20% of QREs that exceed a base amount, where the base can’t exceed 50% of your QREs. The weird part: the fixed-base percentage is derived from your 1984-1988 QREs versus gross receipts, capped at 16%. Yes, the formula is anchored to the Reagan era. It’s weird.

Startups formed after 1988 use a flat 3% rate during their first five tax years, which softens the absurdity but doesn’t make the method appealing. One more catch: the computed credit counts as income unless you elect the reduced credit, so there’s a trade-off checkbox there too. Most companies take the ASC, it’s the sane default for deducting software development costs on your taxes, the same way you pick boring tech that works.

The five-year ASC example

Here’s a worked example showing what the incremental design does:

Look at year 4. Credit more than doubles even though QREs only grew by a third. That’s the incremental design kicking in: once your current QREs exceed 50% of your three-year average, the full 14% applies to the excess. This is a growth subsidy, not a rebate. The system pays you for doing more R&D year over year; flat QREs earn almost nothing.

To estimate your own numbers, KBKG’s R&D Tax Credit Calculator is a plug-in-your-numbers tool. And remember the frame from the top: the credit reduces federal tax owed on a one-to-one basis, and if no tax is owed it carries forward up to 20 years. Not a use-it-or-lose-it situation.

Startups and unprofitable companies: the credit works before profitability

Yes: qualified small businesses can apply up to $500,000 per year of R&D credits against the employer’s portion of FICA taxes. That’s real money against payroll you’re already paying, before profitability, which is genuinely rare in tax land. Eligibility is $5 million or less in gross receipts and five years or less of company history, and the cap was raised from $250,000 by the Inflation Reduction Act of 2022.

The FICA offset

This is the mechanism that makes pre-revenue founders actually care. You’re paying employer payroll taxes on your engineers anyway; the credit offsets up to $500K of that per year. It hits your actual cash position, not some future tax bill you may never have.

AMT, lookback, and who signs which form

Second win: the PATH Act of 2015 made the credit permanent and let eligible small businesses, under $50 million in average gross receipts over three prior years, offset the AMT, the Alternative Minimum Tax, the parallel tax calculation designed to ensure high-income filers pay a minimum amount, too. Before that, the AMT limitation kept the credit out of reach for a lot of smaller companies; after PATH, it stopped being a big-corp-only perk.

Third: the lookback. The ASC can be claimed on open tax years, typically the last three plus the current one, via amended returns. You can go back and grab credits you missed. Entity mechanics are simple: C corps claim it on the business return, S corp shareholders and partners claim it on their individual returns, and Form 6765 does the calculation in all cases.

Many states offer their own R&D credits on top of the federal one, some refundable, with criteria and amounts that differ from federal, so check whether a second credit is sitting there. KBKG’s Payroll Tax Credit Calculator estimates the startup payroll offset specifically.

Book vs. tax: why a book loss can still mean taxable income

GAAP and the tax code classify software costs differently, and that gap produces the strangest outcome in this whole topic. ASC 985-20 governs external-use software: costs are expensed until technological feasibility, then capitalized until general release. ASC 350-40 governs internal-use software: expensed until the preliminary project stage completes, capitalized until it’s ready for its intended use. Capitalized costs amortize over their useful life.

The practitioner insight, stated plainly: your books can show a loss while your return shows taxable income from capitalized development costs. You can be losing money and still owe tax, which feels cursed. It’s not an accounting error; it’s a structural timing mismatch. The standards switch at milestones, like build pipeline stages: the same dollar is an expense before the milestone and an asset after, and the tax code runs its own pipeline on its own schedule.

Counterweight, same as the MVP section: pre-revenue companies in heavy development usually have little revenue, so big capitalized costs rarely create a large liability. The cursed scenario mostly hits companies with actual income colliding with capitalized spend.

Documentation, Form 6765 Section G, and the audit window

The IRS expects contemporaneous records: written at the time, not reconstructed later. And here’s the delightful part for this audience: your git history is literally tax documentation. Commit logs count as evidence. The version control you were doing anyway turns out to be the substantiation.

The required records: payroll with time allocation, project descriptions with technical objectives, commit logs, and records of the uncertainties you addressed. Log the hard parts; that’s what auditors read. Alongside that, you need to analyze development versus maintenance work, technological feasibility, domestic versus foreign work location, and contractor cost basis, with consistent processes year over year.

What Section G is phasing in

Beginning tax year 2025, Form 6765 Section G requires filers to classify the type of software development at filing. Per the December 2025 instructions, project-level business component reporting becomes mandatory for tax years beginning in 2026 for most filers. Given the four-part test evaluates at the feature level, that per-project granularity is where the reporting was always headed; now it’s on the form. So per-project documentation isn’t optional anymore.

The window cuts both ways

IRC Section 6501 gives the IRS three years generally, six for substantial understatement, to examine a return. Here’s the paired insight most articles skip: the lookback opportunity and the audit exposure are the same window. Amended returns to grab missed credits also reopen years to examination. Your claim isn’t done when you file; keep the docs around.

AI-written code and the substantiation gap

Yes, AI-generated code can qualify for the R&D credit in principle. But the claim stands or falls on proving what was built, on which project, at what cost, regardless of who or what wrote the code. That’s the whole ballgame.

Scale context, properly attributed: more than 30% of new code at Google is AI-generated, per Sundar Pichai on Alphabet’s Q1 2025 earnings call, and Satya Nadella said in April 2025 that 20-30% of code in Microsoft repositories is AI-generated. Meanwhile annual corporate R&D credit claims exceed $32 billion per IRS Statistics of Income. A big pot, a lot of people dipping into it, and an increasingly machine-written set of work inside it.

The problem is substantiation, and it’s structural. The same AI accounts that write code also summarize meetings and look up the weather; sweeping every AI dollar into a claim is indefensible. And the old evidence pipeline doesn’t compile here: interviews, questionnaires, and manager estimates can’t substantiate machine-written code. You can’t interview an AI.

Taylor Meadows, CPA, said it straight: “The IRS does not care whether a person or an agent wrote the code. It asks you to prove what was built, on which project, and at what cost.” And per the CodeROI executives, generative AI excels at creating things and is precisely the wrong tool for record keeping. Anna Meadows framed the gap as companies creating value faster than they’re creating evidence, with the claim that this gap now closes: “The AI does the work, and CodeROI writes it down while it happens.”

On the tooling beat, attributed clearly: CodeROI announced the CodeROI AI Agent on Sept. 2, 2026, from McKinney, Texas, via PR Newswire, available in the US and Canada. It captures R&D credits, Section 174 treatment, and software capitalization on AI spend, producing deterministic, audit-ready evidence at the individual code-change level, generated from the actual diffs. It’s passive: no timesheets, no surveys, no workflow changes. It captures contemporaneous data from the day of connection forward, which means it can’t backfill history; that’s an honest limitation.

And two flags: the “first platform” claim is the company’s own self-reported assessment from its August 2026 review of publicly available platforms, and the claim that savings can appear quarterly via lower estimated tax payments instead of six to twelve months after filing is a company claim, not established fact. The mechanism is interesting regardless of who built it: evidence generated from what actually happened, at the moment it happened.

Closing: model both tracks together

So loop it back. The deduction answer lives in Section 174 timing and the OBBBA elections: expense in 2025, spread over 2025-2026, or amend prior returns if you’re under the $31 million threshold. The credit answer lives in Section 41, which keeps paying on costs you’re still amortizing and works even in loss years. They interact. Model both together, your loss position and other provisions included, before you pick your election timing.

The credit rewards growing spend, not one-time spend, and your documentation under the 2026 Section G mandate decides whether any of it survives examination. Concretely: get your per-project documentation together now, and run the OBBBA election choices past a tax professional alongside your credit position before the transition windows close on the defaults. Run the numbers before picking an option. You’d benchmark before a rewrite; do the same thing here, with someone who models this for a living.

Frequently Asked Questions