IRS Guidance on R&D Expenses: What Software Engineers Need to Know
As a software engineer, you might be wondering why you should care about IRS guidance. Well, recent changes to how research and development (R&D) expenses are treated for tax purposes could have a significant impact on your company's financials and, consequently, on R&D budgets and practices. Let's break down the key points of the recent IRS guidance (Notice 2023-63) that are most relevant to us in the software development world.
The Big Picture
The Tax Cuts and Jobs Act (TCJA) changed how companies handle R&D expenses for tax purposes. Instead of immediately deducting these costs, companies now have to spread them out over several years. This change affects expenses incurred since January 1, 2022.
What Counts as Software Development?
The IRS guidance provides some clarity on what activities are considered "software development" for tax purposes. Here's what you need to know:
Definition of Computer Software: This includes not just traditional software, but also cloud computing applications, updates, and enhancements. It's a broad definition that covers most of what we work on day-to-day.
Software Development Activities: The following are explicitly mentioned as software development:
- Planning the development
- Designing the software or upgrades/enhancements
- Building models
- Writing source code and converting to machine-readable code
- Testing (until the software is placed in service or ready for sale/licensing)
- Producing product masters (for software developed for sale or licensing)
What's Not Included: Some activities we might engage in are not considered software development for these purposes:
- Employee training
- Maintenance after the software is in service (e.g., bug fixes)
- Data conversion
- Software installation
Implications for Your Work
Documentation Matters: Given the need to capitalize these expenses, it's more important than ever to clearly document your time spent on different activities. Your company might implement more detailed time-tracking to distinguish between capitalizable development work and non-capitalizable activities.
Project Planning: The way projects are planned and budgeted might change. There could be more emphasis on clearly defining what constitutes new development versus maintenance or bug fixes.
Testing Phase: The guidance specifies that testing is included up until the software is placed in service or ready for sale. This might influence how your team approaches the testing phase and defines "ready for production."
Purchased Software: If your company buys off-the-shelf software, only the costs of upgrades and enhancements count as development. This might affect decisions about whether to buy or build software solutions.
Cloud Projects: With cloud computing explicitly included, projects involving cloud applications are treated similarly to traditional software development.
What About Contracted Work?
If you're working as a contractor or your company outsources some development, it's worth noting:
- The company paying for the work (the "research recipient") generally treats the costs as R&D expenses if the work is done at their direction and risk.
- The company doing the work (the "research provider") might also have to treat their costs as R&D expenses if they bear financial risk or have rights to use the resulting product.
Long-Term Projects
For long-term projects (like those lasting more than a year), there are special rules about how to account for these R&D costs over time. This might affect how your company approaches and budgets for multi-year development projects.
What This Means for Software Engineers
While much of this might seem like accounting minutiae, it can have real-world impacts on how software development is approached:
Budget Allocation: Companies might adjust their R&D budgets due to the change in tax treatment. This could affect resources available for new projects or enhancements.
Project Prioritization: There might be more scrutiny on which projects truly constitute new development versus maintenance or minor enhancements.
Development Practices: We might see changes in how projects are structured or how work is assigned to align with these tax considerations.
Documentation and Tracking: Expect potentially more detailed tracking of time and activities to support tax reporting requirements.
Conclusion
While tax rules might seem far removed from our day-to-day coding tasks, understanding these changes can give you valuable insight into company decisions affecting R&D activities. It's a reminder that software development doesn't happen in a vacuum – it's influenced by broader business and regulatory considerations.
As always, this is a complex area, and companies will likely rely on tax professionals to navigate the details. But as software engineers, being aware of these issues can help us understand and adapt to any resulting changes in our development processes and practices.