R&D Tax Credits for Software Companies: The Engineering Work You’re Already Doing 

Profitable on paper. Burning cash in reality. 

In 2026, most software companies already qualify for federal R&D tax credits—but fail to document them correctly. Section 174 and 280C elections directly affect deduction timing and credit value. Understanding the IRS 4-part test is critical to maximizing benefit while minimizing audit risk.

For SaaS founders and CTOs, this is the paradox: invest millions in engineering yet see taxable income climb. The disconnect isn’t accidental—it’s how Section 174 and R&D Tax credits interact in 2026. 

The reality? Most software companies are doing qualifying R&D work every sprint. They’re just not capturing it correctly. 

Why Your Engineering is R&D 

The federal R&D tax credit wasn’t designed for biotech labs. It was designed for exactly what your engineers do daily: solving technical uncertainty through iteration, building systems where the solution isn’t obvious, experimenting with approaches until something works, and improving performance, reliability, or scalability through engineering. 

If your team uses phrases like “we’re not sure if this will work,” “let’s test a few approaches,” or “we need to iterate on this”—that’s R&D. The work already qualifies. The question is whether you’re documenting it correctly. 

The IRS 4-Part Test: What Software Companies Need to Know 

Every R&D tax credit claim must pass all four parts of the IRS test. Here’s what that means in software terms: 

R&D Tax Credit — The IRS Four- Part Test

Permitted Purpose

Must improve functionality, performance, reliability, quality, or scalability.
✓ Qualifies: Reducing API response time from 800ms to 200ms
✗ Doesn’t qualify: Updating button colors for brand consistency 

Technological in Nature

Solution must rely on computer science, engineering, data science, or mathematics—not business judgment.
✓ Qualifies: Designing distributed system architecture
✗ Doesn’t qualify: Choosing Slack over Microsoft Teams 

Elimination of Uncertainty

At project start, itwasn’t clear how—or whether—the goal could be achieved.
✓ Qualifies: “Can we process 100M events/day without dropping data?”
✗ Doesn’t qualify: Following a documented tutorial 

Process of Experimentation

Team evaluated alternatives, tested approaches, iterated, or refined solutions.
✓ Qualifies: Tested three different database architectures before selecting hybrid approach
✗ Doesn’t qualify: Work completed in single pass with no iteration 

 What Software Development Work Typically Qualifies 

Common qualifying activities include: 

• Core Product Engineering: Feature development with technical uncertainty, system architecture design, performance optimization, security hardening 
• Data & AI/ML Work: Training and tuning machine learning models, feature engineering, algorithm development, model deployment optimization 
• Backend & Infrastructure: API design, microservices architecture, database optimization, cloud infrastructure, auto-scaling, real-time data processing 
• Developer Tools:  Custom CI/CD pipelines, internal tools, testing frameworks and automation 
• Integrations: Third-party API integrations, legacy system modernization, protocol implementation (WebSockets, gRPC, GraphQL) 

The key factor isn’t whether the feature shipped successfully—it’s how the technical challenges were approached. 

What Doesn’t Qualify (And Why Precision Matters)

What Does not Qualify & Why Precision Matters

Being precise about non-qualifying work reduces audit risk: 

• Routine bug fixes with known solutions 

• Cosmetic UI changes without technical challenges 

• Market research and customer surveys 

• Sales and marketing work 

• Standard integrations following vendor documentation 

Critical principle: Including non-qualifying activities doesn’t increase credit value—it increases audit exposure. 

Section 174 & 280C in 2026: What Changed Under OBBB 

Domestic vs Foreign R&D Under OBBBA (2026)

The One Big Beautiful Bill Act (enacted July 2025) significantly changed R&D treatment: 

Domestic R&D (U.S.-based): Immediate deduction in year incurred
Foreign R&D: Must be capitalized and amortized over 15 years 

Software implication: If you have offshore engineering teams, proper geographic allocation matters. 

Want to learn more about Section 174 After OBBBA: R&D Expensing Rules for 2026

The Section 280C Election: 

When claiming the R&D credit, you face a strategic choice: 

Option 1: Take full R&D credit, but reduce your R&D expense deduction by the credit amount
Option 2: Reduce your R&D credit by 21% (corporate tax rate), claim full R&D expense deduction 

Which to choose depends on current vs. future tax rates, NOL position, cash flow, and state tax conformity. 

Small Business Relief: Companies with average gross receipts under $31M can make retroactive 280C elections on amended returns through July 4, 2026. 

Documentation: Where Claims Are Won or Lost 

R&D credits are not storytelling—they are evidence. 

Most software companies already have what they need: 

• Jira/Linear tickets with technical context 

• Pull requests and code review discussions 

• Architecture decision records (ADRs) 

• Design docs outlining approach alternatives 

• Performance benchmarks and load test results 

• Sprint retrospectives documenting iteration 

The key: Connect these materials to specific technical challenges being solved. 

Why Software Teams Miss R&D Tax Credits 

The same patterns repeat: 

• Wrong experts involved – General CPAs understand tax code, not software development 
• Evaluated too late – By year-end, engineering work is scattered across closed tickets and departed employees 
• False assumptions – “We’re not doing cutting-edge AI” (wrong lens—the test is technical uncertainty, not academic novelty) 
• Documentation fear – Teams worry about audit trails when existing engineering artifacts are already sufficient 

The Real Numbers 

Qualifying costs typically include: 

• Engineer salaries (W-2 wages) 

• Contract developer costs (65% of payments) 

• AWS/cloud costs supporting R&D work 

• SaaS development tools (GitHub, Datadog, testing tools) 

Rough estimate: 6-10% of qualified expenses as federal credit, plus state credits where applicable. 

For a software company with $2M in engineering salaries, $500K in contractors, and $100K in cloud/tools, the federal credit could be $200K-250K, with additional state credits of $50K-100K depending on location. 

How Astute Approaches Software R&D Tax Credits 

How Astute Approaches Software R&D Tax Credits

At Astute, we focus exclusively on R&D tax credits for technology, SaaS, and AI companies. Our approach: 

We speak engineer first, accountant second. We understand sprints, CI/CD, microservices, and ML pipelines—not just IRC Section 41. 

We identify R&D work you’re already doing. Our role isn’t to stretch definitions—it’s to document qualifying work that teams don’t realize qualifies. 

We prepare audit-ready documentation. We map engineering activities to the 4-part test using artifacts your team already created. 

We coordinate Section 174 and 280C strategy. Immediate expensing, credit optimization, and state conformity are interconnected. We model all scenarios. 

The Bottom Line 

If your team iterates solutions, solves technical uncertainty, or builds where the path isn’t obvious—you’re doing R&D. The issue isn’t innovation—it’s recognition. 

 Ready to see if your software development qualifies? Schedule a 30-minute discovery call. 

Contact Astute: www.thinkastute.com 

FAQS