Internal-use software refers to computer programs developed by a taxpayer primarily for general and administrative functions or non-computer services, which are generally excluded from the Texas research and development tax credit. [cite_start]For such software to qualify, it must satisfy a rigorous three-part high threshold of innovation test in addition to the standard four-part qualification criteria mandated by the state. [cite: 3]

The Evolution of the Texas Research and Development Tax Credit and the Software Dichotomy

The Texas Research and Development (R&D) tax credit has historically functioned as a critical mechanism for fostering technological advancement within the state’s borders. However, its application to software development has been characterized by significant regulatory volatility, particularly concerning the distinction between software developed for commercial exploitation and software developed for internal operational purposes. [cite_start]The statutory basis for the credit is found in Texas Tax Code Chapter 171, Subchapter M, which incorporates by reference the definitions of “qualified research” and “qualified research expense” (QRE) from Section 41 of the Internal Revenue Code (IRC). [cite: 3]

The primary challenge for Texas taxpayers has been the state’s historical “decoupling” from the current federal IRC. Until the passage of Senate Bill 2206 in 2025, Texas law adhered to the IRC as it existed on December 31, 2011. This adherence created a “static conformity” that excluded subsequent federal regulatory updates, most notably the 2016 federal regulations that significantly relaxed the internal-use software (IUS) exclusion at the national level. [cite_start]Consequently, Texas maintained a more restrictive environment for software developers, necessitating the use of older, more stringent federal standards that were often interpreted even more narrowly by the Texas Comptroller of Public Accounts. [cite: 3]

The “former rule” period, which largely encompasses franchise tax reports originally due between January 1, 2014, and the full implementation of the new permanent credit in 2026, is defined by the Comptroller’s Rule 3.599. This rule has seen multiple iterations, with the most controversial changes occurring in October 2021 and August 2022. These amendments sought to codify a long-standing but often unwritten Comptroller policy that favored “cutting-edge” physical research over “run-of-the-mill” software programming. [cite_start]The resulting landscape required taxpayers to navigate a complex matrix of elective treasury regulations and heightened evidentiary standards to prove that their internal software projects were truly innovative. [cite: 3]

Statutory Foundations and the Impact of Static Conformity

The Texas R&D credit’s reliance on the 2011 IRC established a rigid framework that did not account for the rapid digitalization of the modern economy. Under Texas Tax Code Section 171.651, the state adopted federal definitions to ensure some level of consistency, yet the Comptroller reserved the right to issue independent guidance on how these definitions would be applied for Texas franchise tax purposes. [cite_start]This led to a bifurcated system where software developed for sale, lease, or license was generally treated as a standard “business component,” while software developed for internal use faced an uphill battle for eligibility. [cite: 3]

The static conformity to the 2011 IRC meant that for years, Texas taxpayers could not utilize the more taxpayer-friendly 2016 federal IUS regulations, which clarified that software developed for third-party interaction (such as customer-facing banking portals) was not IUS. [cite_start]Instead, the Comptroller’s 2021 amendments initially attempted to categorize nearly all internal software development as non-qualified, arguing that such activities did not meet the “technological in nature” or “discovery” tests as strictly interpreted by the agency. [cite: 3]

The Internal-Use Software Exclusion: Definitions and G&A Functions

The core of the IUS controversy lies in the definition of “internal use.” Under the former rules and the Comptroller’s guidance in STAR documents such as 202302001L, software is considered IUS if it is developed by a taxable entity for use in general and administrative (G&A) functions or in providing non-computer services. [cite_start]This classification creates a presumption of non-eligibility that the taxpayer must overcome. [cite: 3]

General and Administrative Functions Analyzed

The Comptroller identifies three primary silos of G&A functions that trigger the IUS exclusion. [cite_start]These are not merely suggestions but serve as a definitive list for audit purposes: [cite: 3]

