Frascati Manual and R&D in the software development field

the frascati manual

What is the Frascati Manual and why is it relevant to R&D Tax Incentive claims?

In June 1963, the Organisation for Economic Co-operation and Development (OECD) met with national experts on research and development (R&D) statistics at the Villa Falcioneri in Frascati, Italy. The result was the first official version of the Proposed Standard Practice for Surveys of Research and Development, better known as the Frascati Manual.

Over five revisions later, the Frascati Manual is widely recognised as a cornerstone of internationally accepted definitions of R&D and classifications of its component activities. The Manual contributes to intergovernmental discussions on “best practices” for science and technology policies, and its pertinence to the Australian policy framework was reaffirmed in last year's Review of the R&D Tax Incentive (4 April 2016) authored by Mr Bill Ferris AC, Chair, Innovation Australia, Dr Alan Finkel AO, Chief Scientist and Mr John Fraser, Secretary to the Treasury. In the Review, the panel found that:

"...the definition of [eligible R&D] mirrors the principles in the OECD Frascati Manual which is regarded internationally as setting the benchmark for identifying R&D activities."

Below we set out excerpts taken from the Manual, which may help to elucidate the position of when software development qualifies as R&D. 

…

• ROUTINE SOFTWARE DEVELOPMENT

77. Software-related activities of a routine nature are not considered to be R&D. Such activities include work on system-specific or programme-specific advances which were publicly available prior to the commencement of the work. Technical problems that have been overcome in previous projects on the same operating systems and computer architecture are also excluded. Routine computer maintenance is not included in R&D (see Section 2.4.1 for a more detailed discussion of borderline problems between software development and R&D).

• SECTION 2.4.1 IDENTIFYING R&D IN SOFTWARE DEVELOPMENT

135. For a software development project to be classified as R&D, its completion must be dependent on a scientific and/or technological advance, and the aim of the project must be the systematic resolution of a scientific and/or technological uncertainty.

136. In addition to the software that is part of an overall R&D project, the R&D associated with software as an end product should also be classified as R&D.

137. The nature of software development is such as to make identifying its R&D component, if any, difficult. Software development is an integral part of many projects which in themselves have no element of R&D. The software development component of such projects, however, may be classified as R&D if it leads to an advance in the area of computer software. Such advances are generally incremental rather than revolutionary. Therefore, an upgrade, addition or change to an existing programme or system may be classified as R&D if it embodies scientific and/or technological advances that result in an increase in the stock of knowledge. Use of software for a new application or purpose, however, does not by itself constitute an advance.

2. BASIC DEFINITIONS AND CONVENTIONS

138. A scientific and/or technological advance in software may be achieved even if a project is not completed, because a failure can increase knowledge of the technology of computer software by showing, for example, that a particular approach will not succeed.

139. Advances in other fields resulting from a software project do not determine whether an advance in computer software has occurred.

140. The following examples illustrate the concept of R&D in software.

Should be included in R&D:

– R&D producing new theorems and algorithms in the field of theoretical computer science.

– Development of information technology at the level of operating systems, programming languages, data management, communications software and software development tools.

– Development of Internet technology.

– Research into methods of designing, developing, deploying or maintaining software.

– Software development that produces advances in generic approaches for capturing, transmitting, storing, retrieving, manipulating or displaying information.

– Experimental development aimed at filling technology knowledge gaps as necessary to develop a software programme or system.

– R&D on software tools or technologies in specialised areas of computing (image processing, geographic data presentation, character recognition, artificial intelligence and other areas).

141. Software-related activities of a routine nature which do not involve scientific and/or technological advances or resolution of technological uncertainties are not to be included in R&D. Examples are:

– Business application software and information system development using known methods and existing software tools.

– Support for existing systems.

– Converting and/or translating computer languages.

– Adding user functionality to application programmes.

– Debugging of systems.

– Adaptation of existing software.

– Preparation of user documentation.

142. In the systems software area, individual projects may not be considered as R&D but their aggregation into a larger project may qualify for inclusion. For example, changes in file structure and user interfaces in a fourth-generation language processor may be made necessary by the introduction of relational technology. The individual changes may not be considered R&D if viewed in their own right, but the entire modification project may result in the resolution of scientific and/or technological uncertainty and thus be classified as R&D.

• Examples illustrating differences between basic, applied and experimental research

256. Examples from software development:

– Search for alternative methods of computation, such as quantum computation and quantum information theory, is basic research.

– Investigation into the application of information processing in new fields or in new ways (e.g. developing a new programming language, new operating systems, programme generators, etc.) and investigation into the application of information processing to develop tools such as geographical information and expert systems are applied research.

– Development of new applications software, substantial improvements to operating systems and application programmes, etc., are experimental development.

Table 3.2. Fields of science and technology

• What science field software development belongs to

1. NATURAL SCIENCES

1.1. Mathematics and computer sciences [mathematics and other allied fields: computer sciences and other allied subjects (software development only; hardware development should be classified in the engineering fields)]

…

KEY TAKEAWAYS

