Energy Data Quality Checklist: What to Check Before Any Analysis

No EnPI or baseline model is better than the data it's built on. Before any analysis, four aspects of data quality need to be confirmed: a sound metering hierarchy, time synchronisation, unit consistency, and proper handling of data gaps.

Metering hierarchy

A healthy metering hierarchy starts at the site's main incoming meter, extends to zone- or production-line-level meters, and, where needed, down to equipment-level meters. The sum of sub-meter readings at each level should be periodically reconciled against the meter one level up; a significant, persistent discrepancy signals a calibration error or unmetered consumption.

Time synchronisation

When data is collected from several meters or systems with independent internal clocks, even a few minutes of offset can distort high-resolution analyses, such as fifteen-minute load profiles. Regularly synchronising clocks to a common time source, and paying special attention to daylight-saving changes or time-zone shifts, should be part of the standard data collection procedure.

Unit consistency and handling data gaps

Mixing units is one of the most common sources of hidden error: some gas meters report actual cubic metres while others report normal cubic metres (Nm3), and the calorific value of gas can change over the year. Before any aggregation, the conversion factor and calorific value reference used need to be documented and applied consistently across the whole dataset. Alongside that, every gap in the data needs to be detected first, then flagged, and finally, depending on its length and importance, either filled using a defined method (such as averaging a similar period) or excluded from the analysis; silently filling a gap with zero or an overall average, without flagging it, is the most common mistake that skews an EnPI result without anyone noticing.

Automated validation rules

• Range checks (min/max) based on the actual capacity of the equipment or site
• Rate-of-change checks between consecutive readings to catch impossible jumps
• Cross-checking the sum of sub-meters against the main meter (energy balance)
• Detecting 'flatline' data, which signals a stopped or faulty sensor

An example of a common real-world error, and who owns data quality

For example, at one industrial site, the sum of sub-meter readings over three consecutive months came in about 7% higher than the main incoming electricity meter. Investigation showed one sub-meter had been misconfigured with the wrong current transformer ratio; this discrepancy was only caught because the energy balance was checked automatically every month, and without that cross-check, the error could have gone undetected for months. A catch like this shows why data quality is a shared responsibility across several roles: the instrumentation and maintenance team handles periodic meter calibration, the IT team is responsible for the integrity of data transmission and storage, and the energy manager defines the validation rules and has final say on interpreting data-quality alerts. Without clearly assigning these responsibilities, data-quality alerts tend to get ignored.

Sanity checks before any analysis

Before running any regression model or EnPI calculation, one final, simple check should be done: is this period's data within a reasonable range compared to the same period last year? Have the units been checked once more? Does a sample of the data match the energy bill for the same period?

• The data completeness percentage for the period under review is identified and documented
• Values fall within a physically reasonable range
• No duplicate or out-of-order timestamps exist in the data
• Unit consistency has been confirmed for the whole period, including any manually entered stretches

Finally, these checks shouldn't be a once-a-year exercise; building them into an automated, continuous process is the only way to guarantee that every EnPI number shown to management or an auditor was built from valid data.

Even the best regression model, run on invalid data, just produces the wrong number with high precision.