Wholesale Power Settlements and Shadow Settlement Software: Why the ISO Invoice Error You Find in August Is Already Uncontestable

The variance found three weeks too late

A load serving entity with generation in two markets receives a settlement statement carrying several hundred charge codes. The back office loads it into Excel, compares each line against the prior month, and investigates anything that moved more than a few percent. It is a reasonable process and it is what most organisations do.

This month a rarely triggered uplift charge appears at six figures. It looks plausible because the month had a scarcity event, and it sits inside the noise of a heavier bill. Three weeks later an analyst who happens to be reconciling something else notices that the allocation basis looks wrong for one of the assets. She is right. The ISO applied the charge against a resource that was on a forced outage.

The dispute window closed nine days earlier. The money is gone, and it is gone quietly, which is the part that stings. Nobody made a mistake in the sense of doing something wrong. The process simply cannot find an error faster than the calendar closes.

That is the entire argument for shadow settlement. It is not about distrusting the ISO. It is that charge code formulas are complex, inputs are numerous, and the only way to know your invoice is right is to compute it independently before the clock runs out.

Problem one: variance analysis on totals cannot find allocation errors

Comparing this month's charge code totals against last month's is a smoke detector, not a settlement process. It catches step changes and misses everything that is proportionally normal. Allocation errors, wrong resource attribution, meter data that arrived late and was estimated, and formula changes applied from a tariff amendment all produce numbers that look reasonable at the total level.

The only reliable detection is recalculation from inputs. You take the formula as defined in the tariff and the business practice manuals, assemble the same inputs the ISO used, compute what the charge should be, and compare line by line at the granularity the statement provides. Where your number and theirs differ, you have either found an ISO error or a gap in your own data, and both are worth knowing before the deadline.

The practical shortcut that makes this affordable: charge codes follow a steep distribution. In most portfolios a few dozen charge codes account for the overwhelming majority of the dollars, and those are the ones to recalculate first. Rank your last twelve months of statements by absolute dollars per charge code and the first release scope writes itself.

Problem two: assembling the inputs is most of the work

Recalculation is arithmetic once the data is in one place, and getting it there is the actual project. A single charge might need settlement quality meter data from your meter data agent, day ahead and real time market results and prices from the ISO, your own submitted offers and bids, ancillary service awards, outage records, and the resource registration data that determines which allocation bucket you sit in.

Those arrive on different schedules, in different formats, from different systems, and some of them get restated. Meter data corrections in particular flow through after the fact and quietly change the basis of a calculation you already performed. A settlement engine that does not track the vintage of every input will produce a recalculation that disagrees with itself between runs, and analysts will stop trusting it within a month.

The design that works stores every input as a dated, versioned observation, records which version each calculation run consumed, and can re-run any period against either the original inputs or the current ones. That distinction, between what you knew then and what you know now, is what makes the tool defensible in a dispute conversation.

Problem three: the calendar has more than one deadline

ISOs do not settle once. Statements arrive as an initial calculation and then get restated, with ERCOT publishing initial, final and true up statements where the true up lands months after the operating day, and other markets running their own recalculation cycles on their own calendars. Each publication opens its own dispute window, and those windows are measured in days after the statement rather than months.

Three things follow. First, the deadline clock has to be a first class object in the system, per statement, per market, with alerts that fire early enough for a human to investigate. Second, restatements have to be diffed against the prior version so you can see what the ISO changed and whether it moved in your favour, which nobody does reliably in spreadsheets. Third, an issue found and disputed at the initial statement may still change at true up, so a dispute has a lifecycle rather than an outcome.

Problem four: allocation is where the manual work explodes

Getting the ISO number right is only half the job. The settled amount then has to reach the right internal home: allocated to a specific generating asset, split between joint owners under an operating agreement, attributed to a bilateral contract or a retail book, matched against the hedge that was supposed to cover it, and posted to the general ledger with the correct accounting treatment.

