Is medical technology development eligible?

Yes — but the research allowance assesses experimental development under Section 2 FZulG, not approval. The work before MDR or IVDR conformity is eligible, the conformity procedure itself is not.

Medical Technology R&D Tax Credit 2026

In medical technology the technical question decides, not the MDR risk class.

The certification office does not assess which class a product falls into under the MDR, but whether a technical question was open beforehand and answered systematically. A MedTech manufacturer rarely loses an application on the technology; usually it is lost because pure approval work and development sit in the same project.

Rates, costs and limits

The essentials on the research allowance in medical technology

Funding rate: 25% of the assessment basis, 35% for SMEs. For projects started after 31 December 2025, a 20% flat rate increases the assessment basis (Section 3 (3b) FZulG); the EUR 12 million cap still applies (Section 3 (5) FZulG).
Eligible: Novel operating principles, control concepts, sensors, algorithms and manufacturing processes for medical devices. What counts is not the approval class but whether novelty, technical risk and systematic approach can be demonstrated.
What counts: The employer gross salary of development engineers, software developers and involved clinical scientists for the hours spent on the project. Since 2024 also the depreciation of movable assets used exclusively for the project, such as a test rig. Material for the prototype itself is not eligible.
Ceiling: Assessment base of EUR 12 million per financial year, maximum research allowance EUR 4.2 million.
Contract research: 70% of the cost of commissioned development work is eligible (Section 3 (4) FZulG): testing laboratories, clinical evaluation by third parties, university institutes, external software development.
Retroactive: Applications for closed financial years from 2022 are possible as long as the assessment period of the respective year is still open; for 2020 and 2021 it has expired (§ 12 FZulG in conjunction with § 169 AO). Projects started before 1 January 2026 do not receive the overhead allowance.

Which activities in medical technology are eligible?

The approval class does not decide eligibility. The certification office checks every project against three criteria: novelty, technical risk, systematic approach. If one fails, the application fails. Below are the activities we encounter most often at medical device manufacturers, with the verdict we expect.

Boundary case: eligibility depends on the specific project.

Product development & operating principle

New operating principle with unknown control behaviour under physiological loadEligible
Eligible. Novelty: No device concept available on the market achieves the required control performance for the required disturbance, here an abrupt change in lung mechanics. Technical risk: Whether the control deviation stays within the target mark is not known before modelling, simulation and test bench. Systematic approach: Sensors, estimation model, controller, measurement series, iteration, documented by verification protocols under IEC 62304.
Porting a proven operating principle to a new product lineBorderline
Borderline. Routine as long as the physiological boundary conditions transfer. It becomes eligible when control performance, sensor resolution or material compatibility demonstrably no longer follow from existing design knowledge for the new application. The evidence is the measurement showing where the old operating principle fails.
Variant development for a patient population outside the previous scope of useBorderline
Borderline. Eligible is the part for which no validated design exists and which is resolved in testing. Not eligible is adapting known variants within the existing approval, even if it costs weeks of documentation.
Adaptation development to specification within the known scopeNot eligible
Not eligible. Interfaces, housing variants, accessories: the result is known before the start, the procedure is documented. Effort is not a criterion of the FZulG.

Software as a medical device & algorithms

Own estimation or control model that carries technical riskEligible
Eligible. Anyone who designs a model because standard controllers do not achieve the required accuracy or response time must explain why. That names the state of the art. Keep the rejected modelling approaches and their measurements; that is the decisive evidence later.
AI-assisted diagnostics with open sensitivity and specificity before trainingEligible
Eligible. Whether a model can achieve the required diagnostic performance on the target dataset at all is open beforehand. Training runs, validation metrics and ablation studies across iterations are systematic approach and technical risk in one.
Porting an existing algorithm to a new device generationBorderline
Borderline. Eligible if the algorithm's behaviour under new sensors or computing hardware is unresolved and worked out in testing. Routine if an interface specification and a porting guide prescribe the way.
Software implementation to specification document, UI adaptation, configurationNot eligible
Not eligible. Intended use of the development environment. Only when the specification demonstrably cannot map the requirement and a separate method is developed alongside it does an open technical question exist.

Materials, biocompatibility & manufacturing

