Transcript Available of IRS Hearing on Internal-Use Software

For IRS:

I'd next like to introduce our panel. My name is Danielle Grimm, I'm a special counsel to the associate chief counsel for Passthroughs and Special Industries. To my left is Jamie Park, she is our branch chief of branch 6 of Passthroughs and Special Industries. And to her left is Martha Garcia who is our docket attorney in branch 6 of Passthroughs and Special Industries. And to Martha's left is Christopher Call who is our attorney advisor at the Office of Tax Policy.

So with that I'd like to introduce our first speaker. We have representatives from Alvarez & Marsal Taxand. Will there be one speaker or two? Okay.

MS. KING: Good morning, my name is Kathleen King and I'm a managing director in the Washington D.C. office of Alvarez & Marsal Taxand. I've worked extensively with a research credit for more than 20 years, and I welcome the opportunity to speak today on behalf of the firm and the clients we represent. First and foremost, I want to commend Treasury and the IRS for your efforts on these proposed regulations. We particularly applaud the overall goal to provide a narrower exclusion for software from qualified research. Alvarez & Marsal submitted written comments on the proposed regulations.

My comments today will echo many of those points with particular focus on how this guidance impacts the two key questions that a taxpayer must address in evaluating whether or not software developments activities qualify for the credit. These questions are first: What is internal use software, and second, what are the additional requirements or tests that must be satisfied in order for internal use software to qualify?

With respect to the question of what is or is not IUS, internal use software, we believe that there are three areas that need to be addressed in the regulations as currently drafted. First, we believe that the third-party interaction exclusion and its interplay with the general and administrative function definition should be removed. Second, we believe that the expansive list of general and administrative activities is broader than intended by Congress. And finally we believe that the proposed regulations still fail to acknowledge the unique circumstances of many service industry taxpayers.

As you noted in the preamble to the proposed regulations, the role that software plays in the business activities today is very different than it was when the exclusion for internal use software was originally enacted back in 1986. Today computer software is used in all aspects of business activity, especially in providing goods and services to third parties. This software, software used to provide goods and services to third parties, tends to be highly integrated with all aspects of business and has played a vital role in increasing productivity of the U.S. in a global economy. This purpose is consistent with Congress' intent for the research credit when it was originally enacted to stimulate productivity in the U.S.

As a starting point for determining whether software is internal use or not we believe that you identified in the preamble the key question that needs to be addressed: Does the software benefit solely the taxpayer developing the software? We believe that if there is a direct and meaningful third-party interaction with the software or a portion of the software the increase should stop there. The third-party interaction exclusion should not apply and it will likely serve to disqualify activities that you intend to qualify.

The addition of a dual function software concept is quite insightful and I applaud your forethought to include it. Many corporations have highly integrated systems that are tightly connected to each other so it is very likely that a third party of subset of a system may be linked to a G&A application. You've acknowledged the importance of customer facing web applications in today's economy. Consider that the marketing department is frequently the department tasked within an organization to lead web operations and development. Because marketing quote unquote is specifically listed as a G&A function, some organizations will be forced to redefine this responsibility or fall victim to the third-party exclusion.

We've spent a lot of time in our recent comments on supply chain systems, their value to this economy, and the current connection to G&A functions. Supply chain innovation and the software that manages this innovation has been hailed as one of the greatest producers of productivity over the last 30 years. The best in class supply chain software seamlessly automates communications between the entire supply chain network. This includes suppliers, manufacturers, retailers, and transporters; all of these parties benefit from this software. Sellers get goods when they need them, manufacturers know when products must be shipped and they notify their suppliers. Suppliers can automatically trigger restocks so they receive orders faster. This is the critical distinction between inventory management and inventory accounting; all parties benefit from the supply chain systems. Only the taxpayer benefits from the inventory accounting system.

Finally, we believe that the regulations still fall short from many service industry taxpayers. We strongly believe that a so-called service exception should be added to the definition of IUS. Why? More than 80 percent of jobs in the U.S. today are in the service industry. Telecommunications companies develop software to manager peaks and valleys of demand. There is not a separate charge for the software. There is maybe a small portion of the software that has third-party access. Similar software is used to run a package tracking service. The dual function software is only going to address a small portion likely of that software solution. We recommend that the third-party interaction exclusion be eliminated. If it is not eliminated we ask that careful consideration be given to limit some of the defined G&A activities including marketing, data operations, inventory management and hiring. If the software or a substitative software benefits third parties and involves third party interaction -- and we're talking more than just logging on to a website -- then the increase should stop there. In those facts and circumstances it is not solely benefiting a taxpayer that is developing this software. We also urge Treasury and the IRS to consider an exception for the service industry software that is directly related to their external business operations.

The second step that a taxpayer must do in evaluating whether or not their software systems qualify for the research credit is to look for the application at the High Threshold of Innovation Test. This test is only applied if software has been deemed to be IUS. Consistent with the legislative history, the proposed regulations outlining three requirements for the High Threshold of Innovation Test.

We agree with the regulatory definition of the innovation and commercial availability requirements, but are troubled by some of the proposed changes for the significant economic risk test. First, the preamble statement that the terms capability, method, and design uncertainty, our previously defined terms is a bit disingenuous. Yes, taxpayers are familiar with these terms, but they generally have not been asked to differentiate between capability or method or design uncertainty. It has been sufficient to demonstrate that a technical uncertainty exists. In fact, these types of uncertainty are inherently related to each other and it is often difficult for taxpayers to clearly and unequivocally state or describe which type of uncertainty they face.

This is especially true for software development activities in which design is almost a term of art. The difficulty of using the term design in relation to software is that in some sense the source code of the program is the design for the program being created. The term design is used extensively throughout documentation. Scalability, performance, reliability, security, robustness, all these terms can be part of software design criteria.

All of these items can involve substantial uncertainty. I can foresee many disputes during an IRS examination if this point is not addressed. As I noted in our written comments, example 10, Regulation 1.41-4 is a classic example of how the term design can be confusing. Indeed, newly designed data cashing algorithms of an ERP system satisfy the process of experimentation because the appropriate design is uncertain. Granted, this example is for the process of experimentation test, but I think it clearly shows how the semantics can be intertwined. We recommend that design uncertainty not be specifically excluded under the significant economic risk test.

