A 40-site C&I solar portfolio. Underwritten at $4.1M of customer savings per year. Eighteen months post-COD, the asset manager asks the operator a question that should be easy: did the sites actually save what we said they would?
The honest answer is "we think so, mostly." The operator's monitoring platform shows production. The financial model projected savings. Nobody has compared the projected savings against the actual utility bills — for forty sites, every month — because doing it by hand would take a full FTE. So the savings number in the quarterly investor report is the modeled number with a footnote.
The footnote is the problem. It doesn't survive the first audit, the first refinancing, or the first PPA dispute. And it hides the fact that three sites in the portfolio are underperforming their savings projection by 18% because the host customer was switched to a new tariff in February and nobody noticed.
This guide is about closing that gap — turning "we think so, mostly" into "here is the bill, here is the counterfactual, here is the delta, here is what drove it." Site by site, month by month, across the portfolio.
#What "utility bill verification" actually means
Bill-level savings verification answers one question: for this specific utility bill, on this specific site, in this specific service period, how much did the solar-and-storage system save the customer?
The answer requires two numbers, both grounded in the actual bill.
The actual bill. What the customer was charged this month, line item by line item — energy by TOU period, demand by window, fixed charges, riders, taxes. This is the easy half if you have a good utility-bill extraction pipeline, the hard half if you're hand-keying.
The counterfactual bill. What the customer would have been charged this month if the system had not been there. Same tariff, same service period, same fixed and demand charge structure — but with site load reconstructed as if the solar and battery had produced nothing. This is where most verification work falls down.
Savings is the delta: counterfactual total minus actual total, broken out by charge type. Not a single number. A line-item comparison that tells you whether the savings came from energy reduction, demand reduction, TOU arbitrage, or some combination — and whether each component matched what the underwriting model promised.
This is different from production monitoring (which tells you the system worked) and different from modeled savings (which tells you what it should have saved on paper). It is the only number that maps to dollars the customer can see on the bill.
#Why this is operationally hard at portfolio scale
A single site, one bill, with a clean tariff and a competent analyst on the case — you can verify savings by hand in an afternoon. The problem is that nobody operates one site.
Tariff catalog scale. A 40-site portfolio spans 12+ utilities. Each utility has dozens of C&I tariffs. Each tariff has its own TOU windows, demand charge structures, rider pass-throughs, and rate-change history. A counterfactual bill calculator that doesn't model all of them silently produces wrong numbers on the sites it can't handle. Worse, it doesn't tell you which sites those are.
Counterfactual load reconstruction. To compute what the bill would have been without the system, you need to know what the load would have been without the system. You have the metered consumption (post-solar net load). You have the production data. Reconstructing gross load is straightforward when interval data is clean and complete — and a meaningful headache when intervals are missing, when the battery's behind-the-meter dispatch isn't fully logged, or when the site has parasitic loads the monitoring platform doesn't see.
Recalculation cadence. Bills arrive monthly. Tariffs change monthly. Site behavior shifts seasonally. Verification has to run on a monthly cadence across every site, or it isn't verification — it's a one-time spot check.
The work is not conceptually difficult on any single site. It is operationally impossible at portfolio scale without infrastructure built for the job.
#The three failure modes verification catches
A portfolio that isn't running bill-level verification is running blind to three specific things. They all cost money, and they all stay hidden until something else forces them into the open.
#1. Savings drift the monitoring platform can't see
Production monitoring tells you the system is producing kWh. It does not tell you whether those kWh are translating into the dollar savings that were underwritten. A site can produce exactly its expected output and still under-save because the tariff economics shifted underneath it.
Two ways this happens, both common:
The utility changed the tariff. A site that was on Schedule A-6 in March is on A-6 (Revised) in April. The TOU windows might have shifted by ninety minutes. The demand ratchet might have changed. A verification pipeline that pinned the tariff at COD and never updated will show savings that look stable but are increasingly fictional.
The customer changed the tariff. Host customers switch tariffs without telling the operator. The site moves from a TOU demand tariff to a flat demand tariff because the customer's account manager at the utility recommended it. Savings drop 30% the next month — not because the system underperformed, but because the savings opportunity changed. If you don't catch the switch, you spend three months investigating a phantom asset issue.
Verification catches both on the first bill after the shift. Monitoring catches them never, because nothing about production looks wrong.
#2. Utility billing errors
Utilities make mistakes. Demand charges get billed against the wrong window. Net metering credits get applied at the wrong rate or assigned to the wrong service period. TOU readings get tagged to the wrong tier when a new meter is installed. Estimated reads stack up and the eventual true-up swings savings by thousands of dollars on a single bill.
Without line-item verification, these errors land in the customer's bill, the operator's savings report, and the asset manager's quarterly summary — uncorrected. A verification pipeline that reconstructs the bill independently and compares against what the utility actually charged will flag them on the bill they occurred on. Recovery is a phone call. Without verification, the conversation never happens.
#3. Underperformance the PPA settlement misses — and the report you can't write without it
PPA settlements are typically computed on production, not savings. The customer pays for kWh delivered. But the underwriting case for the project was savings — that's what made the deal attractive to the host and the financier. When actual savings fall below underwritten savings while production stays on plan, the PPA still pays the operator the contracted rate, but the host customer's enthusiasm for the next site cools, the asset's resale value softens, and the LP relationship gets quieter.
This is the failure mode the asset manager feels. They don't run the operations, but they read the quarterly report and ask three things: Is the portfolio tracking to the underwriting case? Which sites are off, and by how much? What's the audit trail? A 5% portfolio shortfall might be twenty sites at -2% or two sites at -50%. The first is a margin issue; the second is an operations failure. Modeled savings can't answer any of these questions, because modeled savings is the underwriting case. "We trust our model" is not an audit trail.
Catching this in month three means adjusting battery dispatch, recommending a tariff switch, or identifying a behind-the-meter load anomaly. Catching it in month eighteen, in front of a refinancing committee, is the same problem at 10x the cost.
#What the verification output looks like
For every site, every month: an actual bill extracted and line-itemized, a counterfactual bill reconstructed against the tariff in effect for that period, and the charge-by-charge delta between them — energy, demand, TOU, NEM credits — rolled up to a total savings number with site-level variance against the underwriting case. Every value traces back to its source: the PDF line for the actual bill, the tariff component and load input for the counterfactual. The deliverable isn't a number. It's a reconciliation.
#How this differs from monitoring, modeling, and M&V
Three adjacent things get conflated with bill verification. They are not the same.
Production monitoring tells you the system worked. It measures kWh produced, battery state of charge, inverter availability. It does not touch the utility bill. A site can be at 100% on monitoring and 60% on bill-verified savings — and most monitoring platforms will never tell you.
Modeled savings tells you what the system should have saved on paper. It runs the underwriting case — itself built on a pro-forma baseline — forward: production model times tariff times time. Modeled savings is what gets reported when bill verification isn't running. It is also what diverges from reality the moment the tariff or the load changes.
IPMVP-style M&V is a measurement-and-verification protocol for energy efficiency projects, adapted by some operators for BTM storage. It compares pre- and post-installation energy use against an adjusted baseline. It is rigorous, but it is energy-focused — it doesn't natively handle TOU arbitrage, demand charge shaving, or net metering credit valuation, all of which are bill-level economic effects that don't show up in kWh totals.
Bill-level verification sits downstream of all three. It uses production data (from monitoring), validates against the underwriting case (from modeling), and complements energy-based M&V (with dollar-based reconciliation). It is the only one of the four that maps directly to what the customer paid and what the financier underwrote.
#What Tariform does
Tariform is a utility-bill intelligence platform with two products built on a shared foundation.
Verify is what this guide is about. For each site in a C&I portfolio, every month: the actual utility bill is extracted and reconciled, the counterfactual bill is reconstructed using Genability's US and Canadian tariff catalog and rate calculation engine, and the line-item delta is reported. Portfolio-level KPIs roll up; site-level drill-down lets the operator investigate any variance. Recalculation runs on a monthly schedule against new bills as they arrive. Every number is traceable — to the source PDF for the actual bill, to the tariff component and load input for the counterfactual.
Extract is the other half of the platform — the same extraction engine, packaged for project finance analysts, energy consultants, and C&I solar sales engineers who need structured bill data for pro-formas, proposals, and audits. Different buyer, different question, same backbone.
If the savings number in your last quarterly report had a footnote, that's what Verify replaces. Book a demo — twenty minutes, your portfolio, you see the variance breakdown.




