Writing a Förderantrag: the complete guide (2026)

A Förderantrag is the document that asks a funding body - a ministry, the Agentur für Arbeit, a project agency (Projektträger), or a Land programme - to back your project or bridge your costs with public money. It is not a pitch deck and not a business plan, even though it borrows from both. Its single job is to let a reviewer (Gutachter:in) check, point by point, that your project matches the programme's criteria and that you can actually deliver it. Everything good in an application serves that one job: making the reviewer's yes easy to justify.

That framing matters because it changes how you write. You're not trying to sound impressive; you're trying to be checkable. A reviewer reads dozens of applications and grades each against a fixed list of criteria. The application that wins is the one where they can find every required element quickly, with no hunting and no doubt. Vagueness isn't a style problem here - it's a scoring problem, because a reviewer can't tick a box they can't verify.

Most German funding programmes are two-stage, and knowing this saves you weeks. In stage one you submit a short Projektskizze or Ideenpapier - typically a few pages that lay out the idea, the innovation, and a rough plan and budget. A jury or the Projektträger reads it and decides whether to invite you to stage two. Only then do you write the Vollantrag: the full, formal application with detailed work packages, a complete financial plan, and every annex the programme demands.

The common mistake is treating the Skizze as a teaser - a vague taste of the idea that holds back the detail. Do the opposite. Write the sketch as the whole application in miniature: a clear problem, a concrete solution, a believable plan, real numbers. The jury isn't deciding whether the idea is interesting; they're deciding whether the full application is worth their reading time. Give them enough to say yes with confidence. Whichever programme you target, the overview of programmes by phase shows which ones use a sketch stage and which take a single full application.

Forms differ between EXIST, ZIM, IGP, the Forschungszulage and the rest, but underneath they ask for the same building blocks. Learn these six and you'll recognise the structure in any programme, no matter what its headings are called.

If one section decides borderline applications, it's this one. Reviewers can forgive a slightly thin market section; they cannot forgive a project they can't picture being delivered. Work packages (Arbeitspakete) split the project into named chunks of work, each with a clear deliverable, an owner, and a timeframe. Milestones (Meilensteine) are the checkpoints between them - moments where something verifiable is done. Together they prove the project is real, sequenced, and controllable.

Keep each work package outcome-shaped, not activity-shaped: "working prototype passes test X" beats "work on the prototype." Make milestones binary - either reached or not, never "roughly 80 % there." And make the financial plan trace back to the packages: a cost that doesn't belong to any work package reads as padding. Our deep dive on milestone planning and work packages walks through this with concrete examples; it's the single best place to invest your editing time.

The reassuring truth is that rejection patterns repeat. Across programmes, the same handful of reasons sink good ideas, and almost all of them are about the application rather than the merit. The most common is applying to the wrong programme - a non-technical innovation sent to a tech-only call, or an R&D claim where there is no real research. Next is vagueness: a problem nobody can verify, an innovation claim with no reference to the state of the art, a plan with no dates.

After that come the structural failures: a milestone plan that's really just a wish list, a financial plan that doesn't match the work, a missing Verwertungsplan so the reviewer can't see the lasting value, and - more often than agencies admit - sloppy formatting and incomplete annexes that signal a founder who won't run a tidy project. None of these is about whether your idea is good. Each one is a box a reviewer couldn't tick, and each is fixable before you hit submit. For the EXIST programme specifically, our five mistakes that sink an EXIST application breaks the pattern down in detail.

Knowing the anatomy is one thing; getting a complete, consistent application out the door is another. The workflow that works is boring on purpose: pick the right programme before you write a word, draft each of the six building blocks against that programme's criteria, then score your own draft the way a reviewer would before you submit - looking for the gaps, the vague claims, the costs that don't tie to a work package. Self-scoring is the step almost everyone skips, and it's the cheapest way to catch a rejection reason while you can still fix it.

This is exactly what granttool.de is built for. It's a KI workspace that keeps your idea, work packages, milestone plan, financial plan and Verwertung in one coherent place, drafts each section against the chosen programme's criteria, and self-scores the result against what reviewers actually grade - so the gaps surface on your screen, not in the rejection letter. We never promise funding; nobody honest can. What we remove is the blank page and the guesswork about structure, so you submit something that reads like it knows the criteria. This is keine Rechts- oder Steuerberatung - the binding rules are always the official programme text and the funding body's decision.

Three procedural things decide more applications than founders expect, and all three sit outside the writing itself. First, talk to the funding body before you submit. Most Projektträger - the agencies that run programmes on a ministry's behalf - offer a Beratungsgespräch, and a short call clarifies whether your project fits, which is the single most common rejection reason. They would much rather steer you to the right call now than reject you later. Second, know your submission channel. Federal programmes mostly run through electronic portals - easy-Online is the common one - and some still require a signed paper version posted by the deadline on top of the electronic file. A perfect application that misses the portal's cut-off, or arrives electronically but never on paper, is a needless rejection.

Third, and most dangerous: do not start the project before you are allowed to. German subsidy law treats a vorzeitiger Maßnahmenbeginn - beginning the funded activity before the grant is approved - as grounds to refuse funding entirely, on the logic that a project you already started clearly did not need the money to happen. "Beginning" can mean signing a binding contract, ordering equipment, or, for benefits like the Gründungszuschuss, taking up the self-employed activity. If you genuinely must start early, some programmes let you request a Genehmigung des vorzeitigen Maßnahmenbeginns in writing first - but that is a permission you ask for, never a thing you assume. This is keine Rechtsberatung; the exact rule lives in your programme's terms and the funding decision, so confirm it there before you commit a single euro.

One more number to settle before the financial plan: the Förderquote, the share of eligible costs the programme actually covers. Few grants fund 100 % - many cover a percentage and expect you to carry the rest as an Eigenanteil (own contribution), and some are loans rather than non-repayable Zuschüsse. Read the funding rate out of the call before you build the financial plan, because it changes how much you ask for and whether you need to show matching funds. Getting the Förderquote wrong is the kind of avoidable error that makes a budget reconcile on your spreadsheet but not against the programme's rules.