Our closing comments: We appreciate the opportunity to comment today and we urge Treasury and the IRS to consider adopting our recommendations. We look forward to providing further input and feedback as you work on finalizing the regulations and related guidance. The IUS phenomenon in many ways is the result of a congressional relic from a time where software development was in a very different place in society. Treasury and the IRS have the ability to acknowledge the change and move the ball forward. The 1999 legislative history requested the Treasury notice the rapid pace of technological advance especially in service related industries in providing rules for internal use software. To have no service exception is a disservice.

Thank you for your time and attention today.

MS. GRIMM: Thank you Ms. King for your comments. Does anyone on the panel have any questions? Okay, so I'd like to invite the next speaker who is Mark Andrus from Grant Thornton. And if you could just let me know when you're ready.

MR. ANDRUS: Ready to go. Good morning, I'm Mark Andrus. I'm a partner at Grant Thornton, the national leader of our Tax Credit Practice. Grant Thornton is the world's leading accounting tax and advisory organization dedicated to mid-size companies. Today I'd like to address an issue that really is of great significance of the market to mid-size taxpayers, and that issue is the effective date of these proposed regulations. We've submitted written comments and so you have that and in those written comments we addressed a lot of other issues regarding examples and language in the examples and so forth, and I'm sure you've got that and are studying through that.

Today I thought I'd take some time and talk just about the effective date. The proposed effective date in the regulations currently states that the regulations will apply to tax years ending on or after the date of publication. This creates some curious situations. Since the credit has expired, and we're not sure if it's going to be extended, the proposed regulations currently don't apply to calendar year end taxpayers. Because those taxpayers then -- the credit expired December 31st and regulations wouldn't' be in effect until January 16th, 2015.

So after 30-some-odd years we finally have these regulations but they really don't apply to calendar year and taxpayers. However they do apply to a small group of fiscal yearend taxpayers, taxpayers that would have a tax year end after January 16, 2015, and that do have some software research activity before December 31st, 2014. So it's probably a pretty narrow group of people and so the question is really is that the intent of these regulations; to provide an equitable advantage to fiscal year taxpayers as it's outlined really in the current proposed effective date.

So to help understand this let's just take a look at kind of a reality check for a minute. Let's consider the technical gymnastics that a taxpayer is going to have to go through, to perform, to apply multiple version of the internal use software regulations. So, the IUS rules are part of section 41(d). Also under 41(d) is the four-part test and other tests defining what is qualified research. In order to apply these regulations, since the IUS regulations really are part and parcel of 41(d) you are going to have to apply multiple versions of the four-part test, multiple versions of all of those examples, and so forth.

So now let's consider a taxpayer who is preparing a 2014 tax return and let's assume that that taxpayer performs software development and non-software development. First the taxpayer is going to have to consider and understand and analyze three versions of the 41(d) regulations. They are going to have to understand the 2004 version for all of the non-software activities. They are also going to have to analyze and understand the 2001 Treasury decision 8930, the final regulations, which, as you remember, has the discover test and all the language around the discover test, so they are going to have to go back and understand all of that. Then they are also going to have to understand the 2001 proposed regulations, which is, again, language that is somewhat different than the final regulations. So a taxpayer is going to have to understand all three of those different sets of rules. Then the taxpayer is going to have to choose which of those 2001 rules they are going to apply, and the taxpayer is then going to have to apply two different versions of the four-part test, two different versions of the examples, two different versions of all these regulations so that they can make a determination.

Now, hopefully we can consider, and in our mind comes the complexity, the difficulty, the confusion that taxpayers are going to face. And although we talk about 2014 this is a multiyear issue because of the three-year statute that returns are open and so forth. So there is a good amount of complexity around this merely because of having the regulations only effective perspectively.

Now, to help understand how large this issue is, based on recent information that was released from the IRS, in 2012 51 percent of taxpayers claiming an R&D credit had gross receipts of less than $10 million. So not all of the taxpayers in that group but a safe assumption that most of the taxpayers in that group are somewhat less sophisticated tax-wise. So we have the majority of the taxpayers kind of in that small mid-size group of companies. One of my favorite quotes of the year is that the tax court recently stated that the R&D credit is one of the most complex sections of the code. That statement was made even before these proposed regulations, and even before just the perspective effective date of the regulations.

Now, let's go and say okay, so what should be done about this? If we take a look at the guiding principles, and we address some of these in our written comments, two key principles there are. "Are the regulations readily applied and readily administered, can they be?" In the advance notice of proposed rulemaking there are a couple of comments in there. The Treasury and the IRS say that they are concerned about rules that add complexity without providing clarity. They state that many new terms would be prone to controversy and could not readily be applied, and so forth. And they suggest that the IUS section of the 41 regs should apply to the same period of time as the corresponding version of those regulations.

In the advance notice it suggests 1986 and says, well, that might be too long of a period of time. There are some other periods that we could consider, and to kind of wrap things up let's consider a couple of dates. Really to achieve the guiding principles that are outlined to make this administrable and so forth, applying the regs back to 1986 might be too far back and there is really no practical reason to do that since most of those years are all closed and done. The most logical solution is to have these regulations apply back to 2004. These regulations are part and parcel of the 2004 final regulations. If these regulations would be applicable back to 2004 then we can match up the internal use software rules which are part of the exceptions with the four-part test that we've all agreed on, we can once and for all do away with the discovery test which we've spent years and years talking about, and it's really what makes the most sense, to be able to use 2004 as that retroactive date because that's really what these regulations should be part of. We would then have one set of coordinated rules for the R&D credit. So 2004 is my vote.

Now, there are some other dates. Maybe if you can consider going back to 2007. 2007 makes some sense because 2007 is when the ASC was enacted, and also based on the IRS data, 70 percent of the R&D credits that are computed in 2012 are computed based on the ASC. So that could make some sense. So then at least if you are under the ASC then you have, again, one set of rules, and there is some continuity between things.

This one doesn't really get my vote, but you have to have a list of three. The third date would be 2011. Again, under ASC and so forth that would then spread at least three years of QRE. So we have one set of rules for fiscal year and calendar year taxpayers that cover the entire calculation.

