Reconciling a California Power Bill

The gate

Most consumer energy calculators cannot tell you whether they would have reproduced your last bill, because they never try. They price a modeled load profile against a simplified rate, and the error disappears into a “typical savings” headline with no residual to inspect.

This engine takes the opposite constraint as its foundation, and enforces it as a merge gate rather than an aspiration:

The residual is one-sided, and that is the point

Every one of the eleven errors is positive: the model runs consistently a little high. A curve-fitted model would have a residual centred on zero. This one has a small, one-directional bias with two known physical causes, both bounded and both recorded:

• Meter-read boundary. Interval sums and the utility's billed kWh differ by about 0.3 kWh per period, because a billing period ends at a meter read time, not at a calendar-day boundary. At residential rates that is roughly $0.10–$0.25 — most of the residual.
• The 2025-vintage franchise fee is still modeled as a percent-of-energy approximation; the 2026 specs use the exact per-kWh rate from Schedule E-FFS. On the two late-2025 statements it shows as a visible +$0.04–$0.05 on that one line.

The errors are physical, not tuned away.

A second tier of evidence, and the line it does not cross

That number is PG&E. On SDG&E the engine has never reproduced a real bill, because no household has yet supplied one — a gap no amount of code closes, restated in §05.

There is a weaker class of public evidence. Every California utility publishes a rate-change notice when rates move, and SDG&E's names a schedule: 400 kWh per month on schedule TOU-DR1, split bundled against unbundled and CARE against standard. Three were filed in 2026, for three different rate vintages. Priced through the same compute_bill the reconciliation uses, the committed TOU-DR1 delivery specs agree with all three: energy rate, Base Services Charge, baseline allowance, baseline credit. It is the only outside evidence of any kind that touches TOU-DR1 — the schedule most SDG&E households are actually on.

The sharpest version of that test assumes nothing about load. Each alert publishes the figure it replaces alongside the one it introduces, so the change is published too. Differencing two vintages cancels everything the document leaves unstated, and the engine's change tracks the published change across every climate zone to within a few cents. A 0.3% error in the delivery energy rate breaks it.

What it is not, stated as plainly as what it is:

• It is not reconciliation, and none of it counts toward the ±$2 figure above. No meter, no billing period, no interval data. A published illustration is an average over an undisclosed population, not a bill that was issued to somebody.
• The document leaves two parameters unstated — how the 400 kWh spreads across time-of-use periods, and which baseline climate zone applies — so both are bounded rather than guessed. An earlier version of this work inferred the climate zone from one quarter's arithmetic; checked against the other two, the inference did not hold, and the test was replaced rather than retuned.
• The generation layer is still untested by anything, and on TOU-DR1 that is where 100% of the time-of-use price signal lives (§04). Every load-shifting and battery conclusion on this schedule rests on numbers no outside document has checked.
• PG&E's equivalent notices cannot be used at all. They quote an average residential bill across every schedule, territory and load shape, which no single tariff spec can reproduce. Recorded for provenance, asserted against never.

These fixtures sit in tests/published_impacts/, deliberately apart from the golden bills, and a test enforces the separation: nothing there may be imported by the engine, so no figure from it can reach anything a visitor reads.

How the engine computes a bill

The bill is a pure function

No I/O, no network, no hidden state, deterministic:

compute_bill(interval_series, [tariff_spec_versions], billing_period) -> itemized Bill

Every utility-specific irregularity lives in a parser or a spec file, never in the billing logic. That is what makes the counterfactual honest: re-simulating the household on a different schedule is the same function with a different spec, not a second code path with its own simplifications.

Bills are computed in layers — delivery, generation, adjustment — because that is how California actually bills. The utility delivers; a Community Choice Aggregator may supply the generation. Separating the layers is what makes the finding in §3 answerable at all.

Tariff specs are data, and they carry citations

Each schedule is a versioned YAML file with an effective date and a citation naming the exact Cal. P.U.C. sheet number and advice letter every number came from. A spec without a citation is invalid. An unknown value is written UNVERIFIED and the loader raises rather than defaulting — an unfinished spec cannot quietly produce a plausible-looking dollar figure.

That rule has already paid for itself twice. Schedule TOU-DR-P is committed and deliberately does not load: it carries a RYU Event Period Adder of $1.16/kWh on event days, and the engine has no concept of an event-contingent charge. Defaulting the event count to zero would make TOU-DR-P the cheapest plan on the board — a free lunch manufactured entirely out of an unmodeled charge. And committing a genuinely incomplete spec exposed a real defect: the loader validated every file in the directory before filtering by schedule, so one half-finished SDG&E spec broke all eleven golden bills.

