Grants for Companies: Avoiding Formal Errors

What grants are and why the formal side of an application decides the outcome#

Grants are public co-financing that a company receives for a predefined project and, unlike a loan, does not repay if it meets the conditions of the call and spends the funds for their intended purpose. Whether a company receives the funds is often decided not by the quality of the idea, but by whether the application was submitted exactly as the call documentation requires. Evaluators first check the formal completeness of the application and only then its content, so a technically excellent project can fail before it is ever assessed on merit.

The formal check is a separate step from the content evaluation. It verifies whether all required attachments are included, whether the data in the application matches the data in the attachments, whether the beneficiary is defined in line with the call's conditions, and whether the application was submitted in the prescribed format. A single inconsistency, for example a difference between the project description in the form and in the technical specification, can be grounds for rejection regardless of how well the project is otherwise designed.

For a company this means that preparing an application is not merely an administrative task, but part of project management. Whoever drafts the documentation must understand both the call's conditions and the technical substance of the project, otherwise gaps appear between what is promised and what is actually feasible. In projects involving information systems, this most often shows up in the description of scope, architecture, and integrations, where the application's author and the contractor who will actually deliver the project need to work together.

The formal errors that keep recurring in applications#

Most formal rejections come from errors that could have been checked and fixed before submission, but companies overlook them because the application is prepared under time pressure or without coordination across departments. These are not content errors but mismatches between forms, attachments, and the actual state of the company, which is exactly why evaluators catch them quickly and consistently.

Each of these errors looks minor on its own, but in a formal review it counts the same as a substantive shortcoming. Calls are designed so the review is consistent and equal for every applicant, so evaluators have no room to interpret intent when a document formally fails to meet a requirement. A company that treats the application as a purely administrative exercise, without insight into the project's technical feasibility, is the one most exposed to these errors.

For a company this means it is worth reviewing the application separately from drafting it — someone who did not write it should check consistency between the form, the attachments, and the call documentation. In projects involving an information system, this review should also involve the contractor who will deliver the project, since they can judge whether the described solution is technically feasible in the scope and manner stated in the application.

• A mismatch between the project description in the application form and in the technical or financial attachment.
• A missing or invalid attachment, such as a declaration, consent, or proof of company status.
• An incorrectly defined scope of eligible costs relative to the activity the company is applying under.
• Inconsistency between the indicators stated in the application and those the company will actually be able to measure afterward.
• An unclear or incomplete description of the technical solution in projects involving an information system or digitalization.
• Submission after the deadline or in a file format that does not meet the call's published technical requirements.

Why technical documentation is critical for IT and digitalization projects#

In projects that involve a new information system, an upgrade of an existing one, or connecting several systems, the formal assessment is not limited to the financial part of the application. Evaluators, and later auditors, also check whether the technical description matches what was actually delivered, so the documentation must be precise already at the application stage, not only by the project's end.

Technical documentation must describe which systems are connected, where the data resides, who processes it, and how traceability of changes is ensured. If the application states that the system will connect to an existing ERP or CRM environment, that integration must actually be realized and documented during delivery, otherwise a gap opens between the approved and the delivered project — one of the more common reasons for later corrections to reports under public co-financing.

For the client this means the technical part of the application must be written together with a contractor who understands the project from an architectural standpoint, not just from a business summary. Inconsistencies between the applied-for and the delivered scope tend to surface only at interim or final reporting, when they are harder to fix than they would have been had the scope been precisely defined before submission.

How to define project scope so it matches the call's conditions#

Project scope must be defined so that each part is individually understandable, measurable, and deliverable, since calls typically require a clear line between what is subject to co-financing and what is not. A vaguely drawn line — say, between developing a new module and maintaining an existing system — is a common source of evaluator questions or later rejection of a specific cost item.

Splitting the project into clearly defined segments makes both the application and later reporting easier, since the company can demonstrate delivery segment by segment rather than having to prove the entire project as one indivisible whole. This approach matters most when a project spans several technical areas, such as system development, integration with existing tools, and rollout at the client's site.

For the company this means aligning scope with the contractor before submitting the application, not only after the funds are approved. A contractor able to take on the project in full or as an individual segment can more easily judge which parts form a technically self-contained whole and which depend on other systems — which directly affects how precisely the scope can be described in the application.

The contractor's role in drafting the technical part of the application#

When a project involves an information system, bringing the contractor in already at the drafting stage — not only after approval — is one of the few real safeguards against formal errors in the technical section. A contractor familiar with the client's existing systems can judge whether the proposed solution is feasible within the stated scope and whether the description matches the architecture that will actually be built.

Involving the contractor at this stage reduces the risk of an application that reads well but turns out technically unworkable in the proposed form — something that often surfaces only during delivery, when reconciling a scope change against the approved application is harder. On larger projects, this stage also fixes who the project manager is, responsible for keeping delivery aligned with the approved documentation throughout.