In closing, the majority of these R&D credits are claimed by mid-sized companies are not super sophisticated but they do a lot of work that is both software development and not software development and so these rules are going to apply to those individuals and those companies, and so we really suggest that you evaluate making these rules retroactive and 2004 gets my vote.

Any questions? Thank you for this opportunity.

MS. GRIMM: Thank you for your comments. Our next speaker is Tyrone Montague from KPMG. When you are ready.

MR. CULP: Actually, I am David Culp. Tyrone is there but I'm going to be delivering our comments today.

MS. GRIMM: Just let me know when you would like the timer to start.

MR. CULP: I'm ready, thank you. Good morning, I'm David Culp, a director at KPMG, LLP. KPMG assists numerous clients in determining the amount of research credit they are allowed in computing their federal income tax. We are not representing any particular client in our comments, but many of our clients would be affected if these regulations were adopted as drafted. We hope that by presenting comments today we can help our clients and the IRS to avoid some potential areas of controversy in the future. We are always glad when the government expresses optimism that the research credit will be there in future years. We are grateful that the IRS and Treasury have developed guidelines that in general will provide some useful determination demarcations about what will and will not be IUS.

Also in general we believe that the description of the High Threshold of Innovation Test and the proposed regulations will be useful in applying the test in particular contexts. However, there are several details in the proposed regulations that raised some concern. Our written submission describes our concern in detail. In the ten minutes we have today we can't do much more than note our comments on a high level.

What is at stake in these regulations is whether a taxpayer software development will be considered for IUS which needs to satisfy the three-part test as well as the general four-part test, or whether it is not for IUS and needs to satisfy only the four-part test. These are sometimes high stakes. A lot of research credit dollars can depend on how the software is classified and on how the three part test is defined.

Proposed regulations basically state one description of what is IUS and two descriptions of what is not IUS. These are useful. These descriptions were provided as simple principles and were the only guidance. They would likely make the classification clear in most cases. These basic classifications would eliminate much of the controversy taxpayers have faced over the past 20 years, but there are details in these definitions that raise concerns.

To be considered software developed for commercial marketing or software that enables a taxpayer to interact with third parties or for third parties to use taxpayer software, the proposed regulation says that the determination needs to be made at the beginning of the software development. This requirement does not appropriately recognize that the purpose the software is intended to fill can change or pivot during the development. Taxpayers can envision commercial opportunities for software in mid-development or think of ways for customers to interact.

A software development project can take several years. Whether qualified research is taking place should be determined based on the activities the taxpayer is actually conducting at the time it performs the research and not on the success of the research of the taxpayer's original vision.

Some commentators suggest using a primary purpose test or looking at whether substantially all of the use would be for one of the three categories, use that to determine how it is classified. We encourage the IRS and Treasury to give further consideration to those ideas.

Proposed regulations include a varying detailed safe harbor that would allow part of the development activities for certain dual function software to be treated as qualified research without satisfying the High Threshold of Innovation Test, even if there is a backroom function to the software when it is actually placed in service.

We appreciate that the IRS and Treasury recognize that some software does not fit cleanly into one of the three categories but is still deserving of a research credit. But this is a very complicated test. We discussed the concerns in our written submission. For now I will say we believe this safe harbor will not work without some flexibility added to it. If the IRS and Treasury believe a safe harbor would be useful, we encourage you to work on this more. However, whatever you decide about a safe harbor please do not hold up issuing final regulations that cover the main points while you deliberate on this.

One nuance in the way the software classifications are described is in the way they deal with related parties. If a related party is involved the general definitions of IUS in the regs wouldn't apply. For example, software that is intended to be commercially marketed to a related party, even at an arm's length transaction where the related party is just another customer, could still be IUS.

One concern we have is that the proposed regulations would apply a very low standard of relatedness. Any user in a sane controlled group with more than 50 percent common ownership would per say be considered a related person. If it is important to treat related party situations differently, we encourage a more realistic standard that considers whether the parties are actually working together in using the software.

Our biggest concern about the high threshold of innovation test in these regulations is that it excludes a taxpayer's efforts to resolve uncertainties about the appropriate design of the software from being able to satisfy the significant economic risk requirement. More than any other type of research, questions about the design of software will often precede or at least be confronted at the same time as decisions about capability and method. Since 1994 design uncertainty has been an acceptable purpose for research to meet the section 174 criteria. It is not appropriate to drop it out of the high threshold of innovation test.

Separately, the proposed regulations contain a statement that it is not always necessary to have a revolutionary discovery or creation of new technologies to satisfy the three part test. This sentence should be removed. It implies that there are situations where a revolutionary discovery is necessary. Let's make sure there are no subtle vestiges of the discovery test lurking in these regulations. We do not see why it would ever be necessary to have a revolutionary discovery or creation to quality IUS for the credit.

The preamble to the proposed regulation states the view of IRS and Treasury that certain types of web design and the installation of enterprise resource planning software generally do not qualify as a process of experimentation. Proposed example 9, dealing with the process of experimentation refers to the taxpayer using quote routine programming end quote to implement its IRP software. The example concludes that its facts do not involve a process of experimentation. We do not know what routine programming is. We think it is likely that some IRS examiner would rely on this example in the regulations to disqualify any programming they consider routine without any need to articulate what is lacking. Also, referring to routine programming seems to infer that there is a discovery test which of course there is not. The regulation should at the least be more specific in describing the difference between routine programming and other software development that does satisfy the process of experimentation requirement. It would be even better to eliminate the phrase routine programming entirely.

Example 9 concludes that the taxpayer's activities related to the IRP software are not qualified research. This example fails to recognize that taxpayer's can and do confront technical uncertainty about the appropriate design of the configuration of an IRP system. Many IRP projects have been unsuccessful because of failure to appropriately configure the system. Example 9 should be revised to recognize that the taxpayer's configuration activities were intended to resolve design uncertainties and should conclude that these activities in this case do meet the process of experimentation test.

We request the taxpayers apply these regulations to tax years ending before January 20, 2015. For many years, taxpayers had been without an authoritative standard for what is IUS and what the test is to make it qualified research. The preamble suggests the standards in the proposed regulations are appropriate to the way software is used in today's economy, rather than to how congress perceived it in 1986, or even how the regulation writers understood it in the early 2000s.