Many companies do not understand what qualifies as R&D in the field of software development. The above provides some guidance which may help to clarify certain aspects. Beyond this, AusIndustry and the ATO have published a number of guidance documents drawing upon this.

The key for companies making a software development R&D claim is to identify eligible core R&D activities that outline a specific scientific or technical advance sought as a hypothesis. Secondly, ensuring the scope of those activities is clearly rationalised to avoid claiming for activities without a sufficient nexus. This may involve claiming support R&D activities with a sufficient nexus to enabling/supporting the experimentation, or excluding certain activities.

Talk to us today about your software development projects for a free assessment of R&D opportunities.

When software development becomes R&D

ELIGIBLE SOFTWARE DEVELOPMENT AS r&d

What is the difference between routine software development and that which qualifies as R&D?

This question is commonly posed by AusIndustry as a part of their compliance reviews, requesting further information.

Software development has long been a contentious area for R&D claims, and it is also the fastest growing area.

With the burgeoning start up ecosystem in Australia and internationally fuelled by seemingly endless online marketplaces and software as a service offerings, software development R&D claims are likely to continue to increase, as is the scrutiny which will be applied by regulators.

So, how do you know your software development activities qualify as R&D? And importantly, if you are already claiming, are you describing your activities appropriately to minimise the risk of audit activity.

IDENTIFYING R&D IN SOFTWARE DEVELOPMENT

Completion must be dependent on the development of a scientific or technical advance, and the aim of the project must be resolution of a scientific or technical uncertainty. 

You may be undertaking R&D if:

• The context in which a solution is sought makes the solution unique or adds complexity,

• there is no reference solution or knowledge that can be leveraged, and

• experimentation (testing of a number of prototype designs) will be required to achieve the solution, or certain aspects of the solution.

To summarise, any software development work where considerable scientific or technological challenges are faced should be considered, provided the solution is not available to, or readily deducible by a competent professional working in the field.

EXAMPLES OF R&D CLAIMS INCLUDE:

• Development of new algorithms, theorems, architectures, protocols, rules engines.

• Advancements to existing system capabilities in areas of performance, security, scalability, availability.

• Redesigning existing systems using new/different technologies, e.g. a legacy monolithic application to decouple functionality, new architecture design to optimise cloud storage.

• Systems integration that involves large scale and complexity of components not previously integrated in a similar manner.

• Developing unique middleware layers for translating messages between differing systems/layers.

IMPROVING YOUR R&D NARRATIVE

In claims that we review, we often find that there is insufficient detail that would enable AusIndustry to ascertain the registered activities meet the legislative definition of R&D activities. Often companies will provide very brief narrative, or discuss commercial objectives and development outcomes.

Here are our top three tips for improving R&D activity descriptions:

1. Discuss the state of the art and available knowledge, emphasising how the scientific or technical knowledge you are seeking differs.

2. Outline research undertaken in an attempt to identify existing solutions that may be leveraged, and the scientific or technical unknowns which remain.

3. Describe the experiments that have been undertaken from a procedural perspective (hypothesis, process of testing, outcomes including observations and evaluations, further design revisions).

Using a R&D Tax consultant that specialises in software R&D claims can significantly improve claim outcomes and efficiency. They should be able to understand the technical terms, work undertaken, and ask the right questions to probe into the strongest areas. Using an interview process, they should be able to identify and document the R&D activities undertaken.

The R&D Tax Incentive, is it time for a Health Check?

The Balanced Risk

To kick off our blog, I thought I would discuss the balanced risk associated with accessing the R&D Tax Incentive program. 

The R&D Tax Incentive program is a tax based program which companies are entitled to claim each year.

It is not a Grant. It is self assessment much like a company's income tax return or an individual's income tax return. A positive is that you have more short term certainty that any funding will be received. However, longer term, claims may be audited, and there is the risk that a company may have to pay back amounts received including interest and penalties, if applicable.

Just because you have been receiving funds under the R&D Tax Incentive for a number of years successfully does not mean that claims made have been accepted as valid. In fact, the longer you have been claiming under the program, the higher the risk of an AusIndustry or ATO review occurring.

AusIndustry reviews are common, with a company typically reviewed once every four years. Greater focus is typically placed on first year claimants, and particular claim types such as software development. ATO reviews are increasing. Key focus areas include refundable R&D Tax Offset claims, software development claims, and legislative integrity provisions such as "payment to associates". 

Contemporaneous substantiating documentation is critical and sought by both regulators.

From successfully passing a review, comes greater comfort. 

SO ARE YOU AUDIT READY?

At RSF Consulting, we offer claimants a no obligation, free "Health Check" review. This can provide you with peace of mind and comfort surrounding existing claims. The review will look at past claims focusing on:

• claim risks and recommendations on how these may be reduced,

• where additional value exists, which may be accessed, and

• where the process of making a claim can be made more efficient.

This is carried out at no cost to you. The process does not require significant input from company personnel, and focuses on reviewing existing claim related documentation.

TALK TO US TODAY ABOUT HOW OUR “HEALTH CHECK” CAN WORK FOR YOU.