R&D Project

What is an R&D project?

R&D project (German: FuE-Vorhaben, short for Forschungs- und Entwicklungsvorhaben, research and development project) refers to a defined project in which a company systematically works on an open technical question. The aim is new knowledge or a new or substantially improved product, process or service offering. A question is open if, at the outset, nobody in the field can say with certainty whether and how the aim can be achieved. An R&D project (in German also called FuE-Projekt or F&E-Vorhaben) has a defined aim, a start and an end, as well as assigned people and costs.

The term comes from funding law. The German Research Allowance Act (Forschungszulagengesetz, FZulG) describes an eligible project as a precisely defined, indivisible task with clearly set objectives, which may consist of several work packages (Section 2 (3) FZulG). For the research allowance, the certifying body (Bescheinigungsstelle) certifies each project individually; in grant programmes, it is applied for and accounted for with a work plan and financing plan. The categories derive from EU state aid law. Outside funding, the structuring into projects matters in the annual financial statements and in the technical review before a funding round or a sale.

The three categories of an R&D project

• Basic research: experimental or theoretical work that primarily generates new fundamental knowledge without a direct commercial application being apparent.
• Industrial research: planned research to gain new knowledge for new or substantially improved products, processes or services, including prototypes in the laboratory.
• Experimental development: use and combination of existing knowledge to develop new or improved products, processes or services, for example through prototypes, pilot projects and tests under realistic conditions.

Most projects in technology companies fall under experimental development. Routine or periodic changes to existing products, processes and services are expressly excluded, even if they constitute improvements. For grants, the classification also has financial consequences, because state aid law permits different funding rates for each category. For the research allowance, by contrast, the rate is the same for all three categories; there, all that matters is that one of the categories is present at all.

R&D project or routine work: the criteria

Whether research or development is involved is decided by the content of the work, not by its effort or its importance to the company. In practice, the criteria of the Frascati Manual are used, an internationally applied guide of the Organisation for Economic Co-operation and Development (OECD) for delimiting research and development. According to it, an activity is novel, creative, uncertain in its outcome, systematic and transferable or reproducible in its results. Three characteristics carry the delimitation:

• Novelty: The aim goes beyond the generally accessible state of the art. What is new only within the company's own business is not enough.
• Technical uncertainty: At the outset it is open whether and by what route the aim can be achieved. The uncertainty must be technical in nature; the risk that a product finds no customers is not sufficient.
• Systematic approach: The approach follows a plan with hypotheses, work steps and resources and is documented so that results can be traced.

As a rule, the following are not research and development: implementing known solutions to a specification, adaptations to customer requests, bug fixing, version changes, quality control and maintenance of existing systems. The law draws a line once a product or process has been essentially fixed (Section 2 (2) FZulG). If further work then mainly serves market development or the smooth running of production, it is no longer research and development. In software development, the line often runs within a team. A method whose performance under certain conditions is open may qualify, but its subsequent integration into the application usually does not. The classification depends on the individual project; there are no blanket rules for whole sectors.

Scoping and describing an R&D project

The scoping determines what can later be justified and evidenced. A project called “further development of the platform” mixes eligible and non-eligible work. Several more narrowly defined projects, each with one clear technical question, are easier to describe, document and review. A project cannot, however, be split artificially. If two projects cannot be clearly separated and neither would have a prospect of technical success on its own, they count as one project (Section 2 (3) FZulG). A sound project description contains:

• the state of the art at the outset and the sources of this assessment
• the technical aim, if possible with measurable target values
• the open technical question and the reason why its answer cannot be foreseen
• work packages, milestones and time frame
• the people involved with their time shares, materials and contracts with third parties

The documentation is kept up to date during the project, not only at the time of the application. Looking back, uncertainty is hard to prove, because the result is then known. Working hours are recorded per project in a timesheet, and contracts with third parties are reported separately as contract research.

R&D projects in annual financial statements and due diligence

