Can I capitalize my system implementation or get tax advantages?

Until recently, most organizations that purchased and implemented a new accounting system would capitalize the costs associated with the application development stage of implementing the new system.

They could do this if the organization physically bought the software via a multiyear license and support arrangement. For book purposes, this allowed an organization to recognize the cost of the implementation (which could be in the millions) over many years, reducing the project’s cost on any one year’s income statement.

Depending on the nature of the implementation, companies may have also capitalized the implementation expense for tax purposes, or they may have deducted at least a portion of the implementation expense as a software development expense in the year the expense was incurred.

With the introduction of software as a service (SaaS), organizations need to understand and evaluate their options to account for their SaaS implementation expenses for both book and tax purposes. This blog post focuses on two major considerations for companies implementing a SaaS solution.

1. Capitalization of the implementation service for book purposes

If the implementation of a new solution includes a multiyear license, an organization can capitalize the license cost and recognize the expense over time. With software as a service, there is typically an annual subscription fee for the software and not a license. However, if the organization has the option of taking ownership of the software, and they can run the software without resources from the vendor, then the organization can still capitalize the cost. With most SaaS systems, vendors to do not give customers this option. If the vendor does give an organization this option, it is most likely with a hosted on-premises system marketed as a SaaS solution, or a single-tenant SaaS system that loses any SaaS luster the minute you take ownership.

Alex Bogopolsky of CrossCountry Consulting, a renowned accounting policy expert, noted:

“The issuance of a new accounting standard in 2015 clarified the customer’s accounting for cloud computing fees, making clear that the costs to license and implement a cloud-based software solution will generally not be eligible for capitalization. When deciding on a software solution for a new accounting system, this new guidance has, and likely will continue, to bring accounting into the decision making process.”

2. Claiming research-and-development (R&D) tax credits

Historically, the IRS treated software implementation expenses as mere “customization” efforts to configure software for a customer’s specific needs. Customization of software solutions like ERP systems might have been deductible as costs that were similar to R&D expenses, but they were never allowed as expenses that were eligible for the federal R&D tax credit.

On Oct. 4, 2016, the U.S. Treasury finalized new regulations that provided additional guidance for organizations that wish to claim the R&D tax credit. If the buyer of a SaaS system pays for new and original coding to implement the system in the organization’s business, then the related development expense may be qualified for the R&D tax credit.

During a SaaS implementation, users will configure systems from a variety of predefined choices. Configuration of preprogramed menu-driven options alone won’t qualify for the R&D tax credit. But many organizations choose to extend the application by developing custom reports, building complex integrations and/or developing their own customizations that live both within and outside of the SaaS system. These expenses may be credit eligible.

Jeff Malo of Andersen Tax offers this insight:

“Prior to the new regulations, most taxpayers didn’t have reasons to segregate the expense of ‘standard’ customization from the cost of the new and original coding that might be required in an implementation of an ERP system. If companies start tracking this information, they could claim significant tax credits.” 

Under the new regulations, organizations will need to track new and original coding costs (e.g. internal labor and consulting fees) separate from the standard SaaS configuration expenses if they want to maximize tax benefits.

Conclusion

Software has been the subject of new guidance in 2016 for both book and tax purposes. The new book guidance may require organizations to recognize more of the expense associated with an implementation in the year the expense is incurred. This may factor into the decision-making process for some organizations considering a SaaS implementation. However, the impact on financial statements can be offset with new opportunities to claim the R&D tax credit for qualified implementation expenses. The corresponding reduction in tax expense may be enough to fully offset any additional book expense, and perhaps even yield additional financial statement benefits.