Purpose of this article
This article explains the normalization methodologies used in Scaler, including what each normalization adjusts for, when normalization is applied, and how normalized values should be interpreted in analytics and reporting.
What is normalization in Scaler?
Normalization in Scaler adjusts reported (energy) consumption to a common basis so that performance can be compared fairly across assets and time periods.
Normalization:
- Does not create new consumption data
- Scales existing, reported values
- Accounts for structural differences such as time coverage, occupancy, and weather
Normalization is primarily used in:
- Portfolio and year-over-year analysis
- Benchmarking and scoring
- GRESB-aligned analytics
Normalization adjusts reported data. It does not estimate missing consumption.
Types of normalization in Scaler
Scaler uses two categories of normalization:
- Temporal alignment (calendarized data) - Adjusts consumption to match standard time periods
- All resources: Energy, water, waste
- Structural normalization - Adjusts for operational differences (occupancy, weather)
- Currently only energy
Temporal alignment
Purpose: Converts consumption from non-standard time periods into standard calendar periods (months, quarters, years).
How it works:
When meter readings don't align with calendar boundaries (e.g., billing periods from January 15 to February 15), Scaler:
- Calculates average daily consumption over the interval
- Allocates this to each month proportionally based on number of days
Example:
A meter reading covers December 15, 2024 to January 15, 2025 (32 days total).
DAILY_AVERAGE = REPORTED_CONSUMPTION / 32
DECEMBER_CONSUMPTION = DAILY_AVERAGE × 17 (days in December)
JANUARY_CONSUMPTION = DAILY_AVERAGE × 15 (days in January)
Where temporal alignment is applied:
- Analytics Portal graphs (when viewing monthly data or annual reporting years)
- Generated reports (GRESB, GRI, etc.)
- Data exports (Monthly Meter Consumption export)
Structural normalizations
Structural normalizations adjust consumption to account for operational differences between assets or time periods.
Time-based normalization
Purpose: Extrapolates consumption to represent a full calendar year.
Where used: Portfolio-level Energy Use Intensity and Total Consumption graphs.
Method:
- For EUI:
Normalized EUI = Reported Consumption / % of Year with Data / Active Area
- For Total Consumption:
Normalized Value = Reported Consumption / % of Year with Data
Alignment: GRESB outlier methodology (resource-level coverage).
Occupancy-based normalization
Purpose: Adjusts consumption to reflect 100% occupancy.
Where used: Portfolio-level Energy Use Intensity and Total Consumption graphs.
Method:
- For EUI:
Normalized EUI = Reported Consumption / Average Occupancy Rate / Active Area
- For Total Consumption:
Normalized Value = Reported Consumption / Average Occupancy Rate
Alignment: GRESB outlier methodology.
Time + occupancy-based normalization
Purpose: Adjusts for both time and occupancy.
Where used: Portfolio-level energy graphs.
Method:
- For EUI:
Reported Consumption / % of Year with Data / Average Occupancy Rate / Active Area
- For Total Consumption:
Reported Consumption / % of Year with Data / Average Occupancy Rate
Alignment: GRESB outlier methodology.
Weather-based normalization
Purpose: Adjusts energy use to account for weather anomalies, so consumption can be compared across years and across assets in different climates.
Where used:
- Portfolio-level energy graphs (View > Weather-based normalization)
- When Weather Normalization is enabled in Portfolio Settings
[Screenshot: Analytics Portal energy graph with the View dropdown open, showing the Weather-based normalization option highlighted — crop to the dropdown plus the graph title for context.]
Method: Scales reported consumption by the ratio of long-term average degree days to the current year's degree days, combining heating and cooling into a single ratio.
Formula:
Normalized Consumption = Reported Consumption × (Average HDD + Average CDD) / (Year HDD + Year CDD)
The same ratio is applied uniformly to every asset assigned to a given weather station, regardless of asset type or HVAC configuration.
The settings table asks for four values per weather station per year because the formula needs both sides of a ratio: Heat and Cooling degree days for that year (the asset's actual weather experience) and Average Heat and Average Cooling degree days (the long-term climate baseline to compare against). Without all four, no ratio can be calculated. All inputs must be in degree-days at the same temperature base (typically 15.5°C or 18°C).
[Screenshot: Portfolio Settings → Normalization tab showing one weather station with all four input rows (Average HDD, Average CDD, Heat degree days, Cooling degree days) populated across multiple years — crop tightly to the table.]
Worked example
Brussels weather station, 2024 input values (degree-days, base 18°C):
- Average HDD: 2,800
- Average CDD: 50
- Year HDD: 3,200 (colder winter than average)
- Year CDD: 30 (cooler summer than average)
Ratio = (2,800 + 50) / (3,200 + 30) = 2,850 / 3,230 = 0.88
For an asset on the Brussels station with a reported EUI of 150 kWh/m²/yr:
Normalized EUI = 150 × 0.88 = 132 kWh/m²/yr
The cold winter pushed actual consumption up. The normalized value reflects what the asset would have used in a typical year, isolating underlying performance from weather effects. The same 0.88 multiplier applies to every asset on the Brussels weather station in 2024.
Application: Applied at the asset level when Allocated weather station is set under Asset Details.
[Screenshot: Asset Details template (spreadsheet view) with the Allocated weather station column highlighted and populated for several assets — crop to the column header plus 5–6 rows.]
Use case: Helps isolate the impact of operational efficiency measures by filtering out weather-driven variability.
Where to source HDD and CDD data: Long-term averages and yearly values are not typically held in client property records. Common sources:
- degreedays.net - free tier for limited use, paid plans for portfolio-wide access. Station-level data with configurable temperature base.
- Open-Meteo Historical Weather API - free, no license required. Daily mean temperatures back to 1940 for any latitude and longitude. Year values and long-term averages can both be computed from the same dataset.
- Eurostat - country-level annual HDD and CDD for EU countries.
- NOAA NCEI - station-level data for US locations, free.
All four inputs must use the same temperature base. Country-level sources are not suitable for asset-level normalization in countries with multiple climate zones.
Limitations of this approach: The ratio applies a single multiplier to total reported consumption, which implies two simplifications worth understanding:
- All energy is treated as weather-sensitive. Much of an asset's consumption is baseload (lighting, plug load, ventilation, lifts, server rooms) that does not vary with outdoor temperature. The ratio scales this baseload portion as well, which overstates the weather effect for assets with high non-HVAC load such as data centres, cold storage, or mixed-use buildings.
- Heating and cooling are combined into a single ratio. A year with unusually low HDD and unusually high CDD can produce a ratio close to 1 and mask real weather-driven changes. Separate ratios for heating-sensitive and cooling-sensitive consumption are more accurate but require splitting consumption into temperature-dependent components first.
Normalized values are best read as directional indicators of underlying performance rather than precise weather-adjusted consumption, especially for asset types where HVAC is not the dominant load.
Enabling weather-based normalization
- Go to Data Collection Portal → Portfolio → Settings → Normalization.
- Toggle to
Enable weather normalization
- Create necessary Weather stations
- Populate the four required values per year for each station: Year HDD, Year CDD, Average HDD, and Average CDD. All four must use the same temperature base.
- Assign an
Allocated weather stationto each asset in Asset Details.
Where normalization is applied
Context | Temporal alignment | Occupancy | Time | Weather |
Analytics Portal - Default view | Yes* | No | No | No |
Analytics Portal - Normalized views | Yes* | ✓ | ✓ | ✓ |
Analytics Portal - Estimated view | Yes* | No | No | No |
Reports (GRESB, GRI, etc.) | Yes | Depends on report | Depends on report | No |
Data exports | Yes | No | No | No |
*Analytics Portal applies temporal alignment when viewing monthly graphs or when meter reading periods don't align with the selected reporting year.
Default/Normalized/Estimated views = dropdown in Analytics Portal graphs only. Structural normalizations (occupancy/time/weather) are only available through the Analytics Portal View dropdown, not in exports or raw data downloads.
Normalization in reports and exports
Normalization is also applied in generated reports and downloadable exports to ensure alignment with the timeframe of the report or reporting framework.
Monthly Meter Consumption export
File: Found in Data Collection Portal → Portfolio → Meter List → Download
Column: actual_monthly_consumption
Method:
When consumption spans multiple months (e.g., quarterly or annual meter readings), Scaler:
- Calculates average daily consumption over the interval.
- Allocates this to each month proportionally based on number of days.
Report generation normalization
Scenario: You've entered annual consumption but generate a quarterly report.
Scaler's Approach:
Scaler uses the daily average from the interval and applies it proportionally to each sub-period in the report (e.g., quarters, months).
Ownership-adjusted normalization
Use case: An asset's data overlaps with the reporting year but is only owned for part of it.
Scaler's Approach:
- Consumption values are prorated to reflect only the days during the ownership window.
- This ensures only in-scope data is included for frameworks like GRESB.
- For like-for-like comparisons, clients may override ownership settings to retain values.
How normalization differs from estimation
Normalization | Estimation |
Adjusts reported consumption | Fills missing or unreported consumption |
Scales existing values | Creates modelled values where data is missing |
Uses structural factors (time, occupancy, weather) | Uses historical consumption patterns |
Focused on comparability | Focused on data continuity |
Results in normalized values | Results in estimated values |
See How Scaler estimates missing energy meter data for details on estimation logic and limitations.
Why normalization matters
Normalization enables apples-to-apples comparison across:
- Assets with partial-year data
- Assets with variable occupancy
- Assets in different climates
- Periods impacted by abnormal weather
By controlling for these variables, Scaler provides clearer insights into operational efficiency and performance trends.
Additional resources
- Energy analytic 'Views' — Understanding available energy analytics views and when to use each
- Energy use intensity (EUI) — How Scaler calculates EUI and what affects it
- How Scaler estimates missing energy meter data — Estimation methodology, confidence scores, and limitations