Wholesale Power Settlements Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does charge code scope balloon so often?

Because the requirement sounds binary. Either you recalculate the invoice or you do not, so the brief says recalculate the invoice, and a statement carries several hundred charge codes. Estimated honestly, that is a multi year programme, and estimated optimistically it is a project that delivers forty percent of a settlement engine and nothing usable.

What makes this avoidable is that charge codes follow a steep distribution. In most portfolios a few dozen codes carry the overwhelming majority of the dollars, and those are the ones where an error is worth finding. Everything else can stay under total based review indefinitely without material exposure.

The fix costs nothing and should happen before you speak to a developer. Rank the last twelve months of statements by absolute dollars per charge code, then count how many codes it takes to reach around ninety percent of the total. That short list is your first release, and it is usually shorter than anyone in the room expects. Add to it any code that is rarely triggered but large when it fires, because those are precisely the ones that slip past variance review by looking like a plausible response to an unusual month. Everything else is phase two, and phase two may never be justified.

What goes wrong with input assembly and restated meter data?

Recalculation is arithmetic once the data is in one place. Getting it there is the project, and most of the schedule risk lives here rather than in the formulas.

A single charge can require settlement quality meter data from your meter data agent, day ahead and real time market results and prices, your own submitted offers and bids, ancillary service awards, outage records, and the resource registration data that determines which allocation bucket applies. Those arrive on different schedules, in different formats, from different systems. Several of them are restated after the fact, and meter corrections in particular flow through quietly and change the basis of a calculation you already performed and possibly already disputed.

The failure this produces is subtle and fatal to adoption. An analyst re-runs a period to check a number and gets a different answer from the one in last month's pack. Nobody can explain the difference, because the difference is in data nobody kept a copy of. Confidence collapses immediately and does not come back.

The fix is architectural and must be decided before the first calculation is written. Store every input as a dated, versioned observation. Record which version of each input every calculation run consumed. Then any period can be re-run against either the original inputs or the current ones, and the system can show the difference. That distinction, between what you knew then and what you know now, is also what makes the output defensible in a dispute conversation rather than merely internally interesting.

Why do market and meter data feeds break after launch?

They break on change rather than on failure, which is why they rarely announce themselves.

Independent system operators publish file formats that evolve. A column is added, a code is retired under a tariff amendment, a new charge appears that your parser has no rule for. A parser that ignores unknown fields will run cleanly and produce an incomplete picture, and the missing charge is invisible precisely because nothing errored. Meter data agents change delivery mechanisms, and a feed that arrived on a schedule for two years starts arriving late, which matters enormously when the deadline is measured in days after a statement.

The second failure is registration drift. Resource registration data determines which allocation bucket a unit sits in, and it changes when a unit is re-rated, a capacity value is updated or a new resource is added. A recalculation using stale registration produces a confident wrong answer, which is worse than no answer because it generates disputes you will lose.

The fix is to fail loudly on the unexpected. An unknown charge code in a statement should raise an exception rather than being skipped. A late file should raise an alert against the deadline it threatens, not simply be waited for. Registration data should carry an effective date and the system should flag when a calculation depends on registration older than a stated age. Build a daily view showing what arrived, what was expected, and what has not appeared, and have somebody look at it.

What happens when the deadline clock is not modelled properly?

This is the failure that makes an otherwise good build worthless, because a variance you find after the window closes is a variance you paid for.

Markets do not settle once. Statements arrive as an initial calculation and are then 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 consequences follow and builds routinely miss all three. The deadline must be a first class object, per statement, per market, with alerts firing early enough for a human to investigate rather than merely be informed. Restatements must be diffed against the prior version so you can see what the operator changed and whether it moved in your favour, which nobody does reliably in spreadsheets. And a dispute has a lifecycle rather than an outcome, because an issue raised at the initial statement can move again at true up and the tracking has to survive that.

The fix is to build the calendar before the calculations. It sounds backwards and it is not, because a system that recalculates beautifully and surfaces the result two days after the window closed has delivered nothing at all.

Should you build custom or configure what you already own?

Do not build if you have a single resource in one market with no joint owners and a simple contract structure. Power Settlements plus one competent analyst will cost less and cover you properly, and the calculation library they maintain against tariff amendments is genuinely hard work you would otherwise carry yourself.

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

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, since changes to how a calculation or an allocation works tend to route through the vendor rather than through your own analyst. Yes Energy is excellent at market data and is often the right source layer underneath a settlement process, but it is not a settlement engine and treating it as one leaves recalculation and the dispute workflow unaddressed.

The pattern that works most often at mid sized firms is hybrid. 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 pace with the tariff. You keep control of the part that reflects your asset structure, which no vendor will ever fit exactly.

How do hidden costs get into the quote?

The calculation engine is not usually what moves the number. These are.

• Each additional market. Charge codes, formulas, file formats and calendars are different per operator with little reuse, so a second market is close to a second project rather than a percentage uplift.
• Meter data delivery. A clean feed from your meter data agent is a very different integration from a monthly file, and the difference is weeks.
• Joint ownership. An asset with several owners and a non trivial operating agreement is a rules engine of its own, sitting inside the allocation work.
• Accrual estimation. Producing a number before the statement arrives adds a forecasting path. Decide early whether finance will genuinely use it, because half of them do not.
• Tariff maintenance. Formulas change when amendments land. Somebody has to notice and update the rules, and that arrangement should be priced rather than assumed.
• Historic reload. Recalculating prior periods to validate the engine needs archived inputs, and if those were overwritten the validation cannot be done.

Ask for these itemised. A quote that prices settlements by number of charge codes alone has not asked how your data arrives.

What separates a build that works from one that fails here?

Ask a prospective developer 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 within two cycles and the tool will be abandoned by people who are right to abandon it.

Second, 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 that somebody reads on Fridays.

Third, ask them to walk 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 and you need to know which one you are buying, because pricing and timeline differ substantially between them.

Fourth, ask what the dispute pack looks like. A good answer produces the operator'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. A dispute pack that requires reconstruction before it can be sent has not saved anybody time.

And settle ownership of the repository and infrastructure accounts in writing before kickoff. Settlement records support financial reporting and commercial disputes, and they may need to be produced long after the operating day they describe.