How often a custody meter should be proved or verified is a real decision, not a fixed rule, because verifying too rarely lets undetected drift accumulate into mismeasurement while verifying too often burns time and money on meters that are behaving. The right frequency balances the risk and value at stake against the cost of checking, and it is informed by the contract, the throughput, the meter's own drift history, and any regulatory floor. This guide explains how that cadence is set, when it should be tightened or relaxed, and how it complements general instrument calibration scheduling by focusing specifically on the proving and verification of custody meters.
Meter Verification Frequency in one line: Meter verification frequency is how often a custody meter is proved or verified to confirm it is still measuring within tolerance, and it is set from the contract requirements, the value of the throughput, the meter's history of drift, and any regulatory minimum. A high-value or drift-prone meter is verified more often; a stable, lower-value one can be verified less often, subject to any floor the contract or regulator sets. The frequency is a risk-based judgement that is tightened when evidence suggests a meter is drifting and relaxed only when a record of stability supports it.
The starting point for verification frequency is almost always the contract and any applicable regulation, because those set obligations that override discretion. A custody contract commonly states how often the meter must be proved or verified, or references a standard that does, and a regulator may impose a minimum frequency for certain measurement points. These form a floor: whatever else the analysis suggests, the meter must be verified at least as often as the contract and the regulator require, and a schedule that lags those requirements is a compliance gap regardless of how well the meter is performing.
Above that floor, the value at stake drives the frequency. A meter carrying a large or high-value throughput justifies more frequent verification, because even a small measurement error on a big flow represents a large quantity of product and money, and the cost of a proving is trivial against that exposure. A meter on a small, low-value stream sits at the other end: the same proving cost buys far less protection, so a longer interval is reasonable. Weighing the cost of verification against the financial exposure of an undetected error is the core of the risk-based approach.
The kind of meter and its installation also inform the baseline. Some meter technologies hold their calibration well and drift slowly, while others are more sensitive to changing conditions, contamination, or wear, and the service matters too, since dirty, wet, or erosive streams age a meter faster than clean, dry ones. A meter that is inherently stable in benign service can start on a longer interval, while one prone to drift or in harsh service warrants a shorter one from the outset, before any of its own history has accumulated.
The most valuable input to verification frequency is the meter's own history, because past provings are direct evidence of how this specific meter behaves. If successive provings show the meter factor holding steady within a tight band, that is a record of stability that can justify relaxing the interval, extending the time between provings within whatever the contract and regulation allow. Conversely, if the factor is moving between provings, drifting steadily in one direction, or jumping unpredictably, that is evidence the meter needs watching more closely and the interval should be tightened until it settles.
This makes verification frequency a dynamic setting rather than a number fixed once and forgotten. The right practice is to review the interval against the accumulating proving record and adjust it: shorten it when drift appears, and lengthen it cautiously only when a genuine run of stable provings supports doing so. A single stable proving is not enough to relax the schedule, because one good result does not establish a trend, whereas a consistent pattern across several provings does. Treating the interval as something the evidence continually updates is what keeps it matched to the meter's real behaviour.
Certain events should override the schedule and trigger verification regardless of when the last one happened. A meter that has been disturbed, cleaned, repaired, or reinstalled, a run that has seen abnormal conditions such as an upset, contamination, or overrange, or a suspicion of mismeasurement from a reconciliation imbalance all warrant an out-of-cycle proving, because the assumption that the meter is unchanged since its last verification no longer holds. Building these event triggers alongside the periodic interval means the frequency responds to what actually happens to the meter, not just to the calendar.
A periodic verification frequency, however well chosen, is a scheduled check between which the meter runs unwatched, and continuous monitoring narrows that blind spot. Many custody meters expose diagnostics or can be cross-checked against a companion measurement, and trending those between provings gives early warning of drift long before the next scheduled verification. A cloud SCADA such as Merobix can gather these signals across many meters, so that a meter beginning to drift, or one whose reconciliation with a check measurement is widening, stands out and can prompt an out-of-cycle proving rather than waiting for the interval to come around.
Continuous visibility also feeds directly into setting the frequency itself. Because a cloud platform can hold the history of a meter's provings and its between-proving diagnostics in one place, the review that decides whether to tighten or relax the interval is grounded in an assembled record rather than scattered reports. A meter with a long, visible run of stable factors and clean diagnostics makes the case for a relaxed interval on evidence, while one whose diagnostics wander makes the case for tightening, and both arguments are stronger when the data is centralised and trended.
It is worth being clear that this continuous monitoring complements verification rather than replacing it. Diagnostics and check-meter comparisons flag that something may have changed, but the proving or verification is what re-establishes the meter factor against a reference and satisfies the contract and regulator. What cloud SCADA does is make the scheduled cadence smarter and safer: it catches drift the schedule would have missed, supplies the evidence to adjust the interval defensibly, and turns verification frequency from a fixed calendar entry into a risk-based cadence that responds to how each meter is actually behaving.
The main factors are the contract and regulatory requirements, which set a minimum floor, the value of the throughput, which justifies more frequent proving when the exposure of an error is large, the meter technology and service conditions, and the meter's own drift history. A high-value or drift-prone meter in harsh service is proved more often, while a stable, lower-value meter in benign service can be proved less often. The frequency is a risk-based balance of verification cost against the exposure of an undetected error.
Yes, but only on evidence and within whatever the contract and regulator allow. A consistent run of provings showing the meter factor holding within a tight band is a record of stability that can justify relaxing the interval, whereas a single good proving is not enough because it does not establish a trend. The interval should be reviewed against the accumulating proving record and lengthened cautiously, and tightened promptly if drift reappears.
An out-of-cycle verification is warranted whenever the assumption that the meter is unchanged no longer holds. That includes after the meter has been disturbed, cleaned, repaired, or reinstalled, after abnormal conditions such as an upset, contamination, or overrange, and whenever a reconciliation imbalance raises a suspicion of mismeasurement. Building these event triggers alongside the periodic interval keeps the frequency responsive to what actually happens to the meter rather than only to the calendar.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.