Software companies have specific considerations when evaluating R&D tax credit software. Their activities involve software development, which raises particular documentation needs — architecture, uncertainty, experiments, engineering evidence, and the internal-use-software rules. This page explains what R&D tax credit software for software companies should track. It is educational and is not individualized advice, and it does not imply that Git commits automatically prove qualification. For the underlying framework, see our page on software development and the R&D tax credit.
Projects and Features
The software should track projects and features at the business-component level. A business component may be a software product, a module, a platform, or a feature set. The software should allow the company to define business components and organize activities, uncertainty, and experiments around them. For more on the business-component concept, see our page on qualified research.
Architecture and Design
The software should track architecture and design decisions — the alternative architectures or designs considered, the technical questions they were intended to resolve, and the evaluation process. This supports the process-of-experimentation element, which looks for an evaluative process of alternatives. For more on this element, see our page on process of experimentation.
Technical Uncertainty
The software should track the technical uncertainty associated with each project — the specific question about capability, method, or appropriate design that was not established at the outset. In software development, this may include uncertainty about whether a system can achieve a target capability, which architecture can meet a performance target, or how to integrate systems. For more on this concept, see our page on documenting technical uncertainty.
Experiments and Evaluation
The software should track the experiments and evaluation process — the alternatives tested, the benchmarks or tests conducted, and the results. In software, this may include performance benchmarks, prototype testing, simulation, or systematic comparison of alternative approaches. For more on experiment-level records, see our page on R&D experiment logs.
Engineering Evidence
The software should track engineering evidence — design documents, architecture diagrams, test results, performance benchmarks, and similar artifacts — and connect them to the projects they support. Centralizing engineering evidence by project makes it easier to find and review. For more on evidence organization, see our page on R&D evidence tracking.
Employee Allocation
The software should track which employees worked on which projects, for what portion of their time, and what their wages were. In software companies, developers often work on multiple projects, so allocation is particularly important. The software should support per-employee, per-project time and effort tracking. For more on the wage framework, see our page on R&D tax credit employee wages, and for time tracking, see R&D time tracking.
Contractor Development
If the company uses contractors for development, the software should track contractor costs by project and analyze whether they meet the contract-research requirements — economic risk, rights to results, and U.S. performance. For more on contractor costs, see our page on R&D tax credit contractor costs.
Repository and Ticket Evidence
Repositories (e.g., Git) and ticketing systems (e.g., Jira, Linear) contain evidence of development activity — commits, pull requests, issues, and milestones. The software may help organize or link this evidence to projects. However, repository and ticket evidence does not automatically prove qualification. A commit history shows that work was done, but it does not establish that the work constituted qualified research under the four-part test. The software should help connect repository and ticket evidence to the technical uncertainty, alternatives, and evaluation that the qualified-research analysis requires. For more on the four-part test, see our page on the four-part test.
Internal-Use Software Considerations
Software developed primarily for the company's internal use is subject to additional requirements beyond the four-part test, including a high threshold of innovation. The software should help track whether a project is internal-use or interacts with third parties, as this affects the analysis. For more on this topic, see our page on internal-use software.
What the Software Does Not Do
R&D tax credit software for software companies does not determine whether activities qualify. It does not automatically analyze commit histories or ticket data to establish qualification. It does not replace professional judgment. It organizes information; the substantive analysis is a separate step. For more on choosing a consultant with software expertise, see our page on R&D tax credit consultant for software development.
Key Takeaway
R&D tax credit software for software companies should track projects and features, architecture and design, technical uncertainty, experiments and evaluation, engineering evidence, employee allocation, contractor development, and repository and ticket evidence. Repository and ticket evidence does not automatically prove qualification, and internal-use software may be subject to additional requirements. For more on the underlying framework, see our page on software development and the R&D tax credit.