Third-Party Subset Analysis
Navigating the intersection of R&D Tax Credit Law (IRC § 41) and Outsourced Development.
Legal Context & Definition
In the context of the US R&D Tax Credit, the "Third-Party Subset" refers to the complex regulatory framework governing research performed by contractors on behalf of a client. Under IRS Treasury Regulation § 1.41-4A(d), research is considered "funded"—and therefore ineligible for the credit—to the extent that the taxpayer is funded by another person.
The Critical Test: To claim the credit within this subset, a taxpayer must prove they retain Economic Risk and Substantial Rights to the research results.
This distinction is vital because it determines which party (the client or the contractor) can claim the Qualified Research Expenses (QREs). If a contract guarantees payment regardless of success, the risk lies with the client. If payment is contingent on success, the risk—and potentially the credit—lies with the contractor.
The Two Pillars of Eligibility
Click the cards below to explore the definitions required by the IRS.
Economic Risk
📉Does the taxpayer bear the expense even if the research fails?
Substantial Rights
🔐Does the taxpayer retain rights to use the results?
Scenario Simulator
Adjust the contract terms below to see how the Third-Party Subset rules apply in a real-world scenario (e.g., a Software Dev Shop vs. a Client).
Select Options
Configure the contract terms to see who can claim the R&D Tax Credit.
Why It Matters: Audit Risk
Correctly identifying the Third-Party Subset is crucial for financial compliance. Misinterpretation often leads to "Double Dipping," where both the client and contractor claim the credit for the same work.
The IRS prioritizes reviewing these arrangements. As shown in the chart, failing the "Funded Research" exclusion results in complete disallowance of the claim and potential penalties.
- Eligible Claims (Risk Retained)
- Disallowed Claims (Funded)
Next Steps: Clarifying Eligibility
Review Contracts
Examine all Master Services Agreements (MSAs) and SOWs. Look specifically for "warranty" clauses and "payment terms."
Document Risk
Create a contemporaneous memo documenting exactly which party bears the financial loss if the project fails.
Coordinate
Communication between Client and Contractor is key to avoid both parties claiming the same expenses (Double Dipping).
Expert Review of Internal Use Software Regulations: The Third-Party Subset Exception under IRC §41
I. Introduction: The Complexity of Software Research Credits
A. Background and Legislative Mandate
The Research and Development (R&D) Tax Credit, codified under Internal Revenue Code Section 41 (IRC §41), represents a foundational element of U.S. fiscal policy designed to stimulate technological advancement and economic growth. Congress enacted this nonrefundable income tax credit in 1981, driven by concerns that domestic spending on research activities was inadequate or declining.1 The legislative intent was to overcome corporate reluctance to bear the significant upfront staffing and supply costs necessary to conduct research programs within a trade or business.1 The credit is inherently incremental, structured specifically to encourage companies already engaged in some research activities to enlarge those efforts, thereby achieving a broader societal benefit.1 Following several extensions, Section 41 was made a permanent provision of the Internal Revenue Code as part of the Protecting Americans from Tax Hikes Act of 2015 (PATH Act).
The core benefit is derived from calculating Qualified Research Expenses (QREs). QREs are generally defined to include in-house research expenses—specifically, qualified wages paid to employees performing qualified services, amounts paid for supplies used in qualified research, and amounts paid or incurred for the rental or lease of personal property used in the research—as well as 65 percent of any amount paid or incurred for contract research expenses.2 To qualify, contract research must be performed pursuant to an agreement entered into prior to the research, requiring the research to be performed on behalf of the taxpayer, and obligating the taxpayer to bear the expense even if the research proves unsuccessful.3 The limitation of contract research expenses to 65 percent is a specific statutory mechanism.2
B. The Unique Regulatory Challenge of Software Development
While the overall mandate of the R&D credit is broad encouragement 1, the rules governing software eligibility, particularly software developed for internal use, are highly restrictive and complex. This complexity arises because modern software development costs constitute one of the most ambiguous areas for claiming the R&D credit.5 The rapid and accelerating pace of technological innovation, particularly in software, often outpaces the clarity of existing regulatory guidance. The IRS has specifically acknowledged the ongoing challenge of defining what constitutes eligible software development costs.5 Comprehensive regulations are required that are flexible enough to encompass the breadth of qualifying activities—from preliminary research and design to testing and deployment—yet precise enough to exclude routine or maintenance tasks that do not contribute to technological advancement.5 This regulatory tension necessitates the strict classification and testing regime outlined in the Treasury Regulations governing Internal Use Software (IUS).
II. Establishing the Internal Use Software (IUS) Framework
A. Definition and Scope of Internal Use Software (IUS)
Internal Use Software (IUS) is broadly defined as software developed primarily for use in the taxpayer’s general and administrative (G&A) functions. This category includes common corporate software used for activities such as human resources, financial accounting, routine data processing, or internal asset tracking. The purpose of classifying software as IUS is to prevent taxpayers from claiming the credit for routine corporate activities that lack true technological advancement or a sufficient element of uncertainty, thereby safeguarding the integrity of the incentive.
Conversely, software is explicitly classified as non-IUS, and thus subject only to the standard, less stringent Four-Part Test of IRC §41, if it meets certain criteria.6 These non-IUS categories include software developed to be commercially sold, leased, licensed, or otherwise marketed to third parties. Additionally, software developed to be used internally by the taxpayer, but not in any G&A function (e.g., highly specialized manufacturing control software), is also classified as non-IUS. Crucially, software developed specifically to interact with third parties, provided it is not also used in any G&A function, is also generally categorized as non-IUS.6 This distinction is the bedrock upon which the Third-Party Subset exception is built.
B. The High Technological Threshold (HTI) Test
If software is definitively classified as IUS, the taxpayer must demonstrate that the development meets the highly stringent High Technological Threshold (HTI) test, which applies in place of the standard Four-Part Test. The HTI test requires the taxpayer to satisfy three criteria:
- Innovation: The software must be intended to result in a reduction in cost or improvement in speed or other factors that is significant and can be measured.
- Financial Risk: The taxpayer must commit significant financial resources to the development, and there must be substantial uncertainty that the resources will be recovered within a reasonable period.
- Non-Commercial Availability: The software cannot be commercially available, meaning it cannot be purchased, leased, or licensed from a third party and used without incurring significant research costs to achieve the intended innovation.
Meeting the HTI test is exceptionally difficult due to the requirement for demonstrable, significant innovation and financial risk, often leading to the disqualification of QREs related to pure IUS projects.
C. Dual-Function Software (DFS) and the Presumption of IUS
A major regulatory complexity arises with Dual-Function Software (DFS). DFS is defined as integrated software that simultaneously serves internal G&A functions (making it potentially IUS) and also enables external functions such as customer interaction or third-party data review (making those specific elements potentially non-IUS).
In handling DFS, Treasury Regulations establish a critical starting point for audit purposes: a presumption that dual-function software is Internal Use Software (IUS).7 This regulatory presumption is not merely a classification formality; it immediately determines the testing standard. By presuming the DFS to be IUS, the regulatory structure mandates that the entire project—unless successfully segregated—must satisfy the rigorous HTI test. This presumption fundamentally shifts the burden of proof onto the taxpayer. Any failure to accurately document, segregate, or allocate costs related to the external functions means that the entire DFS project is swept under the restrictive HTI test, substantially increasing the risk of disallowance of all related QREs.
The critical nature of this presumption dictates the necessity of the Third-Party Subset provision, which provides the only reliable mechanism for overcoming this initial classification and ensuring that the externally focused elements can qualify for the credit under the standard, achievable Four-Part Test.
III. The Third-Party Subset: Definition, Importance, and Application
A. Meaning and Regulatory Foundation of the Third-Party Subset
The Third-Party Subset represents a vital exception and compliance mechanism within the regulations governing Dual-Function Software (DFS). The core objective of the Third-Party Subset is to allow taxpayers to qualify expenditures related to the external-facing elements of software, carving them out from the highly restrictive Internal Use Software (IUS) classification. Treasury Regulations mandate a presumption that all DFS is IUS, subjecting the entire project to the demanding High Technological Threshold (HTI) test.7 This presumption may, however, be overcome if a taxpayer can identify a clearly defined subset of elements or functions—the “Third-Party Subset”—that only enables the taxpayer to interact with third parties or allows third parties to initiate functions or review data on the taxpayer’s system.7 This requires a precise functional segregation effort to isolate the code and development work dedicated solely to external engagement, thereby excluding it from the IUS definition.
The primary importance of this specific regulatory carve-out lies in its direct impact on QRE eligibility. By successfully identifying and substantiating the Third-Party Subset, the expenditures (QREs) directly associated with the development of that subset are immediately exempt from the rigorous HTI test.6 This exemption is fundamental because the HTI test is rarely met in a field audit scenario. Therefore, the Third-Party Subset allows the taxpayer to subject those segregated QREs only to the standard, more manageable IRC §41 Four-Part Test (which evaluates purpose, uncertainty, process of experimentation, and whether the research is technological in nature). This successful segregation is the gateway to unlocking the R&D tax credit for modern software development where internal G&A functions are inseparable from customer-facing operations, provided that the taxpayer can demonstrate the functional segregation and accurately attribute development costs.
B. The Critical Regulatory Consequence (HTI Test Avoidance)
As established, the most significant regulatory benefit derived from successfully defining the Third-Party Subset (TPS) is the avoidance of the High Technological Threshold (HTI) test for the QREs allocated to those specific functions.6 The QREs directly attributable to the TPS are expressly designated as Non-IUS under the regulations.
This structure underscores the necessity of documentation in the audit defense strategy. When a software project is classified as DFS, the entire body of associated QREs is immediately at risk due to the IUS presumption. The regulatory mechanism provides a path to risk mitigation: if the taxpayer can precisely map their development efforts (labor costs, supply usage) to the functions enabling third-party interaction, they can remove those costs from the IUS pool. If this functional and financial segregation is successful, the segregated QREs are evaluated under the less onerous Four-Part Test, dramatically improving the likelihood of qualification. However, a crucial consequence is that if an auditor challenges and ultimately disallows the segregation of the TPS, the underlying software reverts entirely to its original DFS classification (presumed IUS), and 100% of the QREs must then satisfy the HTI test, leading to potential disallowance of the full claim.
C. Case Studies and Practical Example
A practical example illustrates the necessity and application of the Third-Party Subset rules in a modern corporate environment.
Consider a large logistics corporation that undertakes the development of a proprietary Enterprise Resource Planning (ERP) system to manage its entire operation. This system, due to its comprehensive nature, functions as Dual-Function Software (DFS). Its internal modules—which handle functions such as employee payroll processing, internal equipment inventory management, human resources, and internal asset depreciation schedules—clearly qualify as software used in General and Administrative (G&A) functions, falling squarely under the IUS classification.
However, the comprehensive ERP platform also incorporates a sophisticated external module: a secure B2B portal. This portal allows registered external vendors and logistics partners to securely log in, initiate specific shipment tracking functions for their goods, review detailed, real-time data regarding payment status against invoices, and dynamically schedule material drop-offs or collections at the company’s warehouses.
The specific development costs (qualified wages, testing materials, and contract research expenses 2) related only to this vendor portal and its underlying Application Programming Interfaces (APIs) that facilitate external interaction, initiation, and data review constitute the Third-Party Subset.7 By successfully documenting the segregation of these functions from the internal G&A modules, the QREs associated with the development of the vendor portal are exempt from the HTI test and are subject only to the standard Four-Part Test. The remaining QREs associated with the internal payroll and inventory modules must still attempt to satisfy the HTI test, but the most valuable, technologically advanced (and often more qualified) portion of the software—the external-facing portal—is strategically secured for the R&D credit.
D. Segregation of Dual-Function Software (DFS)
The success of the Third-Party Subset strategy hinges entirely upon the taxpayer’s ability to effectuate precise and justifiable segregation. Upon successful identification of the TPS and its related QREs, the regulations stipulate that the remaining software elements—the “dual function subset”—are still treated as IUS and remain subject to the HTI test.6
This requires meticulous allocation of costs. Development teams utilizing modern, integrated coding practices (e.g., integrated Agile sprints) often work simultaneously on components serving pure IUS, the TPS, and the dual-function subset. Taxpayer compliance must demonstrate that the allocation of Qualified Research Expenses—primarily employee wages—is accurate. This means time sheets and development narratives must precisely link employee time and consumed materials specifically to the documented TPS elements, separate from the rest of the DFS. A flawed segregation methodology poses a substantial financial risk; if the segregation is deemed arbitrary or poorly supported during an audit, the IRS may disallow the entire associated claim, not just the poorly documented portion, by invoking the initial presumption that the software is 100% IUS. Thus, the integrity of the time-tracking and functional documentation is paramount for the overall financial viability of the R&D tax credit claim for DFS.
IV. Financial and Compliance Implications: The Safe Harbor Provision
A. Utilizing the 25% Safe Harbor for Remaining QREs
A significant provision of regulatory relief accompanies the complexities of Dual-Function Software segregation: the 25% Safe Harbor. The regulations offer this provision to provide an acceptable mechanism for calculating QREs related to the IUS portion of the DFS. After a taxpayer has successfully identified and allocated QREs to the Third-Party Subset (which avoids the HTI test), they may then include 25% of any remaining QREs associated with the residual dual-function subset in the computation of the credit amount.6
The introduction of the 25% safe harbor acknowledges the impracticality of having the non-carved out portions of DFS fully satisfy the HTI test. Because the HTI test is rarely satisfied in practice, the safe harbor provides critical financial relief by allowing taxpayers to capture a predetermined portion of QREs that would otherwise be lost entirely. This mechanism streamlines compliance for the most complex, dual-purpose software components, recognizing the difficulty in allocating 100% of costs perfectly while adhering to the HTI standard for the internal G&A portions.
B. The Interdependence of Subset Identification and Safe Harbor Use
A critical, often overlooked element of compliance relates to the interdependence between the successful identification of the Third-Party Subset and the utilization of the 25% safe harbor. The ability to invoke the 25% safe harbor is fundamentally contingent upon the accurate and successful initial identification and segregation of the TPS.
The regulatory allowance for the 25% safe harbor is framed as an inclusion for the remaining qualified expenses of the dual-function subset after the initial separation of the non-IUS TPS portion has occurred.6 If, during a regulatory review or audit, the primary TPS carve-out is challenged and ultimately disallowed due to insufficient documentation or functional overlap with G&A, the entire software project reverts to the status of Dual-Function Software subject to the IUS presumption.7 If the initial segregation (Step 1) fails, the software is treated as 100% IUS, necessitating that 100% of the QREs must meet the HTI test. Consequently, the conditional safe harbor provision (Step 2) for remaining QREs may become inapplicable or irrelevant, as the taxpayer failed to properly identify and apply the regulation regarding the subset, potentially invalidating the intended structure of the entire claim. Therefore, the successful application of the Third-Party Subset rule is not merely an option for claiming additional credits; it is a foundational prerequisite for utilizing the subsequent 25% safe harbor relief.
C. Required Documentation and Audit Defense
Effective audit defense requires a comprehensive documentation strategy centered on proving the functional segregation of the TPS. The documentation package must precisely demonstrate what functions were developed, who developed them, why they meet the TPS criteria, and how the costs were accurately allocated.
Key components of the required documentation include:
- Functional Requirements Specifications: Detailed documents must map code components and development activities directly to the external interaction capability, demonstrating that the functions only enable third parties to initiate functions or review data.7 This involves showing a clear distinction between the front-end user interface and the back-end G&A databases.
- Labor and Cost Allocation Records: Time tracking records and project management artifacts must precisely isolate the QREs (qualified wages and supplies) spent developing the TPS, separated from the dual-function components and pure IUS components. This provides the auditable link between the qualified activity and the claimed expense.
- Legal and Technical Analysis: A reasoned analysis must be prepared, explaining why the defined subset elements do not serve a G&A function and how they satisfy the technical uncertainty requirements of the standard Four-Part Test, thus justifying their exemption from the HTI test.
D. Key Software Classification and Testing Matrix
To fully understand the regulatory environment and the strategic importance of the Third-Party Subset, it is essential to compare the various software classifications and the corresponding R&D tests applied to them. The following matrix demonstrates the varied standards of proof required based on the initial functional classification of the software.
Classification of Software for R&D Credit Eligibility
| Software Category | Definition/Function | Applicable R&D Test | R&D Credit Eligibility Status |
| Non-IUS (Commercial) | Developed to be commercially sold, leased, or licensed to third parties.6 | Standard IRC §41 Four-Part Test Only | High Eligibility |
| Non-IUS (Operational) | Developed internally but not used in General & Administrative (G&A) functions.6 | Standard IRC §41 Four-Part Test Only | High Eligibility |
| Dual-Function Software (DFS) | Software serving both G&A and external interaction purposes. | Presumed IUS; requires mandatory segregation.7 | Variable (High Audit Risk) |
| Third-Party Subset (TPS) | Segregated elements of DFS that only enable third parties to interact, initiate functions, or review data.7 | Exempt from HTI Test 6 | Highest Eligibility (If Segregation is Successful) |
| Remaining Dual Function Subset | The portion of the DFS not carved out as TPS (still treated as IUS). | HTI Test applies (Allows for 25% Safe Harbor inclusion of QREs) 6 | Low Eligibility (Unless HTI met or 25% safe harbor used) |
The matrix highlights the critical path for compliance: maximize the allocation to the TPS to avoid the HTI test entirely, and then utilize the 25% safe harbor for the residual, unavoidable IUS components. The failure to achieve the TPS classification forces the entire dual-function claim into the “Remaining Dual Function Subset” category, drastically reducing the QREs that can be claimed.
V. Areas Requiring Further Regulatory Clarification and Next Steps
Despite the regulatory framework outlined in Treasury Regulations, the rapid evolution of technology and development methodologies continues to necessitate clarification and streamlined processes for calculating and applying R&D credits.5 To enhance compliance certainty and fully explain the use of the Third-Party Subset, the following steps are required from administrative and legislative bodies:
A. Issue Definitive Guidance on Segmentation Methodology
The current regulations clearly define the functions that must be separated—the functions dedicated to third-party interaction 7—but they lack detailed instruction on how Qualified Research Expenses (QREs) should be allocated against these functions, particularly within modern, integrated software development environments like Agile or DevOps. The inherent difficulty lies in the fact that development labor often simultaneously contributes to the TPS, the dual-function subset, and pure IUS components within the same development cycle or even the same workday.
The expectation for compliance under current standards often leads to taxpayers struggling to implement cost-prohibitive, minute-by-minute tracking systems. To address this, the Internal Revenue Service should issue a Revenue Procedure or updated guidance detailing acceptable allocation methodologies. This guidance should acknowledge the contemporary realities of software development processes and provide feasible standards, such as proportional allocation based on functional complexity, metrics derived from code check-ins, or fixed safe harbor allocations for labor across integrated development teams. Such clarification would standardize audit expectations and reduce administrative burden.5
B. Clarify the Scope of “Interaction,” “Initiation,” and “Review Data”
The precise terminology defining the Third-Party Subset—specifically, the mandate that the subset only enables third parties to “interact with third parties,” “initiate functions,” or “review data” 7—remains open to subjective interpretation. The lack of detailed operational definitions creates ambiguity, particularly when distinguishing between non-qualified activities and qualified active engagement.
For instance, guidance is needed to determine the threshold of activity required to qualify. Does a simple, publicly accessible webpage displaying general product data constitute “allowing third parties to review data”? Or does the regulation require secure, authenticated access to personalized data, or complex business-to-business (B2B) integrations involving transactional initiation? The IRS must provide concrete rulings, potentially through published examples or an expanded Audit Techniques Guide (ATG), that clarify the level of active engagement or specialized functional capability necessary for customer self-service modules, authenticated vendor portals, and integrated supply chain systems. This clarity would enable taxpayers to structure their documentation accurately and minimize potential disagreement during audit examinations.
C. Refine the Boundaries of “General and Administrative Function” (G&A)
The foundational concept of the entire IUS framework, and consequently the need for the TPS exception, rests on whether the internal software components are utilized for General and Administrative (G&A) functions.6 Significant ambiguity persists in the regulatory landscape concerning the distinction between core operational software (e.g., highly specialized tools for optimizing manufacturing flow or utility network load balancing) and true G&A systems (e.g., basic financial accounting or Human Resources management).
If internal operational software is mistakenly classified as G&A, it becomes Dual-Function Software (DFS), immediately triggering the IUS presumption and the mandatory segregation requirements of the TPS rule. Conversely, if the operational software is correctly recognized as non-G&A (such as specialized process control software), it is classified as Non-IUS from the start 6, rendering the TPS rule and the HTI test irrelevant. To streamline compliance, the IRS must issue clear guidance delineating operational functions, which are inherently non-G&A and subject only to the standard Four-Part Test, from G&A functions. This refinement would substantially reduce the initial scope of software projects that must be subjected to the complex DFS segregation and analysis.
D. Update the Audit Techniques Guide (ATG)
The Audit Techniques Guide (ATG) serves as the primary technical manual for IRS field agents conducting examinations of R&D tax credit claims. To ensure compliance consistency and provide assurance to taxpayers, the ATG must be updated to reflect the complexities and nuances of the Third-Party Subset and Dual-Function Software rules.5
Specifically, the IRS should incorporate explicit, detailed sections within the ATG that provide approved documentation checklists tailored for TPS segregation, offer multiple functional segregation examples derived from common industry scenarios (e.g., e-commerce, banking, logistics), and articulate acceptable calculation methods for both the TPS and the 25% safe harbor. This effort would align regulatory expectations with practical taxpayer compliance efforts, reducing administrative uncertainty and streamlining the audit process by providing a unified set of expectations for both the examiner and the taxpayer.
VI. Conclusion: Strategic Compliance in the Software Age
The Third-Party Subset provision under Treasury Regulations is a vital, non-optional compliance mechanism for corporations seeking to claim R&D tax credits for complex software development projects. The regulatory structure, anchored by the presumption that all Dual-Function Software (DFS) is Internal Use Software (IUS), fundamentally forces the taxpayer to execute a precise, documented functional segregation. The successful identification of the Third-Party Subset allows QREs associated with external interaction to bypass the nearly impossible High Technological Threshold (HTI) test, directly connecting those expenditures to the R&D credit benefit.
Strategic compliance requires an integrated approach that begins with detailed functional mapping and extends through meticulous labor and cost allocation. Furthermore, the ability to leverage the 25% safe harbor for the residual IUS components of DFS is critically dependent on the integrity of the initial TPS segregation. Without robust documentation substantiating the carve-out of third-party interaction functions, the entire claim risks collapsing, resulting in the disallowance of QREs under the stringent HTI requirements. Moving forward, the financial viability of R&D tax credit claims for technological companies hinges on the clarity of forthcoming guidance from the IRS regarding methodologies for segmentation, definitions of external interaction, and the boundary lines separating operational and General and Administrative functions.
Are you eligible?
Why choose us?
Pass an Audit?
What is the R&D Tax Credit?
The Research & Experimentation Tax Credit (or R&D Tax Credit), is a general business tax credit under Internal Revenue Code section 41 for companies that incur research and development (R&D) costs in the United States. The credits are a tax incentive for performing qualified research in the United States, resulting in a credit to a tax return. For the first three years of R&D claims, 6% of the total qualified research expenses (QRE) form the gross credit. In the 4th year of claims and beyond, a base amount is calculated, and an adjusted expense line is multiplied times 14%. Click here to learn more.
Never miss a deadline again
Stay up to date on IRS processes
Discover R&D in your industry
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/
Choose your state
