Energy retail

One meter read. Two positions. Zero spreadsheets.

Every read is simultaneously what the customer owes you and what you owe the grid. Meridian holds both positions on one ledger — so margin, exposure and exceptions are queries, not month-end archaeology.

№ 01The visibility gap

Read-Bill-Collect looks simple on a slide.

Metering in one system. Billing in another. Collections somewhere else. Exceptions cascade through the silos until someone notices a spreadsheet doesn't balance — weeks later. And MHHS brings 48× the data on tighter deadlines.

№ 02Read · quality-aware measurement

In energy, truth comes in degrees. Your ledger should too.

Forecasts, estimates, actuals, validated reads — you bill on the best available. Meridian tracks that confidence at the ledger level: every position carries its quality, and when estimates become actuals the positions reload automatically, with the full bi-temporal trail of what you knew when.

Traditional stack

  • Meter read fails → a log entry nobody reads
  • Bill on estimate, hope for the best
  • Actual arrives → manual reconciliation
  • Can't prove what you knew at the time

Meridian

  • Missing read → an open position on the ledger
  • Bill with a visible certainty level
  • Actual arrives → automatic wash & reload
  • Full bi-temporal audit trail, always
"What percentage of my meters are fit to bill today?" — one query, not a BI project.
CustomerMetersActualEstimateMissingFit to bill
Acme Ltd3210Yes
Beta Corp12831Partial
Gamma Industries474160Yes
№ 03Bill · one reading, multiple valuations

A meter read isn't consumption. It's margin, the moment it lands.

Every read fans out to multiple financial positions: revenue at the customer's tariff, cost at the GSP wholesale price. Double-entry bookkeeping, applied to energy — the spread is your margin, visible now rather than at month-end.

100 kWh
@ ACTUAL
Customer receivable100 kWh × 24p = £24.00
DNO payable100 kWh × 28p = £28.00
Margin−£4.00

This customer is underwater — and you know it at the moment of consumption.

"Which GSP is hurting us?" — internal accounts per DNO make this a table, not a project.
GSPVolumeWholesale costBilled revenueMarginCertainty
_P (South Wales)890K kWh£231,400£213,600−£17,800Actual
_N (South Western)1.2M kWh£264,000£288,000£24,000Actual
_M (Midlands)2.1M kWh£483,000£504,000£21,000Estimate
Total4.19M kWh£978,400£1,005,600£27,200Estimate
№ 04Collect · receivables as positions

Billed isn't banked. The ledger knows the difference.

Invoices raised versus invoices settled, payments due versus payments received — tracked as positions, per customer, per account. Collections sees meter status; metering sees payment history. Cross-domain questions stop being projects.

Beta Corp has an outstanding balance and a missing meter. Both teams can see both facts.
CustomerInvoicedReceivedOutstandingMeter statusRisk
Acme Ltd£12,400£12,400£0All actualLow
Beta Corp£34,200£28,500£5,7001 missingHigh
Gamma Industries£89,100£67,200£21,900All actualMedium
№ 05The engine underneath

The dashboards are queries. The engine makes them possible.

Meridian is the ledger engine underneath: event-driven so exceptions surface as they happen, bi-temporal so disputes and regulators get the full story, and quality-aware so estimate-to-actual is a reload, not a rebuild. Energy retail is a cookbook pattern — energy-settlement, payg-energy, time-of-use-pricing — not a custom build.

  • Stream processing, not batch — exceptions surface same-day
  • Wash & reload — actuals replace estimates with the trail preserved
  • Queries < 50ms · 1,000+ concurrent ops · 1,000+ TPS
# every read, one atomic posting
meter read: 100 kWh · quality=ACTUAL
├─ customer position · revenue @ tariff
└─ wholesale position · cost @ GSP price
margin visible immediately

Settling energy is what we built first.

If you're staring down MHHS with a stack of silos, talk to us.