Deliverables vs Milestones in Horizon Europe: Define, Track, Report

In Horizon Europe, a deliverable is an output submitted to the granting authority at a scheduled point. A milestone is a control point that charts progress and may correspond to the completion of a key deliverable that allows the next phase of work to begin (HE AGA, Article 21.1, p.213). Deliverables are submitted; milestones are verified. Both are contractual once your Grant Agreement is signed, and both live in your Description of the Action (Annex 1).

The distinction matters at two moments. During proposal writing, evaluators scrutinise your deliverables and milestones in the Implementation section to judge whether your work plan is credible. During implementation, both become the management tools that the consortium and the European Commission use to assess progress against the plan. Confuse the two, or overload your plan with dozens of unnecessary deliverables, and you create avoidable reporting burden for the entire consortium.

This article sets out what each term means, how they connect to work packages and tasks, and how to track and report them through the Continuous Reporting Module on the EU Funding & Tenders Portal. For the authoritative rules, consult the Horizon Europe Work Programme 2025 General Annexes and the full Annotated Grant Agreement (AGA).

What Is the Difference Between a Deliverable and a Milestone?

A deliverable is a distinct output, such as a report, a data management plan, or a prototype, that the consortium submits to the granting authority at a scheduled point. A milestone is a control point that confirms a significant achievement has been reached, allowing the next phase of work to begin. The core distinction is simple: deliverables are submitted, milestones are verified.

According to the Annotated Grant Agreement, milestones are "control points in the action that help to chart progress (kick-off meetings, steering committees, first-draft of a survey, prototype, etc)" and "may correspond to the completion of a key deliverable, which allows the next phase of the work to begin or is needed at intermediary points" (HE AGA, Article 21.1, p.213). The same article describes deliverables as "additional outputs that must be produced at a given moment during the action and submitted to the granting authority", with examples including information, a special report, a technical diagram, a brochure, a list, or a software milestone (HE AGA, Article 21.1, p.213).

Think of it this way. A milestone answers the question "have we reached the point where we can move forward?" It usually has a means of verification, such as a validated dataset or a working prototype. A deliverable answers a different question: "what tangible output must we hand over, and when?" One milestone may depend on several deliverables being completed first. In practice, many coordinators find that a well-designed work plan uses relatively few milestones to mark genuine go/no-go decision points, and reserves deliverables for the outputs the Commission actually needs to monitor the action.

The table below summarises the key attributes of each:

How Do Deliverables and Milestones Fit Into the Work Plan?

Deliverables and milestones sit within the Work Breakdown Structure, attached to work packages and tasks. Each one is assigned to a work package, given a lead beneficiary and a due date expressed as a project month, and, for deliverables, a type and a dissemination level. This structure becomes contractual through Annex 1 of your Grant Agreement.

Every Horizon Europe proposal breaks the project into work packages (WPs) and tasks, with a Gantt chart showing the timeline and interdependencies. Deliverables and milestones anchor that timeline to verifiable points. A typical management work package might include D1.1 Project quality assurance and management plan due in Month 1, while a data-focused work package produces a Data Management Plan (DMP) by Month 6. This reflects the requirement that a more detailed plan for the exploitation and dissemination of results, including communication activities, is normally a mandatory project deliverable, provided within 6 months after grant signature (HE AGA, Article 9.1, p.393).

The DMP deserves particular attention. It is a distinct mandatory deliverable type in Horizon Europe, typically due at Month 6 and updated at later stages of the project.

Each deliverable carries two attributes that shape how it is handled:

• Deliverable type: for example R (document, report), DEC (websites, videos, press releases), DATA, DMP (data management plan), or OTHER (software, prototype, demonstrator). Even when the deliverable is a prototype or demonstrator, you are normally asked to submit a written report describing its characteristics (as confirmed in the EMDESK guide on planning deliverables and milestones, drawing on the Horizon Europe proposal template).
• Dissemination level: PU (public, fully open), SEN (sensitive, limited under the conditions of the Grant Agreement), or EU-classified levels (RESTREINT-UE, CONFIDENTIEL-UE, SECRET-UE), as set out in the Annotated Grant Agreement and illustrated on the Healthy Sailing project deliverables page.