It is not appropriate to say one standard applies to 2014 and other recent years while a different standard applies in 2015. There are in fact established IRS policies and some case law that would make it difficult for the IRS to enforce a policy against allowing taxpayers to rely on the standards and proposed regulations in earlier years. There have been no final regulations since the early 2000s. These proposed regulations are way more than a reasonable interpretation of what the statute means referring to IUS.

Taxpayers have waited so long for a useful set of rules we can't understand why they can't rely on these regulations in past years. We request the IRS and Treasury to affirm that retroactive reliance is acceptable and we hope they can issue administrative guidance that applies until final regulations go into effect.

If the final regulations maintain the position that there is one test earlier than 2015 please clarify that reliance on the IUS provisions of the 2001 final regulations by no means would require a compliance with the discovery test.

As a subsidiary matter we note that having vastly different standards for IUS before 2015 raises issues about how to apply the consistency requirement. In computing a research credit for 2015, the QREs for earlier tax years must be determined on a basis consistent with the definition of QREs in 2015. Without any special rule, taxpayers will need, in any case, to recompute their QREs for software development in earlier years consistent with these regulations. If the IRS and Treasury can do anything to make this a less burdensome requirement it would be appreciated.

In closing, please let me reiterate that these regulations are a great improvement on the standards we have thought needed to be complied with over the last 11 years. We think they can be improved. We hope to avoid new areas of dispute with IRS agents over how these regulations should be applied. We hope you take our suggestions into account. Thank you very much.

MS. GRIMM. Thank you, Mr. Culp. Does the panel have any questions?

MR. CALL: I was hoping to ask you to elaborate on the change in use reposition with respect to changing the principle purpose of developing the software. Would you elaborate a little on how that determination would be made in your mind?

MR. CULP: Very often a taxpayer sets out to do a project and it may just be internal use but they hope to explore something. They may intend it for a backroom function, it could be a while down the road they discover, hey, this is great software, we are discovering great things. This could be useful. We could market this out to other people. It might take a couple of years to do that project and if you start with the idea -- you start looking into backroom functions and they do need to expand the project it seems rather narrow to say that it still needs to meet those same standards if there is a different standard for commercial use. Oftentimes they will take up different ideas, different ways of potentially using it and that does affect how software developers need to do it. Each year, even daily, there might be changes but other aspects of the research credit really look to what the taxpayer is actually doing and it seems to be rather short sided even though there is a statutory restriction on IUS to say that once we've started out we can't change anything.

MR. CALL: It sounds like you are proposing a year by year determination about what the activity actually relates to, or is there some sort of demarcation between principle purposes?

MR. CULP: In most research credit analyses we look at a project and it can have different qualifications in the year. In other aspects there might be a process of experimentation going on in one year but not in another but we would look year by year. What exactly the test should be, we had this suggestion about substantial use or predominate use. We don't know what the standard would be but we think that just restricting it to what happens at the beginning of the project is very restrictive and isn't very useful.

MS. GRIMM: I'd like to welcome our next speaker to the podium, a representative from McGladrey.

MR. CLICK: Good morning.

MS. GRIMM: Good morning. If you could just let me know when you are ready I will still start the timer.

MR. CLICK: Good morning, my name is David Click, I'm from McGladrey, the largest accounting firm representing the middle market. Thank you for allowing me to speak today, a day that has been a long time in coming. Congress addressed internal use software distinction in 1986 and almost 30 years and two advanced notices of proposed rulemaking later, here we are.

I appreciate the complexity of the task before the Treasury Department and the Internal Revenue Service. Congress created the distinction for internal use software in 1986, ironically the same year that IBM introduced the first personal computer. For computer software and research much has changed. Indeed, in certainty over the credit as a whole and the rapid pace of technological advancement has made the IRS task of administering internal use software that much more difficult.

With distinction for internal use software made in 1986, software development was primitive compared to what we see today. Software in the 21st century drives businesses and it drives our personal lives. I can fairly confidently predict that over the course of these hearings someone in this room will use their cellphone to check their email, text messages, or twitter accounts, all of this run by sophisticated software and none of the software was imagined by Congress in 1986.

The IRS and Treasury has done a good job with a very workable definition of internal use and non-internal use software as set out in these proposed regulations. Although a long time coming, the regulations are practical and timely, particularly in their approach. The proposed regulations defined internal use software as software developed by the taxpayer for use in general and administrative functions to facilitate and support the conduct of the taxpayer's business. General administrative functions in the proposed regulations are limited to financial management, human resource management, and support services. For example, software developed to manage employee health benefits and not developed for sale is internal use software that must meet both the qualified research activity and meet the High Threshold of Innovation Test. This is an important clarification of internal use software and is more practical than previous definitions. Prior to the new proposed regulations internal use software was defined as software developed by the taxpayer that was not to be commercially sold, leased, or licensed, or otherwise marketed to third parties for separately stated consideration. The new definition in the proposed regulations is realistic as it allows for interactive software or service oriented software that is not commercially sold to be treated as non-internal use software.

The pervasive use of software by business to interact with customers, vendors, and others made the commercially sold delineation outdated. The proposed regulations with its specific definition of internal use software is more in tune with how taxpayers use technology to conduct business. Again, the proposed regulations are a significant achievement. However, I don't want to let my accolades over the IRS's hard work and sensible approach overlook the problems with the proposed regulations. And these problems need to be addressed.

In McGladrey's written comments we critiqued many of the technical aspects of the proposed regulations. Due to time constraints on oral testimony, I want to concentrate on the proposed regulations and the administration of the research credit.

Since 2009 and the Government Accountability Office's report on the administration of the credit, the IRS has taken steps to make the research credit less contentious and more manageable. LB&I initiated a series of meetings with taxpayers, many of whom are here today -- tax practitioners to help clear the air over some of the contention in the research credit. The LB&I dropped the tiered issue approach which was holding up a lot of IRS examinations and replaced it with the industry practice groups that we have to date, and we are seeing tangible results in the field from these industry practice groups.

The IRS issued clarifying regulations under section 174 recently on prototypes to clear up some of the confusion over litigation in this area, regulations on the alternative simplified credit that made that simpler credit calculation more available to more taxpayers, and finally a long awaited internal use software regulations provide taxpayers with a workable definition of internal use software and non-internal use software.

