Grant Utilisation Reporting Without the Month-End Panic
What funders actually ask for, why reconstructing it afterwards never works, and how to record disbursement so the report is a query, not a project.
The report is not the hard part
Every incubator that administers grant money has the same quarter-end experience. Someone opens a spreadsheet, opens a bank statement, opens a mail folder, and starts reconstructing.
Which startup got the second tranche in July? Was that against the original sanction or the revised one? Did we ever actually release the third tranche for the company that went quiet? Who approved the change in amount, and is there anything in writing?
The report is not hard to write. It is hard to assemble, and it is hard to assemble because the information needed was never recorded in one place at the moment it existed.
What a funder is actually asking
Strip away the format differences between schemes and government departments and there are three questions underneath almost every utilisation report:
- Did the money reach eligible recipients? The people you said you would support, selected the way you said you would select them.
- Did it go in the amounts and the stages agreed? Against the sanctioned figure, in the tranches described, with variations approved.
- Did it buy what it was supposed to buy? The activity or the milestone the release was for.
Work from your own sanction letter and the scheme's guidelines for the exact schedule and formats - those differ by scheme and they change. But if your records can answer these three questions for any rupee, no format will trouble you.
The link that only exists at disbursement
Here is the structural reason reconstruction fails.
A bank statement records that an amount left an account on a date. It does not record which grant line it was drawn against, which programme allocated it, which startup it was for, or what had to be true before it was released. Those four facts are created at the moment you decide to disburse - and if you do not write them down then, they exist only in somebody's memory and a mail thread.
Six months later you can usually rebuild three of the four. The one that reliably goes missing is what released it - the milestone, the approval, the evidence. That is also the one a funder is most likely to ask about.
Record the chain, not the payment
The shape that works is a chain, and each link has to be recorded as it happens:
Funding source the grant, with its own ceiling
↓
Programme allocation how much of it this programme may commit
↓
Startup commitment how much this company has been promised
↓
Tranche this specific release, against this milestone
Recorded that way, a utilisation report stops being a project. "How much of source X has been disbursed, to whom, against what" is a query rather than three days of reconciliation. So is the harder question a funder sometimes asks: how much is committed but not yet released?
The reason to store the chain rather than just the payments is that the questions come from both ends. Sometimes you are asked about a source: how has this grant been used. Sometimes about a startup: what has this company received and why. A ledger of payments answers neither cleanly.
Block over-allocation at commitment, not at reconciliation
Over-allocation is committing more from a source than the source holds. It almost never happens deliberately. It happens because two programmes drew on the same grant, each looked affordable in its own spreadsheet, and nobody held the total.
The important detail is when you find out. If the check happens at reconciliation, you discover it after a startup has been told the money is coming, which turns a bookkeeping error into a broken promise and a conversation with a funder. If the check happens at the moment of commitment, the second programme simply cannot commit the money and someone makes a decision with the facts in front of them.
That is the difference between a policy and a control. A policy is a sentence in a document that people follow when they remember. A control is something that will not let the wrong thing happen.
Tranches, and what should release them
Release money in stages, tied to something that has to be demonstrated. This is not distrust; it is the only lever you retain after selection, and it produces the evidence trail as a by-product.
Milestones that work are the ones where two reasonable people would agree whether they have happened:
- A working prototype demonstrated to the programme team
- A named first customer, with the agreement
- Statutory registration completed, with the certificate
- Quantified usage - not "traction", a number you defined at sanction
Milestones that do not work are the ones that need interpretation. "Significant progress on product development" is a negotiation, not a milestone, and you will have it at the worst moment.
Record against each tranche: the amount, the date, the milestone it was released for, the evidence accepted, and who approved it. Those five fields are most of a utilisation report already.
Handle variations as first-class events
Amounts change. A startup needs less than sanctioned, or more, or the schedule moves. This is normal and funders expect it - what they do not expect is finding out from a discrepancy.
Treat a variation as its own recorded event: the original figure, the revised figure, the reason, the approval, the date. Overwriting the original number is the single most common way a clean set of records becomes an unexplainable one, because the report and the sanction letter no longer agree and nothing in between explains why.
What good looks like at quarter end
If the records are kept as above, the quarter-end sequence is short:
- Pull disbursements for the period by source
- Check committed-but-unreleased against the schedule and note slippage with reasons
- Attach the milestone evidence already stored against each tranche
- Note variations with their approvals
- Reconcile the total against the sanction
No archaeology. The reason it is short is not that the reporting got easier - it is that the recording happened at the right moment.
The honest summary
Most incubators do not have a reporting problem. They have a recording problem that only becomes visible at reporting time.
If you change one thing after reading this, make it the point at which you write down what released a tranche. Amounts and dates survive in bank statements. The reason does not survive anywhere unless you put it somewhere on the day.
Frequently asked questions
- What do funders usually ask an incubator to evidence?
- Three things, in some form: that the money went to eligible recipients, that it went in the amounts and stages agreed, and that what it bought matches what was proposed. The specific format varies by scheme; the underlying question does not. Always work from the sanction letter and the scheme's own guidelines rather than from a template.
- Why is reconstructing utilisation afterwards so hard?
- Because the link between a specific rupee and a specific startup is created at the moment of disbursement and nowhere else. Bank statements show amounts leaving. They do not show which grant line the amount was drawn against or which milestone released it. If that link was not recorded at the time, you are inferring it from memory and email.
- Should funding be released in one payment or tranches?
- Tranches, in almost every case. A single payment removes your only real lever after selection and makes non-performance a recovery problem rather than a decision not to release. Tranches also produce the natural evidence trail a funder wants, because each release is attached to something that had to be demonstrated.
- What is over-allocation and why does it matter?
- Committing more money from a funding source than the source actually holds - usually across two programmes that each looked affordable on their own. It matters because it is discovered at disbursement, when a startup has already been told the money is coming. Blocking it at the point of commitment rather than reconciling later is the difference between a policy and a control.