New material or coating with open long-term biocompatibilityEligible
Eligible. Cytotoxicity, mechanical fatigue and degradation behaviour conflict and are measurable. That makes the technical risk quantifiable, the strongest starting position an application can have.
Additively manufactured implants with open fatigue strength under physiological loadEligible
Eligible. Whether the anisotropic properties of the layer-built material reach the required values under cyclic load inside the body cannot be determined before the test series. The series across parameters, post-treatment and fatigue testing is your evidence of systematic approach.
Process optimisation on an existing manufacturing lineBorderline
Borderline. Eligible as soon as a target value is required that the known process demonstrably fails to reach, and the cause is unclear beforehand. Without that measurement the certification office reads only a demanding requirement, and demanding is not a criterion of the FZulG.
Supplier or material change with run-in to release specificationNot eligible
Not eligible. Even elaborate requalification remains commissioning. The way is documented, the result predictable.

Prototype, verification & clinical evaluation

Clinical study to test a new operating principle or a new technology, with measurement plan and abort criteriaEligible
Eligible. The clearest case in this group. Whoever defines in advance what is measured and when the study counts as failed has already documented systematic approach and technical risk before the certification office asks.
Verification and validation protocols under IEC 62304 on a new software moduleBorderline
Borderline. Eligible is the share in which behaviour not previously mastered is only worked out through the test series, documented by change states and test protocols. Simply working through the prescribed test matrix to standard is routine verification.
Clinical evaluation study solely to demonstrate safety and performance for CE markingNot eligible
Not eligible. Necessary and often laborious work, but no gain of knowledge in the sense of the FZulG when the operating principle is already established. You are documenting a result that is technically settled.

Digital health applications & connectivity

DiGA with own digital therapy mechanism and open efficacyEligible
Eligible. Whether a digital intervention mechanism achieves the required therapeutic effect in the target population is open beforehand. The study across several iterations with predefined endpoints is the evidence.
Connecting legacy devices with unclear signal and data quality for a new monitoring conceptBorderline
Borderline. Eligible if it is documented that the available signals do not support the required clinical statement and own methods for conditioning had to be developed. Pure wiring, protocol mapping and dashboards are integration.
Introducing clinical IT standards, HL7/FHIR interfaces or dashboards to specificationNot eligible
Not eligible. Even demanding integration work remains integration. The standards are built for exactly this purpose, the way is documented, the result predictable.

What is regularly rejected

Technical documentation for the MDR, Notified Body communication, post-market surveillanceNot eligible
Not eligible. Pure approval work whose result is settled. The exception is the upstream R&D phase in which a technical solution is first worked out. Then we apply for that part, not the approval documentation.
Audits, conformity assessment procedures, certification by the Notified BodyNot eligible
Not eligible. Mandatory work under the MDR/IVDR whose result is settled. The test reports created along the way can, however, serve as evidence for an eligible project.
Contract manufacturing and supply of components without own development riskNot eligible
Not eligible. Whoever manufactures to someone else's specification bears no technical risk. The case is different when the supplier develops the component itself and is accountable for its behaviour.
Variant, size and colour maintenance within the existing product portfolioNot eligible
Not eligible. The result is fixed beforehand: the same functional scope in a new form. Occasionally submitted by advisers along with everything else, and then it drags the whole project into scrutiny.

Your project is not listed or sits between two lines? That is the normal case; eligibility is decided on the specific facts, not on the heading. Describe the project to us and we will tell you where it stands.

What evidence does the BSFZ expect in medical technology?

Medical device manufacturers practically never introduce an additional system for the research allowance; they have the evidence already, because IEC 62304 and ISO 13485 require it anyway. We evaluate what exists and assign each source to the criterion it supports.

What evidence does the BSFZ expect in medical technology?
Source	What it proves	Criterion
Design History File	The Design History File documents design, rejection and new approach across the whole development, the strongest evidence of experimental development a medical device manufacturer can deliver.	Systematic approach · Technical risk
Risk analysis under ISO 14971	The risk analysis names residual technical risks that could not be excluded before the start, and the measures used to test them systematically.	Technical risk
Verification and validation protocols	Aborted test runs and measurement series date what was tested when and what it was measured against. A failed test run is no blemish; it is proof of an open outcome.	Systematic approach · Technical risk
Software version history · change log	Version history shows attempt, rejection and new approach in the algorithm, exactly the information with which the state of the art can be demonstrated.	Novelty
Usability tests · formative studies	Protocols of formative usability studies record where an interface concept was uncertain and which assumption had to be tested. Rarely read for the research allowance, often decisive for technical risk.
Reports from external testing laboratories	Test reports before and after a design change document the difference between routine testing to standard and working out previously unknown behaviour.	Scope
Time recording · project hours	For the tax office application the hour counts. We map an existing time recording onto the projects instead of introducing a parallel system.	Cost side
Clinical evaluation reports	Clinical evaluations that primarily serve to gain knowledge about a new operating principle document the experimental character when they reflect iterations, not just the safety and performance confirmation.	Systematic approach

