Every year, qualifying businesses can get up to $250,000 back from the Internal Revenue Services (IRS) as part of the US Research & Development (R&D) tax credit program. Once approved, the refund can be applied towards payroll taxes or income taxes.
The IRS published a set of new audit guidelines for businesses applying for the US R&D tax credit program, which outlines which software development activities can qualify under the R&D umbrella.
If an R&D study undergoes an audit, the IRS examiner will use the new guidelines “will aid in risk analysis and will help focus limited audit resources by ranking software development activities at lowest to the highest risk of not constituting qualified research under I.R.C. § 41(d)”.
Which activities will constitute as qualified research?
Under I.R.C. § 41(d)(1), all research activities must include elements of a process of experimentation. That is, the work must be performed in a systematic process to evaluate one or more alternatives to achieve the desired result.
Under I.R.C. § 41(d), software development activities will be rated as “high risk”, “moderate risk”, or “low risk”, which are defined as:
- High risk: these activities usually fail to constitute qualified research
- Moderate risk: these activities often fail to constitute qualified research
- Low risk: these activities rarely fail to constitute qualified research
Which research activities will be at “high risk” of not being identified as qualified research?
The IRS has identified 17 instances where the work performed within software development will be at high risk of not being identified as qualified research under I.R.C. § 41(d) since the primary purpose of conducting these activities is not to resolve software development uncertainties. Activities at high risk of not constituting as qualified research include:
- Maintaining existing software applications or products
- Configuring existing software applications
- Reverse engineering
- Performing studies, or similar activities, to select vendor products
- Detecting flaws and bugs in the software application
- Modifying an existing software business component to make use of new or existing standards or devices, or to be compliant (i.e., certified, validated, etc.) with another vendor’s product or platform
- Developing a business component that is substantially similar in technology, functionality, and features to the capabilities already in existence at other companies
- Upgrading to newer versions of hardware or software, or installing vendor fix releases
- Re-hosting or porting an application to a new hardware or software platform, or rewriting an existing application in a new language
- Writing hardware device drivers to support new hardware (e.g., disks, scanners, printers, modems, etc.)
- Data quality, data cleansing, and data consistency activities.
- Bundling existing individual software products into product “suites”
- Expanding product lines by purchasing other products
- Interface software development activities
- Y2K program changes
- Vendor product extensions
- Graphical User Interfaces (“GUI”)
Which research activities will be at “moderate risk” of not being identified as qualified research?
Under I.R.C. § 41(d), the following types of research activities will often fail to constitute qualified research:
- Functional enhancements to existing software applications/products
- Software developed as embedded applications (which tend to use software already included in a given system to execute new applications)
- Development of software utility programs (e.g., debuggers, backup systems, etc.)
- Changing from a product based on one technology to a product based on a different or newer technology
- Adapting and commercializing technology developed by a joint association or an open software group
Which research activities will be at “low risk” of not being identified as qualified research?
Under I.R.C. § 41(d), the following 4 types of research activities will rarely fail to constitute qualified research:
- Requiring new constructs (e.g., new architectures, algorithms, etc.) for the initial release of an application software product
- Developing system software (e.g., operating system), as this may include resolving uncertainties related to process scheduling and memory management designs, and instruction execution optimization
- Developing specialized technologies (e.g., AI, speech recognition, etc.)
- Developing software as part of a hardware product wherein the software interacts directly with that hardware in order to make the hardware/software package function as a unit
What do the new guidelines mean for my R&D activities?
Given the lack of resources within the IRS for conducting audits, the goal of these new guidelines is to ensure that in the event of an audit, IRS examiners are able to rank activities from at highest to lowest risk of not constituting qualified research to speed up the process.
Ultimately, by publishing this comprehensive set of audit guidelines, the IRS is making it clear that it has started paying closer attention to the type of software development activities businesses are claiming as qualified research under the Research Credit.
While we are providing a high-level overview of which software development activities will be ranked as high risk, moderate risk, or low risk, we highly recommend reviewing the detailed version of the audit guidelines on the IRS website.
The R&D tax credit program is no longer as cut-and-dry as it used to be. Since the IRS can choose to audit an R&D study for up to 3 years after the initial claim filing date, it’s no longer worth it to risk filing a claim that may ultimately be partly, or fully, denied after an audit.
If you’re unsure whether the software development activities will constitute qualifying research, or if you’ve never claimed R&D tax credits, get in touch with us for a free assessment.