Energy Software Development Cost: From Interval to Invoice

An energy platform costs $58,400 to $146,000 for phase one. That is 1,460 hours at a $40 to $100 rate band, or about $94,900 at a $65 blend. The honest span across the seven modules is 1,120 hours at every minimum to 1,980 at every maximum.

The seven: meter data acquisition at 230 hours, validation and estimation at 210, the interval store and settlement timeline at 230, tariff and rating at 260, prepaid and disconnection control at 150, integrations at 220, and operational reporting at 160.

The expensive half is not the one people expect. Ask a supplier what their hard problem is and they will say getting the reads in. Getting reads in is a known shape with known protocols. What costs money is everything that happens after the read lands: turning intervals into a number a customer owes, defending that number when a regulator or a counterparty disagrees, and doing it again when the tariff changed halfway through the period.

Here is the ordinary failure. A customer switches tariff on the 12th. Your rating engine applies the new tariff to the whole month because the tariff is a field on the account rather than a thing with a date range. The bill is wrong by a few dollars, which nobody notices until nine thousand customers do the same thing and the regulator asks you to restate a quarter.

The interval is the unit of everything

A meter read is not a number. It is a number for a period, and the period is the thing the whole system is built around.

Half-hourly, quarter-hourly or hourly, the interval is what gets rated, what gets settled, what gets estimated when it is missing, and what gets restated when it was wrong. Store a running total instead and every one of those becomes impossible.

That sounds obvious and it is routinely got wrong, because the first version of a billing system is written against monthly reads and monthly reads look like a column. The move to intervals is not a schema change. It multiplies your row count by roughly 1,400 per meter per month and changes which queries are affordable.

The interval store and settlement timeline is 180 to 320 hours, and most of that is not storage. It is the timeline: knowing that the value you hold for 14:30 on the 3rd is version 2, that version 1 was an estimate, that the actual arrived nine days late, and that a bill was already issued against version 1. Every one of those facts has to survive, because the restatement is a regulated conversation.

Clock handling is the part that quietly ruins a quarter. Daylight saving gives you one day a year with 23 intervals in an hour-numbered scheme and one with 25, and a meter in the field may report in local time while your market settles in a fixed offset. Teams that store local time and convert on read discover the problem on the last Sunday in October, usually in production, usually in a year when nobody who wrote it is still on the project.

Store in UTC with the interval length as data rather than an assumption. Estates are rarely uniform: a supplier who acquires a book of customers inherits meters on a different interval length, and the rating engine has to handle both without a second code path.

Rating is not invoicing

These get specified as one thing and they are two, which is why the tariff and rating module is the largest at 200 to 340 hours.

Rating turns intervals into money. Invoicing turns money into a document. Rating is where the complexity lives: time-of-use bands that shift with the season, block rates that step at consumption thresholds, standing charges that accrue daily rather than monthly, capacity charges, network charges that your regulator sets and you merely pass through, and taxes that apply to some of those components and not others.

A tariff is a versioned object with an effective date range, exactly like the tenancy in a property system or the membership in a gym. A customer on tariff X until the 12th and tariff Y after it has two rated periods in one bill, and the bill has to show both.

Then there is the direction of flow. The moment you have customers with solar, the meter reads in two directions and the export is compensated under a different rule from the import, sometimes a different rule per customer depending on when they signed up. Suppliers who built import-only rating rebuild it.

Invoicing, by comparison, is cheap and finicky. It needs the right statutory lines, the right layout, and increasingly a clearance step with a tax authority before the document is valid.

The separation pays for itself the first time you need to re-rate. A correction that changes consumption should re-run rating and produce an adjustment, not edit an invoice that has already been issued and possibly already filed with an authority. Systems that fuse the two end up amending documents of record, which is the kind of thing auditors ask about for years.

Back-billing limits are the other reason to keep rating addressable. Several markets cap how far back a supplier may recover under-charged energy, so the rating engine has to be able to answer what a period would have cost under the correct tariff even when you are not allowed to collect all of it.

Prepaid is a different product, not a payment method

Operators ask for prepaid as though it is a billing option. It is a separate operating model and it is 120 to 220 hours on its own.

A prepaid customer has a balance that depletes in near real time, which means rating has to run continuously rather than at period end. The customer tops up through a channel that has to reach the meter — a vending token, an app, a retail agent — and the meter has to accept it offline, because the customer whose power is about to go out is frequently the customer with no connectivity.

Then there are the rules that exist because the alternative is cruel. Friendly credit, where the supply stays on overnight and at weekends even at zero balance. Emergency credit the customer can call on and repays from the next top-up. Debt recovery that takes a percentage of each top-up rather than the whole thing, so a customer in arrears can still buy power.

Each of those is a small piece of logic and together they are the module. They also have to agree with the meter's own firmware, which is implementing some of the same rules independently, and reconciling the two is a real part of the work.

Mode switching is the requirement that catches people. A customer moves from credit to prepaid, or back, and the balance, the debt and the billing history have to move with them without either writing off what is owed or charging it twice. Suppliers who treat prepaid as a separate product with separate accounts find that a customer switching mode becomes two customers, which breaks consumption history, arrears recovery and every retention metric that depends on continuity.

Disconnection is a regulated act with a software trail

Cutting someone's power is the most consequential thing your software will do, and the requirement is almost never "disconnect at zero".

The system has to prove it did the right things first. That means a documented sequence of notifications, a check against a vulnerable-customer register, respect for a seasonal moratorium where one applies, and a record of every one of those checks at the moment it was made rather than reconstructed later.

Build this as a flag on the account and you will not be able to answer the only question that matters when it goes wrong, which is what the system knew at 09:14 on the day it acted.

