[GLOS89_code]

Expert Report on the Definition and Qualification of Specially Designed Software for the U.S. R&D Tax Credit

I. Executive Summary: The Strategic Significance of Specially Designed Software Qualification

A. The Rationale for Software Qualification and the IUS Exclusion

The concept of “Specially Designed Software” (SDS), while not a formally codified term within the Internal Revenue Code (IRC) Section 41, is utilized by practitioners to describe software development activities that successfully qualify for the Research and Development (R&D) Tax Credit. These activities must navigate the rigorous exclusion imposed by IRC § 41(d)(4)(E), which generally denies the credit for computer software developed primarily for a taxpayer’s internal use, known as Internal Use Software (IUS).1 The importance of correctly classifying software development as SDS is paramount, as the R&D credit is intended to incentivize activities intended to eliminate technical uncertainty concerning new or improved business components.2 Software that is definitively not considered IUS—such as software developed for commercial sale, systems enabling robust third-party interaction, or systems forming an integral part of a combined hardware/software product 4—avoids the highly restrictive High Threshold of Innovation (HTI) Test. Strategic classification is therefore the single greatest factor in realizing significant Qualified Research Expenditure (QRE) claims, as these qualifying activities only need to satisfy the standard four-part R&D qualification criteria applicable to all business components.

B. The High Threshold of Innovation and Classification Failure (Including Example)

When software is classified as IUS—meaning it supports generalized and administrative (G&A) functions such as financial management, human resources, or support services 1—it is automatically subjected to the three-part HTI test. This test demands an economically significant improvement, confirmation of non-commercial availability, and, most crucially, the presence of significant economic risk stemming from technical uncertainty regarding resource recovery.6 This requirement is highly restrictive because it strictly differentiates between routine modernization and genuine research intended to discover new information.7 For example, in regulatory Example 17 (Reg. 1.41-4(c)(6)(vii)), a company undertakes a project to rewrite its legacy internal accounting application to a modern client/server architecture using new object-oriented programming techniques, anticipating significant cost reductions and speed improvements.4 Despite meeting the innovation and non-commercial criteria, the project fails the HTI test because the taxpayer was certain that it would be able to overcome the technological uncertainties and implement the improvements within a reasonable period. This failure demonstrates that the required uncertainty must pertain to the technical risk that resources will be unrecoverable, not merely the financial uncertainty of overall project success, thereby restricting credit claims for high-competence R&D teams.4

II. The Regulatory Foundation: Defining Qualified Research and the Software Exclusion

This section analyzes the regulatory framework that dictates whether any software development activity can be classified as Qualified Research.

A. The Foundational Four-Part Test (The Section 41 Gateway)

Before considering the specific exclusions applicable to software, any activity must satisfy four statutory requirements defined under IRC § 41(d).2 These criteria serve as the gateway for all R&D claims:

• Technological in Nature: The activities performed must fundamentally rely on principles derived from physical science, biological science, computer science, or engineering.2 The analysis must look at the methodology used, ensuring it applies scientific or technical disciplines, rather than marketing or social sciences.2
• New or Improved Business Component (Permitted Purpose): The research must relate to the development or improvement of a business component, which includes a product, process, computer software, technique, formula, or invention.7 The intended result must be useful in the development of a new or improved business component, specifically increasing its function, performance, reliability, or quality.3
• Elimination of Uncertainty (Technical Uncertainty): The research activity must be undertaken with the intent to discover information that resolves or eliminates uncertainty concerning the capability, methodology, or appropriateness of the development or improvement of the business component.3 This elimination of uncertainty is the core policy goal of the R&D credit.9
• Process of Experimentation: Substantially all of the activities must constitute elements of a systematic process designed to evaluate alternatives and achieve the desired results.5 This process typically involves identifying the technical uncertainty, identifying alternatives to eliminate that uncertainty, and then systematically evaluating those alternatives through modeling, simulation, or trial-and-error methodology.7

B. Software’s Unique Challenge: The Statutory IUS Exclusion

The R&D tax credit regime treats software development differently than the development of physical products or processes. The tax code specifically excludes costs related to computer software developed by (or for the benefit of) the taxpayer primarily for its internal use.1

1. Defining Internal Use Software (IUS)

Final regulations (Reg. 1.41-4(c)(6)) define IUS narrowly as software developed for use in general and administrative (G&A) functions that facilitate or support the conduct of the taxpayer’s trade or business.1 Crucially, the regulations strictly limit what constitutes a G&A function 6:

