We build an infrastructure that collects the data behind sustainability reports at source, stores it with an auditable trail and manages the recurring reporting calendar. We are not the ones who sign the report; we produce what the report rests on.
In most businesses, sustainability reporting is seen as a report-writing exercise. Yet the report itself is the smallest part of the job; the real burden is collecting the data behind every indicator in it. Energy and fuel consumption, purchased electricity, vehicle fleet consumption, water withdrawal and discharge, waste quantities, headcounts and turnover rates, workplace accident statistics, training hours and supplier information. Each of these sits in a different department, with a different person, in a different format.
In the first year, this data is gathered by hand through an extraordinary effort. Emails go out, Excel files are collected, gaps are filled with estimates, and the report comes out. The second year demands the same effort again — except this time no one remembers how last year's figure was calculated. Comparability is lost, because the method was never on record. And when an audit or assurance engagement arrives, the very first question is exactly that: where did this number come from?
The infrastructure we build is designed to answer that question. Every indicator is tied to a data source, an owner, a calculation method and a period. Data that can be taken automatically is pulled from systems; for items that must be entered by hand, forms and a calendar are set up, and who entered what, and when, is logged. Calculation methods and the factors used are versioned, so the same figure can be reproduced with the same method two years later.
Let us state the limit clearly: sustainability reports may be subject to independent assurance, and we are not the party performing that engagement. You and your consultant decide the report's content, which standard it follows and how the indicators are interpreted. Our job is the data infrastructure: collecting the data at source, protecting its trail and keeping the reporting period from turning into a collection scramble. That separation works in your favour in the assurance process.
Businesses whose own reporting obligation has arisen or will arise soon. Building the data infrastructure before — not during — the year the first report is written determines both the cost and the credibility of the exercise.
Manufacturers who are not themselves in scope but whose buyers ask for data regularly. These requests arrive in a different format from each customer; the data set behind them is largely the same.
Structures that must consolidate data from several sites. Without a common method across sites, the consolidated figure loses its meaning; infrastructure is what establishes that consistency.
Companies committing to performance indicators under loans, incentives or customer contracts. Measuring the committed indicator regularly and consistently matters as much as the commitment itself.
For every indicator to be reported, the definition, unit, scope, calculation method and data source are put in writing. This definition set is the backbone of the report; if two people understand an indicator differently, the problem is resolved here, before any data is collected.
Data available from energy, production, waste, HR and purchasing systems is pulled automatically. As the number of manually entered items falls, both errors and workload fall. Which data arrived automatically remains separately visible in the report.
For data that cannot be taken automatically, simple forms for the responsible person and a period calendar are set up. Who entered what and when, and who changed which value, is on record. Reminders run through the period, not just at its start.
Emissions from direct fuel use, from purchased energy and from value chain items are calculated separately. On the scope 3 side, which categories are included and which data rests on estimates is clearly flagged; hiding that would end the report's credibility.
The emission factors and calculation methods used are stored with their versions. When a factor is updated, past-period figures do not change; if a recalculation is to be done, it is recorded as a deliberate decision. Only then does year-on-year comparison stay meaningful.
Which source, date and method every figure was produced from is traceable. The sample records an assurance engagement will ask for stand ready. This trail cannot be produced after the report is written; it forms at the moment of collection.
Which standard and which request the report answers is decided; the indicator list follows from that. We do this step together with your consultant. Keeping the list as short as possible is the right strategy for the first year; the scope can widen later.
Every indicator is tied to a source: which system, which person, how often. Indicators with no source are flagged; for these, either measurement is set up or the estimation method is defined explicitly.
Automatic connections are built, manual entry forms and the calendar are opened, responsibilities are assigned. Data is collected through a first period and the gaps become visible; that period should be treated as a rehearsal.
Indicators are calculated, consolidated across multi-site structures, and consistency checks are run. Unusual values are examined one by one; that examination usually teaches more about data quality than anything else.
The period close, approval and locking workflow goes live; closed-period data is protected. The process is handed over to the team and the calendar for the next period is set up.
No. The report's content, the standard it follows and the interpretation of the indicators belong to you and your consultant. We build the infrastructure that collects, calculates and preserves the trail of the data the report rests on. Keeping that separation works in your favour in the assurance process; having the party that produces the data separate from the party that interprets the report fits the nature of the work.
What determines the assurance outcome is the reality of the data and the soundness of the processes. What the infrastructure contributes is that every figure's source and method is documented and the sample records requested are ready. That is what the auditor looks for; when it is not ready, the engagement drags on and findings multiply. But if the data is genuinely flawed, the system does not fix that — it makes it visible.
Scope 3 is the hardest part of the job and the one with the most estimation. Our approach is this: start with the categories that can be derived from purchasing and logistics data, and build the process of collecting real data from suppliers gradually. Which categories rest on estimates is clearly flagged in the report. Any set-up that promises to fill every category with real data in year one is not realistic.
The scope is sized to the request. A customer request usually starts with a limited set of indicators; a routine that can produce those indicators regularly and consistently is enough. Building a full-scale reporting infrastructure from day one is unnecessary at that scale — and we will tell you so plainly.
That is a good start and a big advantage; the infrastructure is not built from scratch — existing sources are connected. In that case the work shifts from collecting the data to defining the method and protecting the trail. Any approach that proposes re-collecting data you already collect creates needless cost.
A defined indicator set; automatic and manual collection flows tied to sources; versioned calculation methods and factors; consolidated periodic results; a period close and approval routine; and the data trail an assurance engagement will ask for. Everything, including the source code and the collected indicator data, belongs to you.
In a 30-minute discovery call we listen to what you need and tell you honestly whether custom development or an off-the-shelf product is the better answer.
For manufacturers of machines and devices with embedded software, we build a regime that generates the software bill of materials, keeps the component and licence inventory current, monitors known vulnerabilities and establishes notification and update processes.
Details →We build an infrastructure where product-level material composition, production history, supply chain trail and repair information is collected, versioned and published through a data carrier. The way to be ready when the date is set is to start accumulating the data today.
Details →If your business depends on a program whose developer can no longer be reached, whose source code is incomplete or which has no documentation at all, we take that system over, establish how it works on the basis of evidence, and bring it back to a state where it can live on.
Details →We find the cause of systems that lock up at end-of-day close, month-end reports that never open, and screens that stall when a few users log in at once — by measuring. Not with guesswork, but with query plans and profiling data, measuring before and after with the same rig.
Details →We protect your critical business flows with automated tests: written acceptance criteria, end-to-end scenarios, a regression suite and automated pre-release runs. What an update broke should be learnt from the tests, not from a customer.
Details →We run security audits on delivered or inherited applications: authorisation and data access flaws, authentication weaknesses, injection risks, secrets and key management, dependency vulnerabilities. We also work on the side of closing the findings.
Details →
