Most grant applications require more than one proposal document. A practical grant checklist should cover structured application forms, the main technical or project narrative, budget and budget justification, team documents, partner or support letters, financial evidence, proof of prior work, pitch materials, and any compliance attachments required by the funder.
A grant application is usually a package, not a single file. The package may include portal fields, PDF attachments, budget worksheets, letters, certifications, videos, pitch decks, work packages, and evidence that proves the team can execute. The exact list depends on the funder, call, geography, entity type, and stage of review. A short screening application may only ask for a summary and a few eligibility fields. A full deeptech application can ask for a technical narrative, implementation plan, financial information, intellectual property notes, letters of intent, and a video pitch.
Joltoo uses a normalized submission-asset vocabulary in its grant catalog. In the current catalog snapshot, 2,946 normalized deliverable entries across 1,262 grants are grouped into 38 recurring asset types and 7 families. That product data is useful because it shows what founders actually encounter across many calls: application forms, full forms, technical narratives, budget justifications, short applications, concept notes, CVs, financials, letters of intent, evidence, pitch decks, support letters, commercialization plans, business plans, and implementation plans appear again and again.
Use this page as a pre-submit grant checklist and document map. Always reconcile the checklist with the funding opportunity, Grants.gov or agency workspace, NSF PAPPG, NIH application guide, EIC portal, or other funder-specific forms. The goal is to know what each asset is, what it looks like, and what you can prepare before the deadline starts to compress.
Quick answer: the core grant checklist
For most startup and deeptech grants, the core grant checklist has six layers: eligibility and registration, application forms, proposal narrative, budget package, team and partner evidence, and compliance or special attachments. Not every call asks for every layer, but a founder should know which layer is missing before starting the draft. A technically strong proposal can still fail administratively if the application form, budget, attachments, or certifications are incomplete.
- Start with funder instructions. Treat official instructions as the source of truth. A checklist is useful only if it is reconciled against the current call documents and portal forms.
- Separate forms from narratives. Forms capture structured data such as legal name, project dates, budget totals, and applicant type. Narratives explain the problem, work plan, evidence, and impact.
- Map every attachment to a purpose. Each letter, CV, financial statement, or evidence file should prove something reviewers or grant staff need to verify.
- Prepare reusable assets early. Legal entity details, company summaries, founder bios, facilities notes, financial statements, evidence registers, and pitch materials can be prepared before a specific deadline.
- Leave conditional documents conditional. IP, ethics, regulatory, subcontractor, state-aid, SBC, and data-management attachments should be added only when the funder asks for them or the project clearly triggers them.
| Checklist layer | What it contains | Example asset |
|---|---|---|
| Registration and eligibility | Entity registrations, authorized users, eligibility confirmations, applicant type, geography, and company status. | SAM.gov/UEI for many US federal grants, SME status for some European calls. |
| Structured forms | Portal fields or PDFs that capture applicant, project, budget, and signatory details. | SF 424 R&R form fields, EIC short proposal fields, Grants.gov Workspace forms. |
| Narrative package | The main written case for the work, problem, method, plan, team, and impact. | Technical narrative, concept note, commercialization plan, implementation plan. |
| Budget package | Numbers plus explanation of why the requested resources are necessary and allowable. | Budget form, grant budget template, budget justification, budget narrative. |
| People and partners | Evidence that the applicant, team, collaborators, and customers can support the work. | CVs, biosketches, letters of support, letters of intent, subcontractor documentation. |
| Evidence and compliance | Proof, declarations, and regulated-work attachments. | Prior project evidence, proof-of-concept data, IP/FTO, data management plan, ethics or regulatory documentation. |
The 38 grant application documents to know
The full list below is intentionally broad. Most applications need only a subset, but seeing all 38 asset types helps a founder avoid surprises. Some are always visible, such as application forms and proposal narratives. Others appear only for certain funders, sectors, countries, or project types. Deeptech applicants should pay special attention to evidence, IP, regulatory, financial, and work-package assets because reviewers often need proof that the technology can move from research to deployment.
| Family | Asset | When it appears | Prepare |
|---|---|---|---|
| Forms | Application form | Almost every grant application. | Legal name, entity details, project title, dates, requested amount, applicant contact, authorized signatory. |
| Forms | Full application form | Second-stage or complete proposals. | All structured sections plus attachments and final budget totals. |
| Forms | Short application form | Screening rounds, EOIs, short proposals, accelerator-style gates. | Problem, solution, team, funding ask, summary evidence, eligibility facts. |
| Forms | Cover page | PDF or agency-form submissions. | Title, organization, PI/contact, project period, funding request, signatures. |
| Forms | I-Corps form | Customer-discovery or NSF-adjacent pathways. | Team, market hypothesis, customer discovery plan, participation details. |
| Narrative | Technical narrative | Main proposal body, scope of work, research plan, project description. | Problem, state of the art, innovation, methods, milestones, risks, outcomes. |
| Narrative | Concept note | Pre-proposal, LOI-like gates, invitation workflows. | One to three page case for fit, need, project, applicant, and expected outcome. |
| Narrative | Commercialization plan | SBIR/STTR, EIC, translational, market-facing deeptech calls. | Customers, adoption path, business model, IP, regulatory path, scale-up milestones. |
| Narrative | Business plan | Industry applicant or scale-up awards. | Company strategy, market, product, competition, team, finances, risks. |
| Narrative | Implementation plan | Calls that score feasibility and delivery. | Workstreams, owners, activities, deliverables, dependencies, milestones. |
| Narrative | Executive summary | Front matter, abstract, review summary, portal summary. | Problem, solution, project, evidence, outcome, public benefit. |
| Narrative | Transition plan | Defense, translational, commercialization, or follow-on funding pathways. | How outputs move to customer, procurement, clinical, manufacturing, or investor readiness. |
| Pitch | Pitch deck | EIC, accelerators, interviews, panels, investor-style grant reviews. | Slides on problem, technology, evidence, project, market, team, budget, risks, outcome. |
| Pitch | Pitch video | EIC-style short proposal or video-screening flows. | Two to three minute founder/demo script with prototype, evidence, and grant-funded milestone. |
| Pitch | Briefing chart | Defense or technical-panel workflows. | One-slide non-proprietary summary of objective, approach, impact, cost, and team. |
| Team | CV | Most research, innovation, and expert-reviewed grants. | Role-specific CV or biosketch for key personnel. |
| Team | Team section | Narrative proposals and portal forms. | Roles, commitments, gaps, advisers, partners, facilities, hiring plan. |
| Financial | Budget justification | Most full proposals. | Line-item rationale connecting costs to tasks, effort, rates, quotes, and outputs. |
| Financial | Financials | Company grants, co-funded awards, diligence-heavy calls. | Statements, runway, match evidence, accountant letter, investor or bank proof. |
| Financial | Work packages | Horizon, consortium, implementation-heavy projects. | WP objectives, tasks, deliverables, owners, person-months, timing. |
| Financial | Gantt chart | Projects with strict delivery schedules. | Timeline by work package, milestone, dependency, and deliverable. |
| Financial | TABA request | Some SBIR/STTR commercialization assistance add-ons. | Third-party assistance scope, provider, budget, expected commercialization use. |
| Financial | Capital commitments addendum | Scale-up, blended finance, or match-heavy programs. | Investor, lender, partner, or internal commitment evidence. |
| Evidence | Letters of intent | Customer, partner, pilot, investor, or consortium interest. | Conditional intent statement naming role, resource, timing, and dependency. |
| Evidence | Prior project evidence | Follow-on awards, feasibility claims, track-record checks. | Prior award documents, final reports, completion evidence, customer/pilot summaries. |
| Evidence | Letters of support | Collaborators, customers, facilities, consortium, resource commitments. | Signed letters that specify role, resource, commitment, and relevance. |
| Evidence | IP documentation | Deeptech, university spinouts, hardware, biotech, software IP, EIC-style diligence. | Patent list, ownership, licenses, background/foreground IP, trade secrets. |
| Evidence | Proof-of-concept data | Technical-risk, prototype, translational, and feasibility grants. | Bench data, pilot logs, assay results, validation reports, calibrated test summaries. |
| Evidence | Subcontractor documentation | When external vendors perform substantive work. | SOW, quote, role, deliverable, selection rationale, budget basis. |
| Evidence | Freedom-to-operate analysis | Commercialization and investor-readiness contexts. | FTO memo, counsel note, search summary, risk position, planned next step. |
| Evidence | Investor pre-commitment letter | Blended finance, match, scale-up, or co-investment awards. | Conditional investment or co-funding commitment tied to project award or milestone. |
| Compliance | Data management plan | NSF, NIH, research-data, open-science, or public-access calls. | Data types, storage, access, sharing, retention, privacy, owner. |
| Compliance | Regulatory documentation | Medtech, biotech, energy, aerospace, safety-critical, controlled technologies. | Regulatory pathway, approvals, standards, safety review, trial or pilot requirements. |
| Compliance | Ethics review | Human subjects, animal research, sensitive data, safety, environment, dual-use. | IRB/ethics status, self-assessment, consent, safeguards, exclusions. |
| Compliance | SBC certifications | US SBIR/STTR and small-business programs. | Ownership, size, PI employment, affiliates, registration certifications. |
| Compliance | State aid declaration | European and national public-aid contexts. | Aid received, entity, instrument, fiscal years, declaration accuracy. |
| Compliance | Equity and diversity statement | Some foundation, public, research, or workforce programs. | Access, inclusion, team practices, community or participant considerations. |
| Compliance | Evaluation license application | Technology-access or evaluation-license grants. | Requested technology, use case, evaluation plan, applicant authority, restrictions. |
Seven asset families
The easiest way to manage a grant application is to group documents by job. Forms establish who is applying and what the project is. Narratives persuade reviewers. Pitch assets help panels understand the story quickly. Team documents prove capability. Financial assets explain feasibility and cash logic. Evidence assets prove that claims are not speculative. Compliance assets keep the application inside funder, legal, ethical, and regulatory boundaries.
| Family | Reviewer question | Common mistake |
|---|---|---|
| Forms | Is this applicant, project, and request administratively complete? | Treating form fields as clerical when they define the official application record. |
| Narrative | Is the proposed work worth funding and credibly planned? | Writing a generic story that does not map to the scoring criteria. |
| Pitch | Can the panel understand the opportunity quickly? | Reusing an investor deck that hides the grant-funded project. |
| Team | Can this team execute the work? | Listing impressive biographies without assigning project roles. |
| Financial | Are the requested resources necessary, reasonable, and allowable? | Submitting numbers without calculation basis or task linkage. |
| Evidence | What proves the applicant can do what it claims? | Relying on assertions instead of test data, letters, prior work, or commitments. |
| Compliance | Does the project trigger special rules? | Leaving ethics, data, state-aid, IP, or regulatory issues until after award. |
This grouping also helps when work is split across a team. The CEO may own application strategy, commercialization, and partner letters. The technical lead may own the technical narrative, proof-of-concept data, IP notes, and risk register. Finance may own budget, financials, match evidence, and indirect-cost treatment. Operations or legal may own registrations, signatory authority, data management, ethics, subcontractor files, and certifications.
Most common submission assets
The frequency table below comes from Joltoo catalog normalization, not from a single funder. It should not be read as a universal rule, but it is a useful 20/80 signal. If a founder prepares for the top recurring assets, they are better positioned for most full applications. The top of the table also shows why a document hub matters: the recurring assets are spread across forms, narrative, financial, team, evidence, and pitch categories.
| Rank | Asset | Family | Share of normalized requests | What to learn from the frequency |
|---|---|---|---|---|
| 1 | Application form | Forms | 27.1% | Structured portal data is the most common asset. Do not wait until the final day to learn the form fields. |
| 2 | Full application form | Forms | 13.4% | Full-stage packages often combine forms and attachments. |
| 3 | Technical narrative | Narrative | 8.1% | The main written body remains central for technical grants. |
| 4 | Budget justification | Financial | 6.4% | Costs need explanation, not only spreadsheet totals. |
| 5 | Short application form | Forms | 6.1% | Many funders screen before inviting a full proposal. |
| 6 | Concept note | Narrative | 4.0% | Pre-proposal gates are common enough to prepare a compact project case. |
| 7 | CV | Team | 3.9% | People proof is a recurring requirement. See NIH biosketch and NSF biosketch. |
| 8 | Financials | Financial | 3.7% | Company applicants may need to prove financial capacity or match funding. |
| 9 | Letters of intent | Evidence | 3.3% | Third-party intent often matters before a project is fully committed. |
| 10 | Prior project evidence | Evidence | 3.0% | Follow-on applications need proof that earlier work happened. |
| 11 | Pitch deck | Pitch | 2.9% | Panel and interview processes often need a visual story. |
| 12 | Letters of support | Evidence | 2.7% | Support letters should specify resources and roles, not generic enthusiasm. |
| 13 | Commercialization plan | Narrative | 2.0% | Deeptech funders often need a route beyond the grant period. |
| 14 | Business plan | Narrative | 1.9% | Industry grants may evaluate company viability as well as project merit. |
| 15 | Implementation plan | Narrative | 1.8% | Delivery credibility matters when work is complex or multi-party. |
Example gallery: what the assets look like
The examples below are compact working examples. Their job is to make each document shape visible: fields, evidence, commitments, and decision points. A founder should adapt the language, scale, and evidence to the specific funder. For a broader proposal structure, use this page with the grant proposal template, grant proposal example, and grant proposal sections guide.
| Asset | Mini example |
|---|---|
| Application form field | Project title: High-temperature heat-pump pilot for industrial drying. Requested funding: GBP 420,000. Total project cost: GBP 700,000. Duration: 18 months. Authorized signatory: CEO or board-authorized director. |
| Short application / EOI | Problem: fossil-fuel heat dominates industrial drying. Solution: modular high-temperature heat pump. Project request: validate output, uptime, and integration requirements during a controlled customer-site pilot. |
| Full application package | Portal form, technical narrative, budget form, budget narrative, team bios, letters of support, financial statements, data/ethics/regulatory attachments if triggered. |
| Technical narrative outline | Problem and opportunity; state of the art; proposed innovation; work plan; milestones; risks; team and facilities; expected outcomes and impact. |
| Concept note skeleton | Title, applicant, need, proposed project, innovation, funding ask, expected outcome, why this funder is a fit. |
| Budget narrative row | Senior engineer: 0.4 FTE for 12 months to lead firmware integration, bench testing, and pilot-site troubleshooting for Work Packages 1-3. |
| Co-funding evidence table | Company cash: GBP 110,000, board-approved allocation. Pilot partner engineering time: GBP 45,000 in-kind, partner support letter. Existing investor note: GBP 125,000, signed commitment. |
| Letter of intent paragraph | We confirm interest in evaluating the pilot unit at our industrial drying facility, subject to safety review and project award. We can provide process data, site access for installation planning, and operating feedback. |
| Evidence register row | Claim: prototype reached 250C output. Evidence: bench-test report with calibrated sensor logs. File: Bench_Test_Report_May_2026.pdf. |
| Pitch deck outline | Problem, solution, technical differentiation, evidence to date, grant-funded project, work plan, market and adoption path, team, budget, risks, ask. |
| Support letter sentence | If awarded, Northbridge Manufacturing will provide pilot-site access, one process engineer for monthly technical reviews, and anonymized process data to evaluate uptime and energy performance. |
| Implementation table row | WP2 Bench validation: engineering lead owns protocol, tests, and analysis; deliverable is validation report; dependency is prototype v2 complete. |
| IP schedule row | Patent application 1: filed UK, PCT planned; owner Acme; relevance heat-exchanger control method. |
| Regulatory/ethics row | Human-subjects research: no direct human-subjects research; operator interviews are internal usability feedback only. Site safety review required before pilot installation. |
| Risk register row | Supplier lead-time delay: medium likelihood, high impact; mitigation is dual-source critical connectors before milestone 2. |
- Strong examples name the proof. A technical narrative should not say the technology is validated; it should name the test, dataset, report, operating hours, customer evidence, or benchmark that supports the claim.
- Strong examples connect assets to each other. The budget narrative should point to work packages, the work packages should point to milestones, and the milestones should point to evidence outputs.
- Strong examples stay conditional where needed. A letter of intent is often not a purchase order. Say what the partner intends to do, what conditions apply, and what resource they can provide.
- Strong examples are funder-specific. An EIC pitch deck, NSF project summary, NIH biosketch, and Grants.gov form have different purposes. Do not flatten them into one generic template.
Deeptech-specific assets reviewers look for
Deeptech applications carry a different burden from many general nonprofit or community grants. Reviewers often need to understand technical maturity, evidence quality, risk, IP position, regulatory path, customer pull, manufacturability, and financing logic. That does not mean every application needs a patent memo or regulatory plan. It means the submission package should make technical risk visible and show how the grant-funded work retires that risk.
| Deeptech asset | What it proves | How to make it concrete |
|---|---|---|
| Technical narrative | The problem is technically real and the proposed method is credible. | Use current TRL, state-of-the-art comparison, work packages, milestones, risks, and success criteria. |
| Proof-of-concept data | The project is not speculative from zero. | Show test setup, result, date, measurement method, limitations, and what must be validated next. |
| IP and FTO notes | The company can use and commercialize the relevant technology. | Name owned patents, licensed background IP, trade secrets, known risks, and planned counsel review. |
| Regulatory documentation | The team understands approval, safety, or compliance gates. | State what is required during the grant and what is only a future commercialization step. |
| Commercialization plan | The grant produces evidence that matters after award. | Tie technical milestones to customer, regulatory, manufacturing, procurement, or investor decisions. |
| Financials and co-funding | The applicant can fund its share and survive the project period. | Use signed commitments, board allocations, investor letters, or accountant confirmations where requested. |
| Work packages and Gantt | The work is executable under deadline pressure. | Assign owners, dependencies, delivery months, and evidence outputs. |
A good deeptech grant checklist therefore starts earlier than the application deadline. It asks whether the company can document the current state of the technology, the evidence gap, the funded work, and the next milestone. The TRL levels guide, commercialization plan guide, logic model template, and evaluation plan guide help translate that into reviewer-facing structure.
How different funders package the documents
The same asset can appear under different names. One funder may call the core narrative a project description. Another may call it a technical volume, case for support, Form B, scope of work, or research strategy. A US federal application may be built around Grants.gov Workspace and agency forms. NSF has explicit proposal preparation and checklist requirements. NIH uses SF 424 R&R forms and application-guide sections. EIC Accelerator separates short proposal, full proposal, pitch deck, video pitch, financial information, letters of intent, and FTO analysis. The founder job is to translate the checklist into the funder language.
| Funder path | Likely package | Founder watch-out |
|---|---|---|
| Grants.gov / US federal | Workspace forms, agency-specific forms, attachments, budget forms, registrations, authorized users. | Allow time for SAM.gov, UEI, workspace roles, file requirements, and agency instructions. |
| NSF | Project summary, project description, references, biosketches, budget and justification, current and pending support, facilities, data plan where required. | Use the NSF checklist and PAPPG. NSF formatting and component rules are part of compliance. |
| NIH | SF 424 R&R forms, research strategy or program plan, biosketches, budget, letters, facilities, human subjects or vertebrate animals where triggered. | Follow both the application guide and the notice of funding opportunity. Attachments have strict format rules. |
| EIC Accelerator | Short proposal, full proposal, pitch deck, video pitch, implementation plan, financial information, letters of intent, FTO analysis where relevant. | Do not reuse a VC deck unchanged. The pitch must connect to the innovation, market, implementation, and funding ask. |
| Horizon Europe consortium calls | Administrative forms, Part B narrative, work packages, deliverables, milestones, budget, partner roles, ethics/security where triggered. | Work packages and deliverables must be coherent with resources and partner ownership. |
| Foundation or private grants | Application form, need statement, project narrative, budget, organizational documents, support letters, evaluation plan. | Terminology may be simpler, but evidence and fit still matter. |
What to prepare before choosing a grant
Some assets should be prepared before a specific opportunity appears. Others should wait until a funder has been selected. Preparing everything too early creates stale generic text. Preparing nothing early creates deadline panic. The practical split is to maintain a reusable company evidence base, then customize the proposal package once the call is known.
| Prepare now | Customize after call selection | Prepare only if requested |
|---|---|---|
| Legal entity details, registrations, authorized signatory, company description. | Application form fields, project title, requested amount, call-specific summary. | State-aid declaration, SBC certification, evaluation license application. |
| Founder/team bios in several lengths. | CV or biosketch format required by the funder. | Named expert letters or references required only by the call. |
| Technology one-liner, problem statement, current evidence register. | Technical narrative, work plan, milestones, risks, expected outputs. | Regulatory, ethics, human-subjects, animal, export-control, or security forms. |
| Basic budget assumptions and cost categories. | Budget form, budget justification, indirect-cost treatment, match logic. | Capital commitments addendum, TABA request, special cost forms. |
| Customer discovery notes, pilot evidence, partner pipeline. | Letters of intent, letters of support, commercialization plan. | Signed partner documents with funder-specific wording. |
| IP inventory and ownership notes. | IP section or commercialization narrative. | FTO memo or counsel letter if the funder specifically asks. |
- Keep reusable facts structured. Legal name, registration number, address, leadership, ownership, bank details, facilities, equipment, and project history should not be rewritten from memory each time.
- Keep evidence file names boring and searchable. Use names like Bench_Test_Report_May_2026.pdf or Pilot_LOI_Northbridge.pdf instead of vague final-final files.
- Keep claims and files connected. If the narrative says a prototype ran for 250 hours, the evidence register should point to the log or report that proves it.
- Keep funder instructions separate. Do not overwrite a reusable company asset with call-specific language that may be wrong for the next application.
Which assets deserve separate examples
Not every one of the 38 asset types deserves its own SEO article. Some are too low-frequency or too funder-specific. The better content system is one hub page plus example-led child pages for assets that founders repeatedly need to see. Existing Joltoo guides already cover many assets: budget justification, budget narrative, letters of intent, letters of support, executive summary, NSF data management plan, and grant progress report.
| Example page | Why it matters | What the page must show |
|---|---|---|
| Grant technical narrative example | The technical narrative is the main body for many R&D grants. | Annotated outline, weak vs strong technical claims, milestone evidence table. |
| Grant concept note example | Concept notes and EOIs are common screening gates. | One to three page structure, invite-to-full logic, example opener and project summary. |
| Grant application form example | Forms are frequent but under-explained. | Field-by-field walkthrough, SF424-style and portal-style examples, common mistakes. |
| Grant pitch deck example | Pitch decks and videos are common for panels and EIC-style processes. | Slide outline, grant vs investor deck differences, two-minute video script. |
| Grant financials and co-funding evidence | Company grants often require evidence of financial capacity. | Co-funding table, accountant letter logic, match evidence, investor commitment examples. |
| Proof-of-concept data for grants | Deeptech claims need evidence. | Evidence register, test log summary, prior-project proof, customer/pilot evidence. |
| Grant work plan template | Execution artifacts make feasibility visible. | Work packages, Gantt, risk register, dependency map, deliverable schedule. |
Mistakes this checklist prevents
A checklist does not make a weak project fundable, but it prevents avoidable failures. Many bad applications are not bad because the technology is impossible. They are bad because the package is incomplete, internally inconsistent, or hard to review. The same project title appears three different ways. The budget says one timeline and the work plan says another. The support letter praises the company but does not commit anything. The pitch deck sells the company but never explains the grant-funded work. These issues reduce reviewer confidence before the science or market case is even considered.
- Do not let forms contradict attachments. Requested funding, project dates, PI/contact, title, organization name, and budget totals should match across the portal, narrative, and budget files.
- Do not submit generic support letters. A strong letter names the role, resource, condition, timing, and relevance. A weak letter says only that the project is exciting.
- Do not hide technical uncertainty. Deeptech reviewers expect risk. A credible risk register is stronger than a narrative that pretends everything is solved.
- Do not leave financial evidence until the end. Match funding, bank proof, board allocations, investor commitments, and financial statements can take longer than writing a paragraph.
- Do not overload the package with unnecessary files. Extra attachments can confuse reviewers or violate instructions. Submit what the funder asks for and what the proposal genuinely needs.
- Do not confuse eligibility with readiness. Being eligible means you are allowed to apply. Being ready means you can submit a coherent package with evidence, budget logic, team proof, and compliance coverage.
The best use of this grant checklist is not to copy every item into a folder. The best use is to build a submission map for the specific opportunity: required, conditional, optional, not applicable. Then assign an owner and due date to each required or conditional asset. That turns the application from a vague writing task into a manageable production process.