Load reconstruction is the step in solar savings verification where you rebuild what a site's electricity demand would have been without its solar and storage — the gross load — from the net load the meter actually recorded. It's necessary because the meter only ever saw net load: consumption after the panels and battery already shaped it. To build the counterfactual bill that savings is measured against, you need the load underneath that shaping. The reconstruction is straightforward when the underlying data is clean. The reason it gets attention is that the data usually isn't.

This guide explains why reconstruction is needed, where it breaks when interval data is messy, and how the resulting uncertainty should be handled honestly rather than hidden.

#Why load reconstruction is necessary at all

Savings verification compares the actual bill against a counterfactual bill — what the site would have paid with no system. The counterfactual is priced on the site's load, so the counterfactual needs the load the site would have drawn on its own. That number was never metered.

What the meter recorded is net load: the site's real consumption minus solar production, plus or minus battery charge and discharge. To recover the gross load — the consumption as if no system existed — you reverse the system's effect:

Gross load ≈ metered net load + solar production − battery discharge + battery charge

Run that reconstructed gross load through the tariff and you get the counterfactual bill. Get the reconstruction wrong and the counterfactual is wrong, which means the savings number is wrong — even though it still looks like a clean figure. This is why reconstruction sits upstream of everything: it's the input the entire verification rests on.

#Where reconstruction breaks

With complete, high-resolution interval data and fully logged battery dispatch, the reconstruction above is arithmetic. Three real-world conditions turn it into a judgment problem.

#1. Missing or incomplete intervals

The reconstruction is interval-by-interval, because the tariff prices energy by time-of-use period and demand by interval. A gap in the production feed, a monitoring outage, or a meter that dropped intervals means there are periods where one term of the equation is absent. You can interpolate, but interpolation across an on-peak window — where rates and demand peaks are most sensitive — is exactly where a small data gap becomes a meaningful dollar error in the counterfactual.

#2. Incompletely logged battery dispatch

Solar production is usually well instrumented. Behind-the-meter battery dispatch often isn't — charge and discharge may be logged at coarser resolution than production, or inferred rather than directly measured. Since the battery's whole economic job is to move energy across time (shaving a demand peak, shifting energy out of an expensive window), an error in when the battery acted lands directly on the charge types that matter most: demand and TOU energy. A reconstruction that misplaces battery activity by an interval can misattribute where the savings came from.

#3. Parasitic and unmetered loads

The monitoring platform sees what it's wired to see. Parasitic loads, auxiliary equipment, or sub-metered circuits the platform doesn't capture mean the reconstructed gross load can quietly understate or misshape the site's real demand. These don't announce themselves — they show up as a counterfactual that doesn't quite reconcile with the site's history.

In all three cases, note what's at stake: not whether the system produced (monitoring answers that), but whether the counterfactual is faithful enough to trust the savings delta computed from it.

#Resolution matters because the tariff is time-sensitive

Why insist on interval data at all, rather than monthly totals? Because the tariff prices time, not just quantity.

A flat-rate tariff could be reconstructed from monthly kWh. But C&I tariffs price energy by TOU period and bill demand on the single highest interval — so a kilowatt-hour shifted from off-peak to on-peak, or a peak that lands inside the utility's coincident-demand window, changes the bill substantially even when the monthly total is identical. Reconstruct at 15-minute resolution and you can place each kilowatt-hour in the right window. Reconstruct from daily or monthly totals and you lose the timing the tariff is built around — which is fine on a flat-rate site and lossy on a TOU-and-demand site, precisely the sites where solar and storage savings are largest.

This is the core reason monthly-total reconstruction isn't a substitute on the sites that matter most.

#How uncertainty should be handled: flag it, don't bury it

The honest response to messy data is not to produce a confident number anyway. It's to compute the counterfactual at the best available resolution and surface the precision impact — to say which sites were reconstructed from clean interval data and which were reconstructed from coarser data with a known loss of fidelity.

That distinction is what separates a verification number you can defend from one you can't. A savings figure carried into an LP report or a refinancing should come with its provenance intact: this site's counterfactual was built from complete 15-minute data; that site's had a three-day production gap interpolated across an off-peak window with negligible impact; this other one was reconstructed from hourly data with a flagged precision caveat on its TOU components. The number and its confidence travel together.

A pipeline that silently interpolates and reports a clean figure regardless is producing the same false precision the whole point of verification was to eliminate.

#What this requires upstream

Practically, reconstruction quality is set by the data you can feed it. The verification is most precise with interval-level production and net battery-discharge data, ideally at 15-minute resolution. Where that's available, the counterfactual is faithful. Where it isn't, the work can proceed from 1-hour or daily totals — with a documented loss of precision on TOU-sensitive sites, flagged in the output rather than smoothed over. The reconstruction doesn't fail on imperfect data; it degrades, visibly, by design.

This is the input side of building a counterfactual bill — for what the counterfactual is and how it becomes a savings number, see what is counterfactual billing.

#What Tariform does

Verify reconstructs each site's gross load as the first step in building its counterfactual bill. It takes metered net load together with production and battery-dispatch data, reconstructs the load the site would have drawn without the system, and prices that load on the tariff actually in effect to produce the counterfactual. Where interval data is complete, reconstruction runs at full resolution; where it's incomplete, Verify works from coarser data and flags the precision impact on the affected sites and charge types rather than hiding it. Every counterfactual value traces back to the load input and tariff component behind it.

If your verification needs to handle real-world data — gaps, coarse dispatch logs, parasitic loads — without quietly inventing precision, that's what Verify is built to do. Book a demo — twenty minutes, your portfolio, you see the variance breakdown.

#FAQ

Where do the production and dispatch numbers actually come from?
Solar production comes from the inverter or monitoring platform; battery charge and discharge come from the storage system's EMS or controller logs. Production is usually well instrumented at fine resolution; dispatch logging is the weaker link — often coarser or inferred — which is why the battery terms are where reconstruction error most often enters.
How do you reconstruct load for a solar-only site with no battery?
It's the simpler case: gross load ≈ metered net load + solar production, with no charge/discharge terms to account for. Fewer moving parts means fewer places to go wrong, though the interval-resolution and missing-data concerns still apply, because the tariff still prices by time.
What if solar production data is missing — can it be estimated?
It can be modeled from system specs and irradiance (a PVWatts-style estimate) as a fallback, but that substitutes a modeled term for a measured one and adds uncertainty to the gross load. Like coarse data, it's workable — provided the added imprecision is flagged on the affected site rather than presented as a clean measurement.
How do you check that a reconstruction is actually right?
Sanity-check it against the site's pre-installation billing history — the reconstructed gross load should resemble the load shape the site drew before the system existed. A counterfactual that doesn't reconcile with that history is the usual sign of a missing term: unlogged dispatch, an unmetered load, or a data gap.
Does exported (net-metered) energy complicate the reconstruction?
Yes. When production exceeds on-site demand the net meter records export — net load goes negative — and the reconstruction has to handle that interval correctly so the gross load and the export aren't conflated. Getting it wrong distorts both the consumption the counterfactual prices and the credit side of the actual bill.