• Financial management functions.
• Human resource management functions.
• Support service functions that support day-to-day operations, such as data processing or facilities services.

C. The Implicit Operational Exemption

The strategic avoidance of IUS classification is the most effective means of securing the R&D credit for internal software development. The IRS’s specific and narrow definition of IUS, restricted only to G&A functions, creates a critical strategic opportunity. Any software development that is integral to the core operational processes of a business—that is, software supporting proprietary functions that generate revenue and are not related to financial management, HR, or generalized IT support—should be defensibly classified as non-IUS (often termed “Operational Software”).

For instance, if a high-tech logistics company develops proprietary algorithms for dynamically rerouting shipments in real-time or if a utility company develops custom software to optimize power grid load balancing, this software is “internal” but does not perform a G&A function. By avoiding the G&A label, this Operational Software bypasses the highly complex and risky HTI test entirely.8 Consequently, the development only needs to satisfy the standard four-part R&D qualification criteria, which, while still rigorous, is a significantly easier standard to meet than the HTI test. The initial, and arguably most important, strategic decision for tax compliance is therefore whether the software’s core function maps precisely to the three enumerated G&A categories.

III. Specially Designed Software: Pathways to Qualification (Avoiding the HTI Test)

Software development activities qualify as Specially Designed Software primarily by satisfying one of the regulatory exceptions that exempt the development from the Internal Use Software (IUS) exclusion and, consequently, from the High Threshold of Innovation (HTI) test.

A. Pathway 1: Software Developed for Commercial External Use (Non-IUS)

The most straightforward exemption is for software developed to be commercially sold, leased, licensed, or otherwise marketed to third parties.1 This software is definitively designated as Non-IUS. Examples of software that typically fall into this category include banking transaction software, software applications developed for mobile devices, or custom software built by a manufacturer specifically to enable its customers to place orders online.5 The determination of whether the software was developed for third-party use hinges significantly on the taxpayer’s intent at the start of the software development effort.5 Contemporaneous documentation detailing the business model, pricing structure, and marketing plan is therefore essential to substantiate this claim during an examination.

B. Pathway 2: Software Integral to a Combined Hardware/Software Product

Software that is an integral part of a larger, integrated system also avoids the IUS exclusion. The Integral Rule applies to a new or improved package of software and hardware developed together by the taxpayer as a single product, where the software component is an integral part of that single product.4 In these cases, eligibility for the research credit is determined by examining the combined hardware-software product as a single unit.4

This pathway holds significant strategic value in mitigating audit risk. The Integral Software/Hardware pathway offers a high degree of certainty for qualification because the software’s R&D claim benefits from the favorable historical treatment given to tangible product development research under Section 41. Tax policy implicitly favors physical product innovation, and by merging the software with proprietary hardware development—such as embedded controls in medical devices, proprietary industrial robotics, or operational control systems—the taxpayer shifts the regulatory scrutiny away from the IUS exclusion and toward the general R&D rules for a “business component”.7 This strategic framing minimizes the required internal documentation compared to the highly stringent and subjective demands of the HTI test.

C. Pathway 3: Dual-Function Software (DFS) and Third-Party Interaction

Dual-Function Software (DFS) is a specific type of software that serves internal G&A functions but also enables third parties to initiate functions or review data on the taxpayer’s systems.5 Because it involves interaction with external parties, it is partially or wholly excluded from the HTI requirements.

• Third-Party Exclusion: Software developed specifically to enable third parties to interact with the business systems generally does not need to meet the additional HTI criteria to qualify for the R&D credit.5
• The 25% Safe Harbor: If the DFS or a subset of its elements still contains IUS components, a regulatory safe harbor allows the taxpayer to include 25% of the Qualified Research Expenditures (QREs) of the remaining dual-function software in computing the research credit.6 This safe harbor is conditional: the third-party functions must be anticipated to account for at least 10% of the software’s use.6 This provides an administrative mechanism to capture the R&D value in hybrid systems without having to pass the HTI test.

IV. The High Threshold of Innovation (HTI) Test: The Gatekeeper for IUS

If software is classified as Internal Use Software (IUS) because it supports General & Administrative functions, it must satisfy three highly rigorous additional criteria known collectively as the High Threshold of Innovation (HTI) test (Reg. 1.41-4(c)(6)(vii)).

