Navigating the High Threshold: Internal Use Software Guidelines and the Indiana R&D Tax Credit

I. Executive Summary: The Definition of Internal Use Software (IUS)

Internal Use Software (IUS) refers to computer programs developed primarily for a company’s own general and administrative functions.

To qualify for the Indiana Research Expense Credit (REC), IUS development must satisfy the standard four-part test for qualified research and a three-part “High-Threshold-of-Innovation” (HTI) test.

The State of Indiana provides the Research Expense Credit (REC) through Indiana Code (IC) 6-3.1-4, which serves as a vital incentive for corporate investments in research and development activities conducted within the state.1 While the Indiana REC generally follows the framework of the federal Credit for Increasing Research Activities (IRC §41), the development of computer software, particularly that intended for internal use, is subject to exceptionally strict qualification rules.2 The Indiana Department of Revenue (DOR) mandates that any software classified as IUS must meet a rigorous three-part “High-Threshold-of-Innovation” (HTI) test in addition to the foundational federal four-part test for qualified research.2 This high barrier is designed to limit the credit to internal projects that represent true technological breakthroughs rather than routine business system improvements or customizations.4

II. The Statutory and Regulatory Foundation of the Indiana REC

A. Federal Nexus and State Modification

The Indiana REC is structurally dependent upon, but not identical to, the federal R&D tax credit regime. This relationship necessitates careful application of federal rules alongside state-specific modifications.

The definition of Qualified Research Expenses (QREs) for the Indiana credit is directly tied to Section 41(b) of the Internal Revenue Code (IRC).1 This ensures consistency in the types of costs eligible for the credit, primarily covering wages, supplies, and contract research expenses.5 However, Indiana modifies the federal definition by limiting eligibility exclusively to expenses for qualified research activities that are conducted in Indiana.1 The DOR considers the location where services are performed and where qualified research supplies are consumed when determining QREs.5

The economic value of the credit is calculated based on the taxpayer’s qualified research expenses incurred in Indiana. The standard method involves applying a 15% credit to the lesser of $1 million or the excess of current-year QREs over a defined base amount. A reduced credit percentage of 10% is applied to any excess QREs exceeding $1 million over the base amount.1 The credit is nonrefundable, but Indiana allows taxpayers to carry forward any unused research credits for a period of ten years.6

B. Mandatory Disclosure and Audit Consistency Requirements

Indiana law includes specific provisions requiring taxpayers to synchronize their state and federal research credit claims, which dramatically impacts audit risk.7

A taxpayer claiming the Indiana REC must formally report to the DOR whether a corresponding credit was determined and claimed for those same Indiana QREs under IRC Sec. 41(a)(1) or (c)(4).7 If the taxpayer pursues the Indiana credit but elects not to claim the federal credit for the corresponding expenses, they are statutorily obligated to disclose the precise reasons for this disparity to the DOR.7 Furthermore, the DOR states that it relies on guidance from the IRS in auditing the research credit, and explicitly follows any determination made by the IRS regarding a company’s research credit claim (excluding settlements), provided the expenses were incurred in Indiana.1

This policy creates a substantial burden of proof for any taxpayer attempting to claim the REC in Indiana for activities—such as high-risk IUS projects—that are deemed too risky to claim federally. The explicit requirement to disclose reasons for such disparity, coupled with the DOR’s policy of adhering to federal audit results, means that pursuing a state-only claim for technically challenging software development significantly heightens the likelihood of state audit scrutiny. If the underlying technical eligibility of the research is successfully challenged by the IRS, the DOR will almost certainly conform its determination, underscoring the necessity of ensuring that all claimed QREs, even those claimed exclusively in Indiana, meet the rigorous standards established by the federal tax code and subsequently adopted by Indiana.

III. Defining Internal Use Software (IUS) and the Standard Qualification Bar

A. IUS Classification: Focus on General and Administrative Functions

The initial step in claiming the REC for software development is determining whether the software is IUS or Non-IUS. This distinction is critical because it dictates whether the additional HTI requirements must be met.4

Internal Use Software is defined as software developed by (or for the benefit of) the taxpayer primarily for the taxpayer’s internal use.2 This classification hinges entirely on the intent of the taxpayer and the specific facts and circumstances known at the beginning of the software development process.2 IUS is generally understood as software supporting general and administrative functions that facilitate or support the conduct of the taxpayer’s trade or business. Examples include internal accounting systems, Human Resources (HR) platforms, or supply chain management tools used exclusively by internal staff.2