However, the dual function provisions muddied the waters. The proposed regulations provide a new category of analysis for dual function computer software. Dual function computer software is discussed in the proposed regulations as computer software developed by or for the benefit of the taxpayer, both for use in the general and administrative functions, the facilitator supports the conduct of the taxpayer's trader business and to enable the taxpayer to interact with third parties or allow third parties to initiate functions or review data, is presumed to be developed primarily for the taxpayer's internal use. The proposed regulations go on to provide that to the extent that a taxpayer can identify a subset of elements of dual function software that enables the taxpayer to interact with third parties such subset is not internal use software. The safe harbor is contained in the regulations, et cetera.

The dual function computer software provisions are confusing and unnecessary. It appears to be inconsistent with the proposed regulations definition of non-internal use software. The proposed regulations state that software developed to enable taxpayers to interact with third parties or allow third parties to initiate functions or review data on the taxpayer system is non-internal use software. However, revenue agents could easily confuse interactive software with dual function software resulting in the conflict over the basic definition of software. Further, trying to delineate elements of dual functioning computer software raises significant administrative issues. The proposed regulations do a good job of defining functions that constitute internal use software, financial management, human resource management, and support services. Customer interactive software that has integrated components with inventory management or order processing primarily support customer interaction and should not fall into the dual function and ultimately internal use software category. Software has become far too sophisticated and multifaceted to be boxed into rigid definitions. Integrated software that performs many functions may have integral features that provide customer access and maintain internal functions. It is impractical to treat this software as partly internal use and partly interactive software in a situation where the software may facilitate several integrated functions.

From the point of tax administration to finding and allocating research expenses between internal use and non-internal use components of software is problematic. Revenue agents will have to make imprecise judgments on the nature of the software and allocation of development cost. This will lead to needlessly protracted IRS examinations and the imprecision of such analysis could create a chilling effect on taxpayers otherwise entitled to claim the research credit on software development.

Is it worthwhile for the taxpayer to attempt to allocate costs between various components of an integrated software program? Should a taxpayer invest time and resources defending software treatment from the application of the imprecise definition of dual functioning computer software during the course of the examination?

Let me also pick up on a comment from Mr. Andrus regarding the effective date of the regulations. The proposed regulations were promulgated in January less than a month after Congress allowed the research credit to lapse for the 16th time. Although the regulations are very helpful, even when they are finalized they will apply to almost no one. Many of the comments you received from the tax community requested that the regulations be applied retroactively; taxpayers had waited a very long time for guidance on internal use software. Generally regulations are prospective under section 551 of the Administrative Procedures Act and 7805(b) of the code; regulations have an effective date no earlier than when the regulations are published in the Federal Register. However, given the time it has taken to publish this much need guidance and taking in consideration that most of the calendar year taxpayers are only now preparing their 2014 tax returns, guidance allowing taxpayers to rely on the regulations can be issued in the form of an IRS notice or revenue ruling. Most revenue agents should be instructed not to disturb the treatment of software applying these regulations before the final effective date.

Let me make one final comment about research and development and the tax treatment through the research credit. In finalizing these regulations consider please that final regulations need to be flexible to accommodate the pace of technological advancement and adaptable to future applications that cannot be foreseen today. Confusing provisions such as the dual function software provision or the exclusion of internal use software to overcome design uncertainty are probably already outdated. Final regulations in this area may be on the books for many years to come, leveling guidance to taxpayers and revenue agents alike. Please ensure that the final regulations concerning internal use and non-internal use software are flexible to accommodate technology developments, practical enough to provide taxpayers with clear and certain guidance, and administrable to allow revenue agents to resolve issues efficiently without protracted examinations, appeals, and costly litigation.

Thank you for your time. I'll be happy to answer any questions.

MS. GRIMM: I actually have a question for you. The government did not receive many comments about the treatment of middleware or bridging software, however, your office did submit a few comments about that issue. So I was wondering if maybe you could expand upon that a little bit more, and in particular I was just wondering your office's views on how significant it is to include a rule specific to middleware when there are general rules relating to software in the regulation.

MR. CLICK: I appreciate the curiosity about it, and I know that in the regulations there wasn't a specific definition of what constituted middleware. You asked for, you solicited comments on it, I think from our point of view and what the comments we provided, we see middleware as part of the overall software package and therefore we didn't need to see a distinction between middleware software and regular internal used software. Although we appreciate your curiosity on the issue, I don't think we see it as a separate issue, and again we would refer you back to the comments that were made in the preamble to the regulations that says whether software is not developed for primarily internal use depends upon the intent of the taxpayer, and the facts and circumstances at the beginning of the software development. Whether you are developing regular software, internal use software, or middleware, or connectivity software, we will look at what was the purpose at the time it was being created.

MS. GRIMM: Okay, thank you.

MR. CALL: And your proposal to eliminate the dual function definition, you would say any time it involves third-party interaction it's not internal use?

MR. CLICK: I know Mr. Call you're going to think that is overbroad, but from a practical standpoint, the dual function software provision is going to lead to a lot of problems as far as administration if the credit is concerned. Because again, it seems to be inconsistent with your definition of non-internal use software, and then, the dual function software, the problem with software, and I think Kathleen King raised this in her presentation, the problem with software is it is going to be multifaceted. So, the fact that I've had software for example, I think in our comments we mentioned banking service, where if I go to my bank, my bank can also access my brokerage account. Those might be internal use softwares, but the whole deign of that software was to accommodate my interactions with the bank or with the brokerage house.

MR. CALL: All right, so rather than get comfortable with certain factors that would help us distinguish between the different components, you would say well if it has an outside connectivity, then it's not internal use?

MR. CLICK: I would not want to classify it as, I would want to classify it is as non-internal use, a lot of double-negatives.

MR. CALL: Yeah, yeah, yeah, yeah.

MR. CLICK: I would want to classify it as non-internal use because it is interacting with an outside party, a third party, or it's designed to deliver services. It may have the ancillary effect of managing inventory or report writing or some other function that we may consider to be a backroom function, but if its focus is also to interact with customers then clearly, I would not want to call that internal use software. I thought that the definitions actually that you had, the three categories of definitions in your regulations, I thought were one helpful, and two I think created a well-defined definition of what is going to be internal use software.