A. Criterion 1: Substantial and Economically Significant Improvement

The first requirement mandates that the software must be intended to be innovative, and that innovation must be measurable. This is demonstrated by an anticipated reduction in cost, improvement in speed, or other measurable improvement that is substantial and economically significant if the development is successful.6 This anticipated result must be attributable only to the development of the new or improved software, independent of the effect of any modifications to related hardware or other software.4 This ensures that the R&D credit is claimed for software innovation itself, not merely for ancillary benefits derived from new hardware deployment.

B. Criterion 2: Significant Economic Risk and Technical Uncertainty (The Audit Hot Zone)

This criterion is the most difficult to satisfy and represents the primary focus during IRS examinations. It requires that the software development has significant economic risk, defined by two components: the taxpayer must commit substantial resources to the development, and there must be substantial uncertainty because of technical risk as to whether those resources can be recovered within a reasonable time.6

The uncertainty required must be technical in nature—that is, relating to the capability or methodology of development—and not merely business risk or general financial uncertainty.7 The regulatory framework mandates a distinction between routine engineering and genuine research. The implementation of existing technology by itself is insufficient evidence of innovation. To satisfy this requirement, the use of existing technology must be in new ways that successfully resolve substantial technical uncertainty.8 The documentation must explicitly detail why technical risks (e.g., complex data integration, new interoperability standards) could potentially render the committed resources unrecoverable, despite substantial internal effort. The focus must remain on resolving technical unknowns, not simply overcoming project management complexity.

C. Criterion 3: Non-Commercial Availability

Finally, the IUS must not be commercially available. This means the software cannot be purchased, leased, or licensed and used for the taxpayer’s intended purpose without requiring modifications that, themselves, satisfy both the innovation and significant economic risk requirements of the HTI test.11 The purpose of this criterion is to prevent the R&D credit from subsidizing the implementation of off-the-shelf software or standard industry solutions. The determination of availability must be made at the beginning of the development project.13

D. The Critical Interpretation of Technical Certainty

The analysis of the HTI test demonstrates that technical certainty, even if the project is complex, is a fatal flaw. The failure described in Example 17 of Reg. 1.41-4 is instructive.4 The taxpayer’s internal certainty that the technical difficulties associated with migrating a legacy system would be overcome and that the committed resources would be recovered within a reasonable period, minimized the technical risk in the eyes of the IRS. If the technical outcome is highly certain, the economic risk posed by the technical challenges is deemed insufficient, meaning the activity constitutes routine development rather than qualified research. Consequently, tax documentation must explicitly detail why the technical challenges introduced a risk of failure substantial enough to jeopardize the recovery of committed development resources.

V. Judicial and Regulatory Interpretation: Case Studies in HTI Failure

Regulatory examples and safe harbors provide essential guidance for interpreting the HTI test and managing compliance risk associated with Specially Designed Software claims.

A. Detailed Review of Example 17 (Reg. 1.41-4(c)(6)(vii))

The facts of Example 17 involve Company X, which sought to expand its internal computing power by developing a proprietary “screen-saver-like application” that would run on idle employee computers to execute general and administrative computations.4 X expected this would significantly reduce costs by avoiding the purchase of new hardware.4 In a separate, highly relevant set of facts provided within the same example, X also undertook a project to modernize a legacy application from a mainframe to a client/server environment using new object-oriented programming, expecting significant reductions in maintenance costs and speed improvements.4

• Failure Analysis: Both scenarios conclude that the projects failed the HTI test. The development activities met the innovation (cost/speed reduction) and non-commercial criteria.4 However, in both situations, the regulatory conclusion stated that X was certain that it would be able to overcome the technological uncertainties and implement the improvements within a reasonable period.4
• Consequence: Because X did not have substantial uncertainty, because of technical risk, that the committed resources could be recovered within a reasonable time, the project failed to satisfy the Significant Economic Risk requirement (Criterion 2).4 This critical failure demonstrates that technical competence, coupled with high certainty of success, effectively removes the activity from the scope of qualified research designed to eliminate uncertainty.

B. The Dual-Function Software (DFS) Safe Harbor in Practice

Where software has components serving both IUS (G&A) and external third-party interaction functions, the Dual-Function Software (DFS) rules provide an essential compliance mechanism. The third-party interaction exclusion ensures that software that allows third parties to initiate functions or review data (e.g., customer portals, online ordering) is generally not considered IUS.5

