A meter read is not a number. It is a value with a source, a quality flag and a settlement status, and the bill built on it is a restatement rather than a fact. Systems that store a reading as an integer produce invoices nobody can defend six months later, and that is the part we build.
The commercial facts in one block, before any of the detail. The two halves are utility billing software development and smart metering software development, and the meter data decides what a bill can defend. The tiles cover: Typical integration set, Phase one timeline, Rate band, Phase one range, Stack we actually use and Our commitment.
Typical integration set
01A head-end system collecting from meters, a meter data management platform if you have one, a billing or ERP ledger you are keeping, market messaging to the settlement body, a payments provider for prepaid top ups, and a historian or data warehouse on the operational side.
Phase one timeline
0218 to 26 weeks for the worked example below, run as a squad rather than a single developer. Rollout milestones and settlement programme dates are what move it, and both belong to somebody else's calendar.
Rate band
03$40 to $100 per hour by role and seniority. Reporting and extracts near the floor, the interval store and the settlement timeline near the ceiling. Mixed teams blend to around $65.
Phase one range
041,460 hours in the worked example, which is $58,400 to $146,000 across the rate band and about $94,900 at the blend. The cost section shows every module and its range, so you can argue with any line of it.
Stack we actually use
05Python with FastAPI, Node, PostgreSQL and Next.js, with a time series store alongside Postgres where interval volumes justify it, Terraform for infrastructure and Grafana and Prometheus for metrics. Interval data is an append problem before it is a product one.
Our commitment
06No quote before a discovery that produces the integration inventory and the meter data model decision. Three things we are not: we do not operate metering assets, we are not a licensed supplier or settlement agent, and we are not an accredited service provider for e-invoicing or statutory filing.
Audience
Six positions we are usually called from, and the thing each one is missing. Not a fit: if you want a billing platform replaced end to end inside a quarter, or a partner who will operate your metering assets or act as your settlement agent, we are the wrong firm and would rather say so on the first call.
Meters are going in faster than the systems behind them can absorb the data. What is missing is an interval store that holds quality and source per read, rather than a warehouse that averages the problem away.
The market is moving to half hourly settlement on a timetable nobody controls. What is missing is a data path that can be tested against the new arrangements before the migration window closes.
Recharging tenants for energy means becoming a billing business without a billing licence. What is missing is a defensible calculation, since a submetered bill is challenged far more often than a utility one.
Generation, consumption and export all have to be netted against a tariff that changes by time of day. What is missing is the arithmetic that turns two meters and one contract into one settled position.
A charging session is a metered transaction, a payment and a roaming settlement at the same time. What is missing is one record that all three read from rather than three that reconcile weekly.
Loss figures, collection efficiency and consumption reports disagree depending on which system produced them. What is missing is one authoritative read, with everything downstream reading from it rather than recomputing.
Energy is one word for six businesses. What breaks is different in each, so what we build is different. The operations covered here are: Distribution utilities, Retail energy suppliers, Submetering and landlords, Renewables and open access, EV charging networks and Water and gas metering.
01 · Your operation
What breaks
A rollout multiplies data volume by several orders of magnitude and changes nothing about the billing system underneath it. Prepaid metering adds a control path that the estate was never designed for: a disconnection is a physical consequence of a balance calculation, so a rounding error or a late payment posting becomes somebody's lights. Meter exchanges break consumption arithmetic quietly, because the difference between the new meter's register and the old one's is meaningless and nothing in a naive calculation says so.
What we build
An interval store that keeps every read with its source and quality rather than one value per period, so a restatement is a new record instead of an overwrite. Meter exchange modelled as an event with both final and initial registers captured, so consumption spans the change correctly. Disconnection as a reviewable decision with the balance calculation attached, not a job that fires from a threshold.
The stages a meter read moves through, and what we build at each one. The stages run: Collect from the meter, Validate, estimate and edit, Store the interval series, Rate against the tariff, Settle and reconcile and Restate and re-bill.
The same meter produces a cumulative register and, if it is capable, an interval profile. Consumption from the first is a difference between two readings; from the second it is a sum. They disagree, and deciding which is authoritative is a modelling decision that everything downstream inherits. Add a quality flag, a source, a settlement status and a clock that changes twice a year, and the read stops being a number. Here is the estate we expect to meet, and the decisions that determine whether an invoice can be defended.
Itron, Landis and Gyr, Siemens EnergyIP, Oracle Utilities and Kamstrup cover collection and meter data management, with SAP for Utilities, Oracle Customer Care and Billing, Hansen and Gentrack on the billing side. In India, Genus, Secure Meters and HPL sit on the meter and head-end side of RDSS deployments. The licence boundary between these products is the thing to read before the roadmap is written.
DLMS/COSEM, published as IEC 62056, is the global smart metering standard, and its four DLMS User Association books split the job: the Blue Book carries the COSEM object model and the OBIS identification system, the Green Book the architecture and protocols, the Yellow Book conformance testing and the White Book the glossary. In North America the ANSI C12 family covers optical communication in C12.18, the data model in C12.19 and networked communication in C12.22.
The Common Information Model, defined under IEC 61970 and IEC 61968, is the interchange model between energy management and distribution management systems, and IEC 61850 is the substation automation standard. On the edge, OCPP carries charge point communication and OpenADR carries demand response signals. These are a different estate from billing, with different failure modes and often a different team.
A register is a running total, so consumption is the difference between two of them and the answer depends entirely on both readings being from the same meter with no rollover in between. An interval series is a sequence of period values, so consumption is a sum and a missing period is visibly missing rather than silently absorbed. Both come off the same smart meter and both are identified by their own OBIS code, which is why the model has to carry the code rather than flattening everything into a value column. Deciding which one is authoritative for billing, and saying so once, prevents the situation where two teams answer the same question differently and both are reading real data.
Validation, estimation and editing is a pipeline with a record, not a cleanup pass. A read arrives, gets checked against tolerances and against its own history, and is either accepted, corrected or replaced with an estimate produced by a named method. What must survive is the provenance: which of those happened, when, by what rule, and what the original value was. Systems that overwrite in place produce bills that cannot be explained once anyone asks why last March differs from the meter's own display, and the answer, that an estimate was later replaced, is unavailable because the estimate is gone.
Initial settlement runs on what was known at the time, which for a lot of meter points means estimates. Reconciliation runs later, sometimes much later, replacing estimates with actuals and moving the position for a period that is commercially closed. The consequence for software is that a bill is a version rather than a document, and the ledger has to support restating a closed period with a traceable cause. Teams that model billing as issue-and-forget end up producing credit notes nobody can tie back to a read, which is exactly the thing a regulator or a large customer asks about.
A half hourly day has 48 periods, except on the two days a year when the clocks change, which have 46 and 50. Every naive loop over a day is correct for 363 days and wrong for two, and the failure is invisible until it happens, at which point it is a billing incident rather than a bug report. The related traps sit alongside it: meters keep their own clock and it drifts, some report in local time and some in a fixed offset, and a period label without a timezone is not a time. Store periods against an explicit local calendar with the offset carried, and test the two clock change days deliberately rather than hoping the library handled it.
The most useful hour of a first call is usually spent on what your system stores against a single meter read. Almost everything else on this page follows from that one answer, including the cost.
Five standards a buyer in this sector asks for by name, then every regional instrument in one place. Programme dates in this sector move, so verify the regional row before contracting. The rules in scope are: ISO/IEC 27001, SOC 1 and SOC 2, GDPR and UK GDPR, IEC 62443, PCI DSS and Everything regional, in one place.
The information security management certification procurement asks for by name. For utility work the scope statement matters more than the certificate, because the question actually being asked is whether the meter data path and the customer billing data sit inside the certified boundary or immediately next to it.
SOC 2 covers security and availability and is the standard ask from partners. SOC 1 covers controls feeding financial reporting, and it matters more here than in most sectors because metering feeds billing feeds revenue recognition, so a control weakness in the read pipeline is a control weakness in the accounts.
Half hourly consumption data reveals when a household is occupied, empty or asleep, which makes it far more sensitive than a monthly total and changes both the lawful basis and the retention answer. Granularity is itself a design decision with a privacy consequence, and consent for settlement is not consent for analytics.
The industrial automation and control systems security family, and the standard that comes up once operational technology is anywhere in scope. It matters because the boundary between the operational estate and the corporate one is the thing procurement will interrogate, and a meter control path that can disconnect a customer sits on the wrong side of that boundary if nobody drew it deliberately.
It applies wherever card data touches prepaid top ups or bill payment, and the useful move is nearly always to keep it out of your estate entirely by tokenising at the gateway. Prepaid makes this sharper than usual, because a top up path that stores a card for convenience pulls a system that controls physical supply into scope.
In Great Britain the Market-wide Half Hourly Settlement programme is due to go live by May 2027, with changes landing in stages between September 2025 and July 2027; the migration phase began in October 2025 across an 18 month window and the majority of meter points move between May 2026 and May 2027, which makes this a live constraint on any supplier system being built now rather than a future one. In the European Union the NIS2 Directive, (EU) 2022/2555, had a transposition deadline of 17 October 2024 which most member states missed, prompting the Commission to open infringement proceedings against 23 member states in late 2024 and issue reasoned opinions to 19 in May 2025; energy is one of the 18 covered sectors and sits among the essential entities, and the reporting obligation is a three stage cascade of a 24 hour early warning, a 72 hour notification to the national authority and a final report within one month, which is a software requirement rather than a policy one because three artifacts on three clocks have to come out of your incident tooling. In India the Revamped Distribution Sector Scheme was launched in July 2021 by the Ministry of Power and makes prepaid smart metering the default for distribution utilities, which changes the billing model rather than only the meter, since a prepaid balance is a real time obligation and a postpaid bill is a monthly one.
Ten failure modes with the counter-practice attached. Naming them is more useful than a list of reasons to pick us. The first three below are: A read is stored as one value, Meter exchanges break consumption and The clock change day is never tested.
Without a source and a quality flag there is no way to explain why a bill changed, or to rebuild it when an estimate is replaced. Model the read with its provenance from the first sprint, because reconstructing it afterwards means going back to the head-end for data that may have aged out.
Subtracting the old meter's final register from the new meter's first one produces a number that is either negative or enormous, and both look plausible enough to bill. Model the exchange as an event carrying both registers, so consumption spans it deliberately rather than accidentally.
Two days a year have 46 and 50 half hourly periods, and code that assumes 48 is wrong on exactly those days. Put both dates in the test suite with real data, since this failure surfaces as an invoice rather than as an exception.
Once the estimate is gone, nobody can answer why March was restated, and the customer asking is usually the one who noticed. Keep every version of a read with the method that produced it and let the current value be the newest entry.
Reconciliation will change a period that is commercially closed, and a system that only issues documents answers that with a credit note nobody can trace. Treat a bill as a version with an adjustment path, so a restatement carries its cause.
Rollout volumes are several orders of magnitude above what a billing schema was sized for, and the symptom is a month end that gets slower until it stops finishing. Keep the interval store separate and let billing read a rated result rather than raw periods.
A balance crossing zero because a payment posted late is not the same as a customer out of credit, and the consequence here is physical. Make disconnection a decision with the balance calculation and the payment timeline attached, and keep an explicit hold path.
A period label without an offset is not a time, and meters variously report local time, fixed offset and their own drifting clock. Carry the offset with the period and normalise once at the edge, so the ambiguity has exactly one place to be resolved.
The unallocated difference between the main meter and the sum of submeters is a real number that has to belong to somebody, and burying it in a divisor means it is allocated without being decided. Show it as its own line and make the apportionment schedule dated data.
Matching a month's consumption proves the sum, not the series, and settlement is done on the series. Replay a full year interval by interval and compare period by period, because a compensating pair of errors will always agree at the total.
The honest answer is usually the third one. Three judgements sit outside this table because they are not ours to make: we do not operate metering assets, we are not a licensed supplier or a settlement agent, and we are not an accredited service provider for e-invoicing or statutory filing.
| Component | Our recommendation | Our honest verdict |
|---|---|---|
| Head-end and meter communications | Buy | Protocol stacks, firmware compatibility and field device management come with the meter vendor and are certified alongside it. Building one is a hardware compatibility matrix you will maintain forever. |
| Meter data management | Buy the core, build the edge | Buy the validated store where a credible product exists, then build the estimation rules and the exception handling that encode your own policy. The store is commodity; what you do with a failed validation is not. |
| The interval store and its provenance model | Build | This is the piece every downstream argument resolves against, and it encodes decisions no vendor can make for you. Owning it is what lets a bill be defended rather than described. |
| Core billing and customer ledger | Buy | Years of tariff, tax and dunning edge cases are already inside these products. Building one is somebody else's regulatory backlog that you have not read yet. |
| Tariff and rating for unusual products | Buy the core, build the edge | Buy the engine, build the product definitions. Time of day, netting and export valuation are where your commercial difference lives, and they are exactly what a generic rating table struggles with. |
| Prepaid balance and disconnection control | Build | The consequence of this calculation is physical, so it needs to be reviewable, logged and yours. No product should be making that decision inside a black box you cannot audit. |
| Market messaging to the settlement body | Buy the core | Buy the gateway and its certification, build the mapping and the failure handling. A rejected flow that silently retries is worse than one that stops, and only you can decide which is which. |
| Payments and prepaid top ups | Buy | Card tokenisation, mandates and payout rails are solved, audited and cheaper than the compliance surface of owning them. Build the posting and balance logic on top instead. |
| E-invoicing and statutory transmission | Buy | Only an accredited service provider may transmit, so this is not a build decision at all. Establish who yours is before the plan depends on the date. |
| Operational reporting and loss analysis | Build | Every analytics product will chart whatever definition of a loss you feed it. The value is in one authoritative read that everything else references rather than recomputes. |
| Substation and grid automation | Buy | IEC 61850 estates carry safety certification and vendor testing regimes. Integrate to them and keep the boundary explicit rather than building anything that sits inside them. |
Transparency
Every competitor publishes a total with no hours behind it. Here is the rate, the hours and the multiplication, so you can argue with any line. The scope priced here is a utility or supplier keeping its head-end and its core ledger, and taking the interval store, rating and settlement path in house.
Phase one range
$58,400 to $146,000
The 1,460 hour worked example at the ends of the rate band, about $94,900 at a $65 blend.
Typical timeline
18 to 26 weeks
As a squad. A rollout or settlement milestone inside the window compresses scope rather than the calendar.
Useful hours
1,120 to 1,980
Every module at its minimum, through to every module at its maximum.
| Driver | Hours |
|---|---|
| How many meter points, and at what intervalMonthly registers and half hourly profiles are different systems at the same customer count, and the difference lands in the store and the settlement path rather than in the interface. | High impact |
| Whether reads already carry provenanceIf source and quality are already held per read, this is integration work. If values are overwritten in place, the model goes in underneath everything else and history may not be recoverable. | The largest swing |
| Whether prepaid is in scopeA prepaid balance is a real time obligation with a physical consequence, which is a different system from a monthly bill rather than a setting on one. | 150 to 260 |
| Which head-end and ledger you keepVendor API surface at your specific version, not at the version in the current documentation. This is the most common source of a mid-build surprise. | 80 to 200 each |
| How many market interfacesEach settlement or market counterparty brings its own message set, its own certification and its own rejection semantics, and none of them are negotiable. | Adds real scope |
| How much history has to be replayedReplay testing scales with the variety of meter and tariff combinations rather than with the number of meter points, so a small mixed estate can cost more than a large uniform one. | Rarely small |
| Whether operational technology is in scopeAnything touching substation or control estates brings a separate security boundary and a separate review cycle, and it is a programme decision rather than a sprint. | Medium |
| Module | Hours |
|---|---|
| Meter data acquisition and the 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 |
Engagement
Four models for energy software development, each with the downside stated in the same breath. The models are: Fixed scope phase one, Dedicated squad, monthly, Rollout data programme and Market change retainer. Pick by how settled the scope actually is, not by preference.
Upside
A defined scope, a fixed number and a date. It works best after discovery has produced the integration inventory and the meter data model decision, because that is the point at which scope is genuinely knowable.
Downside
Change costs more than it would hourly, and settlement scope moves whenever a market programme does, which is not something either of us controls.
Upside
A standing team that keeps the domain knowledge in the room, billed on time and materials so you pay for work actually done. Long integration and rollout work suits this shape.
Downside
You carry the utilisation risk, and a quiet month still costs a month. We will tell you when there is not enough work to justify it.
Upside
Scoped to absorbing a metering rollout, priced on the variety of meter and tariff combinations rather than on meter count, with interval replay built into the plan rather than bolted on at the end.
Downside
Discovery is unusually long here, and it can conclude that some of your historic data cannot be recovered with its provenance intact.
Upside
Capacity held for settlement and regulatory changes you do not control, with the standards work already understood, so a programme milestone is planned work rather than a scramble.
Downside
You are paying for availability, and in a quarter where the programme slips that feels a lot like paying for nothing.
Delivery
Five phases, each named by the artifact it produces rather than by a stage in a generic waterfall. The phases are: Meter data decision record, Estimation rule book, Settlement timeline map, Read replay test pack and Operations and evidence pack.
Phase 01
Which series is authoritative, what provenance every read carries, and how a restatement is represented. Written down before anything is built on top of it, because every later argument resolves against this document.
Phase 02
Every validation tolerance and estimation method named, with what it does to the read, what it records, and how a later actual replaces it. This is the document a disputed bill is defended from.
Phase 03
Each run, each reconciliation and each window in which a closed period can still move, with the system behaviour at every one. Agreed with whoever owns your market obligations rather than shown to them afterwards.
Phase 04
A full past year replayed interval by interval against the new model and compared period by period, with clock change days tested explicitly. Monthly totals are not the test.
Phase 05
The runbooks, exception handling procedures and control documentation your operations team and your auditor will ask for, produced as part of the build rather than assembled afterwards under time pressure.
Non-functional
Copy this and run it against us, or against anyone else quoting for energy software development. The groups are: Reads, provenance and replay, Money, settlement and restatement and Boundaries, incidents and scope. Copy any line straight into your own requirements document.
Can the system return the read for a given meter and period as it stood before the last restatement, as a query rather than a reconstruction? Does every read carry its source, its quality and the method that produced it if it was estimated? Are both clock change days in the test suite with real data, and does the suite fail if a day is assumed to have 48 periods?
Can a bill be regenerated exactly as it was issued, and separately as it stands after reconciliation, with the difference explained by named reads? Is every prepaid disconnection decision logged with the balance calculation and payment timeline behind it? Does the reconciliation between a main meter and its submeters run on a schedule with a tolerance rather than on request?
Where exactly is the line between the operational estate and the corporate one, and does anything able to disconnect a customer sit on the correct side of it? Can your incident tooling produce a 24 hour early warning, a 72 hour notification and a one month final report as artifacts rather than as emails? And confirm the boundary: we do not operate metering assets, we are not a licensed supplier or settlement agent, and we do not transmit statutory filings or e-invoices for you.
The worked example is 1,460 hours, which is $58,400 to $146,000 across our $40 to $100 rate band and about $94,900 at a $65 blend, landing in 18 to 26 weeks with a squad. The module ranges sum to 1,120 to 1,980 hours, so a smaller or larger phase one is a question of which modules are in it. We do not quote a fixed number before a discovery that produces the integration inventory.
You do, all three, from the first commit. Repositories, cloud accounts, domains and third party service accounts are in your name or transferred to it at handover. What transfers alongside them is the meter data decision record and the estimation rule book, which is the part that makes the code readable by whoever comes after us.
Because a bill is a restatement rather than a fact. Initial settlement often runs on estimates, reconciliation replaces them with actuals months later, and the customer or regulator asking why March changed needs an answer that names the reads involved. A system that overwrites a value in place has destroyed the only evidence that would have answered them.
The head-end talks to meters and knows nothing about tariffs. Meter data management holds the validated series and does not rate it. Billing rates and invoices and generally cannot hold interval history at rollout volume. They are three products, and buying one does not give you the other two, which is the single most common reason a metering programme discovers a gap with no time left to close it.
It is a live constraint rather than a future one. Market-wide Half Hourly Settlement is due to go live by May 2027, changes have been landing in stages since September 2025 and continue to July 2027, and the migration phase started in October 2025 across an 18 month window with most meter points moving between May 2026 and May 2027. Anything being built for a supplier now has to be testable against the new arrangements inside that window rather than after it.
Because we would rather say that than borrow a client from another sector and call it utility experience. What is on this page instead is the modelling, the standards and the arithmetic, all of which you can check without trusting us. The code, decision records and specifications are yours from the first commit, which is the part that holds whether or not we turn out to be a fit.
Yes, and that is the more common shape of this work. The first question is what your specific version actually exposes and actually stores, because vendor documentation describes the current release and you may not be on it. We would much rather establish that in discovery than in build.
As a reviewable decision rather than a threshold job, because the consequence is physical. The balance calculation, the payment timeline and any hold conditions are attached to the decision and logged, so a disputed disconnection can be explained rather than argued. In practice the most common cause we find is a payment posting later than the balance check, which is a sequencing problem rather than a credit one.
It is the object identification system in the DLMS/COSEM Blue Book, and it is how a meter says what a given value actually is: which register, which tariff rate, which direction, which period. It matters because a data model that flattens everything into a value column has thrown away the only thing distinguishing an import register from an export one, and that distinction is the difference between a credit and a charge.
By replaying it. A full past year is regenerated interval by interval under the new model and compared period by period against what the old system produced, with both clock change days tested deliberately because those are the two days a naive implementation gets wrong. Matching monthly totals is not the test, since settlement is done on the series and a compensating pair of errors always agrees at the total.
Yes, and the modelling differences are worth naming early. Both are measured in physical units and billed after a conversion whose factors change over time, so those factors need their own dated history or a correction becomes a manual adjustment. Read frequency is also much lower, which makes estimation the normal case rather than the exception and means a long estimated run has to be visible as a risk rather than passing as an ordinary bill.
Four steps with a shape attached to each, so booking a call is a known quantity.
Bring what your system stores against a single read, and one bill you had to restate. Those two answers size the project faster than an hour of description would.
We establish whether your reads carry source and quality, and what it currently costs you when they do not. The answer usually explains most of the symptoms you called about.
Module by module against the ranges published on this page, with anything excluded named as excluded. If your existing platform already does most of it, the document says so.
With the scope in hand you choose whether we build it, your team does, or your incumbent extends. The document is useful in all three cases and it is yours either way.
Bring one read as your system stores it and one bill you had to restate. Thirty minutes on those two usually tells both of us whether this is a fit, and you leave with the hours either way.
Real feedback from the people we've proudly partnered with.
Sales Director |Cintas
United States
Zyneto Global Technologies provided excellent project management and technical expertise throughout the engagement. The team was responsive, collaborative, and adaptive, ensuring the project met our expectations and set a strong foundation for future growth.
Founder & CEO |Moneteo
We engaged Zyneto to design and develop a custom web platform for Moneteo, aimed at improving project management, data tracking, and collaboration across internal teams and external partners. Their work included full-stack web development, custom modules for workflow automation, API integration, and comprehensive testing.
CEO |E-Commerce Platform
Overall, their responsiveness and timely deliveries contributed positively to the project's success. The client achieved better data management and quality. The service provider delivered the project on time and ensured prompt responsiveness throughout the engagement. Their innovative approach was outstanding.
Explore further
The interval store and its provenance model
Validation, estimation and rating pipelines
Operations consoles and customer portals
Field devices, charge points and telemetry
Loss detection and consumption forecasting
Exception queues and field work routing
Industrial load and the plant behind the meter
Metering and recharge inside a building
Every sector we build for, in one place
Security, automation and cost work that applies directly to metering and billing systems.