1. Financial Management: This encompasses any software developed for payroll, bookkeeping, accounting, tax compliance, or internal financial reporting. [cite_start]The logic here is that while the software may be complex, it does not directly contribute to a business component held for sale or used in a production process. [cite: 3]

2. Human Resources Management: Software developed for personnel management, benefits administration, employee training, or recruiting falls under this category. [cite_start]Even if a company develops a sophisticated AI for hiring, it is likely viewed as IUS because it manages the taxpayer’s own workforce. [cite: 3]

3. Support Services: This broad and often contested category includes marketing, facility services, legal services, and security services. [cite_start]Software developed to manage a company’s real estate portfolio or its internal legal department is typically excluded from the standard credit definition. [cite: 3]

The Presumption of Internal Use

Under the IRB 2002-4 version of the treasury regulations, which the Comptroller allows taxpayers to elect, there is a strong presumption that software is IUS unless it is developed to be commercially sold, leased, licensed, or otherwise marketed for separately stated consideration to unrelated third parties. [cite_start]This “separately stated consideration” requirement is a high bar, as it often excludes software that is bundled with services or provided for free as an ancillary benefit to customers. [cite: 3]

The High Threshold of Innovation Test

For software that is deemed IUS, the only path to qualification is the “High Threshold of Innovation” (HTI) test. This is an additional layer of scrutiny that must be satisfied after the project has already passed the standard four-part test for qualified research. [cite_start]The HTI test is composed of three distinct prongs, all of which must be met with “clear and convincing” evidence. [cite: 3]

Prong 1: The Innovativeness Test

The software must be innovative in that it is intended to result in a reduction in cost, improvement in speed, or other improvement that is substantial and economically significant. The “substantial and economically significant” requirement is inherently qualitative, leading to frequent disputes between auditors and taxpayers. [cite_start]The Comptroller’s guidance suggests that the improvement must be measured against software that is within the “common knowledge of skilled professionals” in the field at the time the research began. [cite: 3]

Prong 2: The Significant Economic Risk Test

The taxpayer must prove that they committed substantial resources to the development and that there was a substantial uncertainty, because of technical risk, that the resources would be recovered in a reasonable period. This test is focused on the technical possibility of failure, not just the business risk of the project being canceled for budgetary reasons. [cite_start]The taxpayer must demonstrate that the technical challenges were so formidable that the project’s success was in doubt from an engineering perspective. [cite: 3]

Prong 3: The Commercial Availability Test

The software must not be commercially available for use by the taxpayer. This means the taxpayer could not have purchased, leased, or licensed a software package that could fulfill the intended purpose with modifications that would not themselves satisfy the first two prongs of the HTI test. [cite_start]This requirement often forces taxpayers to provide exhaustive documentation of their “make vs. buy” analysis and to prove that no COTS solution was viable. [cite: 3]

Mandatory Exceptions to the IUS Exclusion

[cite_start]

Recognizing that modern software development is often hybrid in nature, both the 2011 IRC and the Comptroller’s subsequent rules provide several “safe harbors” where software is not treated as IUS, even if it is used within the company. [cite: 3]

Software for Computer Services

Software developed to provide computer services is exempt from the IUS exclusion. This is particularly relevant for the Software-as-a-Service (SaaS) industry. If the customer is paying specifically for the functionality provided by the software, the development of that software is not IUS. [cite_start]However, the Comptroller has historically challenged this if the software is seen as merely a delivery mechanism for a “non-computer service” like banking or consulting. [cite: 3]

Integrated Hardware-Software Products

When software is developed as an integral part of a hardware product, and the package is used directly by the taxpayer to provide services to customers, it is exempt from the IUS exclusion. The classic example provided in Treasury Regulation 1.41-4(c)(6) is the development of software for an Automated Teller Machine (ATM) or a telecommunications switch. [cite_start]In these cases, the hardware and software function as a single unit to provide a service, and the software is not viewed as a G&A tool. [cite: 3]

