Custom software for KOMO certificates and attestations applied in projects
A KOMO attestation describes the performance of a construction product in its application, and it does so under conditions. That is where the work lies. The question is not whether a product has a declaration, but whether what happens with it on this project falls within the conditions under which that performance was established.
What a declaration does and does not say
A KOMO product certificate confirms that the product conforms to the technical specification in the certificate and meets the stated requirements. A KOMO attestation goes a step further and describes the performance of a construction product, building element or building system in its application. There is also the attestation-with-product-certificate and the process certificate. Quality declaration is the collective term for all of these documents.
An attestation contains the technical specification, the building parts in which the product may be applied, the performance requirements, the performance in application, the application conditions and the processing guidelines. The assessment is a one-off type assessment that is repeated at least every five years. Products with an attestation alone may not carry the KOMO mark.
Two things from this are immediately relevant on the construction site. Verification on site remains necessary to confirm that the delivered product matches the specification and that the application conditions have been met. A declaration in a folder does not take over that check.
In addition, the underlying regulations are changing. Certification bodies issue attestations under the Building Activities Decree (Besluit bouwwerken leefomgeving) from its entry into force, and for attestations-with-product-certificate and process certificates, conversion to that regime is mandatory. A declaration from an older series therefore does not automatically say what you think it says.
How we build this
The essence is the application. Not the product and not the certificate, but the combination: this product, in this building part, on this project, on this date.
Certificate, attestation or both, with the number, the issuing body and the validity period as they appear on the document.
Where the product has been applied and in which building part. This determines whether the attestation covers the situation.
The application conditions and processing guidelines from the attestation are set as checkpoints for that application.
Not whether a declaration is valid now, but whether it was valid at the moment of application. That is the question that comes back later.
What the software actually does
The integration between application and certificate carries the whole. What else you need depends on your role and on the number of projects running at the same time.
Declaration per applied product
This document covers which product, with its number and setting. Not one folder per project, but one line per application.
Distinguishing between types
A product certificate says something different from an attest. The system shows which type you hold and what it does and does not cover.
Application conditions as checkpoints
The conditions in the attest become points that someone signs off, rather than text that nobody opens.
Validity on the date of application
Expired declarations are rarely the problem. Declarations that had already expired by the date of construction are.
Reassessments tracked
An attest is reassessed at least every five years. The system shows which declaration is due for that deadline.
File per project
What was applied, with which declaration and which sign-off, in the form a client or inspector asks for.
Who we build for
Who asks for this varies by project. Four situations.
Contractors
They apply it and must afterwards show on what basis. Often with suppliers who also change.
Clients
They want to know whether what was delivered matches what was agreed, without having to go through the documents themselves.
Quality assessors
For them the question is not whether there is a declaration, but whether the application falls within its conditions.
Building supervision
They assess the file and benefit from an overview that shows the path from product to declaration.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Technology and integrations
Declarations are renewed, regulations shift and products are replaced by successors. Document types, conditions and checkpoints should be configurable and not hard-coded.
Why Appfront
Having a declaration is not the same as meeting it
The attest applies under conditions. We translate those conditions into points that someone signs off.
The date of application counts
Not whether a declaration is valid today, but whether it was valid when the product went into the façade.
On-site verification remains necessary
A document does not take over on-site inspection. We build that inspection into the trail rather than alongside it.
We do not assess your building
The judgement remains with your quality assurer and the competent authority. We make sure the file underneath it is correct.
Security and privacy
A project file contains supplier details, prices in appendices and the names of the people who signed off. Not all of that should reach everyone. We set up access per role and per project, give a client insight into the accountability without your full procurement file, and log who has viewed what. Integrations run through secure connections to your existing software.
For this subject, the reliability of the moment is the point. A sign-off added after handover is no longer evidence in the event of a defect. We record sign-offs immutably with time and person, and a correction becomes a visible correction alongside the original entry. How we handle security ourselves is set out in our information security policy.
Frequently asked questions about KOMO declarations in projects
A product certificate declares that the product conforms to the technical specification and meets the stated requirements. An attest describes the performance of the product, element or system in its application, under the application conditions established for it.
The technical specification, the building parts in which the product can be applied, the performance requirements, the performance in application, the application conditions and the processing guidelines.
The assessment is a one-off type assessment that must be repeated at least every five years. In addition, declarations have been converted to the Besluit bouwwerken leefomgeving, so an old declaration does not necessarily mean the same thing.
No. Products for which only an attest has been issued may not bear the KOMO mark or logo. This is a common misunderstanding on the building site.
On-site verification is still needed to confirm that the delivered product matches the specification and that the conditions of application have been met. We describe that check on our page about the KOMO app for the building site.
No. This is about application and accountability. We describe the production file under your own assessment guideline on our page about certificate management and BRL files.
Was the declaration valid on the day you applied it?
Pick one product from last year's project and find its certificate, with the validity on the day of application and the conditions that applied. If that takes half a day, a defect will cost you more. We build this as a standalone application and as part of a wider custom software development project.