By Larry Maples and Melanie James Earles
In Brief
Muddled Rules for Software Costs
Applying Treasury Department and IRS regulations on the deductibility of software costs requires patience. Two Treasury attempts at writing regulations for the deduction of costs under IRC section 174 met with so much criticism that they were abandoned. In the absence of Treasury regulations, the IRS’s hard-line temporary regulations on the IRC section 41 credit on deducting internal software development costs are being applied even though their adoption has been delayed indefinitely. The IRS’s Industry Specialization Program has issued useful guidance that the IRS has been following consistently, a good indication of the shape the final regulations will take.
Businesses can recover software costs in several different ways. Certain internally developed software costs may be expensed immediately, while other software costs are subject to various amortization periods (three, five, and 15 years). Software development may also qualify for the IRC section 41 research credit.
The IRS recently issued guidance on handling software costs. Revenue Procedure 2000-50 clears up some ambiguities in previous guidance but does not clarify what constitutes internally developed software. The rules for acquired software are now clear, but remain muddled for developed software. Recent court decisions and a regulations project have addressed the standards that must be met for internal-use software to qualify for the research credit.
Acquired Software
Software costs included in the cost of hardware are capitalized and depreciated as part of the cost of the hardware. Thus, non–separately stated software is depreciated over five years using 200% declining balance depreciation under the modified accelerated cost recovery system (MACRS).
Separately stated acquired software can be treated as a capital expenditure amortizable over 36 months starting with the month the software is placed in service, consistent with Treasury Regulations section 1.167(a)-14(b). The recent revenue procedure restates this rule in order to clarify that the rules for acquired software in Revenue Procedure 69-21, which called for amortization over five years unless the taxpayer could establish a shorter period, have been superseded.
The new revenue procedure does not apply to IRC section 197 intangibles. Acquired software that is classified as a section 197 intangible must be amortized over the significantly longer period of 15 years. Taxpayers can, however, use two significant exceptions to remove most acquired software from the reach of this 15-year rule.
IRC section 197(e)(3)(A) and Treasury Regulations section 1.197-2(c)(4) provide exception for two types of software that will be amortizable over a 36-month period:
The disparity between amortization periods may create tension between taxpayers and the IRS. For example, taxpayers will be inclined to interpret the definition of computer software as broadly as possible in order to be eligible for one of the exceptions above. IRC section 197 defines computer software as “any program designed to cause a computer to perform a desired function.” This broad definition is narrowed to exclude databases or similar items unless they are in the public domain and incidental to operation of the software. According to the 1993 House of Representatives Conference Report [680; and Treasury Regulations section 1.197-2(c)(4)(iv)], under this definition a spell-check feature is computer software, even though it is a database, because it is incidental to the word-processing program. Definitional questions are inevitable, because of the IRS holding that an item which is not computer software must be amortized over 15 years.
Developed Software
Revenue Procedure 2000-50 continues the IRS’s general rule that the costs of developing computer software so closely resemble research and experimental expenses as to warrant similar treatment under IRC section 174. Thus, in theory, development costs may be consistently treated as current deductions or capitalized and amortized over 36 or 60 months [Revenue Procedure 2000-50 sections 5.01(1) and (2)].
Despite the surface impression left by a reading of the revenue procedure, a current deduction for software development is no foregone conclusion. Because the revenue procedure does not define software development, many questions arise (for example, does the cost of customizing an existing software package qualify as development). The Treasury Department twice attempted to define software development, but both times withdrew the proposed regulations because of significant criticism.
In 1983, the IRS issued proposed regulations that would have established a new standard for the kinds of software expenditures that would qualify as research and experimental costs under IRC section 174. Under these proposed regulations, the costs of developing computer software would be section 174 deductions only if they paid for developing “new or significantly improved computer software” (Proposed Treasury Regulations 1.174-2). Whether the software was new or significantly improved would have been determined “with regard to the computer program itself rather than the end use of the program.” Thus, a new application of known programming techniques would not qualify as research and experimental costs. This regulation encountered considerable criticism and the IRS decided not to pursue final regulations.
In 1989, in an attempt to soften the “new or significantly improved” standard, the IRS issued revised proposed regulations. This time, the IRS focused on whether the software had met “its basic design specifications related to function and performance level” (Proposed Treasury Regulations 1.174-2). If the basic design was already in place, developing a new application would not qualify as research and experimentation. On the other hand, performing basic design work would not convert the entire project into research and experimentation. Implementation, training, and testing costs incurred after the basic design was developed would not qualify as research and experimentation. The IRS became dissatisfied with this time-line approach and withdrew these proposed regulations in 1993.
Recent IRS Signals
Since 1993, in the absence of regulations, the IRS has referred taxpayers back to Revenue Procedure 69-21 (now 2000-50), which is of little help because it does not adequately define software development. In the meantime, many examining agents are aggressively capitalizing many software development and implementation costs, spurred on by memoranda from the IRS’s Industry Specialization Program (ISP).
In 1999 and 2000, the ISP issued suggestions to agents examining taxpayers that incur certain software development–type costs. These audit suggestions address enterprise resource planning (ERP), customer relationship management (CRM), and website design costs and also contain a caveat that the positions “are the opinion of the ISP and not necessarily those of the Office of Chief Counsel.” However, the ISP approach is worth observing for two reasons: In most cases, IRS agents can be expected to follow the ISP rationale; and, in the absence of regulations, the ISP may suggest the shape of the IRS’s emerging position.
These ISPs limit software development to writing source code. They instruct examining agents to ask for work schedules, invoices, and resumes of project members so that allocable costs can be isolated. In other words, the ISPs expect an effort to be made to separate personnel costs into software programming and business consulting; the business consulting component must be capitalized.
The primary problem with this approach is that in practice, software is developed hand-in-hand with business process adjustments. The ISPs are clear, however, that the costs of “business process re-engineering” should be capitalized. It may be easy for the IRS to separate re-engineering and programming costs by reference to the program participants’ resumes, but this approach ignores the give-and-take that occurs as processes are adjusted to fit the software and the software is modified to fit the processes.
Tax advisors would normally assume that any costs that could be categorized as training would escape capitalization. The IRS has long allowed a deduction for training costs, and reaffirmed that position in Revenue Ruling 96-62 (1996-2 CB9). Reengineering a task can be viewed as training employees to accomplish a task in a different way. Would the IRS use the ISP approach to capitalize costs that taxpayers may have deducted under previous guidance?
Computer Software Research Credit
Computer software development costs may also qualify for the IRC section 41 research credit. The credit is generally equal to 20% of the excess of the qualified research expenses for the current tax year over the base amount (unless the taxpayer elects the alternative incremental credit). The base amount is a fixed-base percentage (determined by a complex formula) of the taxpayer’s average annual gross receipts for the four tax years before the credit year, and it cannot be less than 50% of the year’s qualified research expenses. To qualify as eligible research expenses, the expenses must be paid or incurred in carrying on a trade or business of the taxpayer, and the expenditures are limited to in-house research expenses and contract research expenses. Qualified research must be for the purpose of a new or improved function, performance, or reliability or quality. Research does not qualify if it relates to style, taste, cosmetic, or seasonal design factors.
The general requirement for the research credit is that the expenditures must be for qualified research. IRC section 41(d)(1) establishes four tests that must be met in order for research to constitute qualified research:
IRC section 41(d)(4)(E) provides that research that would otherwise qualify under section 41 is excluded from the credit if the research was for the development of “internal use” computer software. Statute, regulations, or case law do not define software developed primarily for internal use. However, the 1986 House of Representatives Conference Report explained that software programs used for general and administrative functions (such as payroll, bookkeeping, or personnel management) or in providing noncomputer services (such as accounting, consulting, or banking services) are examples of internal-use software and, thus, excluded from the section 41 research credit.
Internal use software may overcome section 41’s internal use exclusion if it meets three tests listed in the 1986 Conference Report:
To qualify for the research credit and avoid the internal use exclusion, internal use software activities must meet all four of the general requirements for qualified research tests and all three of the internal use software tests. Thus, the development of internal use software has a higher threshold of technological advancement than other fields of research.
IRS Victories
The IRS has successfully denied the research credit for computer software costs in three cases: Norwest, Stationers, and WICOR. Norwest [Norwest Corporation v. Commissioner, 110 TC 454 (June 29, 1998)] was a bank holding company that developed or modified previously developed software for the internal management and administration of its businesses. In order to respond to the IRS’s notices of deficiency, Norwest hired Coopers and Lybrand to ascertain whether the company was entitled to research credits for certain internal-use software development activities. Coopers and Lybrand concluded that 67 of 118 of these activities qualified for the research credit. For purposes of trial, Norwest and the IRS selected eight internal-use software development activities to serve as representative activities. The court found that only one of the eight, the strategic banking system (SBS) customer module project, satisfied all seven tests for qualified research under IRC section 41. (See the Exhibit for the reasons the court disqualified the other seven.)
The SBS project was a massive undertaking to develop an integrated banking system that could interact with several other systems and handle a large volume of data. The court noted that ”qualified research is not limited to the development of new technology but also encompasses the use of existing technology in new and dynamic ways.” The court also noted that the size or complexity of a project can create technical risk. This risk was confirmed when the SBS system at Norwest had failed by the time of the trial.
Stationers, a large wholesaler of office supplies, purchased a software package for use in developing eight separate but related software programs. The company could not use the software package as purchased, but used parts of it to design application codes specific to its needs. Stationers claimed a deduction for the development of these programs under IRC section 174, which the IRS allowed. Stationers then filed an amended return claiming a credit under Section 41 for qualified research activities. When the IRS did not respond, Stationers filed suit to obtain a refund (United Stationers, Inc., v. U.S., 97-2 USTC para. 50,994). The Seventh Circuit, affirming a district court decision, held that Stationers failed the discovery test, the process of experimentation test, and the significant economic risk test (United Stationers, Inc. v. U.S., 99-1 USTC para. 50,136). The court said the taxpayer did not pass the discovery test because it failed to refine or expand the principles of computer science; instead, it modified an existing software program in an attempt to improve the company’s inventory control system. While these applications were new to Stationers and eliminated operational inefficiencies, the court noted that they did not have a broad economic effect. The routine modification of a commercially available software package did not meet the requirements of Section 41(d)(1)(B)(I).
Additionally, even though most of Stationers’ project summaries included general statements about the uncertainty of actually realizing the anticipated operational efficiencies and resultant economic benefits, the court held that there was no technical uncertainty from the outset. Thus, the computer software development neither involved a process of experimentation nor a significant economic risk.
Stationers fought the internal use exclusion by arguing that Congress did not intend for programs involving activities that directly impact external parties (core revenue-generating activities) to be classified as internal-use software. The court did not accept Stationers’ argument, noting that Congress intended the credit to reward taxpayers for a significant contribution to the store of public technological knowledge. The court noted that to avoid the internal-use exclusion, a taxpayer must, to an appropriate extent, make the program available to the public.
In another case (WICOR, Inc. v. U.S., 2000-2 USTC para. 50,833.), the gas utility corporation WICOR, in conjunction with Andersen Consulting, developed a computerized integrated customer information system (CIS) that resulted in improved customer service and company performance in the areas of automated meter reading, computer dispatch, and online cash posting. WICOR purchased a DB2 database to use as the platform for its new CIS. The CIS project required 19,000 employee labor-days and 16,000 consultant labor-days. WICOR spent more than $30 million on the project and claimed a research tax credit under IRC section 41. The district court found that WICOR failed to meet four of the tests and therefore was not entitled to a research credit. The problem seemed to be that WICOR’s experts focused on the utility industry and did not expand their analysis to the computer field as a whole.
The court said WICOR failed the discovery test, because although the information was new to the taxpayer, it was not new to others. One of WICOR’s experts testified that the project satisfied the discovery test because it expanded knowledge of computer science principles within the gas utility CIS application. The court noted that the research tax credit is not intended for projects that expand the universe of knowledge only within a particular industry.
WICOR failed the process of experimentation test as well, because experimentation must involve the development and testing of more than one alternative where the means of achieving a desired result is uncertain at the outset. The 1986 House of Representatives Conference Report explains that this may involve developing one or more hypotheses, testing and analyzing those hypotheses, and refining and discarding the hypotheses as part of a sequential design process.
The court said that WICOR failed the innovation test because a computer software project cannot meet the high threshold of innovation without discovering new principles of computer science. The court noted that WICOR did not consider seeking a patent; thus, the company did not consider its project highly innovative within the field of computer science.
According to the court, WICOR also failed the significant economic risk test because of Andersen Consulting’s input on development. Andersen’s prior experience with similar software projects reduced the technical risk to WICOR.
New Regulations
In December 2000, the IRS issued comprehensive final regulations on how to qualify for the section 41 research credit. Among other things, the regulations introduced a new patent safe harbor, a new recordkeeping requirement, and a rebuttable presumption that the discovery test has been met. The new regulations also make it easier for some companies to claim the research credit for internal-use software. In February 2001, in order to extend the comment period, the IRS put the final regulations on hold and delayed their effective date indefinitely, but said that taxpayers may continue to rely on them.
New documentation requirement. Although the final regulations eliminate the extensive recordkeeping for the experimentation process, they contain a new documentation requirement effective for research projects that begin after March 4, 2001 (delayed). A taxpayer will qualify for the research credit only if it prepares and retains documents written before or during the early stages of a research project. To satisfy the discovery test, these documents should describe the principal questions to be answered and information to be obtained. The taxpayer should also meet the general recordkeeping requirements of IRC section 6001.
Revamped discovery test. The discovery test is met only if the research is undertaken to obtain knowledge that exceeds, expands, or refines the “common knowledge of skilled professionals” in a particular field of science or engineering. The effort does not have to succeed. There has been a lot of controversy over the government’s decision to retain this test, with many people arguing that the common knowledge standard imposes a discovery requirement that was not mandated by statute. Nonetheless, Treasury officials believe the standard is grounded in legislative history.
New rebuttable presumption that discovery test is met. A taxpayer is presumed to meet the discovery test if it meets the following criteria:
This new presumption applies only if the taxpayer cooperates with reasonable IRS requests for witnesses, information, documents, meetings, and interviews. Taxpayers that meet the documentation requirement shift the burden to the IRS to prove that what the taxpayer is trying to discover is within the realm of common knowledge.
For purposes of the discovery test, the issuance of a patent is conclusive evidence that a taxpayer has obtained knowledge exceeding, expanding, or refining the common knowledge of a skilled professional. Obtaining a patent is not, however, a prerequisite for the research credit.
The
new regulations allow an exception for internal use software that provides noncomputer
services to customers (for example, a system that allows customers to monitor
their orders). If several additional tests are met, the expenditures are eligible
for the research credit.
The CPA Journal is broadly recognized as an outstanding, technical-refereed publication aimed at public practitioners, management, educators, and other accounting professionals. It is edited by CPAs for CPAs. Our goal is to provide CPAs and other accounting professionals with the information and news to enable them to be successful accountants, managers, and executives in today's practice environments.
©2002
CPA Journal. Legal Notices
Visit the new cpajournal.com.
){kind=link}