Milestones carry a means of verification instead of a dissemination level. When designing your plan, keep the count proportionate. Enspire Science warns that an "over-the-top" implementation structure with too many deliverables becomes far too difficult to manage once the plan turns into a contractual obligation. A common trap is that a consortium promises dozens of deliverables at proposal stage, then spends the project managing low-value reports. Fewer, meaningful deliverables read as more credible to evaluators and are easier to deliver on time.

How Should You Define Good Deliverables and Milestones?

Define each deliverable and milestone so that it is specific, verifiable, and clearly owned. A good deliverable has an unambiguous output, a single lead beneficiary, a realistic due month, and a stated type and dissemination level. A good milestone marks a genuine decision point with a concrete means of verification, not a vague intention.

Practical rules for deliverables

Each of the five rules below applies directly to what evaluators and project officers check when they review your Annex 1.

1. Name the output, not the activity. "D3.1 Report on ESR Analysis and Methods" tells reviewers exactly what will be handed over, as illustrated by the NCP4HE Horizon Academy project (Grant Agreement No. 101118823), a Horizon Europe-funded action. A title like "Research on the topic" does not.
2. Assign one lead beneficiary. Shared ownership dilutes accountability. Real project deliverables, such as the Project Management Handbook in the EMAI4EU project (funded under the DIGITAL Europe Programme, Grant Agreement No. 101123289), name a single lead partner responsible for producing the document. The same principle applies in Horizon Europe.
3. Set the due date as a project month. Due dates run from the project start, for example M6 or M42, so they stay valid regardless of when the grant actually starts.
4. Match the type to the reality. Mark software and prototypes as OTHER, reports as R, and the data management plan as DMP.
5. Choose the dissemination level deliberately. Only PU deliverables are typically published openly, so decide early which outputs are public and which are sensitive.

Practical rules for milestones

Reserve milestones for the points where the project genuinely stops to check whether it can proceed: a validated methodology before large-scale trials begin, a working prototype before field testing, or ethics clearance before recruitment. Give each milestone a means of verification that anyone can check, such as "signed ethics approval on file" or "prototype passes acceptance test". Milestones that cannot be objectively verified are of little use for steering the project or for demonstrating progress to reviewers.

A practical difficulty arises when the means of verification cannot be met on time. Delayed ethics clearance, for example, can block a milestone and cascade into downstream deliverables. In that situation, log the delay as a critical risk in continuous reporting immediately, agree a revised internal schedule with the affected partner, and discuss a formal amendment with the project officer before the periodic review surfaces the gap.

Because both deliverables and milestones become contractual through Annex 1, changing them later usually requires a formal amendment. Amendments in Horizon Europe are initiated through the Amendments module on the EU Funding & Tenders Portal. The coordinator prepares the amendment request, the granting authority reviews it, and, for changes to the Description of the Action, all beneficiaries must agree (HE AGA, Article 39). This process takes time, so it pays to define deliverables and milestones carefully at proposal stage rather than correct them after signature.

How Do You Track Deliverables and Milestones During the Project?

You track deliverables and milestones through the schedule fixed in Annex 1 and monitored via the Portal Continuous Reporting tool. The coordinator maintains oversight of the whole schedule, chasing due dates and flagging slippage before it affects a payment-linked periodic report.

Tracking is continuous, not periodic. The Annotated Grant Agreement requires beneficiaries to provide regular updates on the status of the action implementation, covering progress in achieving milestones, deliverables, responses to critical risks, and programme-specific indicators such as publications, IPRs, Open Data, training and gender (HE AGA, Article 21.1, p.213). This continuous reporting runs alongside, and is distinct from, the periodic reports that trigger payments.

In practice, an effective tracking routine includes:

• A single master schedule mirroring Annex 1, listing every deliverable and milestone with its WP, lead beneficiary, due month and status. A dedicated project management platform or a shared spreadsheet can keep the consortium aligned.
• Internal deadlines earlier than the contractual due date. Building in a buffer before the Portal due date gives the lead beneficiary time for internal review and the coordinator time for quality control. Given that deadlines are counted in calendar days (HE AGA, Article 38, p.324), even a weekend can consume the margin on a tight schedule.
• A quality-assurance step. Many consortia run a deliverable peer review before submission, so that reports meet the required standard before they reach the Commission.
• Critical-risk monitoring. If a delayed deliverable threatens a downstream milestone, log it as a critical risk and plan mitigation early. A critical risk is a plausible event that could have a high adverse impact on the action's ability to achieve its objectives (HE AGA, Article 21.1, p.213).