MR. CALL: Thank you.

MS. PARK: Just to clarify, so you're saying use the primary test for third-party? Is it primarily the, the --

MR. CLICK: I don't want to say primarily because primarily, in answer to Mr. Call's question earlier about the development of software, I will give you an example of, on the question that you raise with Mr. Call. I had an insurance company a number of years ago who was developing internal use software, and they were developing the software primarily because they couldn't find a software package that would manage their insurance reserves. Once they started developing this, they realized that they could do more than this, and they could help process claims or write the policies, etc., etc., and expanded what they were doing. So again, if that's a situation where initially they were writing software to solve a particular problem, but as the project went on it got bigger and bigger. In that sense, we believe it qualified as internal use software because of the economic risk, they spent a lot of money on it, was it commercially available, etc. That type of software that an insurance company may have where I can go on to my computer, you know get a policy quote, the policy is written. Internally, there is a lot of things that would go on with it, but because it is interacting with the customer, I would want to keep that as non-internal use software. The problem I have Ms. Park is with the administration of the credit. I think that if, if the dual function software is just going to create a lot of administrative problems out in the field.

MS. GRIMM: Thank you very much. Okay, I would like to invite next to speak some representatives from New York Law School. And, if you guys are going to split time, I'm just going to let it run and you can decide who --

MS. DOKUCHAYEVA: And we have --

MS. GRIMM: Okay, so just let me know when you're ready.

MS. DOKUCHAYEVA: All right. And we have one person who is not coming, who didn't come with us.

MS. GRIMM: Okay, that's fine. If you could just introduce yourselves.

MS. DOKUCHAYEVA: Yeah, definitely. Okay, I think I'm ready.

MS. GRIMM: Okay.

MS. DOKUCHAYEVA: Good morning ladies and gentlemen. My name is Anna Dokuchayeva, and I'm a LLM student at New York Law School. Today, along with my colleagues will be addressing and presenting our comments that we submitted to the IRS. Specifically, we will be addressing how the proposed regulation effects financial institutions. I will be addressing the first point, and two of my colleagues Plamen Kovachev and Lauren Jakubowicz will addressing second and third points. Please note that the views that we express today are our own, and not those of New York Law School. It is inequitable to require highly regulated financial institutions to satisfy the High Threshold of Innovation Test for their technological development to be qualified under the Internal Use Software Test, because it may disproportionally affect this financial institution and further increase the cost. You might ask why. Because the compliance is already rising, and recently enacted laws such as Dodd-Frank, FATCA, Basel 2 and Basel 3, require change and regulatory systems, and further requiring the updates for some of the forms of modeling, risk modeling softwares, as well as innovating new softwares. Moreover, the compliance today in terms of Anti-Money Laundering provisions, and Know Your Customer provisions, also require the banks to update their software. In fact, in 2014, it has been reported that 92 percent of North American banks increased their compliance cost. For example, JP Morgan Chase spent $2 billion in 2014. Also, 600 compliance practitioners including a significant number of compliance heads and chief executives reported their compliance spending increased by a lot. In 2013, that compliance spending increased by 17 percent. In fact, the staff has doubled in banks like Citi, Bank of America, JP Morgan, and Goldman Sachs. Not to mention that the market demands for more technological updates, and banks are still struggling from the market downturn of 2002, known also as internet bubble burst, and therefore having a small IT budget. Thus, it requires outsourcing all the internal software development to overseas, and in fact banks spent over half of their IT budget last year on compliance and Barclays reported that they spent 41 percent of IT budget on compliance. The majority of the banks will be developing computer software under the general definition of internal use, and for the banks to receive credit under Section 41, they would have to undergo through the following: First, they have to satisfy the internal software definition, then they will have to meet the prongs of the High Threshold of Innovation Test, then they have to show that the software is innovative, measurable and objective standard is met, there is an economic risk, not to mention that they would have to show that the software actually can be purchased, leased, or licensed. And, on top of it, they have to show that there is a reduction of cost and the software is unique. So you can see that the bank will have to go through a lot of steps in order to receive the credit. Therefore, we request the IRS and Treasury today to take into consideration how it will impact the financial institution, especially the High Threshold of Innovation Test because financial institutions are going to spend more money, and thus compliance costs will eventually pass to consumers, which is us, outsourcing many technological jobs overseas, and in fact this goes against the proposed legislation of Section 41 because it will ultimately effect the U.S. economy somehow.

MR. KOVACHEV: The next point we want to address is related to the definition of third parties. The current definition of third parties indicates that third parties should mean any corporation, trade or business or other person that is not treated as a single taxpayer with the taxpayer pursuant to Section 41(f). The definition further goes with defining third party this is, the ones that do not include any persons that use the software to support the general administrative functions of the taxpayer. We believe that the definition of third-party test is too vague and fails to account for the unique aspect of financial services in other industries. Specifically, the definition of third party should reasonably affect the purpose and the intent of each business. IRS and Treasury have considered the purpose and intent when it comes to internal use software developed for commercial sale, lease, and licenses in addition to looking at the functionality. However, when it comes to third parties the software that enables taxpayers to interact with third parties or allows third parties to initiate functions or otherwise review data on the taxpayer system does not totally benefit the taxpayer. Essentially the current definition of third party, or the examples given in the regulation look more of the benefit that the third party gets and not as much as the purpose or intent for the development of the software. Some of the reasoning behind this and examples we have looked at are regulations related, software developed for purposes of Anti-Money Laundering and Know Your Customer regulations. Some of these softwares are developed for purposes of complying with these regulations and sharing and communicating data with third parties. However, these third parties they don't solely benefit from the taxpayers, so essentially they would not be considered third parties. Other examples that can come into play is mobile banking, as it becomes more and more prevalent with mobile banking additional compliance matters related to Anti-Money Laundering and Know Your Customers would require development of software that would involve interactions with third parties. Again, the sole benefit is to the bank and is not necessarily a benefit to the third party, they might not be included. Another example to develop this point is related to cyber security where in house, where banks develop software to interact with government agencies and other third parties. To kind of high light these points we have looked into some statistics which, for example, involve, discuss the cost of Anti-Money Laundering and Know Your Customer expenses have been increasing over 53 percent for the last year. Some of these banks have spent over $7 billion, and involving some of these softwares, and furthermore as a big bank is spending so much money internal developing software is Goldman where it can be considered to have spent more than 33,000 employees out of which 90,000 are engineers and programmers. Our proposition for this matter is that the definition of third parties should discuss the purpose and intent of the software.

