Internal use adds another eligibility hurdle
Software developed primarily for a taxpayer's internal general and administrative functions generally must satisfy the research-credit high-threshold-of-innovation test in addition to the ordinary qualified-research requirements. That additional test examines innovation, significant economic risk, and commercial availability under the governing rules. Financial management, human resources, and support functions can fall within this internal-use category. The fact that software is customized or costly does not by itself establish eligibility.
Some software is outside this classification or qualifies for an exception. Software sold to customers, software used for certain production or qualified-research functions, and systems interacting with third parties need analysis based on their actual purpose. A project containing both internal administrative and customer-facing functions may require separate treatment. The useful question is what each function does and why it was developed, not whether employees happen to use the same login page. Cost deductibility under the research-expenditure rules remains separate from credit eligibility. The company can have research-related tax costs without a corresponding credit for every dollar of development spending.
Separate a hypothetical system into functions
Assume a business spends $500,000 developing a platform. Its documented cost allocation assigns $300,000 to internal financial reconciliation, $150,000 to a distinct customer ordering interface, and $50,000 to routine data conversion. Assume the customer-facing subset meets the ordinary research requirements and the internal financial subset does not satisfy the additional innovation threshold. The routine conversion is also excluded. Before other qualified-expense rules, the supported activity pool is therefore $150,000 rather than $500,000.
If $100,000 of that customer-facing amount is qualifying employee research wages and $50,000 is ordinary qualifying contract research subject to the 65 percent rule, the illustrative qualified-expense input is $132,500. That equals $100,000 plus $32,500. This is not the credit amount. Historical base computations, section 280C, and credit limitations still apply. The example assumes separate functions can be supported and that every described qualifying expense meets the relevant requirements. It does not imply that a customer interface automatically qualifies or that internal financial software never can. The classification determines which tests must be met; evidence determines whether the particular function passes them.
Preserve the alternatives considered before development
Retain the project charter, functional requirements, architecture, and contemporaneous analysis of available commercial products. For the internal-use test, the commercial-availability review should address whether available software could perform the intended purpose without modifications meeting the applicable conditions. A vendor list prepared after filing is weaker evidence than the actual procurement and technical evaluation used when the business committed resources.
Document the technical uncertainties, potential improvements, resources at risk, and experimental process. A large budget or risk of missing a launch date does not necessarily establish the required technical and economic risk. Keep evidence of competing approaches, prototypes, failures, and decisions made during development. Separate ordinary business-process redesign from technical experimentation. Time records should connect employees and contractors to the functions reviewed, rather than classifying every developer as fully qualified all year. If the system's intended purpose changes, preserve the date and approved scope change. A project that begins as an administrative tool and later adds external functions needs a timeline, not a retroactive assumption that the whole system always served customers.
Keep the credit estimate tied to architecture
Finance should revisit the credit forecast when functionality is removed, outsourced, purchased commercially, or moved into routine implementation. Those changes can alter eligibility even if the approved project budget remains unchanged. The tax estimate should follow supported work performed rather than a fixed percentage of capital spending.
For mixed-function software, review the rules for identifying a third-party subset and any dual-function safe harbor before choosing a calculation. Do not assign a nominal customer feature to an administrative system solely to bypass the additional test. Maintain separate amounts for development spending, deductible or amortizable tax costs, qualified research expenses, and credits usable currently. Management can then compare building software with buying a commercial system using realistic after-tax assumptions. A project may still be the right operating investment when the credit is limited or unavailable. The value of a careful classification is that the business approves the investment on its actual economics and files a claim supported by function-level technical evidence.
Sources & further reading
Consult the original guidance and its effective dates. These references support the educational discussion; their application depends on the specific facts.