R&D Tax Credit — Software & Technology

R&D Tax Credit for Custom Software Development: What Work May Warrant Review?

Custom software development companies may perform activities that warrant analysis under IRC §41 — architecture, integration, performance, and algorithms. Routine development and configuration do not automatically qualify.

Custom software development companies — firms that build software for clients or for their own products — may perform activities that warrant analysis under the federal R&D tax credit. This page explains what development work may be relevant. It is educational and is not individualized advice. For the foundational framework, see our page on qualified research.

What R&D May Look Like in Custom Software Development

Custom software development may involve architecture, integration, performance, and algorithms. Work directed at resolving genuine technical uncertainty in these areas may warrant review. Routine development, configuration, and coding using established methods do not, by themselves, constitute qualified research.

Industry-Specific Examples of Technical Development

  • Evaluating alternative architectures to resolve a question about whether a system can achieve a target capability or performance where the appropriate design is uncertain.
  • Resolving integration uncertainty where combining systems raises a technical question not established at the outset.
  • Developing or evaluating algorithms to resolve a technical question about capability or performance where the appropriate method is uncertain.
  • Engineering for reliability or performance where the appropriate design is uncertain and is evaluated through testing.
  • Developing data-processing approaches to handle scale or complexity where the appropriate approach is uncertain.

Technical Uncertainty Examples

  • Whether an alternative architecture can achieve a specified capability or performance target.
  • Whether a new integration approach can resolve a technical question about system compatibility.
  • Whether an alternative algorithm can achieve a specified accuracy or performance target.

Process-of-Experimentation Examples

A process of experimentation may involve modeling or simulating alternative architectures and measuring performance, testing alternative integration approaches and evaluating results, or benchmarking alternative algorithms and measuring performance.

Potential Business Components

Potential business components may include a new or improved software product, a new or improved architecture, a new or improved algorithm, a new or improved integration approach, or a new or improved reliability approach.

Employee and Contractor Work

Employees whose work may warrant analysis include software architects, developers, data engineers, and quality engineers. Contractor work may include outside developers or consultants performing development work on behalf of the company.

Activities That Generally Require Caution or May Not Qualify

  • Routine coding and development using established methods.
  • Configuration of off-the-shelf software or platforms.
  • Routine bug fixes and maintenance.
  • Cosmetic UI or UX changes without a technical performance target.
  • Ordinary troubleshooting or debugging.
  • Simple client customization using established methods.

Documentation That May Help

Records that may help include architecture evaluation records, integration test results, algorithm benchmarking data, and records connecting personnel to specific development projects.

Example Hypothetical Project

The following is a hypothetical example for illustration only.

A custom software development company is building a system for a client that must integrate with multiple existing systems and achieve a specified performance target. The technical uncertainty is whether an alternative combination of architecture, integration approach, and data-processing strategy can achieve the specified target. The team evaluates alternative architectures, tests integration approaches, and benchmarks performance. Professional review is still needed.

Questions to Ask Internally

  • What specific software, architecture, or algorithm was being developed or improved?
  • What technical uncertainty existed at the outset?
  • How does this differ from routine development or configuration?

Relationship to the Four-Part Test

The four-part test applies the same way as in any industry. The work must satisfy all four elements: permitted purpose, technological in nature, elimination of uncertainty, and process of experimentation. Funded-research considerations may apply to client-funded development; see our page on funded research. For more on software activities generally, see our page on software development and the R&D tax credit.

Key Takeaway

Custom software development companies may perform activities that warrant analysis under IRC §41 — particularly work involving architecture, integration, performance, and algorithms. Routine development and configuration do not automatically qualify. Because these determinations are fact-specific, professional review is appropriate. For related industries, see software development and the R&D tax credit and SaaS companies.

Sources

  1. Internal Revenue Code §41

    Cornell Law Institute (LII)

    Section 41(d) defines qualified research and the four-part test; §41(d)(4)(E) addresses internal-use software; §41(d)(4)(H) addresses funded research.

  2. Treasury Regulation §1.41-4

    Cornell Law Institute (LII)

    Regulatory definition of qualified research, the internal-use-software rules, and the funded-research rules.

  3. Instructions for Form 6765

    Internal Revenue Service

    Summarizes qualified research, software considerations, and excluded activities.

  4. Research Credit

    Internal Revenue Service

    IRS landing page for the Credit for Increasing Research Activities.

By R&D Ledger Editorial Team

Last reviewed: August 2026

Related educational pages

R&D Ledger

Organize your R&D documentation throughout the year.

Explore R&D Ledger