[GLOS88_code]

Expert Report on the Meaning and Importance of Hardware-Software Integration in the Context of U.S. R&D Tax Credit Law

I. Strategic Overview: Defining and Qualifying Hardware-Software Integration

1.1. Executive Summary: The Meaning and Importance of HSI in R&D Tax Law

Hardware-Software Integration (HSI) research encompasses the systematic development, refinement, and comprehensive testing of specialized control algorithms, firmware, and application layers required to enable novel or improved performance characteristics in a physical (hardware) business component. HSI activities are fundamentally technological in nature, relying on the combined principles of engineering (mechanical, electrical), computer science, and physics to achieve a permitted purpose.1 HSI development is intrinsically characterized by the necessity of resolving technical uncertainties that emerge from the interface between algorithmic demands and physical limitations, such as constraints related to real-time processing, the reliability of sensor data fusion, or the complex trade-offs involved in achieving specific kinematic performance and speed requirements.2 These activities constitute the foundational research that precedes the application and production of new techniques and equipment.4

HSI holds paramount importance under Internal Revenue Code (IRC) Section 41 because it provides a reliable pathway to qualify research expenditures that might otherwise be highly scrutinized or potentially disqualified under the restrictive Internal Use Software (IUS) exclusion. By explicitly directing the R&D effort toward overcoming technical uncertainties related to the integrated system’s fundamental functionality, reliability, or physical performance—such as achieving heightened speed, greater precision, or advanced sensor fusion capabilities—companies can demonstrate clear compliance with the stringent four-part test for qualified research activities.1 The integrated nature of the work allows for the maximum inclusion of Qualified Research Expenses (QREs), including the wages of control specialists, the cost of prototype supplies, and cloud compute time, which reinforces the legislative intent of IRC $\S 41$ to incentivize investment in research and breakthrough technologies.3

1.2. HSI’s Role in Mitigating the Internal Use Software (IUS) Exclusion

The application of the R&D tax credit faces a significant hurdle when software is developed primarily for the taxpayer’s own internal use. The final IRS regulations generally exclude expenditures related to software used in general and administrative (G&A) functions, specifically naming financial management, human resource management, and support services.6 This exclusion prevents many routine IT activities from qualifying for the credit. However, HSI activities benefit from a critical exemption because the research is functionally inseparable from a tangible, physical product (the hardware component) that is either developed for commercial sale, lease, or license to third parties, or developed to enable third parties to initiate functions or review data on the taxpayer’s system.6

The analysis of integrated systems must shift the focus from the software’s location (i.e., whether it resides on the taxpayer’s premises) to its primary functional objective. Research concentrated on complex control systems—such as those governing robotics, industrial automation, or embedded vehicles—inherently links the software R&D to the technological advancement of the commercial physical product. This essential linkage removes the software from the typical purview of the IUS restriction, which targets internal administrative tools.7 The development of software intended for release to and control by an outside party, or developed to operate a machine sold to that party, is not deemed internal use software.8 This strategic alignment of software R&D with physical product advancement enables the inclusion of substantial QREs across both hardware and software development teams into the R&D credit calculation.3

1.3. Example Case Study: Robotics and Autonomous Navigation Systems

A powerful example illustrating the qualification of HSI is the development of Autonomous Mobile Robot (AMR) navigation systems designed for dynamic logistics environments. In this scenario, engineers are tasked with developing and testing new Simultaneous Localization and Mapping (SLAM) algorithms to improve the robot’s ability to navigate reliably and safely while optimizing pathfinding latency in highly congested, variable indoor settings.3

The core technical uncertainty lies in resolving how disparate sensor inputs—which constitute the physical hardware component—can be reliably fused and processed by the new control algorithms—the software component—to maintain uninterrupted operation and execute fast, collision-free obstacle avoidance in dynamic, real-world stress conditions.3 The experimentation involves systematic iteration of control code, extensive simulation runs using physics engines, and iterative physical prototype testing under varying lighting, load, and obstacle conditions.3 This research qualifies because the software is integral to the AMR, which is specifically developed and marketed to third parties.6 The resulting QREs include the wages for controls specialists and sensor engineers, the cost of prototype sensors, motors, robot frames (supplies consumed in testing), and the substantial cloud compute resources necessary for training the sophisticated AI/ML navigation models.1 The resulting improvements—such as greater speed or reliability—directly satisfy the permitted purpose test for the overall business component.3

II. The Statutory and Regulatory Foundation of Integrated R&D

