Grant reporting in Horizon Europe: how to manage deliverables, budget and deadlines

The results letter arrives on a Thursday evening. So the team celebrates, partners exchange congratulations in the shared chat, and management drafts an announcement for the website. Then, within two weeks, the first practical questions appear: who collects documents for the first reporting period, when is the first deliverable due, who tracks partner spending, and who reminds the finance team about time records.

Grant reporting starts on day one of project implementation. Teams that build a system early go through reporting periods calmly. Teams that postpone it meet their first periodic report in crisis mode, because a month before the deadline the coordinator ends up digging through old emails, spreadsheets and chats for proof that the project moved at all.

In this guide, we break down how reporting works in Horizon Europe and other EU-funded projects: continuous reporting, periodic reports, deliverables, milestones, financial reporting, amendments and the coordinator’s role. In addition, you will find two practical checklists: what to do in the first 30 days of the project and 60 days before the report.

What grant reporting really is

Grant reporting is a system of evidence that the team delivers what it promised in the proposal. Specifically, it shows that the project follows the work package plan, reaches its milestones, submits deliverables, spends money according to the rules, records risks, and can explain to the donor what happened during the reporting period.

In Horizon Europe and similar programmes, reporting has two sides. The technical side answers the question “what has been done?”, while the financial side answers “how has the budget been used?”. Both sides must match, because if the technical report says a work package is one third complete while 90% of its costs are already spent, the European Commission will ask questions.

Here is the main point about how to report on a grant: reporting works as the project’s operating system. If the team records progress, costs, risks and decisions every month, the periodic report assembles itself from ready blocks. Otherwise, the report turns into an archaeological dig through old correspondence.

The Grant Agreement: when the proposal becomes an obligation

After the consortium signs the Grant Agreement, the work packages, deliverables, milestones, budget and partner roles stop being elements of a well-written proposal. From that moment, they become formal obligations, recorded in the Description of Action (Annex 1 to the agreement).

We have already covered how to structure work packages at the proposal stage. During implementation, those same WPs become the backbone of reporting, since every report builds on progress across packages, their tasks and their results.

A poorly designed work package hurts twice: first during proposal evaluation, and later during reporting. Vague deliverables, unrealistic timelines and unclear role division between partners come back to the team exactly when the reporting period starts.

Continuous reporting: it runs through the whole project

Continuous reporting means regular updates about the project in a dedicated module on the Funding & Tenders Portal. The module opens when the project starts and stays active throughout implementation. Later, the system uses this data to generate part of the periodic report automatically.

So what does the team update in continuous reporting?

• the status of deliverables and milestones;
• critical risks that threaten the work plan;
• publications and research results;
• communication activities and events;
• intellectual property rights (IPR);
• the publishable summary of the project;
• programme-specific indicators.

For example, deliverable D2.1 is due in month M12. In practice, this means that by M3–M6 the team already knows who prepares it, which data it requires, who reviews the quality, where the draft lives, and what proof of completion to attach. If D2.1 first comes up in M11, a delay is guaranteed.

The periodic report: what happens during the reporting period

Every Horizon Europe project runs in reporting periods defined in the Grant Agreement. After each period ends, the consortium submits a periodic report, and the official window for this is 60 days. The report consists of two parts: technical and financial.

Technical Report

• Part A contains structured tables with project data. The system generates them automatically from continuous reporting, so the discipline of previous months pays off here: with updated data, Part A is nearly ready.
• Part B is the narrative section. Here the team describes the work carried out and explains deviations, delays, plan changes and any work left undone. Teams prepare Part B outside the portal using the official template and then upload it as a PDF.

Financial Report

• individual financial statements from each beneficiary and its affiliated entities;
• the consolidated financial statement for the consortium, which the system generates automatically;
• a use of resources report or detailed cost tables, where the programme requires them;
• a Certificate on the Financial Statements (CFS) from an independent auditor, if the EU contribution for a beneficiary reaches EUR 430,000. The CFS goes in with the final report.

In short, the technical report tells the story of the period, while the financial report shows what that story cost and whether the costs follow the rules. The Commission checks both parts for consistency, and in fact, mismatches between them cause most follow-up questions from the Project Officer.

The worst mistake: assembling the report in the final month

Here is a typical scene. A month before the deadline, the coordinator asks partners for updates. One partner sends three paragraphs of generic text. Another sends last year’s presentation. A third asks which deliverable they were supposed to own, and a fourth still has open costs for the period. As a result, the coordinator becomes a full-time reminder service, and reporting becomes a source of stress for the entire consortium.

Writing the report text itself is rarely the hard part. What the team lacks is a system that accumulates reporting material throughout the period. Monthly partner updates, current deliverable statuses, recorded risks and collected evidence turn periodic report preparation from a three-month scramble into a few weeks of calm editorial work.

The evidence library: the folder that saves the project

Reporting needs proof, and you should start collecting it from day one. An evidence library is a structured archive of everything that confirms the work and the costs:

• meeting minutes and attendance lists;
• event photos, webinar recordings, presentations;
• deliverable versions and proof of reached milestones;
• correspondence with decisions that shaped the project;
• contracts, invoices, payment confirmations;
• timesheets or equivalent time records;
• screenshots of communication campaigns and publications;
• links to datasets, repositories and project websites.

