Last year’s kWh is not your baseline

The most widely used savings calculation in the built environment is subtraction: this year's kWh minus last year's kWh. It requires no model, no statistics and no software. It is also, in most climates, primarily a measurement of the weather.

That matters more in this region than in most. The ASEAN Centre for Energy reports that the residential and commercial building sector "accounted for 22% of ASEAN's total energy consumption in 2022" and is "expected to see a 56% increase in energy demand by 2050". In a cooling-dominated climate almost all of that growth is weather-sensitive load. Any method that confuses weather with performance will get the next twenty-five years of building efficiency decisions wrong in both directions.

How much of "savings" is weather

Do not argue about this in the abstract. Compute the building's sensitivity and look at it.

Take the illustrative model we fit in the companion article on IPMVP Option C — a mid-size air-conditioned block drawing about 2,305,000 kWh a year:

kWh/day = 4,180 + 96.5 × CDD₂₄(day) + 2,640 × occupied(day)

The weather coefficient is 96.5 kWh per cooling degree day. A reporting year that runs 1 °C warmer than the baseline year, on every day, adds 365 cooling degree days and therefore about 35,200 kWh — roughly 1.5% of annual consumption. So if you install a measure that genuinely saves 3% and the following year is 1 °C warmer, naive subtraction reports about 1.5%. You have lost half your result to the thermometer, and nothing in the calculation tells you.

Two things follow, and the second is the one that gets people in trouble:

1. A good year-on-year number may be entirely weather and no savings.
2. A bad year-on-year number may be hiding real savings that were swamped by a hotter year. Projects get cancelled on this basis.

What a baseline model actually is

A baseline is not a quantity of energy. It is a function: given the conditions of any period, it predicts what the facility would have used under its old operating regime. Fit it over a representative baseline period, then feed it the reporting period's weather and schedule. The output is a counterfactual. Savings is the gap between that and what the building actually drew — and now the weather sits on both sides of the comparison, so it cancels rather than masquerading as a result.

This is the shape of whole-building evaluation as codified elsewhere: the US Department of Energy's Uniform Methods Project publishes a "Whole-Building Retrofit with Consumption Data Analysis Evaluation Protocol" among its methods for "evaluating gross energy savings".

There is a second distinction worth naming. The US Environmental Protection Agency's Portfolio Manager technical reference draws the line between weather and climate: "Weather refers to annual variations at a single location over time", while "climate refers to regional variations in average weather conditions", and its weather-normalised metric gives "the energy your building would have used under average conditions (also referred to as climate normals)". Normalising to a fixed set of conditions answers "is this building getting better?". Normalising to the reporting period's actual conditions answers "what did this project avoid?". They are different questions and they produce different numbers; say which one you asked.

Choosing the base temperature properly

Degree days require a base temperature, and the conventional 18 °C is a northern-hemisphere heating convention with no relevance to a tropical cooling load. The base temperature is a property of the building — its balance point, the outdoor temperature at which internal gains and fabric losses cancel and mechanical cooling starts to do work. It should be fitted, not assumed.

The method is a sweep. Fit the model at every candidate base across a sensible range, and keep the one that fits best. The open-source CalTRACK methods specify this precisely enough to implement: candidate heating and cooling balance points from 30 to 90 °F, with "maximum gap between candidate balance points in the grid search is 3 degrees F or the equivalent in degrees C"; a constraint that "cooling balance point ≥ heating balance point"; a minimum of "at least 20 degree days per year" for a candidate to qualify; a requirement that fitted coefficients be positive; and selection by fit, where "the model with highest adjusted R-squared will be selected as the final model".

Three cautions that the sweep will not give you on its own.

• A balance point at the edge of your data is an artefact. A tropical building whose outdoor temperature never falls below its true balance point cannot identify one. The sweep will still return a number — the lowest temperature you observed — and the model will degenerate to a straight line. That is fine, as long as you say so rather than reporting a balance point you did not measure.
• A positivity constraint is a physical claim, not a convenience. A negative cooling slope means energy falls as it gets hotter. Discard the model rather than reporting it.
• Write the base down. A report that says "degree days" without a base temperature has not told you what it computed, and no one can reproduce it.

Change-point models, and when each is right

Degree days are one way to encode a balance point. The more explicit way is a change-point regression, in which the break in the energy–temperature relationship is itself a fitted parameter. These model forms are long-established in building energy analysis; ASHRAE's Guideline 14-2023 now includes "a new section discussing how to use the ASHRAE Inverse Modeling Toolkit", the reference implementation for fitting them.

Pick the form from the physics first, then check whether the data supports it. Parameter count is the constraint people ignore: every change point costs degrees of freedom, and a 5P model fitted to twelve billing months is fitting five parameters to twelve points. With hourly interval data the question rarely arises, which is one of the quieter arguments for advanced M&V on interval data — an approach the US Department of Energy describes as using "automation and hourly or better data to produce results that can be faster, and more reliable". Where sub-daily data exists, a time-of-week-and-temperature form, which CalTRACK specifies for its hourly methods, captures schedule and weather together rather than forcing schedule into a single indicator variable.

Weather is not the only thing to normalise

Weather normalisation is the part everybody does, because temperature data is free and easy to join. It is rarely the largest term.

The practical failure is asymmetric effort. Teams spend a week sourcing weather and accept "occupied 08:00–18:00, Monday to Friday" as a permanent truth, when the building actually ran to 22:00 for six months because a tenant extended its lease terms. An extra ninety minutes a day across 250 days, on the illustrative model above, is roughly 250 × 2,640 × (1.5 / 10) ≈ 99,000 kWh — an error half as large again as the entire savings claim in the companion article. Schedules are not metadata; they are drivers, and they need the same provenance as the meter.