Production Process Software

Software developed for use in a production process that meets the requirements of the standard four-part test is not considered IUS. [cite_start]For instance, if a manufacturer develops custom software to control a robotic assembly line, that software is integral to the production of the company’s external business component and is thus excluded from the IUS definition. [cite: 3]

The 2021 Regulatory Pivot and the “Complete Disallowance” Controversy

In October 2021, the Texas Comptroller filed amendments to Rule 3.599 that sent shockwaves through the state’s technology sector. These amendments explicitly listed “internal use software” as a non-qualified research activity and removed many of the nuanced exceptions that taxpayers had previously relied upon. [cite_start]Furthermore, the Preamble to the 2021 rule stated that these changes were an “exposition of existing Comptroller policy,” signaling a retroactive application dating back to 2014. [cite: 3]

This period was characterized by what many tax professionals called the “Complete Disallowance” of IUS. Auditors began systematically denying credits for any software that wasn’t held for direct sale, even if it was highly innovative or customer-facing. [cite_start]Industry groups, including the Texas Taxpayers Research Association (TTRA) and the Council on State Taxation (COST), filed formal protests, arguing that the Comptroller’s rules were narrower than the legislature intended and would stifle investment in Texas. [cite: 3]

The 2021 rules also introduced the “clear and convincing evidence” standard for establishing the credit. In traditional tax law, a taxpayer must usually show a “preponderance of the evidence” (more likely than not) to sustain a position. [cite_start]By raising the bar to “clear and convincing,” the Comptroller made it significantly harder for software developers to overcome the subjective judgments of auditors regarding what constitutes “innovation” or “technical risk”. [cite: 3]

The August 2022 Softening and the Dual Elective Regime

Faced with potential litigation and widespread dissatisfaction, the Comptroller issued a second set of amendments in August 2022. These amendments “softened” the IUS restrictions by allowing taxpayers to elect between two different versions of the federal treasury regulations for internal-use software. [cite_start]This was a major concession, as it allowed taxpayers to choose the regulatory framework that best suited their specific facts and circumstances. [cite: 3]

Election 1: Treasury Regulation § 1.41-4(c)(6) (revised as of April 1, 2003) and IRB 2001-5

This version is often preferred by companies in the financial services or insurance sectors because it contains a unique exception for software used to provide “non-computer services”. For example, if a bank develops a new online banking platform that offers features not available from competitors, and these features are designed to attract customers to the bank’s services, the software might be exempt from IUS treatment under this exception. [cite_start]However, this version requires that the service provided be a “technological service” when applying the single-product rule for hardware-software bundles. [cite: 3]

Election 2: Proposed Treasury Regulation § 1.41-4(c)(6) as contained in IRB 2002-4

This version is notable for establishing a strong presumption of IUS status at the start of the research. However, it is often viewed as more flexible for hardware-software integration because it allows the combined product to provide “any” service, not just a “technological” one. [cite_start]This version also includes twelve additional examples that provide more granular guidance for complex IT environments, though it eliminates the specific non-computer services exception found in IRB 2001-5. [cite: 3]

Taxpayers must apply the elected version in its entirety and cannot “cherry-pick” provisions from both. [cite_start]This election is made on the franchise tax report and is binding for that period. [cite: 3]

The Evidentiary Burden: Clear and Convincing Evidence

One of the most enduring legacies of the “former rule” period is the Comptroller’s insistence on “clear and convincing” evidence and contemporaneous documentation. [cite_start]Rule 3.599(e)(2) specifically mandates this higher burden, which the agency argues is necessary to prevent the credit from being applied to “run-of-the-mill” programming. [cite: 3]

Contemporaneous Documentation Requirements

To satisfy the Comptroller, a taxpayer must provide records created during the development process. Post-hoc narratives created during an audit are frequently rejected as insufficient. [cite_start]For software projects, the required documentation typically includes: [cite: 3]