The most common mistake in assisted applications is a development process constructed after the fact with phases that never existed at your company. Your real Design History File and verification protocols are the better evidence; they provide a complete, dated record of the procedure.

What comes out of it?

Two calculated cases for projects that started after 31 December 2025, once at the SME rate of 35%, once at the standard rate of 25%.

MedTech startup, 35 employees · SME

Employer gross, 8 development engineers and software developers: EUR 680,000. Eight development engineers and software developers working on AI-assisted diagnostic software, R&D share documented via project hours, plus a testing contract placed with an external testing laboratory

R&D personnel costs (employer gross)EUR 340,000

Contract research, 70 % of EUR 40,000+ EUR 28,000

Overhead flat rate 20 %+ EUR 73,600

Eligible expensesEUR 441,600

Funding rate35 %

Research allowance per yearEUR 154,560

Per year. Applied for retroactively over three open financial years: around EUR 0.4 million, without the overhead allowance, because the project started before 2026.

Medical device manufacturer, 280 employees

Employer gross, 25 developers: EUR 2,250,000. Twenty-five developers working on a new implant generation with clinical evaluation, not an SME. Standard rate 25%, contract research with a university hospital

R&D personnel costs (employer gross)EUR 1,237,500

Contract research, 70 % of EUR 180,000+ EUR 126,000

Overhead flat rate 20 %+ EUR 272,700

Eligible expensesEUR 1,636,200

Funding rate25 %

Research allowance per yearEUR 409,050

Per year. The assessment base is capped at EUR 12 million, a maximum of EUR 3.0 million allowance at the standard rate, EUR 4.2 million as an SME.

As a rule of thumb: a development engineer with an employer gross of EUR 85,000 who spends half of the time on eligible projects yields around EUR 17,850 research allowance per year (SME rate, with the overhead allowance — the project starts after 31 December 2025). The whole is capped at an assessment base of EUR 12 million and an allowance of EUR 4.2 million per year. Go to the calculator Comparable figures from supported applications are listed under approved projects.

Guide: R&D tax credit for medical technology manufacturers
The eligibility rules between R&D and approval work, the sources of evidence from IEC 62304 and ISO 13485, as a PDF.

What medical technology manufacturers ask us most often

Are activities for MDR/IVDR approval eligible under the FZulG?+

Pure approval activities such as creating technical documentation, Notified Body communication or post-market surveillance are not eligible. The upstream R&D phase in which a new technical solution is worked out is, however, fully eligible. We precisely separate the R&D share from the approval work so both applications stay cleanly apart.

Can clinical evaluation studies be classified as R&D?+

Yes, if the study primarily serves to gain knowledge about a new operating principle or a new technology. Studies that solely demonstrate safety and performance for CE marking are not, because the operating principle is already settled there. The distinction is decided by the study objective, not by the study design.

Is software as a medical device (SaMD) fully eligible?+

Yes, if the algorithm itself carries technical risk. Algorithm development, model training, verification and clinical evaluation are eligible insofar as it was open beforehand whether the required accuracy or response time is achievable. The MDR risk class does not directly affect eligibility; the open technical question remains decisive.

Are prototypes and physical samples fully eligible?+

Prototypes are eligible as an instrument of experimental development insofar as they serve to gain knowledge. The direct material cost of the prototype cannot be claimed, however. Eligible are the personnel costs of the employees involved, 70% of commissioned contract research and, since 2024, the depreciation of movable assets used exclusively in the project.

Do verification and validation activities under IEC 62304 count as R&D?+

Only the share in which behaviour not previously mastered is worked out through the test series. Simply working through the prescribed test matrix to standard is routine verification and not eligible. What matters is whether it was open beforehand whether the software module achieves the required property at all.

Can suppliers have their component development funded?+

Yes, suppliers can have the R&D work for new components, sensors or assemblies funded, even if these are later installed in medical devices by OEMs. What matters is that the supplier itself bears the technical risk and performs the development work. Pure contract manufacturing to someone else's specification is not eligible.

How far back can medical technology manufacturers apply?+

Applications for closed financial years from 2022 are possible; the assessment period of the respective year is decisive. For many medical technology manufacturers the largest single amount lies precisely in these earlier years, because several product generations sit there unclaimed. Retroactive application

How much effort arises in our medical technology development department?+

For a typical medical technology project we reckon with two to four hours on the part of the head of development: a technical conversation in which we take up the project, and one approval round on the finished project description. We take over the evaluation of the Design History File, verification protocols and time recording as well as both applications.

