EU-funded software: from the offer to reimbursement

In an ordinary project, an app is done when it works and the client is happy. In an EU-funded project there is one more step: the app is done only once it has been accepted, checked and reimbursed. And between “it works” and “reimbursed” there is a lot of paperwork, deadlines and checks.

In our experience, projects don’t lose money because the software doesn’t work. They lose money because the deliverables don’t match exactly what was written in the funding application, because a document is missing at acceptance or because a deadline was missed. Here is what the software side of such a project looks like in Romania, from start to finish.

It all starts with the funding application#

The technical solution described in the funding application becomes, once approved, a commitment. Exactly those deliverables will be checked at the end, point by point.

That’s why the description has to be balanced:

• too vague (“modern online platform”), and at the check nobody can prove what was promised and what was delivered;
• too detailed (the name of a library, a specific version), and any natural technical change becomes a deviation from the project;
• unrealistic in its timeline, and the schedule breaks in the first months.

We work together with the consultant who writes the project: we describe the technical solution, the features, the deliverables and the timeline, while they handle the administrative side. That way, what is promised is also what can be delivered.

Procurement: the specifications and the offer#

Private beneficiaries can’t choose a supplier however they like. Procurement follows a competitive procedure, with a notice published on the beneficiar.fonduri-ue.ro portal, technical specifications and clear award criteria¹.

The tender specifications must faithfully reflect the solution in the funding application. The offer, in turn, must answer the specifications point by point, with the required declarations (for example, the one on compliance with the DNSH principle). An offer that “broadly covers” the requirements can later become grounds for a financial correction.

Deliverables: what is handed over, specifically#

At the end, the beneficiary must be able to show what they received. For the software side, this usually means:

Each row has to link to a point in the funding application and the tender specifications. If a deliverable can’t be shown, for the auditor it doesn’t exist.

Stages, reports and acceptance#

A funded software project is split into stages, each with its deliverables and deadline. At the end of each stage comes:

1. The stage completion report. What was done, how it can be checked and the evidence: screenshots, documents, access to the test environment.
2. Review by the beneficiary. The beneficiary tests and flags anything that doesn’t match. Fixes are made before acceptance, not after.
3. The stage acceptance report. Signed by both parties, it confirms that the stage’s deliverables were accepted.
4. The stage invoice. Issued on the basis of the acceptance report, with the details required by the programme, so it can go into the payment or reimbursement claim.

At the end, the final acceptance report confirms that everything promised was delivered. Together with the stage reports, it forms the file the beneficiary uses for reimbursement claims and checks.

Deadlines aren’t a suggestion#

The implementation period is set in the funding contract. Expenses incurred after the deadline may become ineligible, and an extension usually means an addendum, with justifications and approvals.

That’s why the timeline has to be realistic from the funding application onwards and include a buffer for acceptance and fixes. We plan the stages so that the last acceptance is done well before the end of the implementation period, not in the final week.

DNSH for software, in plain terms#

The “Do No Significant Harm” (DNSH) principle requires that the project doesn’t significantly harm any of the EU’s six environmental objectives: climate change mitigation, climate change adaptation, water, the circular economy, pollution and biodiversity².

For an app, this translates into concrete things:

• efficient hosting: data centers running on renewable energy, with low consumption. For example, Hetzner, where we host, powers its German data centers with hydropower³;
• correctly sized servers: neither oversized nor undersized, so they don’t consume for nothing;
• efficient code: light pages, optimized queries, no processes running needlessly;
• energy-efficient equipment, with a recycling plan at end of life (WEEE);
• documenting these choices, so the beneficiary can prove compliance at the check.

Visibility of the funding#

Funded projects must publicly show the support received, following the programme’s visual identity manual⁴. Besides posters and stickers, this usually also means a page dedicated to the project on the beneficiary’s website, with its description and the funding statement.

When the website or app is itself the project’s deliverable, we include these elements from the start, in the form required by the programme.

Warranty and the durability period#

The project doesn’t end with the final payment. Next comes the durability period: as a rule, 5 years from the final payment, which may be reduced to 3 years for SMEs, as set out in the funding contract⁵. During this time the investment must remain in operation, and the beneficiary reports periodically.

For software, this means the app has to keep working for years: security updates, backups, compatibility with new browser and operating system versions. On EU-funded projects we offer at least the warranty required in the tender specifications, and we stay on with maintenance throughout the durability period.

The mistakes that cost money at reimbursement#

• deliverables that don’t exactly match the funding application or the tender specifications;
• changes made along the way without being approved and documented;
• missing or unsigned acceptance reports, or ones with data that doesn’t match the invoices;
• invoices without the details required by the programme;
• no evidence that the app works and is being used;
• missed deadlines, without an addendum;
• missing DNSH documentation or visibility elements;
• an app that stops working during the durability period.

Almost all of them are avoided the same way: with a supplier who knows from the start that they are delivering not just software, but also the proof that the software was delivered.

We have worked on EU-funded digitalization projects, from simple business websites to complex SaaS platforms. If you are preparing such a project, we can help from the funding application onwards. And if the project interests us and we’d like to take part in the tender, we help you with the documentation free of charge.

See how we work on EU-funded projects

Cover image: almathias, Wikimedia Commons (CC0)