B. Standard Four-Part Qualification Test

Regardless of whether the software is classified as IUS or Non-IUS, all qualified research activity must first satisfy the foundational four-part test derived from IRC §41 8:

1. Permitted Purpose: The activity must relate to a new or improved function, performance, reliability, or quality of a business component.8
2. Technological in Nature: The research must fundamentally rely on principles of physical science, biological science, computer science, or engineering.8
3. Elimination of Uncertainty: The activity must be intended to discover information that resolves or eliminates uncertainty regarding the capability, methodology, or appropriateness of the development or improvement.8
4. Process of Experimentation: Substantially all of the activities must constitute elements of a systematic process of experimentation, which involves identifying alternatives and evaluating them through rigorous methods like modeling, simulation, or systematic trial-and-error.8

C. The Critical Distinction: IUS vs. Non-IUS

The determination of classification is vital because Non-IUS is exempt from the HTI test, needing only to meet the standard four criteria.4 Software is definitively not considered IUS if it is developed primarily for one of the following purposes 4:

1. Commercial Sale: Software developed to be sold, leased, licensed, or marketed to third parties.9
2. Process Integration: Software integral to a production process.2
3. Third-Party Interaction: Software developed specifically to enable third parties (like customers or vendors) to initiate functions and access data on the taxpayer’s system.4 For example, a manufacturer’s customer-facing web portal for online ordering and tracking is Non-IUS because it facilitates third-party interaction.11

Strategic classification of software is often the single most important factor in maximizing QRE claims.4 By structuring projects to enable robust third-party interaction, taxpayers can position the development costs to satisfy only the four-part test, thereby avoiding the notoriously difficult HTI hurdles.

IV. The High-Threshold-of-Innovation (HTI) Test

If software is classified as Internal Use Software, the taxpayer must demonstrate that the project meets all three rigorous prongs of the High-Threshold-of-Innovation test in addition to the standard four-part test.2

A. Prong 1: Innovative (Substantial and Economically Significant Improvement)

The first prong requires that the software must be Innovative.3 Innovation is quantified by demonstrating that the successful development of the software results in a measurable improvement, such as a reduction in cost or an increase in speed, that is substantial and economically significant.2 This is an outcome-based test, requiring taxpayers to prove that the resulting business value justifies the classification as truly innovative R&D, moving beyond mere incremental efficiency gains.3

B. Prong 2: Significant Economic Risk

The second prong requires demonstrating that the project involved Significant Economic Risk.3 This is arguably the most difficult test, demanding that the taxpayer commit substantial resources to the development and face substantial uncertainty, due to technical risk, that those resources would be recovered within a reasonable time frame.2 The risk must stem from technical challenges inherent in the development process, not from external market factors or routine project management issues. This prong directly reinforces the “Elimination of Uncertainty” requirement of the four-part test by tying the technical unknowns to significant financial exposure.

C. Prong 3: Not Commercially Available

The final prong requires that the software be Not Commercially Available.3 This means the software cannot be purchased, leased, or licensed and used for the intended purpose without necessitating modifications that would themselves satisfy the requirements of Innovation and Significant Economic Risk (Prongs 1 and 2).2 If a commercial off-the-shelf (COTS) solution exists that can be adapted through standard customization, the IUS project will fail this test, as the development effort must be fundamentally unique and proprietary to qualify.

The HTI test functions as an integrated validation mechanism, confirming the complexity and magnitude of the research effort. Prong 2 (Economic Risk) validates the technical difficulty and investment scale, while Prong 1 (Innovative) validates that the technical uncertainty was successfully resolved to produce a quantifiable, high-value result. The documentation required for these prongs must demonstrate this integrated complexity for the claim to withstand audit scrutiny.

Criteria for the High-Threshold-of-Innovation (HTI) Test

V. Categories of Software Exempt from the HTI Test

The Indiana DOR acknowledges several statutory exceptions to the HTI test, allowing certain types of IUS to qualify simply by meeting the standard four-part R&D test.2 These exemptions apply because the software’s function is integral to core, non-administrative R&D or production activities:

