R&D Tax Insight: Dual Function Software
IRS Regulations & Context
What is Dual Function Software?
The following text defines Dual Function Software within the framework of US tax law. Hover over the bold terms to see legal annotations.
Dual Function Software represents a critical classification within IRS regulations (specifically T.D. 9786) concerning the Research and Development (R&D) Tax Credit. It refers to software developed by a taxpayer that is intended for both general administrative purposes (Internal Use) and for interaction with third parties, such as customers or vendors. Unlike pure "Internal Use Software" (IUS), which faces a notoriously difficult "High Threshold of Innovation" test to qualify for tax credits, Dual Function Software provides a legal pathway to segregate the consumer-facing aspects of a platform.
The importance of this distinction cannot be overstated for modern digital businesses. If a company can demonstrate that a software development project is Dual Function, IRS regulations allow the taxpayer to identify the subset of development intended for third-party interaction. This subset is exempt from the IUS exclusions, making it significantly easier to claim related wages and expenses as Qualified Research Expenses (QREs). Without this classification, expansive enterprise platforms might be entirely disqualified as "back-office" tools, resulting in the loss of substantial tax savings.
The Classification Logic
Determine if your software faces the "High Threshold of Innovation." Interact with the flow below.
Internal Use Only
Used strictly by employees for G&A (HR, Finance, Back office).
External / Sale
Software meant for sale, lease, or license to the public.
Dual Function
Internal utility + Third-party interaction (vendors/customers).
Why Dual Function Matters: Avoiding the "Trap"
Internal Use Software (IUS) is presumed not to be qualified research. To overcome this, you must pass the three "High Threshold of Innovation" tests.
Dual Function Software allows you to carve out the customer-facing portion and exempt it from these difficult tests.
The "Innovative" Test
Must reduce cost or improve speed substantially. (Hard for IUS)
Significant Economic Risk
Must involve substantial resources committed without certainty of recovery. (Hard for IUS)
Not Commercially Available
Cannot be something you could just buy and modify. (Common failure point)
The Dual Function Advantage
The third-party subset skips these tests and only needs to pass the standard 4-Part Test.
Claimable Expenses Potential
Click buttons to simulate impact
Example: The Logistics ERP
A shipping company builds a new platform. Is it tax-advantaged?
🔧 The Development
The company develops a monolithic ERP system. It handles inventory management, HR payroll, and truck routing (Internal). However, they also build a module allowing customers to log in, track shipments in real-time, and request quotes (External).
âš–ï¸ The Tax Result
Without Dual Function segregation, the entire project might be deemed "Internal Use" because it supports back-office operations. It would likely fail the "High Threshold" test because ERPs are commercially available.
Applying Dual Function Rule: The taxpayer isolates the code and hours spent on the Customer Portal.
- ✔ Customer Portal Expenses = Claimable (Standard Test)
- ✗ HR/Payroll Expenses = Likely Excluded (Fails HTI)
Next Steps: Clarify & Document
To fully utilize Dual Function Software rules, follow this immediate action plan.
Notification
Expert Analysis of Dual Function Software (DFS) under Internal Revenue Code Section 41
I. Executive Summary: The Strategic Significance of Dual Function Software (DFS)
A. Introduction to IRC §41 and the Software Eligibility Challenge
The Research and Development (R&D) tax credit, codified under Internal Revenue Code (IRC) Section 41, was enacted by Congress in 1981 to address concerns regarding the adequacy and potential decline of private sector research spending in the United States.1 The credit is designed as a nonrefundable tax incentive aimed at overcoming the significant staffing and supply costs incurred when companies engage in qualified research programs within a trade or business.1 By making the credit incremental in nature, the statute aims to encourage enlarged research efforts by taxpayers already engaged in such activities.1
A fundamental regulatory challenge within IRC §41 pertains to software eligibility. Taxpayers must rigorously distinguish between genuine “qualified research”—which must satisfy the stringent requirements of the Four-Part Test—and routine development, maintenance, or internal General and Administrative (G&A) activities. Software developed primarily for the taxpayer’s internal use (Internal Use Software or IUS) is subject to heightened scrutiny and a significantly more difficult set of qualifying criteria.2 The determination of whether software qualifies hinges critically on the function and intent documented by the taxpayer at the commencement of the development process.3
B. Meaning and Importance of Dual Function Software (DFS)
Dual Function Software (DFS), as defined under Treasury Regulations Section 1.41-4(c)(6)(vi), refers to proprietary software developed to serve both the taxpayer’s internal general and administrative (G&A) functions and, concurrently, enables necessary interaction with third parties, allowing external users to initiate specific functions or review data within the taxpayer’s system.5 The regulatory structure classifies G&A functions to include financial management, human resource management, and various general day-to-day support services.2 This specialized DFS classification is legally critical because the regulations establish a foundational legal presumption: DFS is initially treated as Internal Use Software (IUS).5 This IUS designation automatically triggers the application of the highly burdensome, three-part High Threshold of Innovation Test (HTIT), which mandates proof of innovation providing an economically significant improvement, demonstration of substantial economic risk, and confirmation of commercial unavailability.2 Consequently, if the software is developed primarily for internal G&A use, and does not fit one of the three exceptions (such as being sold commercially or integral to a hardware package), the HTIT must be met for the Qualified Research Expenses (QREs) to be eligible for the credit.10
The strategic importance of classifying software as DFS lies in securing a pathway to mitigate or bypass the prohibitive requirements of the HTIT. Taxpayers can achieve this by employing targeted regulatory mechanisms, primarily by attempting to identify and segregate a “third-party subset” (TSS). If successfully delineated as solely external-facing—i.e., only enabling the taxpayer to interact with third parties or allowing those parties to initiate functions or review data—the TSS is excluded from the IUS rules and is subject only to the standard Four-Part Test, allowing for 100% QRE inclusion.5 Furthermore, for software elements where G&A and third-party functions are intrinsically interwoven and cannot be cleanly separated (designated the “dual-function subset”), a critical safe harbor exists. This provision allows the inclusion of 25% of the associated QREs of the remaining subset in computing the research credit, provided a verifiable, anticipated third-party usage threshold of at least 10% of the software’s use is met.5 This framework provides essential regulatory relief for complex, integrated business systems, ensuring that significant external-facing technological research is not entirely penalized by its administrative roots.
C. Example of Dual Function Software: Customized E-Commerce Platform
A concrete example of Dual Function Software involves a specialized manufacturing firm that develops a highly customized, proprietary Order Management System (OMS).
The software possesses a clear Internal Function (G&A) component, where its core logistics module handles inventory management, tracks detailed regulatory compliance data for materials sourcing, and executes internal financial reconciliation processes.2 These elements support the general day-to-day services of the company.3 Concurrently, the system features a proprietary External Function (Third-Party Interaction) component, typically a unique customer portal. This portal allows authenticated clients to dynamically calculate complex pricing based on configuration options specific to the manufacturer’s complex products, track real-time delivery status using proprietary routing algorithms, and initiate detailed service requests or returns (actions beyond simple passive data review).16 Because the research and development activity related to the proprietary routing and pricing calculation modules serves both the G&A (internal efficiency and reporting) and the external client interaction, it is classified as DFS. To maximize the research credit, the firm would first attempt to segregate the costs associated with the front-end user interface and dedicated external access components as the Third-Party Subset (TSS), qualifying those costs under the Four-Part Test. The remaining interwoven costs related to the shared pricing/logistics algorithms would then constitute the Dual-Function Subset (DFS subset), potentially utilizing the 25% safe harbor.5
D. Key Initial Insights and Implications
Navigating the DFS classification compels a fundamental shift in compliance strategy, moving beyond simply demonstrating technical effort to validating functional purity and purpose.
The compliance landscape for DFS projects necessitates what can be characterized as a Two-Front Audit Battle. First, the taxpayer must successfully navigate the classification and segmentation hurdles dictated by the IUS/DFS regulations, proving that the software either falls under an exception, is a cleanly segregated TSS, or qualifies for the safe harbor.5 Second, the taxpayer must simultaneously satisfy the fundamental IRC §41 Four-Part Test for the Qualified Research Expenses (QREs) within those qualifying segments—particularly the requirements for a process of experimentation and the elimination of technical uncertainty.18 The successful segmentation of DFS is rendered meaningless if the underlying research activity, even if external-facing, fails to meet the basic standards of qualified research rigor, such as defining specific technological uncertainties at the project’s outset.19
Furthermore, the legal reliance on the taxpayer’s initial intentions creates a regulatory Intent Premium. Regulations state that the determination of whether software is developed primarily for internal use depends on the facts and circumstances present at the beginning of the software’s development, as well as the intent of the taxpayer.3 A failure to formally delineate the third-party functionality as a primary objective—with corresponding documentation—from the project’s inception severely compromises the taxpayer’s ability to overcome the IUS presumption and defend DFS classification years later during an IRS audit. This mandates proactive, contemporaneous planning that aligns legal intent with technical design.
II. The Regulatory Foundation: Internal Use Software (IUS) and the Heightened Standard
A. Overview of the Standard Four-Part Test
All research activities, regardless of their association with software development, must first meet the four requirements stipulated in IRC §41(d) to be considered qualified research. These tests ensure the activities are systematic and targeted toward technical unknowns.2
- Permitted Purpose: The activity must be undertaken to develop a new or improved “business component” that results in improvement of function, performance, reliability, or quality, or achieves a significant cost reduction.7
- Technological in Nature: The research must fundamentally rely on principles of a hard science, such as physical, biological, computer sciences, or engineering disciplines.7
- Elimination of Technical Uncertainty: The activities must be undertaken to discover information to eliminate uncertainty regarding the development or improvement of the business component.7
- Process of Experimentation: Substantially all (at least 80%) of the activities must relate to a process of experimentation designed to eliminate the technical uncertainty.2 Recent legal precedents emphasize that this requires detailed, real-time documentation showing how companies conduct experiments, make iterative improvements, and resolve scientific uncertainty.19
B. Defining IUS and G&A Functions
Software is defined as Internal Use Software (IUS) if it is developed primarily for the purpose of facilitating or supporting the taxpayer’s general and administrative functions.3 The regulations specifically define G&A functions as encompassing three major categories: (1) financial management functions, (2) human resource management functions, and (3) support services functions.3
A long-standing area of contention with the IRS concerns Enterprise Resource Planning (ERP) systems.5 These systems, by their nature, are central to G&A functions.2 When a taxpayer implements or substantially modifies a purchased ERP system, many associated activities—such as evaluating technical requirements, system configuration to match business processes, re-engineering business processes, and routine data transfer programming—are generally deemed non-qualified.7 Furthermore, costs related to the selection and implementation of templates for purchased ERP software are often viewed by the IRS as installation or modification costs required to be capitalized under Section 263(a).20 This historical resistance to crediting G&A activities drives the strict definition of IUS and the subsequent need for the DFS classification when external components exist.
C. The Exceptions to IUS Classification
Critically, certain software development activities are explicitly exempted from the IUS definition and are therefore only required to satisfy the standard Four-Part Test.10 These exceptions include:
- Software developed to be sold, leased, licensed, or otherwise marketed to third parties.10
- Software developed for use in otherwise qualified research activities, such as pharmaceutical development or use in a production process.10
- Software that is an integral part of a larger package of hardware and software developed together as a single product, where the software is an integral part. In these cases, eligibility is determined by examining the combined hardware-software product as a single unit.21
D. The Requirements of the High Threshold of Innovation Test (HTIT)
The stringent HTIT applies to IUS and any non-segregated portions of DFS, acting as a mandatory overlay to the standard Four-Part Test.2
- The Innovation Test: The software must be significantly different from existing implementation methods and provide a measurable, economically significant reduction in cost, or improvement in speed or other metric targeted by the project.9
- The Economic Risk Test: The company must incur significant economic and technical risk, expending considerable resources without the certainty that the project will succeed.9 A key detail provided in the regulations is that the substantial uncertainty required for this test mandates a higher level of uncertainty and technical risk than that required for business components that are not classified as IUS.5
- The Commercial Availability Test: A comparable third-party software must not be commercially available for purchase, lease, or license without substantial modification for the intended purpose.2
E. Key Insights on IUS and HTIT
The regulatory design surrounding the HTIT reveals a specific intention to restrict the credit. The explicit requirement for an elevated risk definition—demanding a “higher level of uncertainty and technical risk” for IUS and DFS 5—establishes a regulatory firewall. This mechanism is designed to filter out merely complex, custom integration projects, which are common when updating G&A systems, and instead reserves the R&D credit only for IUS development that genuinely pushes technological boundaries beyond established industry norms.
This elevated standard contributes to what is often termed the Customization Trap concerning systems like ERPs. Even when substantial customization of a G&A system is required, the project often fails the HTIT because the core function remains G&A; the underlying purchased system violates the Commercial Availability Test; and many customization activities (configuration, data mapping, and process re-engineering) are explicitly non-qualified activities.7 This inherent difficulty in qualifying G&A customization is the primary structural driver forcing taxpayers who integrate external access into administrative systems to rely on the DFS classification strategies.
III. Dual Function Software: Classification, Presumption, and Segmentation
A. The DFS Definition and the IUS Presumption
Dual Function Software is recognized under the regulations as software that is not developed for sale but contains elements that relate to both internal G&A functionality and third-party interaction.5 The third-party element permits external users to interact with the business or initiate functions.5
The critical starting point for all compliance efforts is the Regulatory Presumption: DFS is initially presumed to be IUS.5 This presumption immediately subjects all QREs related to the software to the high burden of the HTIT.5 Taxpayers must proactively take steps to overcome or mitigate this default status.
B. Strategy 1: Identifying and Isolating the Third-Party Subset (TSS)
The most favorable compliance outcome for DFS development is achieved by identifying and isolating a Third-Party Subset (TSS).
The Criteria for TSS designation are rigorous: the TSS must be a subset of elements that only enables the taxpayer to interact with third parties or allows those third parties to initiate functions or review data on the taxpayer’s system.5 If this delineation is successfully made, the TSS is excluded from the IUS definition 11 and is only required to meet the standard Four-Part Test.11 QREs allocable to the TSS may be included at 100%.12
The stringent requirement for the TSS to only enable external interaction demands meticulous attention to architectural design, creating an Architectural Mandate for compliance. If the external layer relies on logic interwoven with the internal G&A processes, functional purity is lost, and the segregation fails. This places extreme pressure on engineering documentation to align with tax compliance, proving that the third-party facing components are technologically decoupled or modular from the G&A core.5
C. Strategy 2: Defining the Dual-Function Subset (DFS) and Default Treatment
If clean segregation into a TSS is technologically or practically impossible because the internal (G&A) and external (third-party) components are interwoven, the remaining costs are allocated to the Dual-Function Subset.15
This DFS subset, which combines both functions, remains subject to the IUS presumption. Therefore, the Default Regulatory Status dictates that, absent the safe harbor election, the QREs related to this interwoven DFS subset must satisfy the full rigor of the HTIT to qualify for 100% inclusion.22 Given the difficulty of meeting the HTIT, the safe harbor provision is often the only realistic pathway for claiming credit on these interwoven costs.
D. Key Insights on Segmentation
The distinction between the TSS and the DFS subset confirms that the regulatory emphasis is not merely on cost tracing, but on achieving Functional Purity. If a specific piece of developed code is essential to both internal reporting and external client execution, the cost is intrinsically linked to G&A, thereby pushing it into the DFS subset. This occurs even if the majority of the code’s benefit is external.5 This establishes a regulatory preference for strict separation over estimated allocation, forcing taxpayers to design systems that minimize interdependence between internal and external-facing proprietary logic to maximize their potential credit.
IV. Detailed Analysis of the DFS Safe Harbor Provision
A. The Regulatory Basis and Use Case
The DFS safe harbor is a critical elective provision provided under Regulations Section 1.41-4(c)(6)(vi)(C).5 It is available only for the Dual-Function Subset (DFS) that remains after the taxpayer has attempted to segregate and exclude any potential Third-Party Subsets (TSS).15 The safe harbor is designed to provide regulatory certainty for complex systems where complete functional separation is impractical, ensuring that some credit can be claimed without requiring the HTIT.15
B. The Mechanics: 25% QRE Inclusion
Under the safe harbor, the taxpayer is permitted to include 25% of the Qualified Research Expenses (QREs) attributable to the DFS subset in calculating the research credit.5 This mechanism provides a defined percentage of eligibility for the interwoven costs, offering considerable relief by replacing the complex, subjective, and difficult burden of proving the HTIT for that portion of the expenditure.
The 25% inclusion acts as a calculated regulatory discount rate for highly integrated systems.13 This implies that the IRS acknowledges the presence of some external innovation but assumes that the majority (75%) of the research costs in the interwoven subset are either attributable to G&A improvements that fail the HTIT or are routine activities. This effectively formalizes the “cost” of failing to achieve perfect technological segregation.
C. The 10% Usage Threshold Requirement
The availability of the 25% safe harbor is strictly contingent upon meeting a usage test: the third-party functions must be reasonably anticipated to account for at least 10% of the overall use of the dual-function software.5
The challenge here is that the regulations do not provide a clear, standardized definition for how “use” is to be measured or substantiated (e.g., CPU time, transaction volume, bandwidth consumption, user sessions, or data exchange volume).5 This regulatory ambiguity means that the Quantification of “Use” is the Weakest Link in the compliance chain. Taxpayers must therefore develop and rigorously document a defensible, objective methodology for projecting and tracking this 10% threshold. Since the test relies on anticipated use, contemporaneous documentation justifying the projection methodology is essential.15
D. Key Insights on the Safe Harbor and Sequence
The regulatory sequencing confirms a prioritization strategy: taxpayers must first pursue TSS segregation, as this offers 100% eligibility. Only the remaining, interwoven costs (the DFS subset) are candidates for the 25% safe harbor.15 The structure thus encourages maximum technological separation prior to resorting to the quantified percentage benefit.
If a taxpayer cannot identify a TSS, the safe harbor cannot be applied to the costs, leaving the entire DFS development subject to the HTIT.22 This requires careful functional analysis at the project’s inception to maximize the segregation of purely external elements before applying the safe harbor to the residual intertwined elements.
V. Documentation Requirements and Audit Defense Strategy for DFS
A. Substantial Substantiation Requirements
The successful defense of any R&D tax credit claim, especially those involving complex DFS rules, hinges entirely on robust documentation. The IRS tax code broadly requires that taxpayers “retain records in a sufficiently usable form and detail to substantiate that the expenditures claimed are eligible for the credit”.23 Examples of required documentation include employee Form W2s, payroll registers, time tracking data, technical design requirements, specs or schematics, prototype documents, and test plans and results.23
B. Documenting Intent and Classification (The Front End)
Given the regulatory reliance on intent at the outset of development 3, documentation must rigorously prove the technical intent to create third-party facing functionality to support the classification of costs into TSS and DFS categories.22 Contemporaneous design documents must explicitly map functional requirements to external interaction goals to substantiate the purpose of the DFS/TSS features.
Furthermore, compliance must address the risk associated with complex projects often blending innovation with standard design, such as architecture and engineering activities or specialized software development.18 Taxpayers must maintain detailed contemporaneous records that effectively separate qualifying R&D from nonqualified maintenance and routine development.18
C. QRE Allocation and Time Tracking (The Core)
Qualified Research Expenses (QREs) for wages are based on the time an employee spends on qualified activities. A crucial rule permits the inclusion of 100% of an employee’s annual wages if “substantially all”—defined as at least 80%—of the services performed by that employee fit the criteria of qualified research.1
The successful defense of a DFS claim depends on the direct alignment between the functional segregation defined by the regulations (TSS vs. DFS vs. G&A) and the payroll tracking documentation. Development time must be meticulously recorded to isolate QREs belonging to each subset and to support the use of the 80% rule.18 This Interplay of Segregation and Substantiation is critical, as granular time logging allows tax professionals to defend specific QRE allocations against IRS challenges.
D. Current Audit Trends and Case Law Requirements
Recent IRS guidance and subsequent court decisions have significantly elevated the substantiation requirements for the R&D credit.18
Case law demands strict adherence to the fundamental R&D tests.19 For example, the Tax Court has denied significant credits where the company failed to prove that the research followed a structured Process of Experimentation (the 80% rule), requiring detailed documentation of design iterations and test results that resolve technological uncertainty (Little Sandy Coal Co., Inc. v. Commissioner, 2021).19 Moreover, taxpayers must now document the identification of specific, technological uncertainties before beginning their research, rather than claiming general uncertainty about design challenges (Phoenix Design Group, Inc. v. Commissioner, 2024).19
The reliance on cross-functional teams and agile development workflows inherently complicates the documentation required to separate qualifying R&D from routine activities.18 This leads to Risk Amplification in Agile Environments for DFS claims. To overcome this inherent audit risk, taxpayers developing DFS must impose customized, highly granular time logging systems specifically configured to link developer time to the segmented TSS or DFS components, alongside the required evidence of technological uncertainty elimination.
VI. Essential Tables and Visualization
To provide clear functional and regulatory guidance, the pathways for software qualification under IRC §41 are summarized below.
Table 1: Software Classification Pathways under IRC §41
| Software Type | Functional Description | Applicable Test(s) | QRE Inclusion (Max.) | Key Regulatory Reference |
| Non-Internal Use Software (Non-IUS) | Developed for sale/license, production processes, or as integral hardware/software package. | Four-Part Test only | 100% | Regs. §1.41-4(c)(6)(ii) 10 |
| Internal Use Software (IUS) | Primarily for General and Administrative (G&A) functions (HR, Finance). | Four-Part Test AND HTIT | 100% (If HTIT met) | Regs. §1.41-4(c)(6)(iv)(A) 2 |
| Third-Party Subset (TSS) | Segregable elements enabling only external interaction/data review. | Four-Part Test only | 100% | Regs. §1.41-4(c)(6)(vi)(B) 5 |
| Dual-Function Subset (DFS) | Interwoven elements serving G&A and third-party functions. | HTIT (Default) OR 25% Safe Harbor | 25% (If Safe Harbor elected and 10% use met) | Regs. §1.41-4(c)(6)(vi)(C) 5 |
The specific requirements for utilizing the DFS safe harbor are equally crucial for compliance.
Table 2: Dual Function Software (DFS) Safe Harbor Requirements
| Criteria | Regulatory Requirement | Compliance Challenge/Documentation Focus |
| Presumption Overcome | Attempt must be made to identify and segregate the Third-Party Subset (TSS). | Architectural documentation demonstrating segregated functionality.5 |
| Remaining Costs | Costs must be allocable to the interwoven Dual-Function Subset (DFS). | Detailed time tracking to isolate QREs belonging to the DFS components.23 |
| Use Threshold | Third-party functions must be reasonably anticipated to account for $\geq 10\%$ of the DFS use. | Development of quantifiable metrics and contemporaneous forecasting/measurement methodology.5 |
| Credit Inclusion | Taxpayer elects to include 25% of the DFS QREs. | Formal election documented in tax filings (e.g., Form 6765, Section G).22 |
VII. Strategic Recommendations and Suggested Next Steps for Clarification
The inherent complexity of Dual Function Software claims, especially regarding the interaction of highly technical functionality with nuanced usage thresholds, underscores the need for targeted regulatory guidance from the Internal Revenue Service (IRS) and the Treasury Department to reduce compliance costs and litigation risk.
A. Suggested IRS Guidance on Quantifying the 10% Usage Threshold
A critical point of regulatory ambiguity resides in the 10% usage threshold necessary to elect the 25% safe harbor under Regs. §1.41-4(c)(6)(vi)(C).5 The absence of a defined measure for “use” forces taxpayers to create subjective measurement standards, such as transaction count, API call volume, or average user session time. This regulatory lacuna creates a significant point of contention during audits, where IRS examiners frequently challenge the taxpayer’s chosen methodology rather than the underlying R&D activity itself.
Recommendation: The Treasury Department and the IRS should issue formal published guidance (such as a Revenue Procedure or Notice) that establishes clear, acceptable metrics and methodologies for substantiating “use” and “reasonably anticipated use” for the 10% threshold.
Clear guidance would standardize compliance and provide administrative certainty, mirroring the regulatory clarity provided for the “substantially all” 80% rule for wage inclusion.1 Standardization would benefit both the taxpayer and the IRS by focusing audits on the existence of the activity rather than the validity of the measurement tool.
B. Recommendation for Regulatory Refinement of the HTIT Application to Residual DFS
The current framework dictates that any QREs within the DFS subset that are not included under the 25% safe harbor (i.e., the remaining 75%) must qualify by meeting the full rigor of the HTIT.13 This often necessitates a rigorous, costly, and resource-intensive effort to prove HTIT compliance for a relatively small, interwoven portion of the research costs.
Recommendation: The IRS should analyze whether applying the HTIT to the 75% residual DFS subset provides meaningful protection for the fisc, or if it simply discourages investment in complex, proprietary systems that are functionally external-facing. A potential refinement could be to permit taxpayers to utilize the 25% safe harbor in exchange for formally waiving any claim to the remaining 75% under the HTIT, thereby establishing a clear administrative closure for the interwoven subset.
This simplification would provide regulatory efficiency: taxpayers receive a defined, predictable benefit (25%) for interwoven research, and the IRS avoids complex and subjective audits centered on the application of the HTIT to mixed-function software elements.
C. Taxpayer Best Practices: Integrated Compliance Planning
Given the heightened audit scrutiny and the emphasis on initial intent 3, a critical next step for taxpayers is to implement an integrated compliance protocol.
Recommendation: Taxpayers should mandate an integrated R&D compliance protocol at the project initiation phase, requiring a cross-functional technical/tax assessment. This protocol must include formal documentation of intent and architectural mapping designed explicitly to achieve clean functional segregation (TSS) or, failing segregation, to establish a defensible measurement methodology for the 10% usage threshold for the DFS safe harbor.
Modern compliance requires that cost tracking systems (e.g., time logs) be configured to map developer time directly to the specific subsets (TSS, DFS), linking those hours to documented technical design uncertainty and the systematic elimination of that uncertainty. This proactive step preempts IRS challenges on both functional classification and the eligibility of the underlying research activity, offering the highest level of audit defense.18
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