Under commercial law, internally generated intangible fixed assets may be capitalised (Section 248 (2) of the German Commercial Code, HGB), but only with the expenses of the development phase. If research and development cannot be reliably separated, capitalisation is excluded (Section 255 (2a) HGB); for tax purposes, a prohibition on capitalisation applies (Section 5 (2) of the German Income Tax Act, EStG). The classification under funding law is independent of this.

In due diligence, the technical review uses project descriptions to assess the state of development and dependence on individual people. The financial review asks about capitalised development costs. Because they do not appear as current expense, they increase earnings before interest, taxes, depreciation and amortisation; in adjusted EBITDA, they are therefore often treated like investments and considered separately. The tax review clarifies whether allowances applied for are covered by certifications and evidence.

Practical example: delimiting R&D projects in a software company

A software company with 25 developers plans around 40,000 development hours for the coming year and examines four strands of work:

• a method that predicts machine failures from incomplete sensor data; it is open whether the target hit rate is achievable if part of the measured values is missing
• a billing module following a known pattern for a major customer
• the migration of the database to a new version
• an encryption for real-time transmission on end devices with low computing power; it is open whether the required latency can be met technically

The company frames only the first and the fourth strand as R&D projects, each with an aim, hypotheses, work packages and a duration of twelve and 18 months respectively. Together they account for about 9,000 hours, which are recorded per project. That is 9,000 of 40,000 hours, or 22.5% of the planned development time. Only this share can, after certification, enter the assessment basis of the research allowance; the remaining 77.5% counts as routine work.

After nine months, the first model approach does not reach the hit rate; the team documents the finding and switches to a second approach. This very course of events shows that the technical question was open at the outset. The example shows two things: R&D is usually a smaller part of the development work in a software company, and a narrow scoping makes this part provable.

Distinctions: R&D project, research allowance, contract research and MVP

• Research allowance: the tax incentive for which a certified R&D project is a prerequisite. The project is the subject, the allowance the funding.
• Contract research: a way of carrying out a project in which third parties take over the work. The requirements for the project remain the same.
• MVP: a product with minimal functionality that tests market assumptions. Its development may contain R&D elements, but the market test itself is not research.

Common mistakes

• Umbrella project instead of a clear question. A project that bundles a whole year's product development inevitably contains routine work and cannot be justified as a whole.
• Aim worded as product benefit. What is asked for is the technical question, not the benefit to customers or the expected effect on revenue.
• State of the art not evidenced. Without a comprehensible account of what was known at the outset, novelty cannot be assessed.
• Documentation only after the fact. A description written in hindsight knows the result and is therefore not very convincing.
• Failed approaches left out. Abandoned routes are the strongest evidence of technical uncertainty and belong in the project file.

Frequently asked questions

Does an R&D project have to succeed in order to be funded?

No. What is funded is the systematic work on an open technical question, not the result. A project that is documented as having failed remains eligible for funding.

Does software development count as research and development?

Only if there is technical uncertainty that points beyond the state of the art. Implementing known architectures and methods does not count, even if it is demanding.

How large should an R&D project be?

Large enough to cover a named technical question completely, and small enough to be separable from other work. Durations of a few months up to a few years are common.

Who decides whether a project is eligible?

For the research allowance, the certifying body, whose determination binds the tax office. For grants, the awarding authority or the commissioned project management agency reviews the classification in the application procedure.

The Roemer Capital view

How a company divides its development work into projects is something Roemer Capital examines before a funding round begins. A structure created for the research allowance can often be reused: for the technical due diligence and for explaining development costs in the financial model. The prerequisite is that times and costs are cleanly allocated.

For Roemer Capital, the yardstick is whether a piece of work creates something technically new; the risk that a product fails in the market does not justify funding. Whether a strand of work reaches this threshold is clarified by specialised partners with whom Roemer Capital coordinates the application work. The tax implementation lies with the company's tax adviser.