MS. JAKUBOWICZ: To address the third point further, to qualify for the credit under the Safe Harbor Provision, the software developed for internal use and for interaction with third parties requires a subjective and reasonable method at the outset of the development, the cost estimation. So the proposed regulations do provide examples where a taxpayer is able to use this objective and reasonable method to estimate the cost, but it fails to provide a set of facts for the taxpayers unable to identify a third party subset at the beginning of the software development. So we think that this method is vague, and that adopting an objective standard would better account for the particularities or characteristics of each industry. For instance, the objective reasonable method used by the financial institutions could differ than used by service providers. For example, financial institutions benefit from Casia automation software which controls the daily workload task to maintain regulatory compliance and a reduced risk. But, as used by a non-financial institution, it's going to serve a different purpose and it will focus on security service and the reliability of IT management solutions. Therefore, we think that the language should be clarified by adding an objective reasonable method within each industry. For the foregoing reasons that we have present, we believe that the regulations are inconsistent with the original legislative intent since they subject financial institutions to a burden of satisfying the internal use software criteria under Section 41. Further, the definition of third parties should reasonably reflect the purpose and intent of each business, and finally the objective reasonable method under the Safe Harbor Rules should clearly reflect the objectivity of each specific taxpayer industry. If efficient and consistent tax administration is sought from enacting these regulations, we respectfully request that the IRS and the Treasury take full consideration of our comment before the proposed regulations are adopted. Thank you for your time and the opportunity today.

MS. GRIMM: Thank you. Do we have any questions from the panel?

MR. CALL: Do you have any suggestions of effective reasonable standards?

MS. JAKUBOWICZ: What we think is that within each industry is going to have to be, it's going to have to be individually addressed within the financial --

MS. DOKUCHAYEVA: Market especially, because the financial services --

SPEAKER: Go up to the mic.

MS. DOKUCHAYEVA: The financial services are so different compared to other industries. Even just to take example of third parties, what we would think service providers would be for the third parties, for financial institutions like anti-money laundering compliance would be very different and know your customers, to mobile banking. There is a lot of regulations around, within the financial institutions, and they have to follow it. Like other industries, you know, for example manufacturing industries do not have to follow the same. So we think that if we would just add the language within each industry, it is just going to help taxpayers to understand and how to measure it within their own industry. Sort of taking that objective standard, but yet sort of subjective.

MR. CALL: Industry specific?

MS. DOKUCHAYEVA: Yeah. Industry specific. Yup.

MR. CALL: Thank you.

MS. GRIMM: I'd like to invite our next speaker to the podium, and that would be Kendall Fox from PricewaterhouseCoopers. When you're ready, just let me know. Ready?

MR. FOX: Ready. Good morning. My name is Kendall Fox. I'm a partner with PricewaterhouseCoopers, LLP. I have over 25 years of experience advising businesses large and small across different industries that incur software related research expenditures. I am a frequent author and speaker on research credit related topics including the primary author of the B&A Portfolio on Research and Development Expenditures. Guidance on this topic is of great importance in accomplishing the goal of the credit to increase qualified research activities in the United States, and I encourage Treasury and the IRS to consider the comments you receive and finalize the regulations with modifications as soon as practicable. I appreciate this opportunity to comment on the proposed regulations on treatment of internally used software for research credit purposes.

My main recommendations are as follows: First design uncertainty is a substantial technical risk and should be included in the high threshold of innovation test for IUS. Second, with congressional intent stated in the legislative history to the Tax Reform Act of 1986, the effective date for the final regulation should be retroactive. Third, the process of extermination example should be modified as I will discuss. Fourth, consider adding an example to the proposed regulations that clarifies consistent with the court's holding in Suder that the software engineering development process can qualify for the research credit. And finally, the dual function software provisions of the proposed regulations should be modified to provide a de minimus safe harbor where third-party functionality is greater than 80 percent, consistent with other research credit provisions, and a pro rata allocation between third party and IUS software based on measurable third-party use rather than limiting the safe harbor to 25 percent. This will reduce complexity and decrease administrative burden. The goal of these recommendations is to further clarify the IUS rules so that businesses can plan their software research budgets with greater certainty as to availability of the credit, and so that the IRS can be better assured the credit will be restricted to activities that the Congress intended to encourage. Design uncertainty is a substantial technical risk, and should be included in the High Threshold of Innovation Test for IUS.

There are two stated rationales offered in the preamble for excluding design uncertainty from the determination of significant economic risk. First, that its exclusion will create a higher threshold for eligibility. Second, that the terms capability and method are viewed by the drafters as previously defined terms that will reduce potential controversy. As to the first rational, we believe that the first and third tests of the High Threshold of Innovations Standard already create the intended higher threshold, and that the software must be both innovative and not already commercially available. Therefore, it is unnecessary to change the process of experimentation definition of uncertainty as it relates to significant economic risk to achieve this purpose. As to the second rational, capability and method are not well defined terms either within the regulations or in court cases dealing with interpreting significant economic risk.

Elimination of design uncertainty from the Znicken Economic Risk Standard, will increase controversy and create difficulties in administration to credit. The three types of uncertainty are inexplicably inextricably linked, and therefore difficult to separate. They also evolve and change throughout the software development lifecycle. At the outset of a research project, the taxpayer may identify method, capability, or design uncertainty. However, many uncertainties are only uncovered as the project progresses. As discussed in the Norwest decision, complex projects by their nature will result in unforeseen problems. The Conference Committee on the 1986 Act explains the required process of experimentation uncertainty with respect to the means of achieving a result, where that uncertainty is eliminated through a sequential design process to develop the overall component. Congress also intended that eliminating uncertainty concerning method is credit eligible using an example explaining the meaning of uncertainty concerning method. The conferees stated "engineers who design a new computer system or who design improved or new integrated circuits for use in computer or electronic products are engaged in qualified research because of the design of those items is uncertain at the outset and can only be determined through a process of experimentation relating to specific design hypotheses as described above."

