Start with the technical work, not the product label.
Software development can raise research credit questions when the team seeks a new or improved function, performance, reliability, or quality and evaluates alternatives to resolve technical uncertainty. The statutory requirements apply to the actual activities, not to the label SaaS, AI, platform, or proprietary software (IRC §41(d)).
Describe what the team did not know at the outset: whether it could achieve a technical objective, which approach could work, or how to design a solution. Then explain the evaluative process. A feature request, commercial deadline, or general wish to improve an application does not by itself establish qualifying research.
Separate experimentation from ordinary implementation.
Consider a team evaluating competing data-processing architectures because it is uncertain how to meet a documented throughput and reliability requirement. Preserved benchmarks, failed approaches, and design decisions may help explain the experimentation. Qualification still depends on the full facts and applicable requirements.
By contrast, installing a known package, configuring a standard integration, changing screen text, or applying a routine patch may involve skilled work without the necessary research process. A difficult task is not automatically qualified research, and an unsuccessful project is not automatically excluded.
A single release can include both kinds of work. Separate the technical investigation from routine implementation, customer onboarding, maintenance, and support. Avoid classifying an entire engineering department as research simply because it contributes to the same product.
Internal-use software needs a closer look.
Software developed primarily for general and administrative functions can be subject to additional internal-use requirements. The regulations distinguish that software from certain software developed for sale or third-party interaction, and include rules for dual-function software and exceptions (Treas. Reg. §1.41-4(c)(6)).
“Our employees use it” is not a sufficient classification. Identify what the software does, who uses it, and whether it supports financial management, human resources, or other administrative functions. A production system, customer-facing function, and accounting application may raise different questions.
Where the additional high-threshold-of-innovation test applies, the analysis includes innovation, significant economic risk, and commercial availability. Document those facts specifically rather than assuming custom development meets the test.
Match development records to your expenses.
Useful records may include architecture decisions, issue histories, prototypes, benchmark results, test output, pull requests, and dated design discussions. A repository can show changes, but commit counts alone are not a reliable measurement of qualified employee services.
Map the relevant work to employees, periods, and business components. Explain which services were included and excluded, and reconcile wage schedules to payroll. For outside developers, examine agreements, rights, financial risk, and where the research occurred. An invoice labeled software development is not enough to determine federal credit treatment.
Document technical facts while participants can explain them. Preserve links or exports from systems whose records may later be deleted. Our time-record guide discusses how to approach incomplete project tracking.
Tell us about your software project.
For an initial conversation, choose one project and explain the technical objective, the approaches considered, and the records available. Include your accountant and a technical contact when possible. You do not need to prepare a tax narrative before calling.
Paribus prepares R&D tax credit studies and supporting claim packages for businesses and their advisors. Call to discuss how your development records could support an activity and expense review. State credit treatment and research outside the United States should be assessed separately from the basic software discussion.
More help with your R&D credit.
Our internal-use software guide explains classification, mixed functions, and the evidence needed for a focused review.