1. [cite_start]Project Approval Documents: Evidence that management authorized the project and identified specific technical uncertainties at the outset. [cite: 3]

2. [cite_start]Design Specifications and Architecture Diagrams: Proof of the “technical nature” of the work and the underlying engineering challenges. [cite: 3]

3. [cite_start]Testing Logs and Bug Reports: Documentation of the “process of experimentation,” showing that the team evaluated multiple alternatives to resolve technical uncertainty. [cite: 3]

4. [cite_start]Time-Tracking and Payroll Records: Direct links between specific employees, their R&D activities, and the qualified expenses claimed. [cite: 3]

The “Discovery Test” and Scientific Advancement

A significant point of friction in Texas audits is the “Discovery Test.” Historically, the Comptroller has argued that qualified research must discover information that “exceeds, expands, or refines the common knowledge of skilled professionals” in the field. This is a much higher bar than the federal “Uncertainty Test,” which only requires that the information be unknown to the taxpayer. [cite_start]While industry groups have fought this interpretation in court, the Comptroller’s guidance continues to emphasize that “simple trial and error” or “brainstorming” is not qualified research. [cite: 3]

Case Study: Navigating the IUS Exclusion in the Healthcare Sector

[cite_start]

To understand the practical application of these rules, consider “MedTech Analytics,” a Texas-based company that developed a new internal data platform in 2023 to manage patient outcomes and insurance billing. [cite: 3]

Project A: The Billing Optimization Engine

MedTech developed an internal tool to automate the complex billing codes required for various insurance providers. While the software used advanced logic, the primary purpose was “Financial Management”—improving the accuracy and speed of the billing department. [cite_start]Under Rule 3.599, this is clearly IUS. [cite: 3]

[cite_start]

To qualify, MedTech must pass the HTI test. [cite: 3]

[cite_start]
• Innovativeness: MedTech argues that the engine reduces billing errors by 90% and increases processing speed by 400%. [cite: 3]

[cite_start]

• Significant Economic Risk: MedTech must prove that the integration with fragmented insurance databases was technically uncertain and that they risked $1.5 million in payroll without a guaranteed outcome. [cite: 3]

[cite_start]

• Commercial Availability: MedTech must show that no COTS billing software could handle their proprietary data structure. [cite: 3]

[cite_start]

If MedTech lacks contemporaneous logs of the failed iterations (the process of experimentation), the Comptroller will likely deny the credit based on the “clear and convincing” standard. [cite: 3]

Project B: The Diagnostic Imaging AI

MedTech also developed an AI model to assist their staff radiologists in identifying anomalies in X-rays. [cite_start]Because this software is used in the “production process” of providing diagnostic reports (the company’s primary service), it is exempt from the IUS exclusion and only needs to pass the standard four-part test. [cite: 3]

Project C: The Patient Portal

MedTech developed a portal for patients to view their results and schedule appointments. If MedTech elects the IRB 2001-5 version, they can argue this is an “ancillary computer service” or a “non-computer service” that attracts customers, potentially exempting it from the IUS exclusion. [cite_start]If they elect IRB 2002-4, they face the IUS presumption and must pass the HTI test. [cite: 3]

The 2025 Legislative Transformation: SB 2206

[cite_start]

Recognizing the administrative burden and the competitive disadvantage of the “former rules,” the Texas Legislature passed Senate Bill 2206 in June 2025. This legislation overhauls the credit for reports due on or after January 1, 2026, and fundamentally changes the treatment of software. [cite: 3]

Rolling Conformity to Federal Form 6765

The most transformative change is the adoption of “rolling conformity.” The Texas QRE is now defined as the portion of the amount reported on line 48 of federal Form 6765 attributable to research conducted in Texas. This effectively incorporates the modern federal IUS regulations (including the 2016 relaxed standards) into Texas law. [cite_start]Taxpayers no longer have to navigate the elective regimes of Rule 3.599 or satisfy a state-specific HTI test that differs from federal standards. [cite: 3]