2.1. The Framework of IRC § 41

The U.S. R&D tax credit, codified under IRC § 41 (and historically supported by $\S 174$), is fundamentally designed to incentivize investment in, and reward companies for, creating new or improved products, processes, or software.5 This requires qualifying research expenditures to be tied to activities aimed at the development and application to production of new techniques and equipment.4 For HSI projects, the R&D activity must relate to a new or improved “business component,” and the integration of hardware and software typically targets the improvement of the functionality, performance, or reliability of the entire physical product as the business component.1 Qualified Research Expenses (QREs) that may be captured include in-house research expenses such as wages for qualified employees, the cost of supplies consumed in experimentation, computer rental or lease expenses, and 65% of contract research expenses paid to third parties for qualified activities.1

2.2. Navigating the IUS Exclusion and Its Exceptions

The definition of Internal Use Software (IUS) focuses on software developed primarily for use in the taxpayer’s general and administrative (G&A) functions, specifically financial management, human resource management, and support services.7 This exclusion necessitates careful classification of any software component involved in an R&D project.

The pathway for HSI to avoid IUS status hinges on two primary exceptions related to commerciality and third-party interaction.6 The software avoids classification as IUS if it is developed (i) to be commercially sold, leased, licensed, or otherwise marketed to external third parties, or (ii) to enable a third party to interact with the system, such as allowing customers to initiate functions or review data on the taxpayer’s system (e.g., ordering products or tracking shipments via a manufacturer’s website).6 Control software developed as an integral part of a machine or system that is sold, such as a robotics control loop or embedded automotive software, inherently satisfies the commercial exception because it is inseparable from the final, marketed business component.3 The IRS acknowledges that software released to, and controlled by, an outside party is not considered internal use software.8

The critical factor in justifying the IUS exemption for HSI is the functional objective of the software component. If the software’s primary role is real-time command, sensing, data processing, and physical execution related to a physical asset marketed to a client, it inherently transcends the “internal support services” definition of IUS. The intent of the IUS rules was to prohibit credit for routine IT infrastructure upgrades. However, advanced control systems—such as those required for sensor integration, failsafe operations, or new communication protocols in a physical machine—are foundational to the technological advancement of the final product and are thus considered integral to the qualifying research activity.9

III. The Four-Part Test Applied to HSI Activities: A Deeper Dive

The HSI development lifecycle provides a robust structure for satisfying all four criteria required for qualified research under IRC $\S 41(\text{d})(1)$.

3.1. Elimination of Uncertainty and Technological Nature

Research activities must be technological in nature and intended to discover information that eliminates uncertainty concerning the capability, methodology, or appropriateness of the development or improvement of the business component.1 HSI research is inherently technological, drawing upon the principles of physical sciences, engineering, and computer science.2 Robotics development, for instance, requires expertise in mechanical engineering, electrical engineering, software, control systems, and sensor integration.5

Uncertainty in HSI projects is often complex, involving the interaction of physical and algorithmic variables. It goes beyond simple cost or market acceptance uncertainties. Qualifying technical uncertainties include: determining the appropriate methodology (the algorithm) needed to achieve specific physical performance goals (e.g., maximizing payload while minimizing kinematic oscillation); or resolving whether the integrated system can reliably operate under complex, variable physical conditions (e.g., dynamic lighting, unexpected obstacles, high-speed demands).1

3.2. Permitted Purpose and the Business Component

The activities must be intended to create a new or improved business component resulting in increased function, performance, reliability, or quality.1 In HSI, the permitted purpose is generally met by demonstrating how the integrated effort improves a physical parameter of the final product. Examples include improving the trade-offs between payload capacity and operational speed (performance), increasing sensor data acquisition reliability (quality/reliability), or adding complex new capabilities such as autonomous navigation (functionality).3

3.3. Process of Experimentation (PoE): Systematically Evaluating Integrated Alternatives

The Process of Experimentation (PoE) requires demonstrating that the taxpayer utilized a systematic process to evaluate one or more alternatives intended to eliminate the identified technical uncertainty.1 This process involves developing hypotheses, testing those hypotheses (through modeling, simulation, or systematic trial and error), and refining or discarding them.9 Critically, the PoE must rely on the principles of engineering or computer science.9

Qualifying HSI Process Steps include:

