How Emissions Calculations Work in GreenSphere

The trust guide. This explains how GreenSphere turns a raw data point — say, 10,000 kWh of grid electricity in Kenya for May 2026 — into a calculated emissions figure that lands on your dashboard, in your IFRS S2 report, and in your audit trail. No methodology theory; just the chain inside the platform.

The two ways emissions get into the platform

Emissions data can be entered in two ways:

• By logging operational activity data and applying an emission factor. The platform calculates the emissions for you from the activity (kWh, litres, kg) using the factor you select.
• By logging the calculated emissions value directly. Used when you already know the total emissions for a period — for example, supplier-provided figures, externally audited values, or emissions you've calculated outside the platform.

Both methods produce entries that flow into the same downstream surfaces (dashboard, reports, audit). They differ in who does the calculation, not in what the result looks like.

Method 1: Activity data + emission factor

The most common path. Walking through it end-to-end with a concrete example:

Inputs. On the Log Data page, choose the relevant raw data point (e.g., Grid Electricity), enter the value (10,000), the unit (kWh), the reporting period (1 May 2026 to 31 May 2026), and the source (e.g., Manual Entry).

The Emissions Impact section. Expand this section and pick the scope and category that match the activity:

• Scope 2: Purchased Electricity for grid electricity.
• Scope 1: Stationary Combustion for diesel burned in on-site generators.
• Scope 1: Mobile Combustion for fleet fuel.
• Scope 1: Fugitive Emissions for refrigerant leaks.
• Scope 3: Category 6 — Business Travel for flights and hotel nights.
• ...and so on across Scopes 1, 2, and the 15 Scope 3 categories.

Pick the emission factor. Select the appropriate factor from the dropdown — typically a country-specific factor (e.g., the Kenya grid emission factor for Scope 2 electricity in Kenya). The factor list is filtered by relevance to your data point and location.

Unit conversion is automatic. You don't need to match the factor's expected unit. If your value is in kWh and the factor is in MWh, the platform converts. Same for fuel volumes, weights, distances — any supported unit pair has a conversion path.

The calculated output preview. Below the factor selection, the Calculated output card shows the resulting emissions in kgCO₂e, computed live as you change inputs. This is your sanity check before saving.

Save. The entry commits with both the raw activity data and the calculated emissions value. Both are queryable.

What the platform does behind the scenes

For the example above (10,000 kWh × Kenya grid factor at ~83 gCO₂e/kWh ≈ 830 kgCO₂e):

1. Raw data point entered — 10,000 kWh, Kenya, May 2026.
2. Factor lookup and unit normalisation — the platform pulls the selected factor's value and converts your activity unit to the factor's expected unit if needed.
3. Calculation — activity × factor (after unit normalisation).
4. Scope assignment — the result is tagged to the scope and category you selected (Scope 2 — Purchased Electricity in this case).
5. Aggregation — the calculated emissions roll up into the relevant indicator totals (Scope 2 total, total emissions, scope-specific intensity metrics) and any dashboard cards that consume those indicators.

Once saved, the entry is visible from both the dashboard and the Emissions page — and from the source raw data type's drill-down on the Raw Data page.

Custom mappings: speed up future logging

If you log the same kind of activity repeatedly (e.g., monthly electricity from a specific site), don't re-pick the scope, category, and factor every time.

Open the Emissions page and set up a custom mapping: link a specific raw data point to a specific scope, category, and emission factor. The next time you log against that data point, all three fields auto-fill. You can still override per-entry, but the default makes routine logging much faster.

This is also where assurance providers prefer to see consistency. A documented mapping that says "all grid electricity in Kenya uses the EMBER Kenya grid factor, three-year average, AR6 GWP basis" applied uniformly is much easier to audit than ad-hoc per-entry choices.

Method 2: Enter calculated emissions directly

When you already know the emissions value for a period — supplier-provided, externally audited, or computed outside the platform — log it directly without going through activity data.

On the Log Data page, switch to the Calculated Metrics tab. Then:

• Select an emissions indicator (e.g., a Scope-specific or category-specific emissions indicator).
• Choose the GHG scope and category the value applies to.
• Enter the total emissions for the reporting period in kgCO₂e or tCO₂e.
• Set the start and end dates of the period.
• Add audit notes and supporting documentation as needed.
• Save.

The entry is tagged with source Manual (versus Calculated for activity-derived values), so the audit trail makes the distinction clear. From the dashboard and Emissions page, both methods appear in the same totals.

Roll-ups: how scopes aggregate

The platform performs emissions roll-ups automatically across several views:

• Total emissions — the sum of every Scope across the reporting period.
• Scope 1 — direct emissions only.
• Scope 2 — purchased energy only (and dual-reported as location-based and market-based where applicable; see Location-based vs market-based Scope 2 in the reporting guides).
• Scope 3 — all 15 categories of value-chain emissions, with per-category breakdowns.
• Scope 1 + Scope 2 — internal emissions, the typical SBTi near-term target boundary.
• Scope 3 separately — external value-chain emissions.

You can view all scopes together on the dashboard and Emissions page, or filter to a single scope. The roll-ups update live as new data is logged.

What the platform doesn't do automatically

The platform handles the calculation chain. It doesn't make methodology choices for you. Specifically:

• Scope 3 category materiality screening is your call. The platform tracks all 15 categories; you decide which to populate based on a screening exercise. See the reporting guide Calculating Scope 3 emissions: the 15 categories explained.
• Allocation across multi-site shared meters is a manual decision. Pick your allocation method (floor area, occupancy, headcount), document it in audit notes, and apply it consistently.
• Emission factor selection where multiple factors apply. The platform offers the relevant factors; you choose which to use and document why. The Custom Mapping feature locks the choice in for future entries.
• Estimation methods for missing data. The platform doesn't extrapolate or impute. If a period's data is missing, the indicator simply has no value for that period unless you manually enter an estimate.

Where to look when you need to defend a number

For any calculated emissions value on your dashboard or in a report, you can trace it back through:

1. The indicator (KPIs page) — see Data Lineage to find the raw data type(s) feeding it.
2. The raw data type (Raw Data page) — see all entries with their values, periods, and sources.
3. The individual entry — open the entry to see the activity value, the emission factor used, the calculated output, the audit notes, and any supporting documents attached.
4. The audit trail — see Audit trail and data history for every change to the entry, who made it, and when.

This chain is the answer to the question every assurance reviewer asks: where did this number come from?

Where to go from here

• The emission factor library — what's in the library, where factors come from, and how to add custom factors.
• Audit trail and data history — how every calculation gets a defensible audit log.
• Generate your first IFRS S1/S2 report — where the calculated emissions surface as disclosure metrics.
• For methodology depth: Calculating Scope 3 emissions and Location-based vs market-based Scope 2 in the reporting guides.