For hybrid software, the 25% Safe Harbor (Reg. 1.41-4(c)(6)(vi)(C)) offers administrative relief.6 This provision allows the taxpayer to include 25% of the QREs attributable to the remaining dual-function components, provided that documentation establishes the third-party functions are anticipated to account for at least 10% of the software’s use.6

The dual benefit of the 25% Safe Harbor extends beyond simple cost recovery. The safe harbor for DFS serves as an important audit mitigation strategy. Proving HTI is inherently a high-risk endeavor, as it requires arguing the taxpayer’s internal state of technical uncertainty and overcoming the precedent set by Example 17. In stark contrast, utilizing the DFS safe harbor requires verifiable, objective metrics—documenting the usage percentage—and applying a straightforward calculation (25% inclusion). Tax compliance teams are advised to prioritize documentation supporting the 10% third-party interaction threshold to secure the predictable 25% credit, thereby avoiding the substantial burden and subjectivity of defending the full HTI test.

VI. Documentation, Cost Accounting, and Compliance Integration

Audit readiness for Specially Designed Software claims requires rigorous, contemporaneous documentation and an understanding of the intersection between tax law and financial accounting principles.

A. Substantiating the Four-Part Test in Software Development

Qualified Research Expenditures (QREs) for software development include costs related to planning, designing, model building, code-writing, and testing (up to the point of internal deployment or development of product masters for external sale).14 Effective documentation must link these costs directly to the four-part test:

• Project Descriptions: Contemporaneous outlines must detail the purpose, technical objectives, and specific technical challenges intended to be resolved (elimination of uncertainty).2
• Process of Experimentation Records: Technical reports and specifications must provide evidence of the systematic evaluation of alternatives, including testing protocols, outcomes, and records of failure analysis or problem-solving.2
• Cost Allocation: Accurate time tracking logs for employees directly performing or supervising qualified research activities are required. Furthermore, qualifying expenses include wages, supplies (e.g., software licenses used in development), cloud computing services used for development or testing environments, and contract research costs, provided the business bears the economic risk of the work performed by the contractor.2

B. HTI-Specific Documentation

For IUS projects subject to the HTI test, documentation must focus on the unique three criteria:

• Innovation Proof: Records must establish the pre-project performance baseline and the precise metrics targeted for improvement, demonstrating that the intended reduction in cost or improvement in speed is substantial and economically significant.6
• Economic Risk Narrative: A formal risk assessment should be prepared at the project’s inception. This assessment must explicitly detail the nature of the technical unknowns, linking them to the potential inability to successfully complete the project or recover committed resources within a reasonable period. This documentation must be carefully crafted to address the specific failure points identified in Example 17.4

C. Aligning Financial Accounting (GAAP/ASC) with Tax Law

A significant complexity arises from the regulatory disconnect between tax law (IRC § 41) and financial reporting capitalization rules (e.g., ASC 350-40 for IUS, ASC 985-20 for external software).18

Under Generally Accepted Accounting Principles (GAAP), capitalization of internally developed software costs (ASC 350-40) typically begins once the preliminary project stage is complete and it is deemed probable that the software will be completed and used as intended.19 Conversely, the R&D tax credit focuses on the process of experimentation intended to resolve uncertainty.7 The phase of research with the highest degree of technical uncertainty—and therefore the highest likelihood of qualifying for the R&D credit—often occurs before or during the earliest stages of GAAP capitalization, when costs are still being expensed for financial reporting purposes.

Taxpayers must recognize this discrepancy and ensure they are capturing QREs that were expensed under GAAP (e.g., preliminary feasibility studies, requirements gathering tied to technical resolution). These early-stage expenditures are frequently the most defensible research costs for the R&D credit because they directly address the elimination of technical uncertainty.7

D. Leveraging the Modern Development Framework

The Financial Accounting Standards Board (FASB) has acknowledged that modern software is not always developed linearly and has removed references to rigid “development stages” from ASC 350-40 to reflect current Agile methodologies.19 Although this shift is in financial accounting, it provides a strong regulatory precedent that supports the application of the R&D tax credit rules to iterative, non-linear development processes.