How does your documentation become an application?

Your trial protocols and your verification documentation under IEC 62304 already document everything the certification office wants to see, just in a different language. Here is the same set of facts in four registers, from the test rig protocol to the application sentence.

In the test field — What gets written anyway

Ventilator AVR-210, series 2
Tidal volume deviation 9% after compliance step
  // target < 5% within 3 breaths, estimator overshoots

- flow sensors ........ 2 pcs
- filter stage ......... v2, IIR
- series 3 ............ 3.5% / 3 breaths ok

In conversation — What the team says about it

"As soon as the compliance of the test lung changes abruptly, our estimator overshoots for two or three breaths. We filtered the sensor data and added a model-predictive controller downstream, and on the third run we were below four percent."

Technically complete and worthless as application text. There is no reference to the state of the art or to the measured variable.

At the BSFZ — What is actually examined

Novelty
Technical risk
Systematic approach

For each of the three criteria the application must contain a verifiable statement. What is described is the knowledge gained on the way to the finished device.

In the application — What we formulate from it

"For the adaptive control of tidal volume via a running estimate of lung mechanics no device concept existed whose control deviation after an abrupt compliance change had been demonstrated below the required tolerance of 5% within three breaths. Whether the estimation model could be stabilised far enough could not be determined in advance. The project established this in three measurement series against a defined target, documented under IEC 62304."

This is the work. The same facts, four formulations, and only one of them is an application. This translation is our actual service: building, from what your test field and your verification documentation produce anyway, the statement the certification office can examine. Not writing more beautifully. Writing differently.

Why do applications fail in medical technology?

Rejected projects from medical technology rarely fail on their technology. They fail on five recurring patterns, and we see them in self-submitted applications just as in externally assisted ones.

The state of the art is missing

The application describes what was built, not why it could not be done with what was available. Without named competitor products, standards or established operating principles the certification office cannot establish novelty. This is the most common reason in our own mandates.

How we do it. We specifically name the device concepts, algorithms and operating principles that were examined and rejected, each with the technical property on which they fail.

Approval work is submitted as the project

Technical documentation for the MDR is not excluded per se, but an application covering "the approval" forces the certification office to assess regulatory work and development together. The routine shares drag the whole project down.

How we do it. We scope the project to the part for which no validated technical solution existed and cleanly separate R&D, conformity assessment and documentation.

Regulatory risk instead of technical risk

Approval timelines, Notified Body capacity and market access deadlines are not technical risks. Anyone arguing this way describes a regulatory problem and gets it decided as such.

How we do it. We phrase the risk as an open technical question: which property of the product was not predictable before the start, and exactly where the project would have failed.

The prototype is described as a product

The application reads like a data sheet: sensitivity, specificity, battery life. The certification office is looking for the way there, the trials that did not work and the measurement that proves the difference.

How we do it. We derive the systematic approach from your own artefacts: layout in the Design History File, trial in the verification protocol, decision in the change log.

Cost side and facts do not match

The BSFZ certifies the project, the tax office checks the costs. Anyone who claims material costs for the prototype, or hours that contradict the project description, loses in the second step, after the certificate has already been issued.

How we do it. We run project description, time recording and research allowance application (ELSTER) against the same scope from the start. The cost side is not created afterwards.

If you already have a rejection, the first step is analysing the decision: which of the five points carries it. That determines whether objection or new application is the right way.

Which other industries use the research allowance?

The sector never decides eligibility — Section 2 FZulG does. These pages show the same three criteria against the activities of each field.

Mechanical engineering — Design, testing, commissioning
Automotive — Drivetrain, battery, driving function
Pharma & life sciences — Compound, formulation, bioprocess
Construction — Methods, materials, component tests
Energy & cleantech — Cell, storage, grid control
Aerospace — Structure, propulsion, avionics
Agriculture & FoodTech — Process, formulation, field trial
Software & IT — Algorithm, model, architecture

Send us a Design History File, not a questionnaire

In the first consultation we talk about your product, not about your legal form. After thirty minutes you know which part of your development is eligible, in what order of magnitude, and whether a retroactive application is worthwhile. The first consultation is free; 30 % of the fee falls due with the BSFZ decision, 70 % only after the allowance has been paid out.

Book a first consultation

Official sources

Read on

Max Nodes

Founder and Managing Director of NOVARIS Consulting. Specialised in the German R&D tax credit (FZulG) since 2021; 25 of 25 accompanied BSFZ applications approved (as of 09/2026). Max Nodes

R&D tax credit for medical technology: development counts, approval does not

Medical technology: use signals better