Deadlines in Horizon Europe are counted in calendar days, not working days. A period expressed in days starts on the day after the triggering event and ends at midnight on the last day (HE AGA, Article 38, p.324). Missing a deliverable due date by a few days over a weekend still counts as late, so schedule accordingly.

How Do You Report Deliverables and Milestones in the Portal?

You report deliverables and milestones through the Continuous Reporting Module on the EU Funding & Tenders Portal, accessible via the link the coordinator receives at the start of the project. According to the Funding & Tenders Portal Online Manual, each beneficiary is responsible for its own deliverables and milestone reporting, which are submitted to the granting authority through the Portal. Standardised deliverables must use the templates published on the Portal.

Deliverables, including any progress reports not linked to payments, must be submitted through the Portal Continuous Reporting tool, with both the schedule and any templates available through the Deliverables screen (HE AGA, Article 21.1, p.213). The Continuous Reporting Module also handles critical risks, the summary for publication, and programme-specific indicators.

Reporting deliverables and milestones is separate from the periodic report that unlocks payment. The coordinator must submit a periodic report within 60 days following the end of each reporting period, as set out in Article 21.2 and in accordance with the schedule in Point 4.2 of the Data Sheet. The granting authority then makes the interim payment within the timeline set out in Article 22 of the Grant Agreement. Continuous reporting, by contrast, happens throughout the project as each deliverable falls due.

A worked timing example illustrates the day-counting rules (HE AGA, Article 38, p.324). If RP1 runs from 1 March 2022 to 31 August 2023, the 60-day deadline for the first periodic report starts on 1 September 2023 and ends on 30 October 2023. Your continuous deliverables, however, are due on their own individual dates throughout that period, independent of the periodic report deadline.

Some instruments follow their own logic. Under European Research Council (ERC) grants, scientific reporting is separate from periodic financial reporting. For ERC Starting Grants, Consolidator Grants and Advanced Grants, where the usual duration is 60 months, the first scientific report is submitted after 24 months, while the first periodic financial report is submitted after 30 months (HE AGA, Article 3, p.424). For ERC Synergy Grants, where the normal duration is 72 months, scientific reports are expected at months 24, 48 and 72, while periodic financial reports are expected at months 18, 36, 54 and 72 (HE AGA, Article 3.1, p.425). Always check your own Grant Agreement Data Sheet for the exact schedule.

What Happens If a Deliverable Is Late or Poor Quality?

A late deliverable is one submitted after the contractual due date set out in Annex 1; a substandard deliverable is one that does not match the description or quality standard promised there. Both are recorded in continuous reporting and assessed during the periodic review. Persistent non-delivery or poor quality can trigger consequences ranging from a request for correction to grant reduction, suspension or termination.

During a review, the granting authority assesses how resources were used in relation to achieved progress, the management procedures of the action, and, for Horizon Europe, the expected scientific, technological, economic and social impact (HE AGA, Article 30). If a review reveals ineligible costs, substantial errors, irregularities, or serious breach of obligations including improper implementation of the action as described in Annex 1, this may lead to suspension, termination, grant reduction and recovery, and potentially exclusion or financial penalties (HE AGA, Article 30). A review carried out during implementation may also recommend reorientations to the action.

In practice, a modest delay on a single low-risk deliverable rarely triggers formal sanctions on its own. Project officers understand that research does not always run to plan. What draws scrutiny is a pattern: missed deadlines, deliverables that do not match what Annex 1 promised, or a downstream milestone left unmet because upstream work slipped. The way to protect the consortium is to communicate early. Flag the delay in continuous reporting, log the critical risk, and, where the change is structural, discuss an amendment with the project officer rather than let the gap surface for the first time in a periodic review.

How Should Coordinators Manage Deliverables and Milestones Throughout the Project?

For coordinators, the priority is a proportionate plan that is easy to track and defensible under review. Before the kick-off meeting, build a master schedule that mirrors Annex 1 exactly, listing every deliverable and milestone with its WP, lead beneficiary, due month, type and dissemination level, then set internal deadlines ahead of each contractual date to allow quality control.

Concrete recommendations for the implementation phase:

