Shadow Settlement: Catching ISO/RTO Invoice Errors Before They Cost You

Every market participant receives an ISO or RTO invoice that runs to hundreds or thousands of line items, settles real money, and is wrong often enough that accepting it at face value is a quiet form of leakage. The charges are computed by the market operator from data you partly supplied and partly cannot see, and the burden of catching errors falls entirely on you.

Participants who do not independently verify their settlements are leaving money on the table, and the true-up windows that let you recover it do not stay open forever.

The Anatomy of a Settlement Statement

Market charges are organized into charge codes, each representing a distinct product or service: energy, congestion, losses, capacity, ancillary services, uplift, and a long tail of administrative and make-whole charges. Each code has its own formula, its own determinants, and its own data inputs, and a participant of any size will see hundreds of them on a single statement.

Understanding which charge codes drive your bill is the first step, because a one percent error on your largest code dwarfs a hundred percent error on a trivial one. You triage where the money is before you reconcile line by line.

• Energy and congestion charges driven by locational prices and your scheduled and actual quantities
• Capacity and ancillary service charges tied to your obligations and awards
• Uplift, make-whole, and administrative charges allocated by formulas you do not control
• FTR and CRR settlements that hedge congestion and need their own reconciliation

Shadow Settlement Is Independent Recomputation

Shadow settlement means recomputing what your charges should be, independently, from your own copy of the inputs, then comparing that to what the ISO billed. Where the two diverge beyond a tolerance, you have a settlement variance to investigate. The discipline is to do this every billing cycle, not just when a number looks suspicious.

The variances cluster in predictable places: meter data that did not flow correctly, a price that was later corrected, a resource that was mis-mapped to the wrong node, or a determinant the ISO calculated differently than you did. Some are your error, some are theirs, and you cannot tell which until you have recomputed it yourself.

You do not dispute an invoice you cannot reproduce. Shadow settlement is the difference between suspecting a charge is wrong and proving it inside the true-up window.

Meter Data, True-Ups, and the Closing Window

Settlements are not one-and-done. Markets issue an initial statement and then a sequence of true-ups as better meter data and corrected prices arrive, sometimes months later. Each true-up restates charges, and each restatement is another chance for an error to appear or a prior one to be corrected. A variance you let slide on the initial can move again at the final.

Meter data is the most common culprit. If your revenue-quality metering did not reconcile cleanly to what the ISO used, every energy and congestion charge built on it is suspect. Catching that requires holding your meter data and the market data side by side, at interval resolution, across every true-up.

FTR and CRR Settlements Need Their Own Reconciliation

Financial transmission rights and congestion revenue rights are the instruments participants hold to hedge congestion, and they settle against day-ahead congestion between defined points. Their value depends entirely on realized congestion, so verifying FTR and CRR settlements means recomputing the congestion component yourself and confirming the payout matches your position. These are often the largest single variances, and the easiest to miss, because they require joining your rights portfolio to market congestion data.

Doing all of this means continuously joining your meter data, your scheduling and position data, the ISO charge determinants, and published prices, then recomputing every material charge code and surfacing the variances before each true-up closes. It is a data integration problem as much as a settlements problem, and spreadsheets buckle under it.

A no-code AI app builder is a strong fit here. With a tool like DOTA, a settlements team can connect their meter data, position data, and the ISO charge files into one app that recomputes charges by code, ranks variances by dollar impact, and tracks each one across true-ups, turning shadow settlement from a heroic spreadsheet effort into a repeatable monthly control.