Counterfactual billing is the reconstruction of what a site's utility bill would have been in a given month if its solar or storage system had not been there — same tariff, same service period, same demand and fixed-charge structure, but with the site's load modeled as if the system produced nothing. It's the second of the two numbers savings verification needs. The first is the actual bill the customer was charged. The savings is the delta between them, broken out charge by charge. Without the counterfactual, you have a bill but nothing to measure it against — you know what was paid, not what was avoided.

This guide explains what a counterfactual bill is, why it's the hard half of savings verification, and how it's constructed.

#Why savings verification needs two bills

Savings is a comparison, and a comparison needs two terms. Verifying what a solar-and-storage system saved on a specific bill requires both:

  • The actual bill — what the customer was charged this month, line by line: energy by time-of-use period, demand by window, fixed charges, riders, credits, taxes. This is the system with solar and storage in place.
  • The counterfactual bill — what the customer would have been charged this month with no system: the same site, same tariff, same period, but with load reconstructed as if the panels and battery produced nothing.

Savings is the counterfactual total minus the actual total — and, more usefully, the difference taken charge by charge, so you can see whether the savings came from energy offset, demand reduction, TOU arbitrage, or net-metering credits. A single savings number tells you how much. The line-item delta tells you why, which is what lets you check the savings against the underwriting case.

The actual bill is the easy half if you can extract it cleanly. The counterfactual is where verification actually gets hard.

#Why the counterfactual is the hard half

To compute what the bill would have been without the system, you need to know what the load would have been without the system — and that's not something any meter recorded. The meter measured net load: consumption after solar and battery already shaped it. The counterfactual requires the gross load underneath.

Reconstructing gross load means adding back what the system did. Take the metered net load, add the solar production, account for the battery's behind-the-meter charge and discharge, and you have an estimate of what the site would have drawn on its own. That estimate is clean when interval data is complete and the battery's dispatch is fully logged — and a real headache when intervals are missing, dispatch isn't fully captured, or the site has parasitic loads the monitoring platform never saw. (How to handle that messiness is its own subject — see how to reconstruct load for savings verification.)

Then the reconstructed load has to be run through the tariff correctly. Which brings in the second source of difficulty.

#The tariff has to be right, and it changes

A counterfactual bill is only as good as the tariff it's computed against. The reconstructed load has to be priced on the exact tariff in effect for that service period — the right TOU windows, the right demand structure, the right riders, the right rates. Three things make this harder than it sounds:

  • Tariff scale. A portfolio spans many utilities, each with dozens of C&I tariffs, each with its own TOU windows, demand structures, and rider pass-throughs. A counterfactual calculator that doesn't model the specific tariff a site is on produces a wrong number — quietly.
  • Tariffs change. The tariff in effect this month may not be the one in effect at commissioning. A counterfactual pinned to the original tariff drifts from reality every time the rate changes.
  • Mid-cycle changes. A bill spanning a rate-change date has to be computed against both rates, pro-rated by the days each covered — the same way the utility computes the actual bill.

Get the load right and the tariff wrong, or the tariff right and the load wrong, and the counterfactual is off — which means the savings number is off, in a way that looks authoritative because it's still a precise figure. Precision is not accuracy here.

#Counterfactual billing vs. modeled savings

It's worth drawing the line between the counterfactual and the modeled savings number it's often confused with, because they sound similar and aren't.

Modeled savings runs the underwriting case forward: an assumed production profile times an assumed tariff. It's built before the bill exists and fixed at the assumptions made at close.

A counterfactual bill is built backward from the actual month: it uses the real metered load, the real production, and the tariff actually in effect, to reconstruct the specific alternative reality of "this site, this month, no system." It's grounded in what happened, not what was projected. (For the full distinction, see modeled savings vs. verified savings.)

That grounding is the whole point. The counterfactual is what makes verified savings a reconciliation against reality rather than a projection — it's the term in the comparison that keeps the savings number honest as the tariff and load drift from the underwriting assumptions.

#What the counterfactual makes possible

Once you have a correct counterfactual bill alongside the actual bill, the savings stops being a single asserted number and becomes a breakdown you can interrogate:

  • How much was saved, as the total delta.
  • Where it came from — energy, demand, TOU, NEM credits — as the per-charge delta.
  • Whether it matched the underwriting case, by comparing each component against what the model promised.
  • What drove a shortfall, because a collapsed delta in one charge type points to its cause: a rate change, a missed peak, a NEM step-down, a billing error.

That's the difference between "the system saved about what we expected" and "here is the bill, here is the counterfactual, here is the delta, here is what drove it." The counterfactual is the term that makes the second statement possible.

#What Tariform does

Verify builds the counterfactual for every site, every month. It extracts the actual bill, reconstructs the site's gross load from production and battery-dispatch data, and computes the counterfactual against the tariff actually in effect using a US and Canadian tariff catalog and rate engine — handling tariff changes and mid-cycle rate splits the way the utility does. The line-item delta between actual and counterfactual is the verified savings, with per-site variance against the underwriting case. Every value traces back: the PDF line for the actual bill, the tariff component and load input for the counterfactual.

If your savings number doesn't yet have a counterfactual behind it, that's the gap between an estimate and a reconciliation. Book a demo — twenty minutes, your portfolio, you see the variance breakdown.

#FAQ

Is the counterfactual a bill the utility issues, or a separate calculation?
A separate calculation. The utility only ever issues the actual bill — the one reflecting the system in place. The counterfactual is computed independently: the reconstructed gross load priced on the same tariff and service period, the way the utility would have billed it had no system existed. It's an estimate, only as good as the load and tariff behind it.
For it to be defensible, does the counterfactual have to be reproducible?
Yes — that's the point of a verified number. A counterfactual that can't be traced back to its load input and the specific tariff component it priced is just another asserted figure. Defensibility means a third party can take the same inputs and arrive at the same counterfactual, which is what lets it stand up in an audit or a dispute.
How is a counterfactual different from a baseline?
A baseline — as in a pro-forma or IPMVP-style M&V — is a historical reference period you adjust and carry forward. A counterfactual is recomputed for each actual month on the tariff in effect that month: not a fixed reference but a fresh "no-system" reconstruction of the specific month being verified, which is why it doesn't drift as the tariff changes.
What if the actual bill itself contains a utility error?
The error sits on the actual side, so the delta against a correctly computed counterfactual comes out wrong — which is exactly what surfaces it. A demand charge billed against the wrong window, or a credit at the wrong rate, makes the savings look off in a specific charge type, pointing at the error rather than hiding it. See producing on plan but saving less.
How do you build a counterfactual for a site with no pre-solar billing history?
You don't need historical bills — the counterfactual is reconstructed from system-era telemetry, by adding production and battery dispatch back to the metered net load to recover gross load, then pricing it on the current tariff. New-construction or day-one solar sites are handled the same way; what's lost is the pre-install history that would otherwise serve as a sanity check, so reconstruction quality matters more.