Settlement is where your numbers meet someone else's

If you sell energy you are settled against a market, and settlement is an adversarial arithmetic exercise conducted in public.

Your aggregated consumption is compared with what the network says you took, and the difference is money. The reconciliation runs in several passes over months, each pass using better data than the last, which is why the interval store needs versions rather than values.

The cost here is not the calculation. It is the explainability: when the settlement figure moves between passes, somebody has to say which meters changed and why, and that answer comes from the timeline or it does not come at all.

Unmetered supply is the awkward neighbour of all this. Street lighting and similar loads are settled from an inventory and a burn profile rather than a meter, so part of your consumption has no reads behind it at all and still has to arrive in the same aggregate. It is a small module that surprises people because it does not fit the mental model the rest of the system is built on.

Market messaging is per counterparty, and it never ends

Integrations sit at 160 to 280 hours and the open-ended part is market messaging.

Switching a customer in, switching one out, sending a change of tenancy, receiving a network charge update — each is a message in a format a counterparty defines, and the Common Information Model standardises the shape without standardising the dialect. Budget per counterparty, not once, and treat the second and third as nearly as expensive as the first.

This is the line item that converts a build into an ongoing engineering commitment. Formats change on the market's schedule rather than yours.

Certification is the part to plan around rather than estimate. Most markets will not let you exchange live messages until your implementation has passed the market's own conformance test, and the test windows run on a published calendar with places that fill. A supplier who finishes the build in March and discovers the next window is in June has lost a quarter to a date they could have booked in January.

Payments and finance are the quieter half of the same module. Direct debit is not a payment method so much as a schedule with its own failure states, and the general ledger integration has to express something most ledgers resist: energy consumed but not yet billed, which is an accrual your finance team will insist on and your billing system has no natural place to put.

Losses are a reporting problem with a revenue attached

Operational reporting sits at 120 to 220 hours, and the line that justifies it is losses.

The energy entering a network and the energy billed from it do not match, and the gap is theft, metering error, unmetered load and genuine technical loss, in proportions nobody knows until they measure. Separating them is an analysis your reporting layer either supports or does not.

What it needs is the ability to aggregate consumption up a network hierarchy — meter to feeder to substation — and compare it against a measured input at each level. That requires the network topology to exist as data, which is frequently the thing nobody owns. The commercial team assumes the asset team has it. The asset team has it in a drawing.

The audit trail belongs here too, and it is not optional decoration. Every estimate, every edit to a read, every tariff reassignment and every disconnection decision needs a who, a when and a why, because each is a thing a customer or a regulator may later require you to justify.

Phase one, module by module

Phase one of an energy platform is 1,460 hours, which is $58,400 to $146,000 at a $40 to $100 rate band and about $94,900 at a $65 blend. That covers seven modules: meter data acquisition, validation and estimation, the interval store, tariff and rating, prepaid control, integrations, and operational reporting.

Two of the seven modules — meter data acquisition at 180 to 320 hours and validation, estimation and editing at 160 to 280 — are the meter-to-data half, and they are inside the 1,460 above.

We have written that half separately, because head-end interfaces, late and out-of-order reads, and estimation as a regulated act rather than a convenience each carry their own decisions. If your problem is getting reliable reads out of an estate rather than turning them into money, start with smart meter data management and treat this post as the layer above it.

Every competitor publishes a total with no hours behind it. Here are the hours.

Module	Hours
Meter data acquisition and head-end interface	180 to 320
Validation, estimation and editing	160 to 280
Interval store and the settlement timeline	180 to 320
Tariff, rating and billing integration	200 to 340
Prepaid, top up and disconnection control	120 to 220
Integrations: market messaging, payments, finance	160 to 280
Operational reporting, losses and audit trail	120 to 220

The worked example takes a mid-point from each: 230 plus 210 plus 230 plus 260 plus 150 plus 220 plus 160, which is 1,460 hours. At $40 per hour that is $58,400. At $100 it is $146,000. At a $65 blend, about $94,900.

Sitting outside that number, each with its own range: quality assurance at 20 to 25 percent of build, environments and deployment at 80 to 160 hours, security review and penetration testing at 60 to 120, NIS2 incident reporting tooling at 100 to 200, and Common Information Model message mapping at 80 hours and up per counterparty.

What moves the number most

Tariff variety moves it more than customer count. A hundred thousand customers on four tariffs is a smaller system than four thousand customers on sixty, because the rating engine's complexity tracks the number of distinct shapes it must express, not the number of rows it processes.

Second is whether you settle. A supplier that participates in market settlement carries the interval timeline, the reconciliation passes and the message formats. A metering business that sells data to someone else who settles carries none of it, and the same seven modules collapse toward the bottom of their ranges.

Third is prepaid. Adding it is the single largest discrete jump in this list, because it changes rating from a periodic job to a continuous one.

What barely moves it: the customer portal, the mobile app, and the number of payment methods. Those are the three things asked about first and they sit inside normal variance.

Where utility builds actually fail

Three failures, none technical.

The first is modelling the tariff as a field. It is a versioned object with a date range, and discovering that after the rating engine exists means rewriting the rating engine.

The second is treating estimates as values rather than versions. The restatement is not an edge case. It is the normal operation of a settled market, and a system that overwrites cannot participate in one.

The third is scoping market messaging once. The first counterparty is a project. The fifth is also a project, and the budget usually contains one.

The cost question has a short answer and it is the arithmetic above. The longer answer is that an energy platform is a time-series system wearing a billing system's clothes, and every expensive mistake in this category comes from forgetting which one it actually is.