Calculation methodology for environmental data
IBM® Envizi ESG Suite provides a standardized, transparent methodology for calculating environmental metrics from raw activity data. Environmental metrics include greenhouse gas (GHG) emissions, energy use, and other impact indicators. A client can configure the platform by using custom or standard emission and conversion factors to suit a wide range of reporting needs. Envizi ESG Suite captures activity data, transforms and normalizes it, applies conversion factors, and calculates outputs such as emissions and energy use.
Definitions
- Activity data
- Raw data captured by Envizi ESG Suite, such as electricity use, fuel consumption, or financial metrics, for example, total cost or taxes.
- Account
- A container for multiple records from a single supplier. Envizi ESG Suite structures data hierarchically by accounts to streamline data management.
- Account style
- A customizable view applied to an account that defines the fields and, optionally, calculations within the account. Envizi ESG Suite support can update existing account styles or create account styles as required.
- Account style rules
- Rules that are applied at the account style level to perform automatic unit conversions or conditional logic, for example, if/then scenarios. For example, rules can convert all incoming energy units to a standard unit such as kWh.
- Data type
- A category that defines the nature of the activity data, for example, electricity, solar production, waste, or fuel. Each data type has a designated primary unit of measure and an associated set of conversion factors.
- Factor
- A collective term that describes conversions that are applied to activity data. A conversion
value is applied to activity data to generate metrics such as the following examples:
- GHG emissions, for example, kg CO₂e per unit
- Energy in GJ per unit
- Mass, volume, area, or distance
- Factor effective and published dates
- Factors often have a validity period. Factors can have either a start date, an end date, remain open-ended or a combination. For more information on effective and published dates, see topic Assigning factors with effective or published dates.
- Factor set
- All factors are grouped into factor sets and align with regulatory or voluntary emissions reporting bodies. The sets are assigned to regions of the world at the global, continental, and country level. Up to three custom factor sets can also be assigned specifically to a client, where one of the custom factor sets is a custom global default factor set. When factor selection takes place for an account item, any custom factor set that is assigned to a client takes precedence over regional factor sets that are managed by Envizi ESG Suite, such as UK Defra, US EPA, or NGER.
- Primary measure
- The core quantitative input that is used for factor application, for example, electricity purchased in kWh. Secondary measures, for example, cost, tax, are captured but not used in conversion calculations. Envizi ESG Suite has the flexibility to capture data in multiple units of measure by using account style rules. However, in the Envizi ESG Suite database, all data is stored in a single unit of measure for factor application.
- Record
- An individual data submission that typically represents a utility bill or invoice. Records include a start date, end date, and one or more quantitative or qualitative data fields.
- Region
- Locations in Envizi ESG Suite are assigned to regions. When a location is assigned to a region, it is best practice to use the lmost granular region that is available in the system. A location can also be assigned to a region other than its geographical region, only for factor selection.
- Sub type
- An optional secondary categorization, for example, fuel grade, that enables more granular factor selection within a data type. The Sub type categorization enables more granular factor selection by providing an extra link between individual factors within a data type and options that can be selected at an account style, account, or record level.
- Statistics
- All activity data that is stored in Envizi ESG Suite are normalized to the month, and all emissions, energy, and so on, are calculated from normalized monthly data, not activity data. It is important to be aware of and understand the difference between normalized and activity data when various reports are interpreted.
Calculation methodology
The following standard formula is applied for calculating metrics, where the result can
optionally be converted to a client-selected reporting unit, Unit 3, through standard SI unit
conversions:
Activity Data (Unit 1) × Factor (Unit
2 / Unit 1) = Result (Unit 2)
The
calculation uses the following units:- Unit 1 is defined by the client at the beginning of implementation, for example, L, kWh.
- Unit 2 is defined by Envizi ESG Suite per factor, for example, kg CO₂e, GJ. Unit 2 cannot be changed.
- Unit 3 can be selected at reporting time in Envizi ESG Suite, for example, metric tons CO₂e, MWh, t, which enables clients to select the preferred unit depending on their reporting requirements.
A conversion for a particular dimension can be calculated only if the conversion value is contained in the factor. For example, electricity factors contain only conversions to emissions and energy, whereas factors for distance might contain conversions for emissions, distance, and volume of fuel, if a fuel economy is provided when the factor is calculated.
Example: Fuel invoice conversion
The example in the following sections shows an energy and emissions calculation based on a sample fuel invoice.
The following sample input data is activity data that is entered into an account from a fuel
invoice for the measures of fuel, distance, tax, and total cost. Data was not supplied for tonnage
hauled, so the data is not stored as a monthly record in Envizi ESG Suite.
- Location
- Distribution Warehouse, Sydney, NSW
- Account
- Exxon Diesel 123
- Account Style
- Diesel with distance and tonnage
- Dates
- January 5 – March 4, 2025 (59 days)
- Data
-
- Diesel fuel: 39,209 L
- Distance: 271,900 km
- Tonnage: Not provided
- Tax: $62,700.50
- Total cost: $478,450.00
Monthly pro rata normalization steps
The activity data is normalized pro rata into monthly values by using the following steps:
- Determine the total number of days for the invoice. Dates are inclusive, so the fuel invoice has 59 days that include 27 days in January, 28 days in February, and 4 days in March.
- Determine the pro-rata ratio for January: 27/59
- Determine the monthly value for January fuel: 27/59 * 39,209 = 17,943.10 L
- Determine the monthly value for February fuel: 28/59 × 39,209 L = 18,607.66 L
- Determine the monthly value for March fuel: 4/59 × 39,209 L = 2,658.24 L
- Repeat the calculation for all the measures and months, which results in three monthly records (January, February, and March) for all four measures (fuel, distance, tax, and total cost) that results in 12 rows of data, as shown in the Fuel invoice example: Monthly normalized activity data table.
| Month | Days | Measure | Primary measure | Amount |
|---|---|---|---|---|
| January 2025 | 27 | Fuel (L) | Yes | 17,943.10 |
| January 2025 | 27 | Distance (km) | No | 124,428.81 |
| January 2025 | 27 | Tax ($) | No | 28,693.45 |
| January 2025 | 27 | Total cost ($) | No | 218,951.69 |
| February 2025 | 28 | Fuel (L) | Yes | 18,607.66 |
| February 2025 | 28 | Distance | No | 129,037.29 |
| February 2025 | 28 | Tax ($) | No | 29,756.17 |
| February 2025 | 28 | Total cost ($) | No | 227,061.02 |
| March 2025 | 4 | Fuel (L) | Yes | 2,658.24 |
| March 2025 | 4 | Distance | No | 18,433.90 |
| March 2025 | 4 | Tax ($) | No | 4,250.88 |
| March 2025 | 4 | Total cost ($) | No | 32,437.29 |
Factor selection algorithm
Only a single factor can be applied per monthly record. The factor selection algorithm
iteratively matches criteria that are stored with the factor against other criteria from the account
style, the location's region, and the time period of the activity data. The algorithm uses the
following matching sequence:
- 1. Data type
- The factor must match the data type.
- 2. Sub type
- Occasionally, factors belong to a sub type. Sub types act as a further division within a data type and enable a user to select a different set of factors within a single data type. For example, within the data type for gasoline 3 fuel grades might exist, each with a different factor.
- 3. Factor set
- With the narrowed down list of factors that results from matching in the previous steps, the
factor selection algorithm assesses the correct factor set. First, the algorithm checks whether the
client has one or two factor sets assigned. If so, the factor sets are checked first. If a factor
set is not assigned, the algorithm checks regional factor sets by comparing the region for the
account's location and the factor set's region level.
Table 2. Example assigned factor sets by region level Region level Factor set type Example assigned factor set 1 Custom factor set 1 None 2 Custom factor set 2 None 3 Regional factor set - Country NGERS 4 Regional factor set - Continent None 5 Designated Default Factor Set Default 6 Global Default Factor Set UK Defra - 4. Region
- After a set of factors is matched based on the previous criteria, the factor selection algorithm compares the location region and the available factors for the region, if any exist. If a factor isn't found, the algorithm searches for factors in regions at progressively higher levels, for example, at the city level, and then at the state, country, continent, and finally at the highest global level.
- 5. Dates
- The factor selection algorithm compares the monthly record against available factors to further refine the list. For more information about effective and published dates, see Assigning factors with effective or published dates.
Available factors in the Diesel [L] data type
The following table outlines the factors that are available in the Diesel [L] data type.
Note: Not all factor conversions and fields are displayed in the following table.
| Factor ID | Name | Data type | Sub type | Factor set | Region | Region level | Effective from | Effective to | Total CO2e/ unit | GJ/ unit |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Diesel 1 | Diesel (L) | None | Default | Earth | Global | N/a | N/a | 2.79 | 0.042 |
| 2 | Diesel 2 | Diesel (L) | None | NGER | NSW | State | N/a | January 2025 | 2.79 | 0.042 |
| 3 | Diesel 3 | Diesel (L) | None | NGER | NSW | State | February 2025 | N/a | 2.67 | 0.04 |
| 4 | Diesel 4 | Diesel (L) | None | NGER | ACT | State | N/a | N/a | 2.79 | 0.044 |
| 5 | Diesel 5 | Diesel (L) | None | NGER | Melbourne | City | N/a | N/a | 2.79 | 0.042 |
| 6 | Diesel 6 | Diesel (L) | None | Client 1 | Sydney | City | N/a | December 2024 | 2.19 | 0.042 |
| 7 | Diesel 7 | Diesel (L) | Heavy Transport | Client 1 | Australia | Country | N/a | N/a | 2.40 | 0.042 |
| 8 | Diesel 8 | Diesel (L) | None | Client 2 | Brisbane | City | N/a | N/a | 3.08 | 0.042 |
Factor assignment and calculations applied to the fuel invoice sample data
Using the factor selection algorithm and the factors that are shown in the previous Available factors in the Diesel [L] data type table, the
following factor assignment analysis focuses on the fuel invoice sample data for January 2025:
- Data type
- All factors are contained in the Diesel data type, so none are excluded from the factor selection algorithm.
- Sub type
- The account style does not have a sub type, so the factor selection algorithm excludes factor 7.
- Factor set
- The client has two custom factor sets defined. Factor 6 for Sydney matches on region, but the factor expired in December 2024 so it is excluded by the factor selection algorithm. Factor 8 for Brisbane is also excluded by the factor selection algorithm because it doesn’t match on region. The NGER factor set is a possible match because it is configured as the default for Australia. The Default factor set is the fall-back if a factor is not retrieved before this point.
- Region
- Factor 5 is excluded because it doesn’t match on region. Factors 1 to 4 are still possible because they are defined at state level or above. Factor 4 is the next factor to be excluded because Sydney is not in the ACT state within Australia.
- Dates
- Factors 2 and 3 match on data type, factor set, and region, but only factor 2 is valid for the month of January 2025, so factor 3 is excluded. Factor 1 could apply, but the factor selection algorithm terminates the loop after a factor has been retrieved. When factor 2 is returned, it is recorded on the monthly row and then the factor selection algorithm continues on to February 2025 to restart the loop.
The following table shows the factors that are assigned to fuel, and the associated energy and emissions calculations for each month in the sample fuel invoice.
| Month | Days | Measure | Amount | Factor ID | kg CO2e / unit value | kg CO2e | GJ / unit value | GJ |
|---|---|---|---|---|---|---|---|---|
| January 2025 | 27 | Fuel (L) | 17,943.10 | 2 | 2.79 | 50,061.249 | 0.042 | 753.6102 |
| February 2025 | 28 | Fuel (L) | 18,607.66 | 3 | 2.67 | 49,682.4522 | 0.04 | 744.3064 |
| March 2025 | 4 | Fuel (L) | 2,658.24 | 3 | 2.67 | 7,097.5008 | 0.04 | 106.3296 |