1. Modeling and Simulation: This essential step often precedes physical fabrication, utilizing specialized simulation software (e.g., physics engines, kinematics models) to evaluate the feasibility of algorithmic and mechanical hypotheses before committing resources to physical prototypes.3
2. Prototyping and Iteration: The physical construction of first-article prototypes allows for the systematic variation of control loops, sensor configurations, or structural parameters to address a specific technical uncertainty.3
3. System Integration Reviews: Throughout the project, systems engineering activities involve monitoring and coordinating concurrent hardware and software developments to ensure seamless integration. These reviews provide early warning if requirements are deficient or not being met by the implementation, often necessitating waivers or the re-evaluation of the requirement itself.10 This continuous feedback loop is strong evidence of a systematic, documented experimentation process.

The strength of HSI claims often lies in the demonstrable interdependence of hardware and software experimentation. If an initial physical prototype fails a load test (a hardware limitation), the subsequent iteration frequently requires not only a stronger material or modified component (hardware change) but also a new or refined kinematic algorithm (software change) designed to compensate for the physical modification or restriction. Documenting this simultaneous, iterative search for a holistic solution provides a powerful defense against claims that the work was routine development, which is considered high risk by the IRS.9

3.4. IRS Audit Risk Categories for Integrated Software

IRS audit guidelines categorize software development activities based on their risk of failing to meet the qualified research requirements.9 HSI development teams must be diligent in ensuring their documentation clearly separates qualifying activities from high-risk tasks:

The determination hinges on whether the research effort is resolving technological uncertainties—not merely organizational, aesthetic, or routine implementation requirements.

IV. Financial Capture and Substantiation of HSI QREs

A complex HSI project, which involves cross-functional teams, requires rigorous cost accounting methodologies to accurately capture and allocate expenditures.

4.1. Capturing Qualifying Wages (IRC § 41(b)(2)(A))

Qualified wages include all amounts paid to employees engaged in performing, supervising, or directly supporting the qualified research.3 In an HSI context, this includes robotics engineers, controls specialists, sensor/vision engineers, and test-lab coordinators.3

Effective substantiation requires detailed records, including employee W2s, payroll registers, and, most critically, time tracking data. This data must clearly link personnel hours directly to the specific qualified R&D activities and projects documented in the technical records.11 Because HSI teams are often matrixed, integrating mechanical, electrical, and software specialists, the cost accounting system must be capable of accurately capturing and allocating fractional time usage. For instance, if an engineer spends time both designing a prototype (qualified experimentation) and constructing the final production model (non-qualified activity), only the time demonstrably tied to the systematic experimentation and prototype testing qualifies as a QRE.3

4.2. Accounting for Supplies and Cloud Compute (IRC § 41(b)(2)(B) and Rental Costs)

QREs extend beyond labor to include materials consumed in the experimentation process (supplies) and certain rental or lease expenses.1

1. Supplies: This includes prototype components, sensors, motors, robot frames, test-fixtures, and vision systems that are consumed or destroyed during the R&D process.3 Substantiation requires detailed invoices, receipts, and inventory logs that link the specific material consumption directly to the documented R&D experiments or prototype iterations.11
2. Computer/Cloud Rental: Lease expenses for computer hardware, specialized laboratories, or high-performance computing (HPC) services are QREs if directly associated with qualified research activities.1 This is particularly relevant in HSI, where high-cost resources such as physics simulation software, kinematics platforms, and dedicated cloud compute services for training AI/ML control algorithms are essential components of the experimentation process.3

The documentation for these costs demands rental contracts, lease agreements, and, crucially, detailed usage logs and schedules demonstrating the specific allocation of computation time or facility usage to qualified research tasks.1 The integration in HSI strengthens the QRE justification by establishing a direct cause-and-effect link between software R&D (e.g., algorithm training via cloud compute) and hardware supplies R&D (e.g., prototype materials), both necessary to eliminate the integrated system uncertainty.

4.3. Treatment of Contract Research

Payments made to external contractors for performing qualified HSI research activities, such as third-party laboratories used for specialized sensor testing or R&D consultants engaged to resolve technical uncertainties, are eligible to be claimed as QREs at 65% of the expense.3

V. Audit Defense and Documentation Best Practices for HSI Claims

The ability to successfully defend an HSI tax credit claim during an IRS examination relies almost entirely on the quality and contemporaneous nature of the supporting documentation.12

5.1. The Documentation Imperative

Documentation requirements for the R&D credit are broad, requiring taxpayers to “retain records in a sufficiently usable form and detail to substantiate that the expenditures claimed are eligible for the credit”.11 For HSI, the documentation must reflect the real-time decision-making processes, the technical challenges encountered, and the structured application of the Process of Experimentation.13 Contemporaneous records, created as the R&D occurred, inherently carry more weight than post-hoc recollections or estimations.13