Organise the archive by work package, reporting period, partner and evidence type. As a result, at the end of the period the team spends its time analysing progress. Without structure, the same time goes into hunting for files across chats and inboxes.

Deliverables and milestones: owner, deadline, evidence

A deliverable is a concrete result the consortium must submit to the Commission or record: a report, a document, a prototype, a platform. A milestone is a control point that confirms the project has reached an important stage and can move to the next phase.

Here is a practical insight from dozens of projects: a deliverable without an owner is a future delay, and a milestone without evidence is a weak spot in the report. So for every deliverable, the project management system should record:

• an owner, meaning a specific person, with the organisation in brackets;
• the official deadline plus an internal deadline 2–4 weeks earlier;
• a reviewer who checks quality before submission;
• proof of completion and the current status;
• the related work package and task;
• delay risks, if any are already visible.

Budget and financial reporting: where chaos usually starts

Financial reporting rarely breaks on the numbers themselves. It breaks on the missing link between costs and the work actually done. Typical consortium problems include:

• costs with no connection to specific work packages;
• partners who interpret budget categories differently;
• personnel costs that do not match the actual workload of people;
• a financial manager who cannot see changes in the technical plan, and a technical manager who cannot see budget risks;
• documents scattered across different storage locations.

Reporting works better when the budget lives next to the work calendar, the deliverables and the partner roles. Then the team spots the question “why is WP3 at 80% spending with 40% progress” in M9, so the Project Officer never gets to ask it.

Amendments: when changes need formal approval

Projects evolve, and plans change. The team can handle part of these changes within day-to-day management. However, changes to the Grant Agreement or its annexes require a formal amendment through the portal. Typical situations include:

• a change in the consortium composition or a change of coordinator;
• substantial changes to the Description of Action (Annex 1);
• substantial changes to the planned work;
• changes that affect the budget or the legal terms of the agreement.

An amendment is a working tool that brings the official document in line with the real life of the project. Trouble starts when the team ignores changes for months and then tries to explain them after the fact in Part B. For complex cases, talk to your Project Officer in advance, because a written consultation before an amendment saves weeks of correspondence afterwards.

The coordinator’s role: run the system

A project coordinator who collects everything from scratch burns out by the second reporting period. The working model looks different: the coordinator sets up the process and then controls how it runs. Specifically, the coordinator owns:

• the reporting calendar, shared across the whole consortium;
• partner roles and templates for regular updates;
• regular check-ins with work package leaders;
• deliverable control and the quality of Part B;
• reconciliation of partner financial statements;
• communication with the Project Officer;
• consistency between Part A, Part B and the financial data.

The coordinator’s job is to build a system where heroic report rescues never become necessary. Managing a grant project with 10+ partners rests on processes, templates and a calendar, so personal heroics stay reserved for genuinely exceptional situations.

KanriFlow: keep reporting in one workspace

Once a project has more than five partners and dozens of reporting elements, Excel and chats stop coping. The reporting calendar lives in one file, deliverable statuses in another, the budget in a third, and the evidence sits scattered across inboxes. Consequently, every update requires manual consolidation.

This is exactly what KanriFlow was built for: a workspace for coordinators of EU-funded projects in Horizon Europe, Erasmus+, Interreg and LIFE. While GetGrant helps you find relevant grant opportunities and prepare a strong proposal, KanriFlow picks the project up after the win. It helps coordinate partners, control deliverables and milestones, run the reporting calendar, track the budget, record risks and prepare for periodic reports without last-week panic.

In practice, this means:

• the coordinator sees which deliverables are approaching and who needs a reminder;
• work package leaders understand their tasks, and partners stop losing deadlines;
• the budget connects to work packages and reporting periods;
• the team records risks as they appear during the period;
• evidence and statuses sit in one place, so the team sees what is ready for reporting and what still needs action.

Checklist: the first 30 days after project start

• create a master calendar for reporting periods, deliverables and milestones;
• assign an owner for every deliverable;
• agree on internal deadlines that come before the official ones;
• build an evidence library structured by WP and period;
• prepare a monthly partner update template;
• hold a kickoff on reporting rules for the whole consortium;
• connect work packages to budget categories;
• open a risk register;
• decide who owns Part B and who controls the financial statements;
• set up a regular status meeting with partners;
• introduce a simple green / yellow / red system for deliverables and risks.

Checklist: 60 days before the periodic report

• check that the continuous reporting data is current;
• update milestone and deliverable statuses;
• collect partner updates using the template;
• verify consistency between WP progress and budget use;
• gather explanations of delays and deviations for Part B;
• review the evidence library for the period;
• draft the Part B narrative and run an internal quality review;
• remind partners about their financial statements and completion dates;
• prepare a list of questions for the Project Officer if complex changes are on the table.

Reporting as a management tool

Good grant reporting gives the team visibility into the real state of the project: what is done, what is delayed, where the risks sit, how the budget moves, and whether the consortium is ready for the next reporting period. So the donor receives a report, and the team receives a management tool.

A strong proposal helps you win the grant. A strong management system helps you deliver it. Build that system in the first 30 days, and every following periodic report becomes a planned event in the team calendar.