This is almost always the largest spreadsheet in the department, and it is the one nobody wants to own. It is also where the value of an independent settlement engine compounds, because once the charges are decomposed to a defensible granularity, allocation becomes a rules exercise rather than an interpretation exercise. Joint ownership percentages, contract effective dates and hedge designations become configuration with an audit trail instead of a formula copied down a column.

Where PCI, Power Settlements and Yes Energy sit

PCI Energy Solutions is deep and well established, and for an asset owner who also wants bidding, scheduling and generation management in one place it is a coherent choice. The trade is weight and pace: it is an enterprise engagement, and changes to how a calculation or an allocation works tend to route through the vendor rather than through your analyst.

Power Settlements is focused specifically on this problem and is well regarded for it. Their calculation library across markets is the thing you are buying, and maintaining that library against tariff amendments is genuinely hard work that they do so you do not have to. What you accept is their release cadence when a market changes, and their model for how results are structured, which may not match how you allocate internally.

Yes Energy is excellent at market data and analytics and is often the right source layer underneath a settlement process. It is not a settlement engine, and treating it as one leaves the recalculation and dispute workflow unaddressed.

The pattern we see most often at mid sized firms is a hybrid: buy or licence the charge code calculation capability where a vendor maintains it well, and build the input assembly, exception workflow, deadline management and internal allocation around it. The vendor keeps up with the tariff. You keep control of the part that is specific to your asset structure.

What this costs and how long it takes

Across the reconciliation and financial control systems Digital Heroes has delivered, the bands run as follows. A first release covering one ISO, the charge codes carrying most of your dollars, automated input assembly, variance detection with deadline tracking and dispute pack generation runs $90,000 to $200,000 and ships in 12 to 20 weeks. Extending to additional markets, full internal allocation to assets, contracts, joint owners and hedges, accrual estimation for close and true up tracking across restatements takes the total to $250,000 to $650,000 over 9 to 18 months.

Cost drivers specific to settlements: the number of ISOs, since each has its own charge codes, formulas, file formats and calendar and there is little reuse between them. The number of charge codes you choose to recalculate, which is a dial rather than a fixed requirement. Whether you need accrual estimation before the statement arrives, which adds a forecasting path. Joint ownership complexity, because an asset with several owners and a non trivial operating agreement is a rules engine on its own. And how your meter data reaches you, since a clean feed from your meter data agent is a very different integration from a monthly file.

When you should not build

Do not build if you have a single resource in one market with no joint owners and a simple contract structure. A specialist vendor plus one competent analyst will cost less and cover you.

Do not build if nobody in the organisation can read a business practice manual and explain a charge code formula. Software does not create that capability, it amplifies it, and a settlement engine configured by people who do not understand the tariff produces confident wrong answers.

Build when you settle across two or more markets and your team is maintaining parallel spreadsheets per ISO. Build when your allocation to owners, contracts and hedges is where the real manual burden lives, since that is the part no vendor will ever fit exactly. Build when finance needs an accrual estimate before the statement arrives and today that number is a guess your controller writes down.

How to choose a developer for settlements work

Ask them how they will handle a meter data restatement that changes the basis of a calculation you already ran. The answer must involve versioned inputs and the ability to re-run a period against either the original or the current data. If they describe overwriting, your recalculations will disagree with themselves and nobody will trust the output.

Ask how the dispute deadline is represented. It should be an object per statement per market with escalating alerts, not a column in a report.

Ask them to walk through one charge code from your own market end to end, using the business practice manual. You are testing whether they will engage with the tariff or expect your team to hand them arithmetic. Both models can work, but you need to know which one you are buying.

Ask what the dispute pack looks like. A good answer produces the ISO's number, your number, the inputs behind each, and the specific tariff reference, in a form a market participant relations analyst can act on without rebuilding it.

Ask who owns the repository and the infrastructure accounts, and get it in writing before kickoff. At Digital Heroes the client owns the code from the first commit. A cheap next step that always pays: rank the last twelve months of statements by absolute dollars per charge code, and count how many codes it takes to reach 90 percent of your total. That short list is the first release, and it is usually shorter than anyone expects.