Research expenditures should not be disqualified from the credit where the capabilities and methodology are thought to be known at the outset, but during the project design uncertainties may or in fact do cause it to fail. The IRS has added a new level of subjectivity to the high threshold of innovation by requiring a person process during IRS audits to separate resolution of design uncertainty from method and capability. This is inconsistent with improving the high threshold of innovation by changing the innovation standard to one that can be measured and defined, increase speed, reduction in costs, etc. We therefore request that the IRS restore design uncertainty to the definition of significant economic risk.

Effective date. The high threshold of innovation requirement has its genesis in the Tax Reform Act of 1986, where Treasury was instructed to promulgate regulations implementing the standard. The Conference Committee report states, the conferees intend that these regulations are to apply as of the effective date of the new specific rules relating to internal use software, i.e., internal use computer software costs that comply under the three part test set forth in this paragraph are eligible for the research credit even if incurred prior to the issuance of such final regulations. This language shows that the final regulations were always intended to be effective retroactively. The conference report also states, the conferees expect and have been ensured by the Treasury Department that guidance to this effect is to be promulgated on an expedited basis. Thirteen years later, the legislative history of the Tax Relief Extension Act of 1999 instructed Treasury to issue regulations regarding what constitutes internal use software. Fifteen years after that, proposed regulations have now been released. These regulations adopt a well thought out, straight forward definition of what is and is not IUS. This definition is consistent with Congress' 1999 instruction to Treasury and with the '86 legislative history example IUS Softwares General Administrative Software. However, the preamble to the post regulation states that software not developed for internal use under these proposed regulations, such as software developed to enable a taxpayer to interact with third parties may or may not have been internal use software under prior law. This statement reflects the fact that taxpayers and examiners have faced uncertainty as to what constitutes IUS versus third-party software. The lack of clarity and previous regulatory guidance and the resulting uncertainty is unnecessarily exacerbated by not allowing a taxpayer to apply the concepts in these proposed regulations retroactively.

Administrative difficulties with the prospective date include: Complying with the duty of consistency principle for a taxpayer that incurred qualifying software development research expense in earlier tax years, applying different rules and definitions to software development projects that span multiple tax years, and possible disparate treatment of taxpayers that incur similar expenditures in different tax years. Ironically, a taxpayer that first takes the risk and initiates a research project prior to the effective date may not receive a research credit while a second taxpayer incurring similar expenditures after the effective date may receive a tax credit. Therefore, we request that the IRS include a retroactive effective date when the proposed regulations are finalized.

Process of Experimentation Requirement. The examples illustrating application of the process of experimentation requirement to computer software require clarification. The proposed regulations include six new examples for inclusion in Regulation Section 1.41-4. These examples illustrate how the process of experimentation test is applied to software related activities and clarify that the mere evaluation of commercially available software and the configuration of purchased software are not considered a process of experimentation.

The following are comments on the proposed examples: Example 7. The facts of this example list a single alternative, the separate server with round robin workload distribution that the taxpayer consider and evaluated. This would be consistent with Regulation Section 1.41-46 which provides that the evaluation of one or more alternatives is acceptable. In Example 7, the IRS implies that the taxpayer must evaluate more than one alternative to quality. We therefore recommend that this example be clarified or removed. Example 9. In the facts of this example, the IRS uses the phrase "routine programming". The term routine programming is both subjective and unmeasurable. Moreover, in the recent case of Suder v. Commissioner, the IRS produced an expert who argued that the taxpayer's activities in questions were routine programming and routine software development. In allowing the taxpayer's activities to qualify, the tax court was not persuaded by the distinction of routine versus non-routine and also concluded that engineering know-how could not be distinguished from the principles of engineering. We urge the IRS to remove the phrase "routine programming" in this example to reduce confusion and to be consistent with the Tax Court opinion.

Examples 8 and 10. These examples appear to relate to IUS software. We urge the IRS to provide greater clarification as to whether these applications are qualified research activities by continuing the example through to the application of the High Threshold of Innovation Test. The Suder case outlined the various stages of a typical software development process. It would be useful for taxpayers and examiners that if an example addressing the typical software development process were added to the final regulations, this example would be similar to the shredded food blade, and automotive examples in the final regulations in Regulation Section 1.41-4.

Dual function software. We encourage the IRS to modify the safe harbor in cases in which the taxpayers anticipate third-party facing use to exceed 25 percent, but less than 80 percent. Given that taxpayer must document anticipated use, it should then follow that the portion of software treated as third-party facing should mirror this analysis. In other words, the proportion anticipated to be third-party facing should be the proportion of ________.

In conclusion, we encourage the IRS to modify the proposed regulations in accordance with these comments before the regulations are issued in final form. Thank you.

MS. GRIMM: Thank you. Are there any questions from the panel?

MR. CALL: I have a question about the last point, and I have concerns about the administrability of a determination of third-party use for dual function software, could you speak to that and whether that would be a burden?

MR. FOX: Well I think that when you get to what are objective reasonable methods of determining what is in fact third party, tax payers may be able to develop statistics. I think my comment was with concern to the safe harbor being only 25 percent would be considered to be subject to the safe harbor when 95 percent of the functionality of the software might be intended to be third-party facing. That seems inequitable. If you already have to go through the effort of demonstrating third-party use and documenting and improving it, why wouldn't that then be the allocation between the two if in fact you retain a dual function test? Similarly to the wage and the process of experimentation test with the 80 percent safe harbor, once you prove that at least 85 percent of an activity is a process of experimentation even if you have non-qualified activities, they still allow 100 percent, and that's again to make administration easier and to prevent having to parse apart de minimis parts of a project.

MS. GRIMM: Okay, thank you. So those were the representatives who asked to speak today before this hearing. Is there anyone else in the audience who would like to provide any additional comments with respect to this regulation? Okay, well, I would like to thank everyone for attending and for all the thoughtful comments that were provided, and in particular to the speakers. Thank you for going beyond your comments, it's helpful when you expand upon them and give us different examples and we appreciate that. Thank you for attending and this hearing is now officially concluded.