Structuring Tranche-Based Grant Disbursement

Why stages, and what they actually buy you

An incubator that disburses a grant in one payment has exactly one decision point: selection. After that, whatever happens, happens.

Staging gives you a second, third and fourth decision point, and each one is a moment where a startup that has stopped moving can be talked to before more money leaves. That is the real argument for tranches - not distrust, but the fact that a single payment converts every later problem into a recovery problem.

The secondary benefit is that staging produces your evidence trail as a by-product. Each release has a reason attached, and a reason attached to a payment is most of what a funder asks for.

A shape that works

For a typical incubation grant, three releases:

Tranche	Share	Released against
First	25-30%	Sanction, agreement signed, bank details verified
Second	40-50%	A demonstrated milestone, mid-term
Final	25-30%	Completion, final report, utilisation evidence

The first release should be enough to genuinely start and not so much that stopping later is impossible. Front-loading is the common mistake: a grant that pays 70% up front is a single payment with extra paperwork.

Choose milestones two people would agree on

This is the whole game, and it is decided at sanction rather than at review.

Milestones that work — someone outside the conversation could verify them:

• A working prototype demonstrated to the programme team on a date
• A named first paying customer, with the agreement attached
• Statutory registration completed, with the certificate
• A specific, pre-agreed usage number reached
• A hire made into a named role

Milestones that do not work — they need interpretation, and the interpretation happens when money is at stake:

• "Significant progress on product development"
• "Market validation completed"
• "Team strengthened"
• "Traction demonstrated"

The test is simple. Imagine the startup says the milestone is met and you disagree. If the argument would be about facts, it is a milestone. If it would be about the meaning of a word, it is not.

Write the evidence, not just the milestone

Alongside each milestone, write what will count as proof. "First paying customer" is better than "traction". "First paying customer, evidenced by the signed agreement and the first invoice" removes the last ambiguity, and it tells the founder exactly what to prepare.

Decide the miss policy before anyone misses

Startups miss milestones. Not most of them, but enough that improvising the response is a bad plan, and improvising it under pressure with a founder in the room is worse.

Write down the four options and when each applies:

1. Extend. The work is happening and the timeline was optimistic. Usual for a first miss with visible progress. Record the new date and the reason.
2. Partial release. Part of the milestone is genuinely met. Useful, but only if the split was defined in advance - inventing a partial amount on the day is how precedents get set accidentally.
3. Restructure. The plan changed for a defensible reason. The remaining milestones are rewritten and re-approved.
4. Stop. Nothing is happening, or the company has effectively ceased. The remaining commitment is released back to the source so it can be used.

That fourth one matters more than it looks. If a stopped commitment is never released, the money sits committed-but-undisbursed and quietly reduces what you can allocate to the next cohort, and nobody notices because the total still looks correct.

The chain to record, and why both ends matter

Every release should be recorded against the full chain:

Funding source  →  Programme allocation  →  Startup commitment  →  Tranche

You need both ends because the questions come from both ends. A funder asks about the source: how has this grant been used? A governing body asks about the company: what has this startup received, and why? A flat list of payments answers neither cleanly.

Against each tranche, five fields carry almost all the weight later: amount, date, the milestone it was released for, the evidence accepted, and who approved it. The one most often missing is the fourth.

Block over-allocation at the moment of commitment

Over-allocation is committing more from a source than it holds. It happens when two programmes draw on the same grant and each looks affordable on its own.

The important thing is when the check happens. Caught at reconciliation, you have already told a startup the money is coming. Caught at commitment, the second programme simply cannot commit it and someone decides with the facts visible.

That is the difference between a policy and a control. A policy is followed when remembered; a control does not let the wrong thing happen.

Watch committed-but-unreleased

The number most incubators do not track, and the one that causes the most year-end surprise.

Committed money is spoken for but has not left. If milestones slip - and they do - you can reach year end having disbursed far less than sanctioned while having no headroom to commit anything new. Both facts are true at once and they look contradictory in a report unless you were tracking the middle number all along.

Review it monthly. The question is not "how much have we paid out", it is "how much have we promised that has not yet been released, and is any of it stuck".

A short checklist for the next sanction

• Number of tranches agreed and written into the sanction
• Each milestone stated so two people would agree on it
• Evidence for each milestone specified in advance
• Miss policy written down, with all four options
• Approval authority named for release and for variation
• The chain from source to tranche recorded, not just the payment
• Over-allocation blocked at commitment
• Committed-but-unreleased reviewed monthly