Why Most Renewable Energy KPIs Are Inaccurate

In renewable energy operations, a familiar scenario plays out more often than anyone likes to admit. Someone pulls up the analytics platform, reviews the performance report, and the numbers look reasonable. Then someone else, a new manager or team member, starts digging into the underlying data, and things don’t add up.

Production figures don’t reconcile with meter readings. Performance ratios at the plant level don’t line up with the inverters. KPIs that should match across systems, don’t. The report was built in good faith, but the data behind it isn’t what it appears to be.

The problem usually starts much earlier in the chain than most operators realise.  

 

If you want the truth, go to the original source 

Everyone knows that electricity loses energy as it travels. The longer the distance, the more energy is lost along the way. Data works the same way. The further it gets from the source, the less accurate it becomes.

At a solar plant, energy starts at the panels and moves through string combiner boxes, inverters, and transformers before reaching the point of interconnection (POI) and is measured by the revenue meter. At multiple steps in the chain, the energy is transformed — DC to AC, low voltage to high — and some is lost in the process.
.
An analogous principle applies to operational data. Every intermediary system the data passes through, like a SCADA, a BMS, a historian, a DAS or logger, transforms it in some way and valuable data is lost in the process. By the time data reaches your analytics platform, it’s passed through systems that weren’t designed with your analytics needs in mind. Getting data from the source is the obvious fix. Most teams just don’t know it’s possible. 

 

 

 

What Goes Wrong, and Where  

The SCADA wasn’t built for your analytics.  

SCADA systems are control systems designed, configured, and installed by engineers whose job was to make the plant run. The tag list your SCADA exposes was configured, typically years ago,  prior to the commercial operation date (COD). It reflects what was needed to operate the plant or what the engineer assumed operators would later be interested in. This was almost certainly long before AI-driven analytics were part of the picture. And it was likely before anyone asked what data your analytics platform would need to accurately calculate performance ratio, diagnose underperformance, or compare production across a portfolio. The tags that would be useful for analysis may simply not be there.
.
Sampling rate is the same story. Your SCADA might be polling equipment every five minutes because that was cost effective and deemed sufficient for control purposes when it was configured. If your SCADA is polling irradiance sensors every five minutes, a passing cloud that drops irradiance for 90 seconds gets averaged out of the record entirely. Your performance ratio calculation for that period treats the plant as if it was operating in full sun, making the output look worse than it was.
.
Beyond the SCADA, many plants have additional layers. Historians, DAS, smart loggers, each applying arbitrary rules about what data to pass on, at what frequency, and how to handle gaps.
.
The engineers who configured your control system were focused on building the plant, not operating it. Plants and portfolios often change hands during their life cycles. They can be developed by one company, sold to an operator, and then acquired again down the line. There’s no way an EPC contractor could anticipate what a future owner’s analytics team would need. Construction and operations are different disciplines, and the handoff between them can be where a lot of data quality problems are quietly baked in. 

 

Inaccuracies compound.  

A stressed SCADA system will drop data collection to protect core control operations, allowing gaps to enter the record. Each system the data passes through adds its own compromises. By the time something like performance ratio or state of charge appears on a dashboard or report, it may have inherited compromises at multiple steps of the journey from source to screen. No single step is catastrophic, but the cumulative effect can be significant and largely invisible. The data looks complete and reports generate without errors. Nothing flags that last week’s performance ratio was calculated from interpolated values filling a gap created by a loss of connectivity — values that would have changed the result if the full data had been available.   

  

Most Teams Assume This Is Just How It Works 

Most operators know their data isn’t perfect. They’ve seen the discrepancies and had the uncomfortable moment when a meter reading doesn’t match what the dashboard reported. Over time, teams build manual processes to compensate. Data cleansing routines get built to catch known errors — clamping out-of-range values, dropping duplicate timestamps, and back-filling gaps with interpolation or last-known-good values. Valuable time is spent reviewing and correcting reports before they go out. It becomes a layer of invisible work that happens every day, just to get the data to a point where analysis is trustworthy.
.
It’s assumed that fixing this would mean reconfiguring the SCADA, which is harder than it sounds. That typically means coordinating across teams, calling in the original SCADA vendor, and paying to reconfigure a system that was considered done at handover. It may even include an entirely new round of acceptance testing of the plant control system. So, the workarounds stay and gradually become part of the workflow.
.
And that only solves it for one plant. With very few exceptions, every plant SCADA is configured differently. There is no portfolio-wide fix.  Those workarounds accumulate alongside the portfolio. Ten sites are manageable. At fifty, the inconsistencies multiply.
.
Different SCADA configurations, different tag names, different sampling rates, all feeding into a single analytics platform trying to produce consistent KPIs from fundamentally inconsistent data.
.
At some point, someone digs into the details. An investor asking why performance ratio dropped, a due diligence process requiring clean auditable data. Those conversations are uncomfortable, but the real cost is the underperformance that went undetected while the data was too unreliable to trust. Every fault that wasn’t caught early represents revenue that wasn’t recovered. Investors care about data quality because inaccurate data means missed production and lost revenue. 

 

Getting Data from the Source  

The default approach is to have your analytics platform to do its best with whatever data the SCADA provides. The better way is to use the data that will optimize your analysis, so you can optimize the performance of your plant. That means collecting directly from the equipment, before anything has been processed or filtered by a system that wasn’t designed with your analytics needs in mind.
.
The real power comes from managing all of this centrally, through a unified configuration layer. Tag lists, units of measure, and sampling frequencies should be defined once, applied consistently across every site in the portfolio, and updated as needs change—without vendor involvement. If your analytics requirements evolve, or you bring in a new tool with different data needs, you simply update the configuration rather than re-engineering data flows at each site. And because every site is collecting data the same way, your KPIs mean the same thing regardless of which plant they came from. This is a consistency that is easy to underestimate until you’re trying to aggregate performance across a mixed portfolio and realise each site has been measuring slightly differently all along. 

 

The Question Worth Asking  

Scratch the surface of most renewable energy analytics problems and you’ll find a data problem underneath. Before investing in a more sophisticated analytics platform, ask a foundational question: how much time is your team spending cleaning and correcting data just to make it usable? If the answer is significant, that’s where to start. Better tooling built on unreliable data produces more sophisticated, yet still unreliable results. It will be better to start solving the problem at its source.