EU Project Deliverables and Reporting: What You Actually Have to Produce

Munich, 28 September 2026 · Nexuswelt Group

Almost everything written about EU funding stops at the moment of award. What happens afterwards – what you have to produce, when, in what system, and who submits it – is learned by most partners in the week before the first deadline.

It is not complicated, but it has specific mechanics that are easy to get wrong and awkward to fix retrospectively. This is the practical account: the two reporting systems, the difference between deliverables and milestones, how deadlines are counted, and the choices made at proposal stage that you live with for the project’s duration.

The relationship between the two is the thing to understand. Continuous reporting is not a preliminary to periodic reporting – it becomes part of it. A consortium that neglects the continuous module all period then faces a periodic report whose Part A is empty and whose evidence has to be reconstructed.

Deliverables and milestones are not the same thing

A useful way to hold it: the milestone is the checkpoint, the deliverable is the thing that passes through it. Both are contractual obligations set out in Annex 1 to the grant agreement – the Description of Action –  with the dates you proposed and the Commission accepted.

Dissemination levels: a proposal-stage choice you live with

Every deliverable carries a dissemination level, set per deliverable rather than for the project as a whole:

• PU – public, fully open. These are the deliverables typically published on a project website.
• SEN – sensitive, with access limited under the conditions of the grant agreement.
• EU-classified levels – RESTREINT-UE, CONFIDENTIEL-UE and SECRET-UE, for the small number of cases where they apply.

The level is pre-set from your proposal. It can be modified during grant agreement preparation, but once the project has started, changing it is considerably harder. This is worth ten minutes of attention at proposal stage: marking a deliverable public that will contain commercially sensitive detail creates a problem two years later that is easier to avoid than to solve.

The reporting period rhythm

Projects are divided into reporting periods, typically of twelve or eighteen months, which do not necessarily align with calendar years. The number is fixed during grant preparation and depends on duration: projects of roughly two to three years usually have two periods, three and a half to four years three, and five years four.

One constraint worth planning around: pre-financing together with interim payments may not exceed 90% of the maximum EU contribution during the project. The balance follows the final report, which is a cash-flow fact rather than a reporting detail.

What is actually in a periodic report

Technical report, Part A

Generated automatically by the system from the data you entered into continuous reporting: deliverables, milestones, publications, dissemination activities, project indicators. You do not write it – you cause it to exist by maintaining the continuous module.

Technical report, Part B

The narrative, uploaded as a PDF using the official template. It describes the work carried out per work package during the period, explains deviations from the Description of Action, and includes a publishable summary. Deviations, delays and objectives or deliverables not fully achieved need explanation with consequences and proposed corrective action – this is where a report is judged, not in the description of what went to plan.

Avoid duplicating Part A. Reference it instead. Reviewers read both, and repetition makes a report longer without making it more informative.

Financial report

Individual financial statements per beneficiary, generated by the system from the financial data entered, with a payment request. Note that the Commission does not check every cost for eligibility – that responsibility remains with the beneficiary – but subcontracting costs are examined closely against what the grant agreement foresaw.

How deadlines are actually counted

Two mechanics that catch people out:

• Periods expressed in days are calendar days, not working days. The count starts the day after the triggering event and ends at midnight on the last day. A period ending 31 August produces a 60-day deadline of 30 October.
• A deliverable due in month six is due on the last day of that month. If month six is June, the deadline is 30 June – not the start of the month, and not a date the consortium chooses.

If a deliverable due within a reporting period has not been submitted, the delay has to be justified in the report before it is locked for review. Deliverables carry a status – submitted, approved or rejected – and rejection means revision rather than a failed project, provided it is handled promptly.

The deliverable count trap

This one is created at proposal stage and paid for over several years.

A consortium writing a proposal wants to look thorough, so it promises deliverables generously – one per task, sometimes more. Once the grant is signed, every one of those is a contractual obligation with a date, an owner, a dissemination level and a place in the reporting system.

There is no required number. Keep deliverables to what the Commission genuinely needs in order to monitor progress. An over-specified work plan is a burden that grows heavier each reporting period, and it produces low-value documents that nobody reads and everybody has to write.

The same discipline matters when planning deliverables for communication and dissemination: each one should have a clear purpose, owner and useful output.

What goes wrong

• The continuous module is left empty until the periodic report activates, at which point Part A is blank and the evidence has to be reconstructed.
• Partners assume they can submit. They can upload; only the coordinator submits, and a coordinator discovering this at hour eleven has a bad two days.
• Deliverable due dates are read as approximate. They are contractual and dated to the end of the month.
• Deviations are omitted rather than explained. A reported and explained deviation is normal project life; an unreported one found by a reviewer is a different conversation.
• Part B duplicates Part A, producing length without substance.
• Dissemination levels are set carelessly at proposal stage and become awkward once results have commercial value. The dissemination level should also be consistent with the project’s wider approach to dissemination and exploitation.
• Nobody accounts for the review period. Approval of the periodic report is a precondition for payment, and review takes a further two to three months after submission.

What changes under lump sum funding

Under lump sum funding, there is no reporting of actual costs and no financial audit of the resources used , which removes the financial reconciliation layer entirely. Technical reporting remains, and payment is tied to the completion of work packages rather than costs incurred.

The practical consequence is that completion evidence becomes more important, not less. A work package declared complete needs to be demonstrably complete against the activities described in the project description – which makes deliverable and milestone design a financial matter as well as a planning one.

A system that works

1. Set up the evidence collection in month one and run it continuously, even when nothing is due.
2. Assign one person per partner responsible for uploading, with a named backup.
3. Set internal deadlines ten to fifteen days before official ones. Partner corrections always take longer than expected.
4. Review deliverable due dates quarterly against actual progress, so delays are known before they are late.
5. Keep a running note of deviations as they occur, with the reason. Reconstructing this at reporting time is difficult and visibly reconstructed.
6. Check dissemination levels once at grant preparation, while they can still be changed.
7. Plan cash flow around review time, not submission time.

How Nexuswelt supports project teams

Nexuswelt contributes to EU-funded projects as a partner on communication, dissemination, stakeholder engagement and exploitation – which means producing deliverables in the reporting system rather than advising about it from outside. The companion article on the first twelve months of coordination is our guide to managing a multi-partner consortium, and more on the firm is on the Nexuswelt about page.