Can a Software Studio Claim Austria's Forschungsprämie? Which Dev Costs Qualify

Yes, if the work resolves genuine scientific or technological uncertainty. Austria's Forschungsprämie pays back 14% of qualifying R&D costs as a cash premium, even if you make zero profit. The catch: routine software development does not qualify. The test is whether a competent engineer could have solved it with known methods. If yes, it is build work, not research. Figures current as of June 2026. This is general information, not legal or tax advice.

Does software development qualify for the Forschungsprämie?

Some of it does. The Forschungsprämie is tied to the Frascati Manual definition of R&D, and the FFG applies five criteria, all of which must hold: the work must be novel, creative, systematic, uncertain in outcome, and transferable or reproducible. The criterion that disqualifies most software is uncertainty. If the result is achievable with standard techniques by a competent developer, it is routine engineering, not research, no matter how hard or expensive it was.

Concrete examples we see. A new consensus mechanism, a novel cryptographic scheme, an algorithm that pushes a performance boundary nobody has published a solution for, or a machine-learning model where it is genuinely unclear whether the approach will work: those resolve technological uncertainty and qualify. A CRUD app, a payment integration, a redesign, a migration to a new framework, or wiring up an existing LLM API: those are build work and do not. The same project can contain both. You claim the research portion and exclude the rest. That split is exactly what the FFG opinion scrutinises.

Which of your dev costs actually count?

Eligible costs are the direct costs of the R&D activity. For an in-house software studio that is mostly salaries, plus the overhead and equipment attributable to the research. Here is an illustrative example for a studio running one qualifying research project for a year. The numbers are made up to show the mechanics, not a benchmark.

• Developer salaries (gross, incl. employer costs). 2 engineers at 70% of their time on the research project: EUR 180,000
• Research lead / architect (part-time on the project). EUR 40,000
• Directly attributable overhead (cloud compute for experiments, prototyping hardware, project-specific tooling): EUR 25,000
• Total qualifying R&D base: EUR 245,000
• Forschungsprämie at 14%: EUR 34,300 cash back

Two things to keep straight. First, the premium is a cash credit against your tax account, not a deduction. You get it even at a loss. Second, only the share of each salary that went into the qualifying work counts. If an engineer spent 70% of the year on research and 30% on routine maintenance, you claim 70%. You need timesheets or a defensible allocation to back that ratio, because the tax office can ask.

The FFG Gutachten: what gets a claim rejected

For in-house R&D, the tax office does not judge whether your work is research. The FFG does, through a free annual expert opinion (Jahresgutachten) that you request when you file. The Gutachten is the document the Finanzamt relies on. Get it wrong and the claim collapses.

What gets a claim rejected, from what we have seen and what the FFG documents:

• Describing build work as research. If your project description reads like a feature list, the FFG will classify it as routine development. You have to name the specific scientific or technological uncertainty you were resolving and why known methods did not answer it.
• No systematic method. Research has a hypothesis, an experiment, and a documented outcome. "We tried things until it worked" is not systematic.
• Claiming the whole project. Mixing the qualifying research with the surrounding build and claiming 100% invites a cut or a rejection. Split it honestly.
• Thin documentation. The Gutachten is only as strong as the project description you submit. Vague inputs get conservative opinions.

The practical move: write the project description in the language of uncertainty and method, keep records as you go, and do not wait until filing season to reconstruct what happened. See how we scope this inside delivery on our software development and fractional CTO pages.

Forschungsprämie vs Germany's Forschungszulage: a comparison

If you operate on both sides of the border, the two regimes differ in rate, cap, and who certifies. Both are R&D tax incentives, both reward the work even at a loss, but the mechanics are not interchangeable.

Sources: PwC Austria, FFG, and Baker Tilly on the 2026 German rules.

How it stacks with aws and FFG grants (the double-funding rule)

The Forschungsprämie is a tax incentive, not a grant, which is why it can sit on top of direct funding. But you cannot count the same euro twice. If an aws or FFG grant already covered a specific cost, that cost is out of your premium base. The premium applies to your own, non-subsidised spend on the qualifying work.

This is where stacking gets valuable: a grant covers part of the project cash up front, and the premium pays back 14% of what you actually carried yourself. The discipline is clean cost accounting, knowing exactly which euro a grant touched so you do not double-dip. We walk through the full stack, including which grants pair cleanly with the premium, in our companion post on stacking aws and FFG funding.

"The premium does not reward how hard you worked. It rewards resolving an uncertainty that known methods could not. Write your project description in that language, or the FFG will read it as build work."

Q&A: We are a bootstrapped studio with no profit. Can we still claim?

Yes. The Forschungsprämie is a cash premium credited to your tax account, not a deduction from taxable profit. A loss-making or pre-revenue company gets it paid out the same as a profitable one. For bootstrapped studios this is one of the few non-dilutive sources of cash, and it does not care about your margin.

Q&A: We do contract dev for a client. Who claims it?

It depends on where the research risk sits. If you carry out R&D on your own account and own the result, you claim it as in-house research, uncapped. If a client commissions the research from you, the client can claim it as commissioned research, capped at EUR 1,000,000 per year, and you cannot also claim the same work. The contract structure decides this, which is exactly why Werkvertrag vs time and material matters beyond billing. Settle who owns the research before you sign.

Q&A: Does AI / LLM R&D qualify?

Only if it resolves real uncertainty. Calling an existing LLM API, prompt engineering, or wiring a model into your product is integration work and does not qualify. Training or materially adapting a model where it is genuinely unclear in advance whether the approach will reach the target, developing a novel architecture, or solving a research-grade data or evaluation problem can qualify. The line is the same as everywhere else: known methods, no claim; genuine technological uncertainty, possible claim. Compliance work under the EU AI Act is separate, and we cover its cost in our EU AI Act compliance cost post.

Q&A: How far back can I claim?

You have time. The premium is claimed per business year, and the window runs until four years after the end of that business year. So you can still capture recent years you missed, as long as you can reconstruct a defensible project description and cost allocation. Do not rely on this as a strategy though. Reconstructing R&D documentation two years later is painful and produces weaker FFG opinions than recording it as you go.