Rate versions split inside a billing period

A single statement routinely straddles a rate change, and delivery and generation change on different dates. In the case-study year alone: PG&E delivery changed three times, the summer season began 1 June, and the CCA's generation rate changed on 2026-02-15 — a date derived from the household's interval data by finding the split that reproduces the statement's printed peak/off-peak kWh, then confirmed against the CCA's published sheet.

Periods are N-period, day-typed, month-conditional

Time-of-use resolution is an ordered, first-match-wins rule list. SDG&E requires it: three periods, different weekday and weekend windows, and month-conditional carve-outs. Holidays price as weekend days — and the two utilities do not agree on which days those are. Both name the same eight holidays, but PG&E follows federal observance while SDG&E Electric Rule 1 states that a holiday falling on Sunday moves to Monday and no change is made for holidays falling on Saturday. So on 4 July 2026, a Saturday, a PG&E customer gets Friday the 3rd priced off-peak and an SDG&E customer gets nothing.

Two things that look like schema gaps and are not

Flattening PG&E's tiered E-1 to an average would destroy the marginal price signal the optimizer exists to compare. Instead E-1 is expressed through the existing baseline-credit machinery, which is an algebraic identity rather than an approximation:

tier1·min(u,B) + tier2·max(0,u−B)  ==  tier2·u + (tier1−tier2)·min(u,B)
0.32561 − 0.40702 = −0.08141   ← exactly the printed baseline credit

PG&E's own unbundling confirms this is the tariff's real structure: the tier difference is a named component, the Conservation Incentive Adjustment. And SDG&E's non-bypassable charges already sit inside the published energy rate, so the netting logic carves them out of the offsettable subtotal instead of adding a line — no double count.

One household, end to end

Disclosure. This is the author's own account, published deliberately and with attribution. Anonymising it would be theatre — the repository carries my name — and blurring the dates or amounts would destroy the one property that makes the reconciliation worth reading, which is that a third party can check the rates against the tariff sheets. The account is CARE-enrolled, California's low-income discount, disclosed here because the CARE modeling below is one of the more interesting results and cannot be presented honestly with the rate class hidden.

This is not a vanilla bundled account, and that turned out to be the point. The CCA overlay, the PCIA, the generation credit and the CARE discount that the roadmap had deferred to a later milestone were all required immediately, just to reproduce the first bill.

CARE rates are derived, then independently checked

PG&E does not print residential CARE rates in its tariff book. They were solved from the CARE rates appearing on the household's own statements — two parameters, five independent constraints, fitting to ≤1e-5:

care_energy   = 0.65 × standard − 0.01038
care_baseline = 0.65 × standard

The question is whether that is a coincidence of one schedule or a real statewide rule. Three checks say it is real. Applying it to E-1's two printed tier rates yields a CARE tier differential of −0.05291, exactly the CARE Baseline Credit printed on the E-TOU-C statements — a different schedule, a number never used in the fit. SDG&E, unlike PG&E, prints its CARE tables explicitly, and they state “CARE Discount 35%”. And on SDG&E the layer split is not merely consistent but exact: delivery and generation re-sum to the published Total Electric Rate and Total Adjusted CARE Rate on all twelve season × period cells. It remains an assumption on PG&E, and --no-care produces the fully tariff-grounded ranking with no derived rate in it.

The result: switch — but not for the reason anyone expects

Re-simulating the same 4,345 kWh of real intervals under every eligible schedule, at rates in effect today, with the CCA on and off:

The $170.72 a year has almost nothing to do with the rate schedule. The recommended plan is the schedule the household is already on. The whole saving comes from leaving the CCA, and it decomposes cleanly:

The mechanism is checkable on the sheets. A 2018-vintage CCA customer pays a PCIA of 0.03679/kWh, while the 2026 bundled PCIA is −0.01011 — a credit. That ≈4.7¢/kWh gap is wider than the CCA's generation discount, so the CCA has quietly become the more expensive option for this particular vintage. Nothing about the household's usage is unusual: the finding is entirely an artefact of when service started, and generic calculators miss it because they do not model PCIA vintages at all.

What would have to be true for this to be wrong

Reporting a recommendation without its failure conditions is the thing this project exists not to do.

