May 17, 2024
Navigating the tax system as a software company can make your head spin. To help us get a better grasp on complex but important topics such as software capitalization, Section 174, and more, we sat down with tax specialist Bill Barnes, the Tax Partner leading the R&D tax credit consulting practice at the nation’s largest non-audit accounting and advisory firm, CFGI.
Read on to see what Bill has to say about audits, how engineering and finance can work together, software capitalization, and more.
On Auditing SaaS Companies
Jellyfish: What are you commonly looking for when auditing a SaaS company around software capitalization and/or R&D tax credits?
Bill Barnes: Companies should review capitalized software development costs versus expensed costs, as well as software development costs they deemed qualified versus costs deemed non-qualified.
For the R&D credit, we request quantitative documentation to evaluate the underlying amounts computed at the account, department, and project levels. In addition, a process memo and/or qualitative documentation are also typically necessary to validate the company’s representations and to substantiate why certain costs were treated a certain way for tax purposes.
For businesses that incur software development costs, it’s mission critical to have accounting and documentation policies in place that not only ensure tax compliance but also enable the business to capture, maximize, and sustain any available tax benefits related to such costs.
Whether a company is claiming the R&D credit or determining software development costs for tax purposes, having accurate and reliable contemporaneous quantitative and qualitative documentation readily available is of the utmost importance.
Bill Barnes, Tax Partner, CFGI
Quantitative documentation is typically examined to validate the calculations, identify any areas of concern, and ensure the amounts tie back to source documents such as the general ledger detail, invoices/purchase orders, contracts, as well as other contemporaneous documentation generated from (or stored within) the accounting and financial systems.
We also review qualitative documentation to substantiate the facts and circumstances supporting the company’s key determinations regarding the treatment of costs for credit and capitalization purposes.
On the Most Common Software Capitalization Challenges
Jellyfish: Where do you most often see companies struggling with software capitalization?
Bill Barnes: Companies across all industries are struggling with the new mandatory requirement to capitalize software development costs for tax purposes following the recent law change enacted by the Tax Cuts and Jobs Act (TJCA) for tax years beginning on or after January 1, 2022.
For tax purposes, businesses have historically had significant flexibility regarding their treatment of software development costs. They’ve had, for example, the ability to immediately deduct such costs or to elect to capitalize and amortize their software development costs over different recovery periods.
Following the TJCA tax law changes to IRC Section 174 (effective for tax years beginning after December 31, 2021), businesses are now required to capitalize “any amount paid or incurred in connection with the development of any software” under IRC Section 174 with a five-year recovery period for costs paid or incurred for software development activities conducted in the United States, or, 15 years for costs paid or incurred for software development activities conducted outside the U.S.
Businesses previously could deduct software development costs immediately. Due to a lack of reporting requirements and the flexibility to deduct such costs under various statutes prior to the TCJA law change, many businesses have not historically tracked these costs for tax purposes to the level of detail now necessary. As a result, businesses are struggling to determine, quantify, and document the tax treatment of their software development costs and determine whether such costs now require mandatory capitalization.
Making matters more challenging, the tax code and regulations don’t currently define “software development,” so many businesses are uncertain if, and to what extent, their activities result in costs that require capitalization. They’re also unsure whether there may be any opportunity to optimize their treatment in line with their key objectives and overall tax strategy.
Businesses also continue to struggle with determining whether software development costs incurred under contract (i.e., paying a third party or being paid by a third party) require capitalization for tax purposes. Many still struggle, too, to determine which of these costs are considered “incidental” to software development activities requiring capitalization under IRC Section 174.
On the Data that Supports Capitalization
Jellyfish: What are you looking for in the data provided around software capitalization and/or R&D tax credits? For example, data accuracy, precision, consistency, etc.?
Bill Barnes: Data accuracy, precision, and consistency are all equally important to ensure that the data provided around capitalization is reliable and useful. Only accurate, precise, and consistent data can enable the proper analysis and documentation of the costs incurred by the business for determining capitalization versus expense, as well as for identifying and quantifying costs potentially qualified for R&D credit purposes.
That said, there’s equally significant value in having the data tracked contemporaneously at the project and activity level to any extent possible. Real-time tracking increases reliability with improved data accuracy and consistency, but contemporaneous data tracking also ensures the maximization of any available tax benefit.
That said, there’s equally significant value in having the data tracked contemporaneously at the project and activity level to any extent possible. Real-time tracking increases reliability with improved data accuracy and consistency, but contemporaneous data tracking also ensures the maximization of any available tax benefit.
Bill Barnes, Tax Partner, CFGI
At the same time, this tracking simultaneously mitigates audit and exam risk by creating underlying audit support documentation in real-time via project accounting/cost tracking. This tracking can also be supplemented with qualitative documentation or memos summarizing the activities being performed.
In the event of an exam, contemporaneous documentation that substantiates the costs incurred with the key determinations the business made for determining treatment will carry significant value with the IRS. This documentation will also lead to an increased likelihood of sustaining the reported tax treatment and credit benefit without unfavorable audit adjustments.
On Data Hygiene
Jellyfish: Are there any good “data hygiene” habits or practices you’d recommend to engineering and finance teams at SaaS companies to ensure audits go smoothly? How can finance teams best prepare for an audit?
Bill Barnes: Be proactive in developing and implementing a plan for how you will track and document the treatment of your software development costs for tax purposes. At a minimum, identify a lead in the finance group who can work with a technical lead on the software development side to create processes and/or implement tools that track and document the treatment of costs in real-time, at the project level (including activity level detail, if possible).
Once the plan is implemented, regularly evaluate whether the costs are being categorized appropriately in line with expectations based on what work is being performed and the intended goals of the effort. If you are using time tracking, hours should be evaluated to ensure all hours are being reported and categorized appropriately in line with the expected activities per each employee’s workload and each project’s timeline.
In all cases, it’s critical to document whether the software development effort is intended to result in new or improved performance, functionality, quality, or reliability or whether the effort is routine and ordinary maintenance (including implementation of off-the-shelf software that only requires installation and configuration of pre-coded parameters). That indication will make life much easier for determining the tax treatment of the costs.
In a similar manner, once software being developed that is intended for lease, license, or sale establishes technological feasibility or once software to be used in the trade or business is placed in service, the business should note that date and track any subsequent costs separately. Those costs may be excluded from mandatory capitalization under IRC Section 174 and are unlikely to qualify for the R&D credit.
That said, if any efforts are undertaken after this that are intended to result in upgrades or enhancements that add new functionality or materially increase the software’s speed or efficiency, those costs should be flagged for potential inclusion in Section 174 and R&D credit.
As you can see, it’s important to document and understand the activities being performed on each development effort as well as the intended goals of such activities, given that the tax treatment of costs for IRC 174 and the R&D credit is highly dependent on these data points. Without having this information tracked in detail, it can be very difficult to put the puzzle together in the following year, especially if documentation is minimal or if there has been employee turnover.
On Not Going at it Alone
Jellyfish: Is there anything else you wish more engineering and finance teams knew/understood about software capitalization and/or tax credit reporting?
Bill Barnes: Invest the time on the front end in developing processes and implementing tools to ensure that you have the information and documentation necessary to determine the proper tax treatment of software development costs with audit-ready substantiation and support.
That said, don’t go at it alone, especially when you are creating the fundamental processes and determining how the tax law applies to your activities and related costs. There are quite a few steps that companies can take that will not only save them costs in the long run but also better prepare their businesses to ensure they maximize any available tax benefit while mitigating potential audit and exam risk.
As with all things in tax and accounting, there are various nuances and complexities at the federal, state, and international levels that you should proactively discuss with your tax advisor to ensure compliance with all jurisdictions, maximization of any available benefit, minimization or mitigation of risk, and, most importantly, proper alignment with your overall tax and business strategy.
Plan and Account for Change
Until December of 2023, many technology companies and founders had only dim awareness of the changes to Section 174. As Gergely Orosz reports, “The change was expected to be repealed (reversed) in December 2022, so many accountants didn’t inform customers for that reason. So, businesses got a surprise when the first tax payments fell due last April.”
Change is still possible—from modifying the law to repealing it—but companies need to account for all possibilities. As Bill shared with us toward the end of our conversation, “Whether the administrative guidance changes again or a recent case law decision interprets the law differently than the IRS, it’s important for companies to work with a tax advisor who has their finger on the pulse of any developments.”
Learn more about Section 174 and its impact on software companies here.
