Meteringonline · in service since 1998
MOL turns meter readings into invoices, tariff decisions and carbon reports.
Most of this industry sells you three products from three vendors: a head-end system to collect from the meters, a meter data management system to validate what it collected, and a billing system to invoice from it. MOL is all of it — acquisition from any major meter, validation you can defend at audit, billing, and the reporting that large corporates now need as much for emissions as for cost. Written by PMT, in service since 1998.
01
Acquire
Half-hourly interval data from virtually any revenue-grade meter used in South Africa — over power line, cellular or IoT. MOL was designed meter-agnostic from the start.
02
Validate
Rule-based validation, estimation and editing. Every reading carries a state — raw, valid, verified or estimated — so nobody bills on a number without knowing where it came from.
03
Bill
Any South African tariff: time-of-use, sliding-window demand, inclined block, seasonal. Summated accounts that diversify demand correctly. Billing cycles that straddle a tariff change.
04
Analyse
Load profiles, consumption comparisons, weather-normalised baselines, benchmarking by the metric your industry actually uses — sales, covers, rooms, tons.
Meter data management
Where the number came from, and what was done to it.
MOL's MDMS sits between acquisition and everything downstream of it — billing, tariff modelling, emissions reporting. It validates each interval against configurable rules and keeps the provenance of every value alongside the value itself: what state it is in, which check it failed, who verified it, whether it was estimated.
That record is what a query resolves against. A tenant disputing a recovery, an auditor testing a carbon figure and a municipality defending a demand charge are all asking the same thing, and the answer has to survive being checked.
It is also what makes an anomaly actionable rather than merely visible. A failed check that carries its own history tells you whether you are looking at a metering fault, a genuine change in the load, or a communications gap that has now been recovered.
Raw
As it came off the meter. Untouched, and not yet trusted.
Valid
Passed every automated check. Safe to bill.
Verified
Failed a check, was investigated, and a person confirmed it.
Estimated
Could not be recovered, so it was calculated — and it says so.
That last distinction is the one that matters when a customer queries a bill. An estimated reading is not a problem — an estimated reading that nobody labelled is.
One system, where the industry normally sells you three.
Conventionally these are separate products, usually from separate vendors: a head-end system to collect from the meters, a meter data management system to validate what it collected, and a billing system to turn that into invoices. Asset and fleet management is often a spreadsheet.
Each boundary is an integration project, a place where data is copied and starts to diverge, and a support contract. And when a number turns out to be wrong, every vendor can credibly point at the one upstream of them.
MOL is all of it, in one system. When a bill is queried, the invoice line traces back through the tariff, to the validated interval, to the raw reading, to the phasor snapshot taken when that reading was collected. One audit trail. One accountable party.
Multi-vendor acquisition
Your existing meters are not a problem to be replaced.
DLMS was meant to make meters interoperable. In practice every manufacturer implements its own variant of it, which is why most systems can only read the meters their vendor happens to sell — and why "we'll need to replace your meters first" is such a common opening position.
PMT holds protocol agreements with most of the major meter manufacturers represented in Southern Africa, and MOL was written meter-agnostic from the first line. An estate assembled from three vendors over two decades reads into MOL.
No rip-and-replace
A rollout starts by reading what is already on the wall. Working instruments stay working, and the capital goes where it is actually needed.
No vendor lock-in
MOL does not decide your meter procurement. You can tender hardware competitively, on price and specification, without asking whether the system will read it.
One view of a mixed estate
Electricity, water, gas and heat — across manufacturers and generations — reported through the same hierarchy, on the same half-hourly basis.
Emissions reporting
Two questions decide a carbon number: what generated it, and who consumed it.
Neither is answerable from a utility invoice. An invoice tells you a total for a period and a supply point. It cannot tell you which half hours came off the grid and which came off your generators, and it cannot tell you which tenant used them.
Both distinctions change the reported figure, and both are decided at half-hourly resolution. Which is exactly what MOL already holds.
What generated it
Load-shedding moves emissions between scopes.
Grid electricity is Scope 2 — indirect, at the national grid factor. Burning diesel on site is Scope 1, direct combustion by whoever has operational control, at an intensity far above the grid.
So an afternoon on the generators does not just cost more. It moves that consumption from one scope to another and changes the intensity behind it. MOL already separates the two — the same conditional virtual meters that recover the cost of running generation identify exactly which intervals it supplied.
Who consumed it
Floor area is an estimate. A meter is not.
A landlord reporting on operational control separates common-area consumption, which is theirs, from tenant space, which is downstream. Where a building is not sub-metered by tenant, the accepted fallback is to apportion by floor area.
That is a guess with a methodology attached, and it is wrong in every building where a restaurant and an office occupy the same number of square metres. Sub-metering replaces it with a measurement, and stops the same kilowatt-hour being counted twice.
Where the standards are heading
Annual averages are on their way out. Hourly matching is on its way in.
The GHG Protocol is revising its Scope 2 guidance, and the proposal on the table would require contractual instruments under the market-based method to be matched hourly rather than netted off across a year — with load profiles named as one of the mechanisms that makes it workable. It is still a proposal, and the final text is not expected before late 2027.
The direction is not in doubt, and it is unkind to anyone whose evidence is a folder of invoices. An organisation already collecting validated half-hourly data per supply point has the substrate for it. One reconstructing consumption from monthly totals does not, and cannot go back and get it.
0.906
kgCO₂e per kWh
South Africa's grid emission factor for 2023, published by the DFFE in 2025. Among the highest in the world, which is what makes the consumption number worth measuring properly.
R308
per tonne, from January 2026
Phase two of the carbon tax, up from R236, running to 2030 with the free allowances declining as it goes.
2026
Carbon budgets become mandatory
Affected companies register, set a company-level budget, file a mitigation plan and report annually — the first commitment period began in January.
MOL is not a carbon accounting package and we do not sell it as one. What it holds is the thing those packages are least able to get hold of: consumption per site and per tenant, per half hour, separated by source, validated, and with every estimated interval labelled as estimated.
Verifying every invoice by hand takes a room full of people.
A large portfolio receives thousands of utility invoices a month, each running to dozens of tariff line items, and each needing to be checked against what the meters actually recorded. The arithmetic is not difficult. The volume is.
Which is why most portfolios verify a sample and pay the rest. An error in the supplier's favour, inside the unsampled remainder, is an error nobody finds.
Three numbers, two questions.
Every account is valued three ways: the statement the site received, the utility's own line-item detail behind it, and the same tariff applied to the client's own check meter.
Which asks two separate questions. Does the utility's detail reconcile to the statement it sent? And does that tariff, run against your metering, agree with what it billed? An account has to pass both to be cleared without a person.
| Site | Statement | Bill detail | Your meters | Status |
|---|---|---|---|---|
| Mainstreet Mall | R 142,860.44 | R 142,860.44 | R 141,993.18 | AgreesWithin tolerance on both checks. |
| Mainstreet Mall — Liquor | R 9,204.17 | R 9,204.17 | R 9,188.02 | AgreesWithin tolerance on both checks. |
| Northgate Retail Park | R 204,118.72 | R 187,650.31 | R 187,402.88 | QueryThe utility's own detail does not add up to the statement it sent. |
| Riverside Centre | R 318,442.09 | R 318,442.09 | R 291,204.63 | QueryYour metering is 8.6% below what was billed. |
| Southfield Depot | R 96,331.05 | R 96,331.05 | R 96,102.44 | AgreesWithin tolerance on both checks. |
OCR that understands tariffs
Scanning a document is nothing new. The difficulty is interpreting what comes out — identifying the fields on an unfamiliar statement and reading them against the tariff they were billed on, to rebuild the invoice as structured data. MOL was proved first on Eskom accounts, deliberately: they are the most complex tariffs in the country.
It knows when it is wrong
Every individual charge is summed and checked against the statement total. Anything that does not reconcile is set aside for a person rather than passed downstream. Accuracy across thousands of accounts is consistently better than 97.5 per cent — better than manual capture, and unlike manual capture it declares its own failures.
Ten data capturers
One person, a few hours
Days to capture
Minutes
Paid, then queried
Approved before the due date
What's in MOL
Ten capabilities on one repository. Each has its own page.
Meter data management
Validation, estimation and editing against configurable rules. Gap, spike, reactive-energy and high/low usage checks, with anomalies escalated for inspection rather than silently estimated.
Data visualisation
Load profiles, heat maps, baseload analysis and period comparison. Consumption is invisible until somebody draws it — and most of what is wrong shows up as a shape before it shows up as a number.
Dashboards
Management, operational and site-level views. The estate at a glance for a financial director, and the exceptions queue for the person who has to act on them today.
Tariff & billing
A tariff team that tracks Eskom, municipal and NERSA changes. Eskom Megaflex alone breaks into eleven distinct charge components — all of them modelled.
Virtual meters
Mathematical metering points where a physical meter isn't feasible, including standby generation recovery. Vector summation across all four quadrants, so diversified maximum demand falls out correctly.
Prepayment
Prepayment for commercial tariffs an STS meter cannot handle: time-of-use, maximum demand, common-area apportionment, multiple utilities on one balance.
Engineering diagnostics
A phasor snapshot every time a meter is read, plus the events the meters raise themselves — tamper, phase loss, reverse energy, and last-gasp notification when the power goes.
API
A documented JSON API over the meter register and the interval data. The same meter reachable by building, by cost centre or by single-line diagram, because those three hierarchies do not align and each caller needs a different one.
How it is delivered
Nothing to install. Nothing to license.
MOL is delivered as software as a service. There are no servers or applications to install at your site — all functionality is reached through the web portal, with roles and privileges set per user. PMT was selling metering this way before the term SaaS existed.
MOL is built on open-source infrastructure throughout. No proprietary third-party software or hardware requiring licensing sits anywhere in the stack — which is why we can change any part of it when a customer needs something changed.
- Delivery
- Cloud SaaS · no client-side install
- Access control
- Granular roles · two-factor authentication · full audit trail
- Availability
- High-availability database cluster · off-site disaster recovery
- Ownership
- Every line developed and maintained in-house