A solar PPA savings true-up is the periodic reconciliation that checks whether a power purchase agreement actually delivered the savings it promised — the host customer's guaranteed discount against what they would have paid the utility without the system — and settles the difference. It needs three numbers for every period: what the customer paid the developer (the PPA invoice), what they paid the utility (the actual bill), and what they would have paid with no solar or storage at all (the counterfactual). The first two are documents you can collect. The third has to be reconstructed against the tariff in effect — and that reconstruction is where a true-up quietly goes soft, or stops happening altogether.

This guide explains what a savings true-up actually reconciles, why the counterfactual is the number that decides the settlement, where true-ups go wrong, and what it takes to produce one a developer and a host can both sign.

#What a savings true-up reconciles

A PPA with a savings guarantee promises the host that its all-in cost of energy will come in below the do-nothing case by some margin. "All-in cost with solar" is not one bill — it's the PPA payment plus the reduced utility bill the site still gets. So the true-up compares two totals:

Without the system (counterfactual) With the system (actual)
Utility bill Full bill on the pre-solar tariff and load Reduced utility bill, extracted from the PDF
PPA payment — What the host paid the developer for solar kWh
All-in cost Counterfactual utility bill Reduced utility bill + PPA payment

Realized savings is the counterfactual minus the all-in actual cost. If a guarantee is in play and realized savings fall short, the developer typically owes a make-whole payment to close the gap. That settlement is the whole point of the exercise — and it rests entirely on a number that isn't printed anywhere: the counterfactual.

#Why the counterfactual decides the settlement

Two of the three inputs are evidence. The PPA invoice is what the developer billed. The actual utility bill is a document you can extract line by line. Nobody argues about those.

The counterfactual is the one number that has to be built, and it's the one the settlement turns on. Move the assumed tariff, the load shape, or the demand peak even slightly and the do-nothing total moves — and with it, whether the guarantee was met and who owes whom. A true-up is only as defensible as its counterfactual. When a make-whole payment is on the line, "trust our spreadsheet" is not an answer the paying party accepts.

This is also why the modeled number can't stand in for it. The savings projected at financing was the right tool to size the deal, but it drifts the moment the tariff or load changes — and a true-up settled against a stale projection settles against fiction.

#Where true-ups go soft

Most savings disputes don't come from a bad system. They come from a soft counterfactual or a true-up that was never built to be inspected.

  • The blended-rate shortcut. Reconstructing the do-nothing bill as average ¢/kWh × kWh erases demand charges, ratchets, and TOU structure — exactly the charges solar and storage move most. The counterfactual ends up understating avoided cost, and the guarantee looks missed when it wasn't (or vice versa).
  • Tariff drift. The host's tariff changes, gets a rate revision, or the customer switches plans after signing. A counterfactual frozen at the contract's assumptions reconciles against a rate that no longer exists.
  • A stale baseline. Using one pre-install bill as the template for every future period bakes one season's load and one rate snapshot into every true-up. (Building one that holds up is its own discipline — see defensible solar pro-forma baseline.)
  • No line-item trail. A true-up that produces a single savings figure with no breakdown can't answer "which charge type drove the shortfall?" — so a disagreement has nothing to resolve against except two opposing totals.

#What a defensible true-up requires

The same thing verified savings requires in general: the actual bill, a properly reconstructed counterfactual, and the line-item delta between them — produced per site, per period, with provenance.

  1. The actual utility bill, extracted — energy by TOU period, demand, fixed charges, credits, taxes.
  2. The PPA invoice for the period, as paid.
  3. A counterfactual bill reconstructed against the tariff actually in effect that period — full rate structure, not a blended average — on the load the site would have drawn without the system. That load often has to be reconstructed from interval data.
  4. The settlement math: counterfactual − (actual utility bill + PPA payment) = realized savings, compared to the guarantee.
  5. A line-item trail so a shortfall resolves into which charge type and which period — and every figure points back to its source.

Done by hand across a portfolio of PPAs, this is the work that slips: the annual true-up arrives, the counterfactual gets rebuilt under time pressure, and corners get cut on the one number the settlement depends on. Done with infrastructure built for it, it runs as the bills arrive.

#What Tariform does

Verify produces the reconciliation. For each PPA site, every period, it extracts the actual utility bill, reconstructs the counterfactual against the tariff in effect using a US and Canadian tariff catalog and rate engine, and reports realized savings as a line-item delta — energy, demand, TOU, credits — that you net against the PPA payment and test against the guarantee. Every number traces to its source: the PDF line for the actual bill, the tariff component and load input for the counterfactual. It's the same machinery described in utility bill verification for solar and storage, pointed at the contractual true-up.

If your next savings true-up will decide a make-whole payment, the counterfactual is the number worth getting right. Book a demo — twenty minutes, your portfolio, you see the reconciliation broken out by charge type.

#FAQ

What's the difference between a savings true-up and a production guarantee?
A production guarantee checks whether the system generated the promised kWh — an energy question, answered from the meter. A savings true-up checks whether the host realized the promised dollars, which depends on the tariff, demand charges, and TOU structure, not just output. A system can hit its production guarantee and still miss its savings guarantee when the tariff shifts or demand charges don't get shaved as modeled; a site can produce on plan and still save less.
Is the counterfactual the same as the baseline from the original pro-forma?
No, and conflating them is a common source of disputes. The baseline is the pre-install snapshot used to size the deal, fixed at financing. The counterfactual is rebuilt every period on the tariff and load actually in effect then, so it tracks the rate changes and plan switches the baseline can't. The baseline is where the deal started; the counterfactual is what each period is actually settled against.
How do net-metering credits and exported solar factor into a true-up?
They land on both sides, and the treatment has to be consistent. The actual utility bill already reflects NEM credits for energy the system exported; the counterfactual, by definition, has none, because there's no system exporting. Crediting exports in the counterfactual, or missing them in the actual bill, is one of the easier ways to silently inflate or understate realized savings — which is why each credit has to trace back to its source line.
Does a savings true-up apply only to PPAs, or also to leases and ESAs?
The mechanism is the same wherever a contract promises a dollar outcome. A PPA prices solar per kWh, a lease charges a fixed payment, an energy-services agreement bills for delivered savings — but each can carry a savings guarantee, and verifying it always reduces to the same reconciliation: actual all-in cost against a reconstructed counterfactual. Only the "what the customer paid the provider" line changes shape.
Who is the savings true-up for — the developer or the host?
Both, and that's exactly why it has to be independently defensible. The developer needs it to confirm a guarantee was met and to scope any make-whole payment; the host needs to trust that the do-nothing number wasn't shaded in the developer's favor. A line-item reconciliation traceable to the source bill is what lets both sides rely on the same figure.
How often should a PPA savings true-up run?
Contracts usually settle annually, but the counterfactual should be built per bill, monthly, and rolled up. Per-bill reconciliation catches a tariff change, plan switch, or billing error on the first bill it appears on — while it's still cheap to address — instead of surfacing eleven months of accumulated drift at the annual settlement.