• Audit your deliverable count at proposal stage. If a work package lists more than a handful of deliverables, ask whether each one is genuinely needed for the Commission to monitor progress, or whether it can be merged or dropped. Reviewers reward credible plans, not long ones.
• Distinguish milestones as decision points. Reserve milestones for go/no-go moments and give each a checkable means of verification. If a milestone depends on a deliverable, sequence the due dates so the deliverable lands first.
• Set the dissemination level per deliverable, not per project. Decide which outputs are PU and which are SEN before submission, so your public website can host the open deliverables as they are completed.
• Run a peer-review step before each submission. Assign a quality manager to check every deliverable against Annex 1 before it is uploaded to the Continuous Reporting Module.
• Use one platform for the whole consortium. A shared project management tool keeps every partner reporting against the same schedule and gives the coordinator real-time visibility of what is on track and what is slipping.
• Initiate amendments early. If a deliverable due date or milestone definition needs to change after grant signature, do not wait. Start the amendment process through the Portal Amendments module as soon as the need becomes clear, since negotiating across a consortium takes time.

Consider the following illustrative scenario, constructed using deliverable names from the Social Prescribing EU project as an example. A partner leading D6.2 Prototype of a Digital Tool signals in Month 20 that integration testing is behind schedule and the linked milestone "prototype passes acceptance test" is at risk. The coordinator logs this as a critical risk in continuous reporting, agrees a recovery plan with the partner, and informs the project officer. Because the issue surfaced four months before the due date, the consortium either recovers the timeline or negotiates a due-date amendment before the periodic review, avoiding a finding of improper implementation.

Conclusion and Outlook

The line between deliverables and milestones is not a technicality. It shapes how you design a credible work plan, how you track progress, and how you demonstrate performance to the Commission. Deliverables are the outputs you submit; milestones are the control points you verify. Both are contractual once Annex 1 is signed, both are managed through the Portal Continuous Reporting tool, and both are assessed at periodic review against the plan you proposed.

The most resilient consortia treat continuous reporting as an ongoing discipline rather than a periodic scramble, keep their deliverable count proportionate, and communicate delays early. As the Commission continues to refine its reporting tools and templates on the Funding & Tenders Portal, the underlying logic stays constant: define clearly, track continuously, report on schedule, and never let a missed deliverable be the first thing your project officer hears about your project.

Frequently Asked Questions

Do you submit both deliverables and milestones to the European Commission?

No. Deliverables are submitted to the granting authority through the Portal Continuous Reporting tool. Milestones are control points that each participant verifies internally and reports as achieved. According to the Annotated Grant Agreement (Article 21.1, p.213), deliverables are outputs that must be produced and submitted, while milestones chart progress and may correspond to the completion of a key deliverable that lets the next phase begin. The Funding & Tenders Portal Online Manual confirms that each beneficiary is responsible for its own deliverables and milestone reporting, which are submitted to the granting authority through the Portal.

What are the deliverable dissemination levels in Horizon Europe?

Horizon Europe uses PU (public, fully open), SEN (sensitive, limited under the Grant Agreement), and EU-classified levels, as set out in the Annotated Grant Agreement. Only deliverables marked PU are typically published openly, for example on a project website. You set the dissemination level per deliverable, not for the whole project.

How are deliverable and report deadlines counted in Horizon Europe?

Deadlines are counted in calendar days, not working days. A period expressed in days starts on the day following the triggering event and ends at midnight of the last day (HE AGA, Article 38, p.324). For example, a 60-day periodic report deadline after a reporting period ending 31 August 2023 starts on 1 September and ends on 30 October 2023.

How many deliverables should a Horizon Europe proposal include?

There is no fixed number, but a proportionate count is essential. Keeping deliverables to those the Commission genuinely needs to monitor progress is best practice. Overloading a work plan with low-value deliverables becomes a contractual burden once the grant is signed, as Enspire Science notes in its guidance on Horizon Europe implementation structures. A leaner set of specific, verifiable deliverables reads as more credible to evaluators and is easier to deliver on time.

Where do you report milestones and deliverables during a Horizon Europe project?

You report them through the Continuous Reporting Module on the EU Funding & Tenders Portal, accessible via the link the coordinator receives at project start. According to the Funding & Tenders Portal Online Manual, each beneficiary is responsible for its own deliverables, which are submitted to the granting authority through the Portal, following the schedule in Annex 1. Standardised deliverables must use the templates published on the Portal Deliverables screen (HE AGA, Article 21.1, p.213).