A store’s gas use is up 18% on last January. Is a boiler failing, did someone change the thermostat schedule, or was it just colder? Without weather normalization, nobody can say.
Weather normalization separates what the weather did from what the building did. It sounds technical, but the working version fits on one page, and a spreadsheet is enough to run it.
Why raw comparisons mislead
Heating and cooling follow the weather, and the weather does not repeat. Compare this January with last January, and the difference mixes two things: how the building behaved, and how cold it was outside.
On a multi-site report, raw comparisons produce noise in both directions. Sites look worse in a cold month and better in a mild one, and real problems hide inside the weather swing.
A 10% increase in a month that was 15% colder may be good performance. A flat month in a mild winter may be a problem nobody sees.
Degree days in one paragraph
A degree day measures how far a day’s average temperature sat from a base temperature, often 65°F. A day averaging 25°F counts as 40 heating degree days at that base. A day averaging 80°F counts as 15 cooling degree days. Add up the days in a billing period and you have a number that tracks how much heating or cooling the weather asked for.
Heating degree days (HDD) drive gas use and electric heat. Cooling degree days (CDD) drive air conditioning. Our glossary defines both, along with baseload and the other terms used here.
Split use into base and weather
Most buildings’ energy use has two parts. Baseload runs whatever the weather: lighting, plug loads, refrigeration, cooking, water heating. Weather load rises and falls with degree days.
With 24 months of bills and the degree days for each billing period, a simple regression finds both parts. For a gas meter, the result might read:
monthly therms = 400 + (0.9 × HDD)
That says the building uses about 400 therms a month for baseload, plus about 0.9 therms for each heating degree day. These numbers are illustrative; every building gets its own.
Use 24 months, not 12. One year gives you one winter, and one winter may be unusual. Two years give the regression a fair chance of seeing both cold and mild months.
Electric meters work the same way, usually with cooling degree days doing the work in summer. A building with electric heat may need both.
Choosing the base temperature
The 65°F base is a convention, not a law of physics. A building starts heating when the outdoor temperature drops below the point where its own lights, people and equipment no longer keep it warm.
An office full of equipment may not need heat until it is well below 65°F outside. A lightly used warehouse may need it sooner. If the fit looks poor, try the regression at a few base temperatures and keep the one that explains the bills best. Write down which base you used, so next year’s comparison uses the same one.
Reading the slope and the base
Once every site has a formula, the two numbers become a way to compare sites, not just months.
- A high heating slope per square foot points at the envelope or the controls: leaky doors, poor insulation, heat running in empty hours.
- A high baseload per square foot points at what runs regardless of weather: lighting left on, equipment that never sleeps, or a water heater set too high.
Compare similar sites with each other: stores with stores, offices with offices. The site at the top of either list is where a facilities visit earns its time.
Example: three winter months
Same building, same formula, illustrative numbers:
| Month | HDD | Expected therms | Actual therms | Difference |
|---|---|---|---|---|
| December | 900 | 1,210 | 1,230 | 2% over |
| January | 1,100 | 1,390 | 1,600 | 15% over |
| February | 800 | 1,120 | 1,110 | 1% under |
December and February sit within a couple of percent of expected. January used 15% more than its weather explains. That is the month to look at: a stuck valve, a changed schedule, a loading dock door left open.
Now compare the raw view. January used 30% more gas than December. Read raw, January looks 30% worse; read against the weather, it is 15% off. Half of the jump was weather, and the other half is worth a phone call to the site.
Match degree days to read dates
Bills do not follow calendar months. A billing period might run from January 9 to February 7, and its degree days have to cover those same dates, or the regression learns the wrong thing.
Three habits keep this honest:
- Sum daily degree days across each bill’s actual read dates.
- Flag estimated reads, which can shift usage from one period into the next.
- Use the weather station nearest each site, not one station for the whole portfolio.
The last habit matters on the Front Range. Denver, Boulder, Colorado Springs and Fort Collins do not share one weather pattern, and a site near the foothills can differ from one out on the plains.
If the same month looks off at several sites at once, check the weather data before the buildings. A wrong station or a few missing days of readings moves every site that relies on it, and the fix is in the spreadsheet, not on the roof.
What normalization cannot fix
Weather normalization explains weather. It does not explain a new tenant, longer hours, an added freezer case or a site that closed for a month. Those are real changes in the building, and they belong in writing.
In the Peg Method, those written changes are the only reason to move the peg, the agreed baseline everything is measured against. A site that added a second shift gets a new baseline with a note saying why. A site that simply used more gets a question.
Normalization also has limits on electricity. Monthly kWh tracks degree days reasonably well; demand charges do not. A 2017 National Renewable Energy Laboratory analysis explains that demand charges are typically based on the highest average electricity usage in a defined interval, usually 15 minutes, during a billing period (NREL, via ScienceDaily). One hot afternoon or one cold morning can set that, and monthly degree days will not show it. For demand, you need interval data.
Portfolio Manager’s version
ENERGY STAR Portfolio Manager shows weather-normalized figures alongside actual energy use. They are useful for comparing years at the building level, and for benchmarking.
They are not a substitute for a monthly baseline by meter. A team that wants to catch a problem in the month it starts needs expected usage for each meter, for each billing period, compared with the bill as it arrives. Our note on setting up Portfolio Manager for many sites covers the benchmarking side.
A simple routine
For each meter, once:
- Pull 24 months of bills with their read dates.
- Sum heating and cooling degree days for each billing period, from the nearest station.
- Fit usage against degree days, and record the baseload and slope.
- Agree the result in writing as the baseline.
Then, every month:
- Compute expected usage from that period’s degree days.
- Compare actual with expected, and flag gaps beyond a set threshold, such as 10%.
- Write one line explaining each flagged gap.
Step 7 is the one that gets skipped. A flag with no explanation is just a colored cell. A flag with one line, such as “door sensor failed, repaired on the 14th,” is a record someone can use next winter.
Where to start
A Peg Baseline does the first half of this routine for up to 25 sites: 24 months of bills and interval data, every meter mapped to a site, weather-normalized and agreed in writing. Our energy consumption monitoring then reads each month against that baseline, so a cold January shows up as weather and a stuck valve shows up as a variance with a reason attached.
