How to Collect Sustainability Data Across Projects, Sites and Business Units

Single-site sustainability reporting is manageable. You have one electricity meter, one fuel account, and one team responsible for the data. Multi-site reporting — across ten construction projects, three manufacturing facilities, and a corporate office — is a different problem in kind, not just in scale.

Here’s how to structure data collection when your sustainability footprint is distributed across the organisation.

Define your organisational hierarchy first

Before building any data collection process, you need a clear and agreed organisational hierarchy:

• Business unit — the top-level division (e.g., construction, infrastructure, property)
• Project — a specific contract, development, or initiative with a defined lifecycle
• Site — a physical location where operations occur (may map 1:1 with a project, or a project may span multiple sites)
• Facility — a fixed asset within a site (a building, a machine, a meter)

This hierarchy matters because it determines how your emissions data aggregates. A Scope 2 figure for Site A in Project X belongs to both that project (for project-level reporting) and the business unit (for corporate reporting). Without a consistent hierarchy, those two figures will never reconcile cleanly.

Document the hierarchy, assign codes, and make sure it’s reflected in every system that captures sustainability data — including accounts payable, fleet management, and HR.

Identify the data owners at each node

For each node in your hierarchy, identify:

• Who is responsible for data collection?
• What data are they responsible for (fuel? electricity? water?)?
• How frequently do they collect and submit data?
• To whom do they submit it?

In most organisations, data ownership is fragmented:

• Site managers are responsible for meter readings and fuel logs
• Accounts payable processes invoices (which contain the actual consumption data)
• Fleet managers own vehicle fuel records
• Facilities managers own building utility data

None of these people typically have sustainability reporting as a primary role. Building a data collection process means creating a workflow that fits into what they already do, not creating a separate parallel process they have to maintain on top of existing work.

Design the minimum viable dataset for each category

For each data type, define the minimum fields required to make it useful at reporting time:

Electricity invoice:

• Site/project code
• NMI or meter reference
• Billing period (start date, end date)
• Consumption (kWh)
• Invoice reference number

Fuel record:

• Site/project code
• Fuel type (diesel, petrol, LPG)
• Volume (litres)
• Date of delivery or consumption
• Plant item or vehicle (for allocation)

Water reading:

• Site/project code
• Meter reference
• Reading date
• Volume (kL)
• Source type

These minimum fields are what you need to calculate emissions, attribute them to the right reporting dimension, and trace them back to a source document. Additional fields are valuable but shouldn’t be a barrier to collecting the basics.

Build the collection workflow

For each data source, the workflow needs to answer:

1. Who enters the data? (Or: who uploads the document?)
2. When do they enter it? (Monthly, at invoice receipt, at period end?)
3. How is it validated? (What happens if data is missing or implausible?)
4. Who reviews it before it enters the emissions calculation?

The simpler this workflow is, the more reliably it will be followed. Complexity is the enemy of consistent data collection across sites.

Consider:

• Central collection of invoices (accounts payable forwards utility invoices to a central sustainability inbox before processing)
• Site-level submission for meter readings and fuel logs (standardised form or mobile entry)
• Automated retrieval where utilities offer data APIs or structured export formats

Handle the hard cases explicitly

Shared meters: A single meter that covers both a project site and an adjacent permanent facility. Decide upfront how consumption will be allocated (by floor area, by headcount, by sub-metering) and document the decision. Don’t leave it ambiguous.

Mobile plant that moves between sites: A crane that works on Project A for six weeks and Project B for the next four months. Define whether allocation is by calendar day, by hours logged, or by site-reported fuel delivery. Record the allocation method with the data.

Subcontractor data: Decide whether subcontractor emissions are in scope, and if so, what data you need from them and how you’ll collect it. Trying to retrofit this at year end is painful — build it into contracts and onboarding.

Incomplete periods: A site that opened mid-quarter. Decide whether you pro-rate or report from the date operations commenced. Document the approach.

Use project codes consistently — everywhere

The most common failure in multi-project data collection is inconsistent use of project codes. The project code in the sustainability data needs to match:

• The project code in the financial system
• The project code in the fleet management system
• The project code in the AP system where invoices are processed

If these don’t align, reconciliation at reporting time requires manual investigation of every discrepancy. This is manageable for five projects; it’s unmanageable for fifty.

---

Ayika is built for exactly this multi-site, multi-project structure. Data is tagged at the point of entry with organisational hierarchy, so consolidation is automatic. Book a demo to see how it handles your structure.