1. Software for Qualified Research: Software developed for use in an activity that otherwise constitutes qualified research, outside of the development of the internal use software itself.2
2. Software for Production Processes: Software developed for use directly in a taxpayer’s production process, such as specialized systems controlling manufacturing robotics or assembly flow.2
3. Integrated Hardware/Software Package: Software that is an integral part of a new or improved software and hardware package developed together as a single product (or costs to modify an acquired package), used directly by the taxpayer in providing services in its trade or business.2

VI. Navigating Dual-Function Software (DFS)

Dual-Function Software (DFS) poses a unique challenge because it simultaneously supports internal administrative functions (IUS) and enables interactions with third parties (Non-IUS).9

A. Presumption and Segmentation

DFS is inherently complicated and is initially presumed to be Internal Use Software.12 To overcome this presumption, the taxpayer must be able to identify a distinct component or subset of the software system that specifically enables interactions, functionalities, and data revisions with third parties.12 If the entire system is developed to enable third parties to interact with business systems, the entire project may be classified as Non-IUS.4 However, if the external functionality cannot be entirely separated from the internal administrative functions, the system falls under the DFS designation.

B. The 25% Safe Harbor Rule

For elements that remain classified as Dual-Function Software, a partial credit may be claimed under a regulatory safe harbor.4 This allows the taxpayer to include 25% of the Qualified Research Expenditures (QREs) related to the dual-function subset when calculating the research credit.12

This safe harbor is contingent upon meeting two strict criteria 11:

1. The research activities related to the development or improvement of the dual function software must still qualify as “qualified research” (meeting the four-part test).
2. The taxpayer must reasonably anticipate that the dual function software or subset’s use by third parties, or the taxpayer’s use to interact with third parties, will constitute at least 10 percent of the total use of that specific subset.11

This 10% usage threshold introduces a mandatory quantitative element for DFS claims. Taxpayers must produce documentation showing that, at the time of development, there was a credible expectation or projection, based on market needs or technical design, that external interaction would reach this minimum usage level. Without this initial quantification and subsequent corroboration of third-party use, the safe harbor provision cannot be utilized.

VII. Indiana DOR Compliance and Documentation Guidelines

The Indiana DOR emphasizes that adherence to documentation standards is critical for substantiating all REC claims, particularly given the heightened scrutiny of IUS.1

A. Contemporaneous Documentation Standard

Taxpayers are required to retain records in a “sufficiently usable form” and detail to substantiate claimed QREs and Qualified Research Activities (QRAs) at the project level, adhering to the standard established by Reg. § 1.41-4(d).1 The documentation should generally be gathered at the time the qualified research was performed.1 This principle prevents taxpayers from relying solely on oral testimony or management estimates years after the fact, which, without measurable corroborative records, is generally considered insufficient to support a claim.1

B. Key Records for IUS/HTI Substantiation

Successful defense of an IUS claim requires documentation that links specific expenditures directly to the resolution of technical uncertainty and the fulfillment of the HTI criteria. Essential documents include:

• Project Authorization: Project proposals, budgets, and work orders detailing the scope, objectives, and known technical uncertainties that initiated the research project.1
• Technical Proof: Testing verification data, summaries, progress reports, and meeting minutes documenting the systematic process of experimentation, alternatives evaluated, and the elimination of technical uncertainty.1
• HTI-Specific Records:

• Documentation of market scans and internal analyses demonstrating why commercially available software was unsuitable and why the required modifications would themselves constitute R&D (Prong 3).2
• Detailed R&D budgets and risk assessments quantifying the financial resources committed and the technical uncertainties that created substantial economic risk of resource recovery (Prong 2).2
• Metrics and validated data (before-and-after reports) confirming the substantial and economically significant improvement achieved in terms of cost reduction or speed enhancement (Prong 1).2

• Expense Substantiation: Detailed job descriptions and time records for each employee, documenting the percentage of time devoted specifically to qualified research activities conducted in Indiana.1

The audit focus for IUS claims is highly technical.1 Auditors look beyond simple expense records to verify that the taxpayer overcame genuine technical barriers through a systematic process, resulting in a demonstrable and superior outcome that could not have been achieved through standard commercial avenues.

VIII. Case Study: Applying IUS Guidelines to an Indiana Taxpayer

Consider a hypothetical Indiana-based financial services company, FinTech Solutions, and two software projects under consideration for the REC.

