Interplay between Sec. 174 and Sec. 41 for software development
INSIGHT ARTICLE |
The Internal Revenue Code provides a tax credit for certain expenditures related to research and development (R&D) performed in the United States. Despite the availability of the Sec. 41 R&D credit, a company may be precluded from claiming it based on the tax accounting method the company employed for the treatment of the research expenditures. This is especially the case for taxpayers that develop software for internal use, as a taxpayer’s financial statement treatment may conflict with the tax accounting treatment required for Sec. 41 purposes. Taxpayers should note the interplay between tax accounting methods and tax credit eligibility when choosing to adopt or change their method of accounting specific to software development activities.
R&D tax credit under Sec. 41
To qualify for the R&D credit, a taxpayer must have research expenses associated with development efforts that satisfy the four-part test in Sec. 41(d). Qualified research expenses are expenditures that (1) may be treated as expenses under Sec. 174; (2) relate to research undertaken to discover information that is technological in nature; (3) relate to research that is intended to be useful in the development of a new or improved business component; and (4) constitute elements of a process of experimentation.
The regulations under Sec. 174 define qualified research expenses as expenditures incurred in connection with a trade or business representing R&D costs in the experimental or laboratory sense (Regs. Sec. 1.174-2(a)(1)). Costs qualify as experimental if they are for activities intended to discover information that would eliminate uncertainty pertaining to the development or improvement of a business component, which refers to any product, process, computer software, technique, formula or invention that is held for sale, lease, or license or is used in the taxpayer’s trade or business (Regs. Secs. 1.174-2(a)(1) and (3)).
Uncertainty regarding development efforts exists if the information available to the taxpayer does not establish the capability or method for developing or improving the product or the appropriate design of the product (Regs. Sec. 1.174-2(a)(1)). Further, the Sec. 41 regulations provide that the information is technological in nature if the required process of experimentation used to eliminate the technological uncertainty fundamentally relies on the principles of the physical or biological sciences, computer science or engineering (Regs. Sec. 1.41-4(a)(5)(i)).
However, certain activities are excluded from the definition of qualified research. Except as provided in the regulations, activities related to internal-use computer software developed primarily for the taxpayer’s general and administrative functions are not considered qualified research (Regs. Sec. 1.41-4(c)(6)(iii)(A)). General and administrative functions are defined as financial management, human resource management and support services (Regs. Sec. 1.41-4(c)(6)(iii)(B)).
Tax accounting methods for R&D expenditures
Although the default method of accounting for research and experimental expenses is to deduct the costs under Sec. 174 in the year they are incurred, taxpayers may instead elect to defer the expenses and amortize them over a period of not less than 60 months (Sec. 174(b)) or elect to amortize them over a set 10-year period (Sec. 59(e)). Taxpayers may also charge these expenditures to a capital account, though within a project the taxpayer must apply the same method to all research and experimental costs incurred in the year (Sec. 174(b)(1)(C)). For costs to be potentially eligible for the Sec. 41 R&D credit, the costs must first be treated as R&D expenditures under one of the above-mentioned acceptable methods under Sec. 174 (Sec. 41(d)(1)(A)).
Specific guidance on the treatment of computer software costs is provided in Rev. Proc. 2000-50. The revenue procedure defines computer software as any program or routine designed to cause a computer to perform a desired function or set of functions and outlines the documentation required to describe and maintain that program or routine. This revenue procedure addresses three categories of computer software costs: those relating to self-developed software, acquired software, and leased or licensed software. For costs incurred to self-develop computer software, the revenue procedure permits taxpayers to treat the costs in a manner similar to Sec. 174 but not technically as Sec. 174 expenditures.
According to Rev. Proc. 2000-50, taxpayers may choose to currently deduct the costs of self-developed software in the year incurred or amortize the costs over 36 months from the date the software is placed in service or 60 months from the date of completion. However, computer software subject to amortization as a Sec. 197 intangible or costs treated as Sec. 174 research and experimentation expenditures are specifically excluded from the treatment allowed in Rev. Proc. 2000-50. As such, taxpayers should bifurcate costs appropriately between Sec. 174 and Rev. Proc. 2000-50, as R&D expenditures must be treated as Sec. 174 costs to be potentially eligible for the Sec. 41 R&D credit. Also, the cost of acquiring or leasing or licensing another taxpayer’s software, as covered in Rev. Proc. 2000-50, generally does not meet the four-part qualification test of the R&D tax credit.
In many instances, a taxpayer adopts one of the accounting methods available under Sec. 174 or Rev. Proc. 2000-50 and in later years finds that its established method does not align with its current tax objectives. Recently, many companies found themselves in a net operating loss position coming out of the Great Recession and thus elected to capitalize and amortize computer software development or R&D costs. Presently, taxpayers may find it more beneficial to currently deduct these types of expenditures.
Luckily, taxpayers can generally file an accounting method change under the automatic consent procedures to elect alternate treatment of these expenditures under another permissible method of Sec. 174 or Rev. Proc. 2000-50 (Sec. 174(a)(3) and Rev. Proc. 2000-50, §8.02). But herein lies the issue—changes under Sec. 174 are executed on a cutoff, or prospective, basis for expenditures incurred in the year of change and future years only (Sec. 174(a)(3)). Therefore, taxpayers do not get the benefit of a historical adjustment for previously incurred R&D expenditures (likely moving the items from amortizable to currently deductible).
While taxpayers may be precluded from claiming a tax credit associated with otherwise qualified expenditures incurred prior to the method change, the consistency rule under Sec. 41(c)(6) requires taxpayers to similarly treat qualified expenditures in all tax years, resulting in the inclusion of these costs in a taxpayer’s base period computations. However, if a taxpayer elects to file an accounting method change to treat expenditures under Rev. Proc. 2000-50 rather than Sec. 174, a full Sec. 481(a) historical adjustment is required, which allows for current recognition of previously deducted/capitalized items under the new accounting method (Rev. Proc. 2000-50, §8.01). While taxpayers may find it beneficial to avoid characterizing costs as falling under Sec. 174 to receive a favorable Sec. 481(a) adjustment for previously capitalized items, treatment of those expenses under Rev. Proc. 2000-50 may be inconsistent with also claiming these as Sec. 174 costs for purposes of computing an R&D credit under Sec. 41.
Opportunities and risks for computer software projects
Typically, computer software projects involve incurring costs related to employee wages and benefits; the purchase or acquisition of hardware technology or office buildouts; the purchase of third-party software packages or software licenses; legal fees; and third-party consulting fees for market research, feasibility, initial design, development, infrastructure coordination, configuration and customization. Many technology firms subcontract work to offshore subsidiaries or service providers due to lower labor rates overseas. Frequently, taxpayers capture and treat all of these costs similarly, even though the aforementioned accounting method treatment can differ significantly depending on the type of cost incurred.
For example, implementation of an enterprise resource planning (ERP) system could consist of acquired software (36-month amortizable life under Rev. Proc. 2000-50), licensed software (treated similar to rent under Rev. Proc. 2000-50), custom middleware development (treated as either amortized over 36 months under Rev. Proc. 2000-50, expensed under Sec. 174(a) or Rev. Proc. 2000-50, or amortized over 60 months under Sec. 174(b)), and project management and configuration expenses (potentially deductible under Sec. 162).
Further, qualified costs for the R&D tax credit must be domestically incurred and include wages reported on Form W-2, Wage and Tax Statement, box 1, that are paid to an employee for directly performing, supervising or supporting qualified research; supplies directly used in the performance of qualified research; and 65 percent of contract research expenses to perform qualified research (Sec. 41(b); Regs. Sec 1.41-2). The taxpayer claiming the R&D credit must retain substantial rights to the research results and economic risk in the research; therefore, costs related to license fees, the acquisition of a third-party software or patent, and fixed-fee contracts with third parties typically do not qualify for the credit (Regs. Sec. 1.41-2(a)).
In implementing a new software development project, whether it be associated with website design, a mobile application or an ERP system, there are many pitfalls for taxpayers attempting to claim the R&D credit. One area relates to differentiating between the configuration of a preexisting program option (i.e., the selection of configurable options from a list of modules) and the customization of that software program or ancillary features that require development.
Generally, configuration does not meet the technical-uncertainty test of Sec. 41; however, customization may give rise to technical uncertainty through requirements definition, data modeling and design, security design, architecture design, software application design, custom coding, custom interface development, middleware development, integration of various software and/or hardware components, and related testing. In addition, costs associated with activities performed to build content on a taxpayer’s system or make cosmetic changes to the interface to meet user preferences may be disallowed to the extent these activities do not meet the permitted-purpose test of Sec. 41(d)(3)(A).
As Sec. 41 provides heightened requirements for internal-use software, taxpayers should also consider who the system users are and whether the software should be considered internal-use. While software developed to be sold, leased, licensed or otherwise marketed to third parties clearly should not be included in the definition of internal-use software (Regs. Sec. 1.41-4(c)(6)(iv)(A)), what about software development for e-commerce sites or custom modules for ERP systems? Based on the new final regulations, taxpayers may claim software development costs associated with these types of solutions under the four-part test to the extent the software is developed to enable a taxpayer to interact with third parties or to allow third parties to initiate functions or review data on the taxpayer’s system (Regs. Sec. 1.41-4(c)(6)(iv)(B)).
To the extent the software is dual-function, taxpayers will need to identify the subset of software that may be treated as non–internal-use versus the software elements that are for general and administrative functions (Regs. Sec. 1.41-4(c)(6)(vi)(C)). In addition, if portions of the software were purchased off the shelf, taxpayers should shrink back to only include costs associated with the incremental improvements, as expenditures associated with purchasing software are disallowed (Regs. Sec. 1.41-4(a)(8), Example (10)). Software used in production processes or to perform research may also qualify under the four-part test; however, the costs associated with these types of solutions are commonly capitalized and expensed under other tax accounting methods, such as Rev. Proc. 2000-50, which may preclude taxpayers from claiming these costs under Sec. 41.
Further, allocations need to be made between general business consulting, hardware development, software development, R&D activities, project management, maintenance and support, hardware installation, software installation, and employee training, as each category could be subject to a different accounting method treatment, and only parts of software development and R&D may qualify for the R&D tax credit.
Taxpayers should be aware of the numerous tax accounting methods available to account for software development expenditures, as well as R&D credit qualification criteria for software development and internal-use software. These options allow taxpayers to choose their recovery period for software development expenditures. The R&D tax credit rules also provide many tests that must be met to qualify for the R&D credit. As with most tax determinations, all facts and circumstances must be considered, and taxpayers must have detailed contemporaneous documentation to support the tax accounting method treatment and credit eligibility tests.
Excerpted from the April 2017 issue of The Tax Adviser. Copyright © 2017 by the American Institute of Certified Public Accountants, Inc.