Where the starting point on the previous page got stuck — buying a tool over an organised process — this is where the real work begins: organising the process itself, before a system is built around it. What that involves and what it precisely is, is set out on What it is. Below are the steps, in order, with what each step requires and delivers.
What you provide: an idea of which topics are material, or nothing yet — in which case esgia's double materiality assessment is a logical starting point.
What happens: the tool converts the chosen topics into a work list. This can be done all at once for all material topics, or topic by topic — CO2 first is a common order, because most organisations already have fragments of data on that lying around.
Duration and involvement: this is a matter of making choices, not calculation work. One person with an overview of the reporting scope can do this alone; no team is needed.
What you provide: the topics chosen in step 1.
What happens: the register generator lists the data points required for that — what is needed according to the standard, broken down per topic. This is a mechanical derivation from recorded datasets, not an estimate. The result is a list, not a judgement about what you already have in-house; that follows in step 3.
Duration and involvement: building the register itself is a matter of minutes, because it is a generator. The time only starts to add up in what comes after: finding out who in the organisation has the answer.
This is the core, and also the step that takes the most time. Per data point you record: where it comes from, which processing steps it undergoes along the way, who is responsible, accountable, consulted and informed (RACI), and which quality rules apply — valid value ranges, signals for deviations that require explanation.
What you provide: knowledge of the organisation's own source systems and processes — who reports on what where, which system delivers which figure. No one outside the organisation has that knowledge; the tool asks for it according to a fixed input-process-output structure, so that every answer is recorded in the same way.
What happens: because every data point follows the same structure, a lineage emerges that can be traced — not a collection of separate Excel conventions per department, but one format in which source, processing and owner are held together. That is why the outcome remains explainable: an assurance party can trace back, per figure, where it comes from and who signs off on it, instead of having to reconstruct that from email exchanges.
How this is divided: this does not have to be done by one person. Because the register works per data point, the work can be split across the people who actually know the source — one person fills in the energy data, another the personnel figures. Each part follows the same template, so the pieces fit together afterwards without rework.
Duration: this is the step where the turnaround time lies, and that depends on how many source systems there are, how fragmented ownership currently is, and how many data points the topic involves. A single topic with a few sources is completed faster than a group-wide register with dozens of entities.
What happens: the readiness report follows from the completed register and the lineage. It shows, per topic, where you stand, in what order the remaining data points can be tackled, and an indication of the turnaround time per topic — based on what is still missing, not a promise about when it will be finished.
Form: the report comes out of the tool as an exportable document, with the register and the RACI assignment as an underlying annex. This is also the document that serves as a controls checklist towards an assurance process: not because it replaces assurance, but because it shows what there is to check and who is responsible for it.
Remeasurement: a year later — or at the next reporting round — you go through the same structure again. What that delivers is not a new register from scratch, but a comparison: which data points that were missing last year are now filled in, where ownership has changed, and whether quality rules still hold. That is immediately the difference between an annual manual exercise and a process that can be repeated.
What this is not: it is not a reporting tool that produces the VSME or CSRD report itself — that is esgia's area of work. Nor is it a tool to answer someone else's questionnaire; that happens at supplia or esgreply. And there are no completed projects to refer to — the tool structures the process, it proves nothing about the outcome. What a well-structured register concretely means for the reporting itself is set out on Outcomes; background on methodology and standards is in the knowledge base.
The steps above are the same, regardless of who carries them out. In route 1 you go through the bootcamp template yourself, per topic, and export the register with the controls checklist for the assurance party. In route 2 a partner runs the bootcamps in which the register and the lineage are created, while the tool holds it all together. In route 3 the entire setup is handed over to the partner, carried out on FTE TO AI's own machine. The tool itself is currently in waitlist mode — the above describes how the steps work once it becomes available, not a running product.
Whatever route is chosen, the steps above remain work: hours from people who know the sources, time in systems that do not always cooperate. How much this concretely requires in tasks and capacity can be viewed via the work scan of [FTE TO AI](https://ftetoai.com).
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.