Validation, estimation and editing: what VEE means for meter data

A water meter reports 1,842 m³ at 03:00 and 1,849 m³ at 04:00. For a household that is 7,000 litres in an hour. Is it a burst pipe, a meter whose clock drifted so two days of use landed in one hour, or a reading that arrived twice with different timestamps?

Three more cases from everyday operation:

A register goes down by 40 litres overnight. A broken meter, or legitimate backflow in a building with a pressure tank?
A reading is missing on the day the tariff changes. The bill needs a value for that instant.
A field technician corrects a value after a meter exchange. The monthly total in the report still shows the old number.

Every meter reading is a claim, not a fact. VEE, short for validation, estimation and editing, is the set of rules that turns claims into data that can be billed, analysed and defended. The term comes from electricity metering, where it has been a standard part of meter data management for twenty years. It applies just as much to water, heat and gas, and it now appears in most tenders for a meter data platform.

What the EU rules say

The European rules for metering data are written for electricity, but they make a distinction that every utility should copy.

Directive (EU) 2019/944, Article 20(a), separates two kinds of data. Validated historical consumption data must be made available to final customers on request. Non-validated near real-time data may also be made available, through a standardised interface, to support demand response and other services. The directive does not say how validation is done. It says that the two kinds of data must be told apart.

Implementing Regulation (EU) 2023/1162 sets the interoperability rules for access to that data. Its definition of validated historical metering data is worth reading twice: data collected from a meter, “or completed with substitute values that are determined otherwise in case of meter unavailability”. In other words, estimation is part of validated data by definition, as long as the substitute values are determined by a rule and can be told apart from measured ones.

IEC 61968-9:2024, the Common Information Model (CIM) interface standard for meter reading and control, gives the data model. A meter reading in a CIM message carries a reading quality alongside the value: whether it was measured, estimated or edited, and why. The standard is written primarily for electricity distribution and states that it can be applied to gas and water metering as well.

Together these say three things. Keep validated and non-validated data apart. Allow substitute values, but mark them. Carry the quality of a reading with the reading, not in a separate spreadsheet.

Validation: deciding what to trust

Validation runs when a reading arrives. It does not change the value. It attaches a status, and if the reading fails, a reason. The checks that matter in practice:

Check	What it catches
Future timestamp	Meter clock ahead of real time; a small tolerance is normal
Too old or out of order	A reading that arrives after later ones have already been processed
Duplicate timestamp	The same reading delivered twice, or two readings claiming the same instant
Spike or high increment	A jump that exceeds what the meter size and recent history make plausible
Absolute magnitude	A value the register cannot physically hold
Unit mismatch	A device reporting litres into a meter configured for cubic metres
Stuck register	No change over a period in which consumption is expected
Gap	No reading in a window where one is due, for example a billing date
Decreasing register	A register that counts backwards
Register versus interval	Hourly consumption values that do not add up to the index the meter reports

Two of these need judgment rather than a rule.

A decreasing register is not always an error. Backflow through a meter is real, and a rule that rejects every decrease will throw away genuine data. The better pattern is to flag the reading, keep it, and let the pattern over several readings decide.

A spike depends on the meter. A 7,000-litre hour is impossible for a DN15 household meter and routine for a DN100 inlet. Thresholds have to follow the meter size and, ideally, the meter’s own history. One fixed number for all meters produces either false alarms on large meters or blind spots on small ones.

Two design rules separate good validation from decorative validation:

A rejected reading must not feed the baseline for the next one. If a spike is rejected but still counts towards the recent history, the band widens and the next spike passes.
Validation must not fail open. If the history lookup is unavailable, the reading should be stored as not yet validated, not as valid. Silence is not approval.

Estimation: filling a gap by rule

Estimation produces a value where none was measured. The common need is a billing instant: the end of the month, the day the tariff changed, the day the tenant moved out. The meter reported the day before and the day after, and the bill needs the value in between.

The usual strategies, in increasing order of ambition:

Carry the previous value forward. Consumption in the gap is zero. Simple, conservative, and wrong for anything that was actually running.
Repeat the previous usage. Assume the same consumption as the previous period of the same length.
Interpolate. A straight line between the last reading before the gap and the first after it. The right default when both ends exist.
Profile-based. Use the same period last year, or a comparable group of meters. Needed when the gap is long.

