Meta title: Which documents should you prepare for Pronovo? Useful evidence and supporting files
Meta description: Build a coherent Pronovo file: required documents, technical evidence, administrative proofs, how the list changes with project stage, and what to check before submission.
There is no single document list that applies to every Pronovo file. The pieces you need depend on the programme, the applicable category, the type of installation, its power, the relevant project date and the stage you are at when you submit. For the broader framework, start with the dedicated Pronovo page.
What documents do you need to prepare for a Pronovo file?
You need a common core, then the evidence specific to the category you are applying under. In practice, Pronovo looks at project identification, technical characteristics and administrative proof. The correct list therefore depends on the programme, the installation type, its capacity and the moment you submit.
According to the logic set out on Pronovo’s official website, in its client portal and in the related request forms, a file is generally built around three document families: project identification documents, technical documents and administrative proofs. The first family connects the request to a concrete installation: address, location, basic file data and request category. The second shows what is actually built, ordered or commissioned, depending on the project stage. The third proves who is submitting, on whose behalf and under what authority.
The key practical rule is simple: each document must answer a requested proof, not just make the file look complete. A plan, invoice, certificate, schematic or form extract only has value if it matches the exact question asked by the Pronovo portal. The most common edge case is a project that changed between preparation and submission: capacity extension, change of operator, new correspondence address or a technical variant that was ultimately installed. In that case, the document set has to be rebuilt from the final version of the project, not from older files.
If you first need to check whether you are the right person to submit, or whether the applicant can be the owner, operator or a representative depending on the case, see also who can apply for Pronovo. For a broader view that is not focused on documents, keep the main Pronovo page as your reference point.
Subsidy simulator
Move from reading to a concrete simulation
We prefill the simulator with the useful context from this page so you can move faster and check the subsidies that fit your situation.
Why does the list depend on the project stage?
The list changes because a project does not have the same evidence available before filing, during review and after completion. Some documents only exist once the installation is finished or connected to the grid. Others are needed as soon as the file is opened. The right approach is therefore to think in terms of project stage, not document habit.
On Pronovo’s official pages and in the way its portal works, the logic is clearly sequenced: some information is used to announce or register a request, some to confirm completion, and some to complete a file when Pronovo asks for additional evidence. That is why a document that is useful today can be insufficient tomorrow, or useless too early. In practice, if your application is filed before the installation is finished, you will not yet have the same evidence as for a project already in service. Conversely, if filing takes place after completion, Pronovo may expect proof that the final configuration matches what was declared.
The edge case appears when the project timeline and the submission timeline do not line up neatly: for example, a project prepared on one technical assumption and submitted after a modification, or a file opened before all final documents exist. In that situation, you need to check whether the category, decisive date or expected evidence has changed in the meantime. That is exactly why document preparation must be tied to the right filing moment. For this, when to submit a Pronovo application is the logical companion article: it explains when certain proofs must already be available and when they do not yet exist.
Which technical documents must be aligned before submission?
Before you submit, the technical documents must tell exactly the same story. Same address, same declared power, same installation layout, same relevant date and the same equipment if the procedure requires them. Technical consistency often matters more than the number of files, because Pronovo checks alignment first and detail second.
Pronovo’s directives, forms and technical evidence requests are designed to verify that the declared installation corresponds to an identifiable reality. This includes power data, installation type, location, declared components when required, and the documents that describe the final build or configuration. The essential practical condition is to unify your source data before you even open the portal: if the power on a plan does not match the figure entered in the form, or if the site name varies from one document to another, the file becomes inconsistent even when each individual document looks correct.
The classic edge case concerns projects that changed along the way: added modules, inverter replacement, extension of an existing installation, or several generators on the same site. In these situations, it is not enough to add the latest document you received from the installer. You need to check which exact configuration the Pronovo request is about and make sure every technical document describes that same version. If you want to reduce the risk that a technical mismatch is treated as a substantive error, how to avoid a Pronovo rejection is the useful next step.
Which administrative proofs most often cause blocks?
Administrative blocks rarely come from one missing paper alone. They usually appear when the applicant’s identity, right to act, file contact details and attachments do not match. A file can look complete and still be blocked if Pronovo cannot clearly connect the request to the right person, the right site and the right role.
Pronovo’s official material shows that administrative data is not secondary: it is used to identify the applicant, the owner or the operator depending on the procedure, as well as the effective contact for the file. In practice, delays often come from a very simple issue: the name in the portal is not the one shown on other documents, the mandate is unclear, the official address differs from the one used elsewhere, or the file was prepared by an installer while the formal applicant is someone else. When Pronovo expects proof of representation, ownership, operation or standing under the relevant category, that proof must be clear, current and fully aligned with the rest of the file.
The edge case is common in co-ownership, condominium ownership, companies that have changed their legal name, files submitted by a third party, or cases where the building owner is not the operator requesting the support. In that context, checking who can apply for Pronovo often helps identify the right administrative proof before submission. And if your main concern is rejection because of inconsistency or unsuitable evidence, you can also review how to avoid a Pronovo rejection.
How should you organise documents to avoid an inconsistent file?
Good organisation is not about storing every file in one folder. It is about matching each document to a specific proof expected by Pronovo. Organising by family, version and date helps avoid invisible contradictions. File consistency often depends on order, naming and readability as much as on content.
Pronovo’s portal and official forms call for attachments with distinct purposes. In practice, your structure should reproduce that logic. It is useful to separate project identification documents, technical documents, administrative proofs and any follow-up exchanges. That makes it easier, before submission, to check that nothing is being used as a substitute for something else. A file named “final.pdf” is not very helpful when you are trying to verify completeness; a clear name that indicates the document purpose, the site concerned and the version reduces the risk of uploading the wrong attachment.
The edge case appears when several versions exist at the same time: an old offer, an updated schematic, a new certificate, a re-signed document or a corrected file after a request for further evidence. Without a clear system, the wrong version can easily end up in the portal. A simple method is to keep only one “to submit” version for each requested proof, while archiving replaced versions separately. If you need to return to the broader programme framework before rebuilding your file, the Pronovo page remains the central anchor.
What should you check before opening the portal or submitting?
Before you open the portal or submit, check that you know the correct request category, that the right applicant is filing, that the available documents match the project stage and that every copied detail is identical from one document to another. The final check is less about adding files than about removing contradictions.
Pronovo’s official instructions, the client portal and the procedural documents all point in the same direction: an admissible file is a readable, coherent file that matches the request actually being filed. The practical requirement is to do a cross-check before the final entry. Verify names, addresses, power, category, important dates and the applicant’s role. Also make sure every attachment answers a requested proof and that no document still depends on a future event that has not happened yet. If the availability of a document depends on the project calendar, that needs to be acknowledged explicitly, and the submission timing should be adjusted rather than compensated for with approximate attachments.
The most underestimated edge case is a file prepared well in advance and then submitted after the documents, the project or the procedure have evolved. Between file opening and submission, some fields may have been completed based on an older version of the project. That is why it is worth repeating a cross-check just before sending, first with when to submit a Pronovo application for timing, then with how to avoid a Pronovo rejection for file quality. If those two pages match your documents, you greatly reduce the risk of an incomplete or contradictory file.
What are the most common questions?
The same few questions come up again and again, because the file rules depend on the project stage, the request category and the applicant’s role. The answers below summarise the practical points that most often determine whether a Pronovo file is ready to go or still needs adjustment.
Is the Pronovo document list the same for every project?
No. The list depends on the request category, the installation type, the power level, the relevant project date and the stage of the file. An installation that is already complete does not have the same evidence available as a project still in preparation.
Do you need all technical documents from the start?
Not necessarily. Some technical documents only exist after completion or at a more advanced stage. You therefore need to distinguish between documents required when the file opens and those requested at the confirmation, follow-up or final submission stage.
Which administrative proofs cause the most delays?
Delays usually come from inconsistencies in identity and role: a poorly identified applicant, an unclear mandate, diverging contact details or uncertainty about who is entitled to submit under the procedure. These are often consistency blocks rather than a total absence of documents.
Can you submit an incomplete file and add documents later?
That depends on the procedure, the project stage and what Pronovo already expects as proof at the time of submission. If a document is not yet available because it depends on the calendar, you should first check whether the correct submission moment is later. Submitting too early with approximate attachments can make processing harder.
How should you organise the documents before sending them?
The safest approach is to group documents by proof family: project identification, technical documents, administrative proofs, then any follow-up material. Each file should have a clear name and an identifiable final version so that an older document does not get uploaded instead of the correct one.
Which official sources support this approach?
The article’s logic follows Pronovo’s official operating framework: the website, client portal and procedural forms do not treat the file as a random bundle of attachments, but as a structured set of proofs that must match the request, the project and the stage of submission. When a requirement depends on official rules, the correct source is always the relevant Pronovo document or the applicable federal framework.
- Pronovo AG — official website and client portal: general information on requests, forms, attachments and procedures: <https://pronovo.ch/en/>
- Pronovo AG — forms, directives and procedural documents: available through the official Pronovo sections according to the programme and request category.
- Fedlex — applicable federal legal bases: official texts useful when the category, date or procedure depends on the regulatory framework: <https://www.fedlex.admin.ch/>