This development enables taxpayers to argue that the “process of experimentation” under IRC § 41 is a continuous function embedded within modern Agile and DevOps sprints. This interpretation supports the inclusion of QREs derived from ongoing iterative modeling, testing, and refinement that occurs throughout the project lifecycle 14, provided the underlying technical uncertainty is consistently documented and tied back to the four-part test.

VII. Future Policy Recommendations and Next Steps for Clarification

The regulatory environment surrounding Specially Designed Software, particularly the HTI test, remains challenging due to the inherent subjectivity of technical certainty and the rapid evolution of engineering practices. To further clarify and explain the use of Specially Designed Software more fully, the following next steps in regulatory guidance are necessary:

A. Seek Formal Guidance on Non-Linear Development Methodologies

The current regulations and interpretive examples often appear to rely on a traditional, sequential development model (e.g., Waterfall). This regulatory approach fails to align with modern industry practices where iterative, Agile, and DevOps methodologies dominate.19

Recommendation: Treasury and the IRS should utilize the annual Priority Guidance Plan 20 to publish a Revenue Ruling or Notice defining how the Process of Experimentation (IRC § 41(d)(1)(C)) applies specifically to Agile and other non-linear development models. This guidance should include administrative safe harbors for documenting the identification and resolution of technical uncertainty within short development sprints, thereby streamlining compliance for the majority of modern software companies.

B. Issue Clarification on “Significant Economic Risk” to Objectify HTI

The current interpretation of Significant Economic Risk (Criterion 2 of HTI) is overly subjective, particularly when applied using the rationale found in Example 17.4 Taxpayers with highly competent engineering teams are often penalized because their internal confidence in overcoming technical hurdles invalidates the economic risk claim.

Recommendation: New regulatory guidance is necessary to establish objective, measurable parameters for the “technical risk” required for IUS, shifting the focus from the taxpayer’s confidence to the inherent technical difficulty of the project. This clarification should define objective criteria distinguishing between: (1) routine implementation or modification of commercially standard technology (which fails HTI); and (2) complex integration, optimization, or creation of novel systems for non-standard outcomes (which would constitute qualified research). This would help ensure the R&D credit incentivizes truly innovative solutions regardless of the developer’s internal estimation of success probability.

C. Develop Specific R&D Guidance for Artificial Intelligence (AI) and Machine Learning (ML)

The development of proprietary Artificial Intelligence (AI) and Machine Learning (ML) systems for internal process optimization (e.g., predictive maintenance, internal data categorization) often falls under the “support service functions” definition of IUS 6, forcing these activities into the restrictive HTI test.

Recommendation: The IRS must address how the iterative, experimental nature of AI/ML development aligns with the R&D criteria. Guidance should clarify whether the complex, continuous process of training, tuning, and validating proprietary ML models inherently satisfies the Technical Uncertainty and Process of Experimentation requirements. The uncertainty in achieving desired model performance (e.g., meeting accuracy thresholds or reducing algorithmic bias) is fundamentally a technical uncertainty concerning system “capability” or “methodology”.2 Given the increasing prevalence of AI in core business activities and even in IRS auditing infrastructure 23, preemptive guidance in this area is critically important to bridge the tax and technology disconnect.

VIII. Key Data Tables for Inclusion

The following tables summarize the critical criteria for classifying software development activities under IRC § 41.

Table Title: Software Classification for R&D Tax Credit Eligibility

Table Title: The Three-Part High Threshold of Innovation (HTI) Test

R&D Tax Credit Preparation Services

Swanson Reed is one of the only companies in the United States to exclusively focus on R&D tax credit preparation. Swanson Reed provides state and federal R&D tax credit preparation and audit services to all 50 states.

If you have any questions or need further assistance, please call or email our CEO, Damian Smyth on (800) 986-4725.
Feel free to book a quick teleconference with one of our national R&D tax credit specialists at a time that is convenient for you.

R&D Tax Credit Audit Advisory Services

creditARMOR is a sophisticated R&D tax credit insurance and AI-driven risk management platform. It mitigates audit exposure by covering defense expenses, including CPA, tax attorney, and specialist consultant fees—delivering robust, compliant support for R&D credit claims. Click here for more information about R&D tax credit management and implementation.

Our Fees

Swanson Reed offers R&D tax credit preparation and audit services at our hourly rates of between $195 – $395 per hour. We are also able offer fixed fees and success fees in special circumstances. Learn more at https://www.swansonreed.com/about-us/research-tax-credit-consulting/our-fees/