And the largest single driver between schedules is the baseline credit, which E-TOU-C and E-1 have and E-TOU-D does not — not the peak/off-peak spread most rate advice fixates on.

The unverified assumption, and why it cannot change the answer

The statements carry a Utility Users' Tax Adjustment: a municipal credit cancelling most of the gross 8.5% tax, whose mechanism is not derivable from the bills and could not be confirmed from public sources. Five candidate mechanisms were fitted across all eleven statements; a fixed credit of $0.21649 per billing day had the tightest fit — coefficient of variation 0.080, against 0.207 for per-kWh and 0.330 for a fraction of the net bill.

That is adopted, and still marked UNVERIFIED. What makes it safe is not the fit quality but the shape: a per-day credit is schedule-independent, so it shifts every candidate by the same constant and cannot reorder a ranking. The optimizer does not assert this — it re-ranks under all three rival mechanisms and prints all three orders, which are identical. An assumption you cannot verify should be handled by showing it does not matter, not by arguing it is probably right.

The cross-check that is still missing

The milestone asks for a comparison against the utility's own free rate-comparison tool. It could not be completed: PG&E's Rate Plan Comparison sits behind an account login and, for this account, returns “This account has no service agreement eligible for rate enrollment” — most likely because generation is with a CCA. The harness is built and waiting behind a --pge-comparison flag, and the report prints the exact steps to close it. It is listed as open rather than quietly dropped. Four cross-checks that are complete: every rate traces to a Cal. P.U.C. sheet and the unbundled components sum to the printed total exactly on all four schedules; the generation credit derived from the tariff (−0.12699 / −0.10031) reproduces the value independently least-squares fitted from the bills (−0.12705 / −0.10030) to 6e-05; 3CE's published sheet reproduces the bill-derived rates exactly; and the E-TOU-C leg of the ranking is the same engine that reproduces all eleven statements within $0.22.

Five findings a generic calculator misses

These came out of building the engine, not out of looking for marketing copy. Each is checkable from public documents.

What is still assumed, approximate, or unknown

Presented in full, because a methodology writeup that lists only its strengths is marketing.

Blocked on data, not on code

Two milestones have complete, tested engines whose definitions of done cannot be demonstrated. The SDG&E reconciliation needs three real SDG&E bills; the specs are tariff-exact and the layers re-sum to SDG&E's published totals, but no household can currently supply bills or a Green Button export. The NEM 3.0 payback needs one real household with solar and export interval data. None exists.

The demonstration driver therefore runs on a clearly labelled synthetic load — and for that reason no payback figure from it appears anywhere in this document. Its rates, non-bypassable charge set and ACC export tables are all real and cited; the load is not, and a payback number computed on a fabricated load is exactly the kind of figure that survives out of context. The engine is done. The claim is not.

Assumptions carried into published numbers

Known approximations, all under $0.05 per bill

• The 2025-vintage franchise fee uses a percent-of-energy approximation; 2026 uses the exact per-kWh rate from Schedule E-FFS.
• The 2025 summer generation credit is fitted from a single summer sub-period; the 2026 one is tariff-exact.
• The California Climate Credit is modeled as an observed per-bill line rather than a versioned semiannual credit.
• The California Energy Commission surcharge is asserted on PG&E specs and deliberately not asserted either way on SDG&E, whose rate tables show no such column. Adding it unsourced would break the layer-identity test.

Schema limits

Rates carry only standard and care variants, so FERA and the affordable-housing class are not modelable. Per-kWh adders have no CARE variant. There is no tiers concept — currently correct, for the reason given in §2. And where a modeling choice has dollar impact, it is surfaced as a decision rather than made silently: SDG&E baseline allowances are per climate zone, so the territory must be supplied at bill time and omitting it raises rather than defaulting, because a wrong zone silently mis-sizes the largest credit on a California bill.

Reproducing this

conda env create -f environment.yml && conda activate energy-advisor
pytest                                              # over 1,700 tests

PYTHONPATH=src python scripts/reconcile_report.py   # the 11 line-item comparisons
PYTHONPATH=src python scripts/rate_optimizer.py     # ranking, why, sensitivity, assumption audit
PYTHONPATH=src python scripts/nem3_report.py        # NEM 3.0 engine (real rates, synthetic load)

The golden-bill reconciliation is the merge gate: nothing touching the tariff or NEM modules lands while any of the eleven statements is out of tolerance. Real interval exports and bill PDFs are gitignored and never committed; the committed fixtures carry no name, address or account number.