Transition to a Permanent, Refundable Credit

The new regime eliminates the expiration date of the credit, providing long-term certainty for R&D investors. [cite_start]Furthermore, it introduces a refundable component for entities with no franchise tax due, which is a “game-changer” for startups and small tech companies that are often in a loss position while developing software. [cite: 3]

The Repeal of the Sales Tax Exemption
[cite_start]

As part of the compromise to make the credit permanent and more generous, the legislature repealed the sales and use tax exemption for research property effective January 1, 2026. For software developers, this means that while the franchise credit is easier to claim, they will now have to pay sales tax on the servers, computers, and specialized hardware used in their labs. [cite: 3]

Administrative Procedures and Audit Defense under Rule 3.599

Until the 2026 rules take full effect, taxpayers under audit or filing for open years must adhere to the administrative requirements of Rule 3.599. [cite_start]The Comptroller’s Tax Policy Division has issued several memoranda clarifying how these audits should be conducted. [cite: 3]

The Role of Statistical Sampling

For large software organizations, the Comptroller permits the use of statistical sampling as described in IRS Revenue Procedure 2011-42. This allows an auditor to review a representative sample of software projects rather than examining every project in a company’s portfolio. [cite_start]However, if the sample finds that a significant portion of “internal use” projects fail the HTI test, the entire credit claim can be adjusted downward proportionately. [cite: 3]

Interaction with IRC Section 174

Recent guidance from the Comptroller in March 2025 emphasizes the interplay between IRC Section 174 and the R&D credit. The Comptroller clarified that while an expense must be a Section 174 expense to be eligible for the credit, this is a “necessary but not sufficient” condition. [cite_start]For software, this means that even if development costs are properly capitalized for accounting purposes or deducted under Section 174, they can still be excluded from the credit if they fail the IUS/HTI tests or are deemed “routine maintenance”. [cite: 3]

The Shrink-Back Rule

When a software project is too broad to qualify as a single “business component,” Rule 3.599 allows for the “shrink-back” rule. This permits taxpayers to carve out the specifically qualified portions of a development effort. [cite_start]For example, if a company builds a new HR portal (generally excluded), but within that project, they develop a revolutionary new database encryption algorithm, the costs associated with the algorithm may qualify even if the portal itself does not. [cite: 3]

Judicial Precedents and the Future of Policy

The legal battles surrounding the Texas R&D credit continue to shape the state’s tax policy. [cite_start]Cases like Ryan LLC v. Hegar highlight the tension between the Comptroller’s desire for “cutting-edge” innovation and the legislature’s intent to provide a broad-based incentive for all types of technological advancement. [cite: 3]

The 2025 legislative changes represent a significant victory for the taxpayer community, effectively overriding many of the Comptroller’s most restrictive interpretations. [cite_start]By tying the credit to federal law, the state has acknowledged that the 2011 “discovery test” and the “clear and convincing” burden were out of step with the competitive needs of the Texas economy. [cite: 3]

However, for those navigating the “former rule” period, the Comptroller remains a formidable gatekeeper. [cite_start]Success in claiming the credit for internal-use software requires a deep understanding of the 2001-5 vs 2002-4 elective versions, a robust repository of contemporaneous documentation, and the ability to articulate technical risk in a way that satisfies an auditor’s subjective standard of “innovation.” [cite: 3]

As Texas moves into the permanent credit era, the historical “former rules” for internal-use software will eventually fade into memory. Yet, they remain a vital case study in the challenges of static tax conformity and the profound impact that administrative rule-making can have on the trajectory of a state’s technological ecosystem. [cite_start]For now, software developers in Texas must continue to walk the fine line between routine operations and high-threshold innovation, ensuring that every line of code is backed by the evidence required to sustain its place in the research and development framework. [cite: 3]

Final Thoughts