For the client this means choosing a contractor is not only about who will build the system, but who can break the project into segments that can be applied for, delivered, and proven individually. This matters especially when taking over an existing or unfinished system, where source code, architecture, and the state of the data must be reviewed before the scope can even be defined.

• Reviewing existing systems, architecture, infrastructure, and data before defining the scope of the new project.
• Splitting the project into segments that are each technically self-contained and demonstrable.
• Defining responsibilities, deadlines, and reporting between client and contractor.
• Drafting a technical description that matches the actual architecture, not just a business summary of the project.
• Defining which documentation, access, and passwords are part of the final handover.

Data security compliance and audit-trail requirements#

Projects co-financed from public funds are typically subject to later audit, so traceability of changes, separation of environments, and proper handling of data must be in place already during delivery. This is not only a question of data-protection compliance, but also proof that the project was carried out as applied for and approved.

In practice this means development, test, and production environments are kept separate, real personal data is not used in the test environment, and every change goes through review and testing before it reaches production. Such separation is not only a security measure but also part of demonstrating that the system was built and tested under control — a point audits of co-financed projects frequently examine.

For the client this means that already at the application stage it must be decided how data processing will be documented, who will have access to the system, and how traceability of changes will be maintained throughout the project. A contractor who treats this as a standard way of working, not an extra requirement, reduces the risk that a post-project audit uncovers a gap between what was applied for and what actually exists.

What follows approval: delivery, reporting, and the audit trail#

Approval of an application does not mark the end of formal requirements — it marks the start of a period in which delivery must track the approved documentation. Any substantive change of scope, such as extra functionality or a different integration, must be agreed and documented, otherwise a gap can appear at reporting time between what was approved and what was actually delivered.

Companies often underestimate how much documentation must be produced during delivery, not only at the project's close. Interim reports, evidence of completed activities, and technical system documentation must stay aligned with the approved application throughout the project's duration, rather than being assembled retrospectively when the final report is due.

For the client this means deciding, already at the start of delivery, who is responsible for keeping technical execution aligned with reporting to the competent authority. On larger projects a project manager takes on this role, tracking both technical progress and compliance with the approved documentation, which reduces the risk of a gap surfacing only at the final review.

Taking over existing or unfinished systems within co-financed projects#

Many co-financed projects do not mean building a system from scratch, but upgrading, completing, or connecting a system the company already developed in-house or with another contractor. Formal risk is higher here, since the application must precisely describe what already exists and what is subject to new funding — otherwise evaluators may doubt whether they are looking at a new project or funding for work already done.

Before scope can be defined, the source code, architecture, infrastructure, and state of the data in the existing system must be reviewed, since only that review makes it possible to precisely separate what counts as an upgrade from what counts as new development. Without it, the application risks describing a scope that turns out to be technically different during delivery, requiring later reconciliation with the competent authority.

For the client this means it is worth involving the contractor before the application is submitted, not only after funds are approved, since only then can the contractor accurately assess what is technically feasible within the applied-for scope and what would require additional development that was never part of the application.

How to choose a contractor for the IT part of a publicly funded project#

Choosing a contractor for the technical part of a co-financed project is not the same as choosing one for an ordinary development project, since the contractor must also understand how technical documentation ties into the call's requirements and later reporting. This is not only a question of development capability, but of the ability to work in clearly defined, demonstrable segments.

Before choosing a contractor, a company should check whether they understand the difference between a business description of a project and the technical documentation that evaluators and later auditors will review. A contractor used to producing documentation only for their own purposes does not necessarily know what public co-financing requires in terms of traceability, environment separation, and evidence of completed activities.

For the client, the final judgment rests on whether the contractor can break the project into segments that can each be defined, delivered, and proven individually, and whether they are willing to take responsibility for keeping the approved documentation and the actual delivery aligned throughout the project's duration.

• The ability to produce technical documentation that satisfies both the call's requirements and the actual architecture.
• Experience taking over existing or unfinished systems after reviewing code and infrastructure.
• Separate development, test, and production environments and a controlled process for rolling out changes.
• A clear definition of project management, responsibilities, deadlines, and reporting.
• Willingness to take on the project in full or as an individual, separately demonstrable segment.
• A clear definition of which documentation, access, and data form part of the final handover.

Ownership of code, data, and documentation after project close#

After a co-financed project closes, it often turns out that ownership of the source code, data, and documentation was never clearly settled at the start, which can complicate both audit and later maintenance of the system. A clear statement that source code and data belong to the client must be part of the agreement with the contractor before delivery even begins, not only at handover.

Handover at project close must include not just a working system, but complete documentation and all access and passwords needed to run the system independently or move to another contractor. An incomplete handover is a common source of trouble at later audits, since the competent authority may ask for proof that the client actually received everything the application defined as the project's result.

For the client this means it is worth setting the terms of handover — documentation, access, ownership of code and data — in the contract with the contractor already alongside preparing the application, not only after the project ends. That way, every element the call requires as proof of delivery is actually on hand when it needs to be submitted to the competent authority.