Weather data needs provenance too. If the model is fitted against one station and evaluated against another, or against a station whose readings arrive late and are backfilled, the residuals will carry that. NOAA's Global Surface Summary of the Day, a public daily station archive, covers "over 9000 stations" and notes that "the latest daily summary data are normally available 1-2 days after the date-time of the observations" — a lag that matters if your platform computes savings nightly. Record which station, and which version of its record, produced the number.

Reading the residuals

A baseline is a description of a regime. When the regime changes, the baseline silently stops describing the building — and because it keeps producing numbers, nothing announces this.

The detection method is not a threshold on total consumption. It is the residual series: actual minus predicted, plotted against time and against each driver. A healthy baseline gives noise centred on zero. A drifted one has shape, and the shape tells you which cause you are looking at.

Two of these worked through

A step you cannot explain. Residuals sit on zero for eight months, then jump to −180 kWh/day and stay there. Negative means the building is using less than the model predicts, which looks like savings and is not: it starts three weeks before the ECM was commissioned. Check the tenancy record and you find a floor vacated on the same date. The correct treatment is a non-routine adjustment for the vacancy, in the sense IPMVP uses the term, derived from something measured — the floor's sub-meter, or the difference in lettable area in use — not an eyeballed offset. Until you have that, the honest report says savings cannot be separated from the vacancy.

A seasonal wave. Residuals are positive from March to June and negative from November to January, year after year, and CV(RMSE) still passes. The model is under-predicting in the hot, humid months. The base temperature is too high, or the model is missing a humidity term and the latent load is riding on the seasons. Re-sweep the base, add dew point or specific humidity as a candidate driver, and check whether the wave collapses. If it does not, the model form is wrong, not its coefficients — and a savings figure computed in the hot months is biased by exactly the amount of that wave.

None of this is visible in a summary statistic. A model can pass every CV(RMSE) threshold it is held to and still carry all six shapes above. Berkeley Lab's accuracy assessment of automated M&V found "median coefficient of variation of the root mean squared error (CV(RMSE)) was less than 25% for every model tested when twelve months of training data were used" — a useful benchmark, and still only a median over a population. It says nothing about whether your particular residuals have structure this month.

What to do with the intervals that are not there

Gaps are not an edge case; they are the normal condition of building data. What you do with them decides whether the baseline is a measurement or an estimate wearing one's clothes.

CalTRACK is worth quoting because it is unusually explicit. Baseline data is disqualified when the "number of days of consumption and temperature data missing should not exceed 37 days (10%) for billing and daily methods". In the reporting period, "if a day is missing a temperature value, the corresponding consumption value for that day should be masked", and "counterfactual usage is not calculated when daily temperature data is missing". And, decisively: "Values of 0 are considered missing for electricity data, but not gas data."

That last rule is the whole argument of Null is not zero written as a method specification. A zero in an electricity series is a claim that the building drew no power. Unless it was de-energised, the claim is false, and a method that averages it in has invented a reading. Absence is representable, and it should be rendered as absence with a reason.

Baseline persistence and versioning

A baseline is a record, not a setting. It has an author, a creation date, a period, a driver set, a model form, its coefficients, its fit statistics, and an immutable history. If someone can overwrite a certified baseline without leaving a trace, your savings claims are not auditable regardless of how good the mathematics is — and the first person to ask for that trace will be an auditor, not a colleague.

The obligations that follow are practical:

• Version, never overwrite. A correction creates version 2 and keeps version 1 readable. Reports name the version they used.
• Re-derive, do not patch. If a driver series is corrected upstream, refit from the corrected data rather than adjusting coefficients by hand.
• Keep the inputs, not just the outputs. A baseline you cannot refit from stored intervals is an assertion about a computation nobody can repeat.
• Record every non-routine adjustment against the version it applies to, with the measurement it was derived from.

When to re-baseline, and the trap in doing it

Re-baseline when the facility's regime has genuinely changed and the change is not the measure you are trying to evaluate: a building extension, a change of use, a new tenant mix, a meter boundary that moved. Do not re-baseline because the current baseline is producing inconvenient results.

The trap is specific and it catches good teams. Re-baselining after a successful measure resets your savings to zero. The new baseline is fitted over a period that already contains the improvement, so the improvement becomes the new normal and stops being visible. Next year's report shows nothing, the project looks like it stopped working, and the only evidence it ever worked is a superseded model.

Persistence of savings is a real reporting requirement in most incentive and performance-contract frameworks, and it means the original baseline has to be kept, versioned and adjusted rather than replaced. The adjustment carries the unrelated change; the original model carries the measure. Keeping those two separable is the entire point of versioning, and it is why a savings platform has to behave like a ledger rather than a dashboard. We make the broader version of that argument in Your energy dashboard has not saved you anything.

A checklist you can run this week

• Does your savings number use a model, or a subtraction?
• If a model: what are the drivers, and does each have a physical mechanism?
• What base temperature, and was it fitted or assumed? Is it inside the observed range?
• Which model form — 2P, 3P, 4P, 5P — and why that one?
• Are you normalising to reporting-period conditions, or to climate normals? Which question are you answering?
• Which weather station, and when did its data arrive?
• Is the schedule a maintained driver series, or a sentence someone typed once?
• Can you produce the residual plot? Does it have shape?
• Is the baseline versioned, with an author, a date and its fit statistics?
• What happened to the intervals where the meter did not report?

Ten questions. In our experience most portfolios cannot answer six of them, and the last one changes the number most. If you want to know which of the ten your own estate fails, the fastest route is to send us what you already measure — the answer usually takes an afternoon, and it is the same work that finds the first savings.