Your runway says 14 months. Your bank account says 9. Somewhere between those two numbers is the truth, and for most European startups it's hiding in a spreadsheet nobody has opened since the last board meeting.
I've been on both sides of that gap: as a founder watching a French URSSAF bill arrive three weeks earlier than budgeted, and as a consultant cleaning up forecasts for Dutch and Spanish teams who discovered in November that their grant money wouldn't land until March. Cash flow forecasting for a European startup is not the same exercise as doing it in the US, and most templates you'll find online were written for a world with one tax authority and one payment culture.
This is what actually matters when you build the thing.
Key takeaways
- Forecast cash, not profit. Revenue recognition and bank balance are two different sports, and only one of them keeps you alive.
- European tax timing (VAT, social contributions, corporate tax instalments) breaks more forecasts than bad sales do.
- Horizon Europe and similar grants pay in tranches with pre-financing and reimbursement lag. Model them as two or three separate future events.
- B2B payment habits vary wildly across the continent: a German client at 30 days and an Italian client at 90 days need different lines in your model.
- A 13-week rolling view catches the near-term squeezes; an 18-month view tells you whether to raise now or later.
Why European startups get cash flow forecasting wrong
The core mistake is importing an American mental model. In the US, a founder worries about payroll and runway. In Europe, you worry about payroll, VAT across borders, social charges that differ by contract type, corporate tax prepayments, and the small matter of a customer in Milan who considers day 75 a perfectly reasonable moment to pay.
None of that shows up in a standard template.
The profit-versus-cash confusion
You signed a €120,000 annual contract in January. Great. Your P&L shows €10,000 of revenue per month. Your bank account shows whatever the client decides to send, whenever they decide to send it — possibly after a purchase-order round trip through their procurement department that eats six weeks before the invoice is even issued.
A forecast built on recognised revenue is a forecast of a fiction you tell your board. A forecast built on expected bank arrival dates is the one that tells you whether you make payroll in August.
The tax timing trap nobody models
Here's a concrete example. I once built a forecast that assumed French VAT would be a neutral pass-through. It isn't, in cash terms: you collect VAT from clients in month one, you remit it to the treasury in month two or three depending on your filing regime, and if you're in a refund position on cross-border services, the repayment can take months. That's real cash sitting outside your account while your forecast quietly pretends it's already yours.
Same story with social contributions. In France, employer charges on salaries are due in the month following payment, which means your biggest cost line has a one-month lag built into it. In Germany, wage tax and social security have their own due dates. If you hire across three countries, you now have three separate cash calendars that your forecast must respect.
Rule: model every tax and contribution line with the actual due date, not the accounting period it belongs to.
Build your forecast bottom-up, not top-down
Top-down forecasting looks like this: "We'll do €2M next year, so roughly €166k per month, minus costs, so we're fine." That sentence has killed companies.
Bottom-up means you start from operational drivers you can actually observe. How many new customers per month, at what average contract value, with what payment terms, and how many days between signature and cash? Then you layer hiring, tooling, rent, and every statutory payment on top.
What a bottom-up model looks like in practice
- Customer count × ACV × collection lag, per segment, because enterprise and SMB pay on completely different clocks.
- A hiring plan with the true cost of a hire in month one — recruitment fee, onboarding, and the fact that social charges start before the person is productive.
- Grant tranches as separate dated events if you have any non-dilutive funding, with pre-financing and reimbursement modelled distinctly.
- A line for annual software renewals that all cluster in Q1 because that's when your procurement cycle happens.
The point isn't precision. It's traceability: when the number moves, you need to know which assumption moved it. A top-down model can't tell you that. A bottom-up one can point at "Italian collections slipped 20 days" and you fix one input.
The country-by-country reality check
Payment culture is not a stereotype, it's a forecast input. Roughly speaking, you can expect B2B invoices to settle in around 30 days in the Nordics and Germany, drifting toward 60 and sometimes beyond in parts of Southern Europe. This isn't about anyone being unreliable; it's about deeply rooted administrative habits and, in some markets, a supplier-financing culture where late payment is simply normal practice.
The EU has been pushing back on this with late-payment rules, but enforcement and habit move slower than legislation. Build your model on observed behaviour, not on the terms printed in your contract.
| Market | Typical B2B collection reality | What to put in the model |
|---|---|---|
| Germany, Netherlands, Nordics | Invoices settle close to terms | Contract terms + 5 days buffer |
| France | Reliable but administration-heavy; VAT timing matters | Contract terms + 10 days, plus statutory VAT outflow |
| Spain, Italy | Longer settlement, procurement friction | Contract terms + 30 to 45 days |
| Any market, public sector client | Payment tied to budget cycles and certificate approvals | Assume the worst month you've seen, then add two weeks |
I'll admit I got this wrong early on: I built one blended collection assumption across all customers because it was simpler. The result was a forecast that looked fine on average and was wrong every single month, in opposite directions depending on which invoices happened to land. Segmenting by market fixed it. Blended assumptions hide exactly the variance that hurts you.
Grants and non-dilutive funding need their own calendar
European startups have access to something their US peers largely don't: substantial public funding. Horizon Europe, national innovation agencies, regional schemes. It's real money and it can fund a whole work package.
It also arrives on a schedule that has nothing to do with your burn rate.
Most grant structures work in tranches: an initial pre-financing payment, then reimbursement of eligible costs against periodic reporting. That means you spend first and get paid later, sometimes many months later, and the reporting cycle has its own delay on top. If you're forecasting a €400k grant as a single inflow in month six, you will be badly wrong.
How to model a grant correctly
- Split it into its actual tranches with the dates from the grant agreement.
- Add a realistic lag between cost incurrence, report submission, and payment receipt. In my experience that gap is measured in months, not weeks.
- Keep grant-funded costs in the model as normal outflows, because you pay them regardless of when reimbursement arrives.
- Run a downside scenario where one tranche slips a full quarter. If that scenario is fatal, you have a problem now, not later.
The trap is treating grant money as runway. It's committed money, which is different from available money. Your runway is what's in the bank plus what will actually arrive on schedule.
How often should you update a cash flow forecast?
Monthly is the floor, and weekly is better for the near term. The reason is simple: forecasts rot. A model built in January and reviewed in April is not a forecast, it's a historical document with optimistic formatting.
The rhythm that works: a 13-week rolling cash view updated every week or every fortnight, showing week-by-week expected inflows and outflows. This is the operational tool — it catches the squeeze coming in five weeks while you can still do something about it. Then an 18-month view reviewed monthly, which is the strategic tool: it tells you whether you need to start raising in three months or nine.
Why 13 weeks specifically? It's roughly a quarter, which is long enough to see a problem forming and short enough that you can forecast individual invoices with some confidence. Beyond a quarter, you're forecasting categories, not transactions.
Scenario planning without the theatre
Every guide tells you to build base, downside, and upside scenarios. Most founders build three versions of the same optimistic model and call it done.
Do this instead: build the base case honestly, then build a downside that assumes your two largest customers pay 45 days late and one new hire slips a quarter. Not a catastrophe scenario — just a mildly annoying one. If your downside case shows a liquidity crunch, you've learned something useful. If your downside is still comfortable, your base case probably has room for optimism.
The upside case is the least useful of the three, honestly. You'll never be unhappy about money arriving faster than expected. Spend that modelling effort on the downside instead.
What belongs in the downside scenario
- Collections slip by your worst observed delay, not your average
- One grant tranche moves a full quarter
- Your largest client churns at the start of the period, not the end
- VAT refund on cross-border services takes an extra two months
None of these are dramatic. All of them together can turn a 14-month runway into a 7-month one, which changes your entire fundraising calendar.
The habit that matters more than the model
The best forecast in Europe won't save you if nobody looks at it. The founders I've seen survive tight periods share one behaviour: they open the cash file every Monday morning, before email, and check one number — the projected bank balance 30 days out. Not the P&L. Not the board deck. That one number.
It sounds almost too simple. But the discipline of looking at it weekly means you notice drift when it's still a two-week problem instead of a two-month crisis. The model becomes a habit rather than an artifact, and the habit is what actually protects you.
One more thing, and this is the part I'd defend to the end: put the statutory payment calendar in the same file as your customer collections. Not in a separate tax spreadsheet, not in your accountant's inbox. Same file, same view. The moment VAT and social charges live somewhere else, they stop being part of your forecast — and they are absolutely part of your cash.
Your bank balance doesn't care how good your revenue chart looks. It cares what lands, and when.