A. Example 1: Non-Qualifying Internal Use Software (Administrative Enhancement)

Project: FinTech Solutions develops an in-house proprietary software tool for employee performance tracking, resource allocation, and internal compliance training.

Analysis:

1. Initial Classification: This software is developed solely for internal human resources, administrative tracking, and managerial purposes. It facilitates or supports general administrative functions.2 Therefore, it is classified as Internal Use Software (IUS).
2. HTI Test Requirement: Since it is IUS and does not fall under any exception (it is not used in production, or integrated with hardware, or used for qualified research), it must satisfy the three-part HTI test.2
3. HTI Test Review:

• Innovative: While the system improved HR efficiency by 15%, FinTech cannot demonstrate that this improvement is “substantial and economically significant” relative to customized commercial HR platforms.
• Significant Economic Risk: The technical challenges involved mapping employee data and optimizing the user interface, which are common development risks, not uncertainties rooted in principles of computer science that jeopardize the recovery of substantial resources.2
• Not Commercially Available: Several specialized HR/compliance tracking solutions exist commercially, requiring only moderate configuration to achieve the desired outcomes. The modifications FinTech performed did not themselves rise to the level of innovation or significant economic risk.2

Conclusion: The QREs associated with this project are ineligible for the Indiana REC because the software development failed to meet the rigorous High-Threshold-of-Innovation Test.

B. Example 2: Qualifying Non-Internal Use Software (Third-Party Interaction)

Project: FinTech Solutions develops a new proprietary API and associated platform that allows third-party institutional clients to directly upload, manage, and revise complex financial data sets and initiate automated trading functions on FinTech’s systems.

Analysis:

1. Initial Classification: Although FinTech’s internal employees use the backend of this system to monitor the trading, the software’s primary function and design intent, established at the start of development, is to enable third parties (clients) to interact with the business systems.4
2. HTI Test Requirement: Since the software is primarily designed to facilitate third-party interaction, it is classified as Non-Internal Use Software (Non-IUS).11 Consequently, the HTI test is not required.4
3. Standard Test Review: FinTech must only prove the four-part test was met. They must show the development involved technical uncertainty (e.g., developing novel API security protocols or optimizing data transmission algorithms) and utilized a systematic process of experimentation based on computer science principles to achieve a permitted purpose.8

Conclusion: Assuming the four-part test is adequately documented, the QREs associated with the development of the client interaction platform are eligible for the Indiana REC. By structuring the software to prioritize third-party interaction, FinTech successfully navigated around the HTI hurdle.

IX. Conclusion and Strategic Recommendations

The Indiana Research Expense Credit is a powerful state incentive, but its application to software development, particularly Internal Use Software (IUS), is highly selective. The Indiana DOR’s reliance on the federal High-Threshold-of-Innovation (HTI) test ensures that only internal projects that resolve substantial technical uncertainty and deliver profound, measurable economic benefits qualify for the credit.

Strategic Recommendations for REC Compliance

1. Establish Clear Intent and Classification Upfront: Taxpayers must formally determine and document the primary function and user base of software at the project’s inception. This critical step determines whether the project must satisfy the four-part test, the HTI test, or if it falls into an exception category.2
2. Leverage HTI Exemptions Strategically: Wherever possible, structure software development to fall into the Non-IUS categories. Developing systems that are integral to manufacturing processes or designed specifically for robust third-party interaction (e.g., customer portals, vendor integration tools) bypasses the rigorous HTI test entirely, significantly increasing the probability of a successful claim.2
3. Mandatory Quantification for HTI and DFS: For projects classified as IUS, rigorous quantitative documentation is non-negotiable. This includes detailed evidence demonstrating that the financial benefits are “substantial and economically significant” (Prong 1) and, for Dual-Function Software, concrete projections showing that third-party usage is reasonably anticipated to meet the 10% safe harbor threshold.2
4. Maintain Audit-Ready Documentation: Given the DOR’s policy of deference to IRS audit findings and the mandatory disclosure requirement for non-claimed federal expenses 1, documentation standards must meet the highest federal level of detail. Taxpayers should contemporaneously collect records—including technical risk logs, market unavailability studies, and process of experimentation narratives—to substantiate the resolution of technical uncertainty and the satisfaction of the HTI criteria.1

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/