Classify the software before estimating costs.
The internal-use rules focus on software developed primarily for general and administrative functions, such as financial management, human resources, and support services. Classification depends on the facts and intended use at the beginning of development (Treas. Reg. §1.41-4(c)(6)).
A system used by employees is not automatically disqualified, and a product with a customer-facing screen is not automatically outside the internal-use rules. Identify the functions being developed, their users, and how they relate to the business. Avoid treating a large application as a single undifferentiated item when distinct functions warrant separate analysis.
What is the high-threshold-of-innovation test?
Where the high-threshold-of-innovation test applies, the analysis addresses innovation, significant economic risk, and commercial availability. The ordinary research requirements also remain relevant. A business case showing expected savings alone does not demonstrate that development satisfies all of these tests.
For an internal scheduling platform, for example, separate the expected operating benefit from the unresolved technical questions. Preserve records of the alternatives considered, the technical obstacles, and the work needed to evaluate them. A demanding integration project is not necessarily qualifying research simply because implementation took longer than planned.
The general software development guide covers activity evidence that remains useful alongside this classification review.
Review software with internal and external functions.
Some systems serve employees and also let customers or other third parties initiate functions or review data. The regulations contain specific dual-function rules. Identify the relevant functions and supported subsets before applying any special treatment.
Provide user-flow descriptions, architecture diagrams, access roles, and original requirements. These can help explain which capabilities were intended for external interaction and which supported administration. The applicable rules should be evaluated against those facts rather than a product's marketing label.
Discuss material changes in intended use with the preparation team. Later customer adoption does not necessarily explain the purpose documented when development began.
What software records should you keep?
- Purpose: Original requirements and intended users.
- Alternatives: Build-versus-buy evaluations and available solutions considered.
- Technical work: Design decisions, prototypes, benchmarks, and test results.
- Costs: Employee work, contractor arrangements, and project periods.
- Boundaries: Routine configuration, maintenance, training, and other excluded work.
A procurement comparison can explain what was available, but it should not be rewritten after the fact to imply a review that never occurred. Preserve the records you have and identify gaps honestly.
Similarly, a software ticket count does not directly measure qualified expense. Tickets differ in scope and may combine technical investigation with ordinary fixes. Explain how the activity review connects to the employee wage analysis.
Not sure how your software is classified?
Paribus Advisors helps businesses and their accountants evaluate research activities and qualified expenses as part of R&D study preparation. An initial discussion can identify the software's purpose, the relevant tax years, and the records needed for a more focused review.
Tell us what the application does and who uses it. You do not need to know its tax classification before calling. We can help identify the questions to review and the records your tax team will need.