A grant budget should include the costs required to deliver the funded work: personnel, fringe, subcontractors, consultants, materials, equipment, travel, indirect costs, fees or match where allowed, and a budget justification that connects every cost to a work package.
For an R&D startup, the budget is a second version of the technical plan. If the work plan says you will build, test, validate, or demonstrate something, the budget should show who does the work, what they need, and why the cost is eligible.
Use this after you have a proposal structure. If the writing itself is the blocker, start with how to write a grant proposal.
The mistake founders make is treating the budget as finance admin at the end of the application. Reviewers often read it as a planning signal. If the budget is vague, over-rounded, or disconnected from milestones, it suggests the project itself is not fully thought through.
A strong budget does the opposite. It makes the proposal feel more executable. It shows that the team understands the work, the people required, the external capabilities needed, the evidence to be generated, and the practical cost of getting from the current state to the funded milestone. In R&D grants, that credibility can matter as much as the total amount requested.
Template
| Budget line | What to include | Justification question |
|---|---|---|
| Personnel | Founder, engineer, scientist, project manager, technical lead effort. | What work package requires this person's time? |
| Fringe or benefits | Employer costs linked to salary. | Is the rate allowed and documented? |
| Subcontractors | Specialist labs, CROs, engineering firms, university partners. | Why must this work be external? |
| Materials and supplies | Prototype parts, lab supplies, consumables, test materials. | Which experiment or milestone needs them? |
| Equipment | Equipment needed for R&D or testing. | Is purchase allowed, or should this be rented/shared? |
| Travel | Pilot, partner, field test, or required project travel. | What project outcome depends on this trip? |
| Indirect costs | Overhead, facilities, administrative support if allowed. | What rate or policy supports the calculation? |
The template should be adapted to the funder format, not copied blindly. Some applications ask for detailed cost categories. Others ask for a short budget table and a narrative. Some require separate partner budgets, cost share, indirect rate documentation, or quotes. The underlying logic stays the same: each line should have a project reason, an amount basis, and an eligibility basis.
Before filling in amounts, decide what level of detail the reviewer needs. A small feasibility grant may not need a complex model, but it still needs credible effort estimates and direct costs. A larger demonstration grant may need period-by-period spending, partner allocations, subcontractor statements of work, equipment rationale, and matching-fund assumptions. Detail should scale with risk and award size.
Line items
A good grant budget is specific enough to be credible and simple enough to audit. Avoid round-number guesses unless they are backed by a rate, quote, salary basis, or scope.
- Start from work packages, not from a target award amount.
- Assign personnel effort to each work package.
- Separate internal work from subcontracted work.
- Check whether equipment, travel, fee, indirect costs, and match are allowed.
- Keep assumptions visible so reviewers can follow the math.
A reviewer does not need every procurement detail, but they do need enough information to believe the budget was built from real assumptions. Salary should come from effort and rate. Subcontractor cost should come from scope. Materials should come from build and test cycles. Travel should come from a project need, not a generic business-development wish.
The fastest way to improve a budget is to replace round numbers with assumptions. "Materials: $30,000" is weak. "Three prototype build cycles at approximately $10,000 each, based on current supplier quotes and expected rework" is stronger. The number may be the same, but the second version lets the reviewer understand the logic.
Personnel costs need the same treatment. Do not simply list founder salaries. State the effort percentage, the role, the work packages, and why that level of effort is plausible. If a founder is claiming 80% effort while also managing fundraising and sales, reviewers may question realism. If an engineer is allocated lightly to a technically intense work package, reviewers may question delivery capacity.
Build from workplan
The cleanest grant budget starts with work packages. Build the work plan first, then cost each activity.
For R&D applications, the work package is the bridge between technical ambition and financial credibility. If work package 1 is prototype design, the budget should show design personnel, specialist software or tools if needed, materials for the first build, and any external engineering support. If work package 2 is validation, the budget should show lab time, test fixtures, independent testing, consumables, travel, or partner costs.
| Work package | Budget question | Evidence to collect |
|---|---|---|
| Technical design | Who designs it, how much time, and what tools are needed? | Salary basis, role descriptions, software/tool quotes. |
| Prototype build | What materials, parts, fabrication, or equipment are needed? | Bill of materials, supplier quotes, build quantity assumptions. |
| Testing and validation | Who runs tests and what environment is required? | Lab quote, test protocol, partner letter, facility rate. |
| Commercial validation | What customer discovery or pilot work is in scope? | Interview plan, pilot scope, travel rationale, advisor role. |
| Project management | Who coordinates delivery, reporting, and risk management? | Effort estimate and reporting responsibilities. |
This method also prevents underbudgeting. Founders often remember engineering time but forget testing cycles, reporting, quality documentation, partner coordination, field travel, or regulatory input. Those missing costs become delivery risk later.
Underbudgeting can be as damaging as overbudgeting. A lean budget may look disciplined, but if it cannot support the promised milestone, reviewers may see the project as unrealistic. For deeptech startups, validation is often the category that gets squeezed: independent testing, repeat experiments, calibration, failure analysis, environmental testing, documentation, and partner integration all take time and money.
A good workplan-to-budget process starts with the evidence target. If the grant is meant to prove prototype reliability, budget for the conditions, cycles, fixtures, personnel, and analysis required to prove reliability. If the grant is meant to support customer-relevant validation, budget for partner coordination, travel, data capture, and acceptance criteria. The budget should fund the evidence, not just the activity.
Justification
The budget justification explains why each cost is necessary, reasonable, allocable to the project, and consistent with the work plan. It should not repeat the spreadsheet. It should explain the logic behind the spreadsheet.
The best justification answers three questions at once: why this cost is needed, why the amount is reasonable, and why the funder should pay for it under this call. A line item can be technically useful and still be a poor grant cost if it is outside scope, unsupported, or better treated as company overhead.
| Cost | Weak justification | Stronger justification |
|---|---|---|
| Engineer salary | Needed for development. | 0.4 FTE for firmware work in WP2 and integration testing in WP3. |
| Prototype materials | Parts for prototype. | Materials for three build-test cycles tied to milestone M2. |
| Subcontractor | Testing services. | Independent validation lab for thermal and reliability tests required before pilot deployment. |
| Travel | Partner visit. | Two technical staff visits for pilot installation and acceptance testing. |
Eligible costs
Eligibility is not universal. A cost that is allowed in one R&D grant can be capped, excluded, or treated differently in another.
This is why budget drafting should happen with the call guidance open. Some funders distinguish between feasibility studies, industrial research, experimental development, demonstration, and commercial activity. Some allow indirect costs through a stated rate; others require a negotiated rate or cap. Some treat equipment as purchase, depreciation, rental, or ineligible capital cost. Some allow subcontracting only within limits.
| Cost type | Usually safer when... | Usually risky when... |
|---|---|---|
| Personnel | Effort is directly tied to funded tasks. | The role is generic company management with no project allocation. |
| Subcontractors | They provide specialist capability the team does not have. | They perform most of the core innovation without clear justification. |
| Equipment | The project requires it and the funder allows the treatment. | It looks like general company infrastructure. |
| Travel | It is necessary for testing, pilot, consortium, or required meetings. | It is general sales or conference activity. |
| Commercial work | The call explicitly funds validation, market readiness, or commercialization. | The call funds only technical R&D. |
If a cost feels strategically important but not clearly eligible, do not hide it. Either move it to company-funded activity, explain the eligibility basis, or ask the funder before submission. Reviewers are more forgiving of a clear boundary than a budget that quietly stretches the rules.
Eligibility also affects timing. Some costs are eligible only after the award start date or only after a contract is signed. Some require procurement rules, multiple quotes, or prior approval. Some funders allow depreciation rather than purchase. If the company starts spending before checking these rules, it may create costs that are real for the business but unusable in the grant.
This is why finance and technical leads should review eligibility together. The technical lead knows what the project needs. The finance owner knows how the funder will treat the cost. If those conversations happen late, the team may have to rewrite the work plan or find company cash for costs it assumed the grant would cover.
Example
| Category | Example amount | Rationale |
|---|---|---|
| Personnel | $120,000 | Technical lead, engineer, and project manager effort across three work packages. |
| Subcontractors | $45,000 | External validation lab and regulatory consultant. |
| Materials | $30,000 | Prototype build materials and consumables. |
| Equipment | $20,000 | Specialized test fixture needed for project measurements. |
| Travel | $8,000 | Pilot installation and partner testing. |
| Indirect costs | $27,000 | Calculated according to allowed rate or funder rule. |
The example is deliberately simple. Real budgets may need multiple periods, partner budgets, cost-share, currency rules, indirect rate calculations, or country-specific funding rates. The core principle does not change: the spreadsheet should be a transparent financial model of the work plan.
A useful way to check the example is to ask whether the project could still be delivered if one category were removed. If removing subcontractors means there is no independent validation, then subcontractors are not optional support; they are part of the technical evidence plan. If removing travel has no effect on the work, the travel may not belong in the grant budget.
The example also shows why percentages alone are not enough. A budget can look balanced by category and still be wrong for the project. A software-heavy R&D project may have high personnel and low materials. A hardware validation project may have significant materials, lab testing, and equipment access. A clinical or regulated project may require external specialists. The distribution should reflect the work, not a generic ideal.
If the funder provides a maximum award amount, resist the instinct to spend up to it automatically. Start with the project cost, then decide whether the project should be resized, co-funded, or staged. A budget that conveniently equals the maximum award can look suspicious if the assumptions are thin. A slightly smaller but well-justified request can be stronger.
Mistakes
| Mistake | Why it weakens the application | Fix |
|---|---|---|
| Budget does not match the work plan | Reviewers cannot see how money produces milestones. | Map every line item to a work package. |
| Unexplained subcontractors | The team may look incomplete or costs may look inflated. | Explain why external capability is necessary. |
| Ignoring indirect cost rules | The budget can become non-compliant. | Check the funder rule before calculating overhead. |
| Underbudgeting validation | The plan may look unrealistic. | Include testing, iteration, and evidence-generation costs. |
Budget mistakes are often symptoms of strategy mistakes. A company that cannot explain personnel effort may not have clear work-package ownership. A company that hides subcontractor dependency may not have the right team. A company that underbudgets testing may be trying to make the award fit instead of making the project credible.
Review process
Before submission, review the budget in the same order a skeptical reviewer might read it: scope, people, partners, materials, timing, and rules.
- Check scope first: every cost should support the funded project, not general company growth.
- Check people next: effort levels should be plausible for the tasks and timeline.
- Check partners: subcontractors and consultants should have a defined role and output.
- Check materials and equipment: quantities should match build and test assumptions.
- Check timing: costs should occur in the period when the work happens.
- Check rules: indirect costs, travel, equipment, fee, and match should follow the funder guidance.
- Check story: the budget should make the project feel more credible, not more confusing.
This review is worth doing before the final narrative edit. If the budget reveals that a work package is vague, fix the work package. If the narrative promises validation but the budget has no validation cost, fix both. If the team claims a partner is essential but the budget gives them no role, reviewers will notice.
For founders, the budget can also be a forcing function. It shows whether the company actually understands the next milestone. If a milestone cannot be costed, it may not be defined clearly enough to fund.
Run the review twice: once for compliance and once for story. Compliance asks whether the cost is allowed, calculated correctly, and supported. Story asks whether the cost makes the project more believable. A technically compliant budget can still weaken the proposal if it does not explain why the money produces the promised result.
The story review should include someone who was not inside the spreadsheet. Give them the work plan and budget, then ask them to explain how the money turns into milestones. If they cannot explain it, the reviewer may not be able to either. That is usually a narrative problem, not a math problem.
Narrative examples
A budget narrative should make a reviewer think: this team knows exactly what it will do with the money.
The narrative does not need to be dramatic. It needs to be concrete. The difference between a weak and strong budget justification is usually specificity: role, task, quantity, rate, timing, and connection to a milestone.
| Line item | Thin narrative | Stronger narrative |
|---|---|---|
| Founder technical effort | Founder salary is needed to manage the project. | The CTO will allocate 35% effort to WP1 architecture, WP2 prototype integration, and WP4 technical reporting. This role is required because the work depends on proprietary system design decisions. |
| External lab testing | A lab will test the prototype. | The subcontracted lab will run environmental and reliability tests for Milestone 3 using the protocol described in the work plan. Independent testing is needed because customer pilots require third-party performance evidence. |
| Materials | Materials are needed for prototype development. | Materials cover three build-test cycles, including sensor housings, boards, connectors, and consumables. Quantities are based on two engineering builds and one validation build. |
| Travel | Travel is needed for meetings. | Travel covers two engineers visiting the pilot site for installation and acceptance testing. Remote support is insufficient because the work includes physical calibration and operator training. |
These examples work because they explain necessity. They do not ask the reviewer to infer why a cost belongs. They show the task, the milestone, and the reason the cost cannot be removed without weakening the project.
When drafting your own narrative, avoid adjectives like critical, essential, and innovative unless the sentence also explains why. A reviewer cannot audit an adjective. They can audit a work package, a rate, a quote, a test protocol, or a named deliverable.