Why the Finanzplan sinks applications: the eight rejection patterns reviewers see

The Finanzplan is rarely the headline reason an application is rejected, and that is exactly why founders underestimate it. It does its damage indirectly. A market section can be argued; a team gap can be framed; but a budget either reconciles with the plan or it does not, and a reviewer who finds it does not reconcile starts reading the rest of the application more sceptically. The Finanzplan is the section where a careful reviewer checks whether the rest of the application is real, because numbers are harder to bluff than prose. A sloppy budget signals a team that has not actually thought through its year, and that doubt bleeds into every other score.

The good news: every pattern below is fully avoidable, and fixing them is mechanical, not creative. You do not need to be a finance person to write a Finanzplan that does not trip these wires. You need to read the call's budget rules, itemise honestly, and keep the budget consistent with the plan. What follows is the list of patterns reviewers see again and again, in roughly the order of how often they show up. None of this is tax or accounting advice; for the treatment of specific costs, confirm with a professional.

The first cluster is about how the budget looks, and it betrays guesswork. Pattern one is round numbers: a Sachkosten table full of clean thousands (5.000, 10.000, 2.000) reads as estimated on the back of a napkin. Real costs are 1.847, not 2.000. Pattern two is the catch-all line - "Hardware and software: 8.000" - that tells the reviewer nothing and hides whatever you could not be bothered to itemise. Pattern three is the orphan line: a cost with no home in any work package or milestone, which the reviewer cannot connect to the plan. Pattern four is the missing justification: a line item with no one-sentence reason tying it to the project, leaving the reviewer to guess why you need it.

All four are cheap to fix and disproportionately damaging to leave in. Round your numbers to real estimates, itemise every catch-all into its components, give every line a work-package home, and add a one-sentence justification to anything above a trivial amount. None of this takes long; all of it makes the budget read as a plan rather than a guess.

The second cluster is about substance, and these cost more. Pattern five is funding ineligible costs: putting items in the budget the programme does not cover - a founder salary in a stipend programme, ongoing operating costs the grant excludes, or equipment that looks like it belongs on a research grant rather than a startup. Pattern six is the double-funding problem: claiming the same cost from two overlapping programmes, which is not just a point loss but a compliance issue the Projektträger takes seriously. Pattern seven is the mismatch with the plan: the Ideenpapier promises a hardware prototype but the Sachkosten contain no materials, or the plan runs customer pilots but the Coaching budget has no go-to-market line.

Pattern eight is the most subtle: an implausible total. A budget that asks for far more than the venture credibly needs in twelve months, or far less than the plan would actually cost, both fail the smell test. Asking for too much reads as padding; asking for too little reads as a team that has not understood what their own plan costs. The fix for all four structural patterns is the same: write the budget last, derive it from the work packages, check it against the call's eligibility rules, and cross-check it against any other funding you hold so nothing is claimed twice.

Double funding deserves its own paragraph because founders trip on it innocently. The rule is roughly: the same cost cannot be paid by two public funding sources at the same time. It does not mean you can never hold two grants - many founders run a stipend and a separate company-level programme in parallel - it means each euro of cost is funded once. If your EXIST Sachkosten cover a laptop, a regional programme cannot also fund that laptop. Most Projektträger ask you to declare other funding (de-minimis aid in particular has cumulation limits across programmes), and an undeclared overlap discovered later is far worse than a declared one handled cleanly up front.

The practical move is to keep a single ledger of all funding you have applied for or hold, and to be transparent in the application about what else is in play. Reviewers do not penalise honesty here; they penalise discovered concealment. When in doubt about whether two programmes can co-fund a cost, ask the Projektträger directly - they would much rather answer the question before the application than discover the overlap during an audit. And because cumulation limits and aid categories are a legal question, treat anything here as orientation and confirm the specifics with the programme and a professional, not as binding advice.