Key records for HSI substantiation include technical design requirements, system specifications or schematics, prototype build logs, detailed failure analysis reports, formalized test plans, and the resulting test data and evaluations.11

5.2. Strategy for Defending HSI Claims in an Examination Context

During an IRS examination, the taxpayer must present a clear, organized narrative linking the technical efforts to the claimed financial expenditures.15 Organizing the claim by major project categories—such as autonomous navigation systems, machine-vision integration, or improved kinematics—helps the examiner grasp the scope and technical validity of the research.15

Examiners will focus heavily on the taxpayer’s cost accounting system and request documentation explaining how the time of engineers, programmers, and consultants, as well as the consumption of supplies, was tracked and allocated to qualified research activities.11 If the documentation is insufficient, the extent of reliance on oral testimony will be weighed. While testimony from employees who performed the research may be used, the IRS is not obligated to accept estimates or extrapolations, emphasizing the need for robust, written, contemporaneous evidence required under $\S 6001$.14 Proactive, transparent reporting and integrated planning across R&D and tax departments are essential for successful audit defense.12

VI. Future Regulatory Clarification and Next Steps

To further clarify and maximize the effective use of the R&D credit for advanced, integrated HSI systems, Treasury and the IRS should take proactive steps to reduce definitional and substantiation ambiguities.

6.1. Formal Definition of Integrated Control Software (ICS)

Recommendation: The IRS should issue a dedicated Revenue Ruling or update existing regulations to formally define and provide a explicit safe harbor exemption for Integrated Control Software (ICS).

Current regulations lack explicit guidance tailored to software embedded within physical products, often forcing reliance on the general “commercial sale” exception.6 This ambiguity leads to ongoing audit disputes regarding whether necessary components like firmware, operating systems, or real-time control logic constitute non-qualifying Internal Use Software if they also perform ancillary internal monitoring functions. Formally defining ICS as software essential to operate, control, or monitor the function, performance, or reliability of a tangible physical business component sold or leased to third parties would definitively eliminate this major area of contention, encouraging greater investment in advanced HSI technologies such as IoT, robotics, and complex industrial automation systems.

6.2. Harmonizing Audit Guidance for HSI’s Dual-Domain Process of Experimentation (PoE)

Recommendation: The IRS Research Credit Audit Techniques Guide (ATG) must be updated to include explicit, detailed case studies illustrating how the systematic evaluation of alternatives works when hardware and software iterations are interdependent.

Existing audit guidance provides extensive detail on the PoE for general software 9 but less on how to assess the simultaneous, dual-domain experimentation inherent in HSI. New guidance should confirm that the failure of a hypothesis in one domain (e.g., a physical constraint identified during a prototype test) can appropriately trigger a subsequent qualifying R&D activity in the complementary domain (e.g., modifying control logic to mitigate the physical limitation). Furthermore, this updated guidance should affirm that modeling and simulation costs—specifically high-performance computing (HPC) and cloud compute resources—are intrinsically qualified when used to test the combined physical and algorithmic alternatives necessary for integrated system function.1

6.3. Clarification on QRE Allocation for Shared R&D Resources

Recommendation: The IRS should publish explicit guidelines detailing acceptable allocation methodologies for shared computer rental/lease expenses and specialized facility costs.

HSI often requires substantial financial investments in high-cost, specialized testing infrastructure, cloud compute for algorithm training, and dedicated test laboratories.1 These resources are frequently utilized across both qualified R&D tasks (e.g., model iteration) and non-qualified routine operations (e.g., production system monitoring, routine quality assurance). Clear regulatory guidelines are necessary to substantiate the qualified portion of these expenditures. Such guidance should explicitly recognize advanced tracking systems—such as cloud compute usage logs tied to specific GPU clusters, or detailed time logs correlated to specific laboratory equipment usage—as “best evidence” for accurately apportioning the cost, similar to the level of detail required for wage substantiation.1

VII. Appendix: Key Regulatory Synthesis Tables

The following tables synthesize the essential technical requirements and financial substantiation metrics necessary for successfully claiming the R&D tax credit for Hardware-Software Integration activities.

HSI Activities and Satisfaction of the IRC § 41 Four-Part Test

Key HSI Qualified Research Expenses (QREs) and Substantiation Requirements

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/