Which strategy is right depends on the use. For a water bill, interpolation between two actual readings is usually fair to both sides. For a leak alarm, no estimate should be used at all.

Three rules apply whatever the strategy. The estimate is flagged as an estimate wherever it appears, including on the invoice and in the API. It is replaced by the actual value if one arrives later, and the replacement is recorded. And it is reversible: an estimate that turns out wrong can be withdrawn without hand-editing a database.

Note the difference between estimating a reading and estimating a derived figure. A zone water balance that apportions a stale inlet reading across days is estimating a volume, not a meter value. It should be flagged in the same way, but it does not need to write anything back to the meter’s history.

Editing: when a person changes a value

Editing is the part most systems get wrong, because it looks harmless. An operator opens a chart, sees a wrong point, and deletes it. The data is now cleaner, and the evidence that there was ever a problem is gone.

The rules for a defensible edit:

Never delete. Mark the reading invalid and keep the value. A deleted reading cannot be audited and cannot be restored.
Keep the original. An edit creates a new value with a source of “edited”. The measured value stays available.
Record who, when and why. User, timestamp, old value, new value and a reason. The reason is not optional.
Give every reading a source. Measured by the device, entered manually, imported from a file, estimated, edited. These must be distinguishable years later.
Require approval for billing-relevant edits. The person who proposes a correction and the person who approves it should not need to be the same.
Propagate the change. A corrected reading for last Tuesday must reach last Tuesday’s daily total, the monthly report and every export that already shipped the old value. A system that only updates the reading has not finished the edit.

The last point is where the quiet failures live. Totals are often calculated once, at night, and never rebuilt. A correction made a week later sits in the reading table while every report built from the totals stays wrong.

One definition of “usable”, everywhere

A platform typically serves readings to a dozen consumers: billing, alarms, consumption analyses, water loss calculations, customer portals, a public API, exports to third parties. Each of them has to answer the same question: which readings count?

If each consumer answers it separately, they will answer it differently. Alarms will ignore readings that the public API happily delivers. The water balance will include a rejected spike that the chart hides. A customer will see one number in the portal and a different one through the API, because one applied the meter’s offset and the other did not.

The fix is organisational as much as technical: one rule for what a usable reading is, written down, and applied by every consumer. The CIM reading quality is a reasonable place to anchor that rule, because it carries the status with the reading rather than relying on each consumer to remember the filter.

What to ask a supplier

If VEE appears in your tender, or you want to know whether the platform you have already does it, these questions separate the answers:

Does every reading carry a validation status and a reason, or only a value?
Which checks run on arrival, and are the thresholds configurable per meter size or per project?
Does a rejected reading influence the validation of the next one?
What happens to a reading when validation cannot run?
Can a reading be hard-deleted? By whom, and is the value kept?
Which estimation strategies exist, are estimates flagged on the invoice, and can an estimate be withdrawn?
Where is the audit trail for an edit, and does it record old value, new value, user and reason?
When a past reading is corrected, which totals, reports and exports are rebuilt?
Do the API, the exports and the user interface apply the same validity rule and the same offsets?

A supplier who can show the audit trail for one edited reading, end to end, has usually answered most of the other questions as well.

How Divako approaches it

Divako validates every reading on arrival and stores the outcome with the reading: a validity flag and the reason a reading was rejected, visible to the operator and carried into the data that leaves the platform. Readings from water, heat, electricity and gas meters go through the same checks regardless of which network delivered them.

Estimation and stipulation of billing readings live in Divako Settlement. It proposes a substitute value from the strategies above, records the source and the reason, holds billing-relevant corrections for approval, and can roll a stipulated value back when the actual reading arrives.

The same validity status feeds water loss management, where a rejected inlet reading matters more than most: in a top-down water balance, customer metering inaccuracies and data-handling errors are counted as apparent losses, and every one of them shifts the leakage estimate.

Sources

Directive (EU) 2019/944, Article 20(a): validated historical and non-validated near real-time consumption data.
Commission Implementing Regulation (EU) 2023/1162: interoperability requirements and procedures for access to metering and consumption data; Article 2 definitions.
IEC 61968-9:2024: Enterprise business function interfaces for utility operations, Part 9: Interfaces for meter reading and control.