A custody meter's factor is only trustworthy for as long as the meter and the conditions it was proved under stay the same. Proving frequency is the decision of how often to re-prove that meter so the factor never drifts out of validity unnoticed. Prove too rarely and you risk billing on a stale factor; prove too often and you burn labor, product, and prover time you did not need to spend.
Proving Frequency in one line: Proving frequency is how often a custody transfer meter is proved to establish a fresh meter factor. Operators set it using calendar intervals, accumulated throughput, changes in operating conditions, or statistical control-limit triggers, balancing the cost of over-proving against the measurement risk of under-proving. The goal is to keep a valid, current factor at all times.
There is no single right answer to how often a meter should be proved, because different triggers suit different situations, and most operators use several together. A calendar interval - proving every so many days or at a fixed schedule - is the simplest and is common where flow is steady and predictable. A throughput trigger proves the meter after it has passed a certain accumulated volume, which ties re-proving to actual usage and wear rather than to the clock, and makes sense where flow rates vary widely.
Condition-based triggers, often called prove-on-change, re-prove whenever something that affects the meter factor shifts: a meaningful change in flow rate, temperature, pressure, viscosity, or product being measured. Because the factor is only strictly valid at the conditions it was proved under, a large move in operating point is itself a reason to re-prove rather than trust the old factor. Control-limit triggers add a statistical layer, prompting a prove when the trend of successive factors shows the meter drifting toward the edge of its accepted band.
Layered on top of all of these are contractual and regulatory requirements. Custody transfer is a commercial handover, so the buyer and seller frequently agree in the contract on a minimum proving frequency, and jurisdictions or company standards may impose their own. In practice the effective proving frequency is the strictest of whatever the contract, the standard, and the operator's own risk assessment demand, and a good schedule is the combination of a routine interval plus event-driven proves whenever conditions or trends call for one.
Both extremes cost money, which is why frequency is an optimization rather than a maximize-safety exercise. Under-proving is the more visible risk: if the factor drifts while the meter runs on a stale value, every barrel measured between proves is billed slightly wrong, and on a high-throughput custody stream even a small factor error becomes a large financial exposure over time. Worse, if a factor is discovered to have expired or drifted, the parties may have to negotiate a retroactive correction for the whole period since the last valid prove, which is disruptive and contentious.
Over-proving has quieter but real costs. Each prove takes operator time, may require diverting flow or interrupting normal operation, consumes product in the prover loop, and puts wear on the prover and its detectors. Proving far more often than the meter's stability warrants spends all of that to confirm what you already knew - that the factor had not moved. There is also a subtle statistical cost: proving so often that normal run-to-run scatter dominates can make people react to noise as if it were a real shift, chasing factors that were never actually drifting.
The sweet spot is a frequency matched to how stable the particular meter and stream actually are, learned from the meter's own history. A meter whose factor has been rock-steady over many proves can safely stretch its interval; a meter whose factor wanders needs proving more often, or needs the underlying cause of the wander fixed. Setting frequency from evidence rather than from a fixed habit is how operators get a valid factor at all times without paying for proves that told them nothing.
The failure mode a schedule is meant to prevent is a factor quietly expiring because everyone was busy and no one noticed the meter was due. A cloud SCADA platform closes that gap by tracking, for every custody meter, when it was last proved and against which trigger, and by counting down the calendar days and the accumulated throughput toward the next due point. When a meter approaches its interval, or when a monitored condition moves far enough to warrant a prove-on-change, the system can raise a reminder or alarm so the prove is scheduled deliberately rather than discovered late.
Trending is the other half. By plotting each meter's successive factors against date, an operator can see whether the meter is stable enough to stretch the interval or is drifting and needs more frequent attention, and can distinguish a genuine trend from ordinary proving scatter. That same trend feeds control-limit triggers, so a factor heading toward the edge of its band prompts a prove before it crosses. Turning the raw proving history into a visible trend is what lets frequency decisions be made from evidence rather than habit.
Merobix records proving events and factors alongside the live measurement data and makes both viewable from any browser, so the proving schedule and the meter's factor history live in the same place as the flow it is measuring. The platform does not perform the prove or compute the factor - that stays in the certified prover and flow computer - but by scheduling the next due prove, flagging conditions that call for an early one, and preserving the trend of factors over time, it ensures a valid factor is always current and no meter runs past its proving window unnoticed.
There is no universal number; the right frequency depends on the meter's stability, the throughput and how much conditions vary, and any contractual or regulatory minimum. Common practice combines a routine interval - by calendar or by accumulated volume - with event-driven proves whenever operating conditions change materially or the factor trend heads toward its control limits. The effective frequency is the strictest of the contract, the applicable standard, and the operator's own risk assessment.
Prove-on-change means re-proving the meter whenever an operating condition that affects the meter factor shifts significantly, such as a large change in flow rate, temperature, pressure, viscosity, or the product being measured. Because a meter factor is only strictly valid at the conditions it was proved under, a big move in operating point is itself a reason to re-prove rather than continue on the old factor. It is used alongside routine calendar or throughput intervals, not instead of them.
Over-proving is not more accurate so much as more frequent, and each prove costs operator time, may interrupt flow, consumes product, and wears the prover. Proving far more often than the meter's stability warrants spends all of that just to reconfirm a factor that had not moved. It can also cause people to react to normal run-to-run scatter as if it were real drift, chasing changes that were never there.
Safety & engineering notice. This article is general educational information, not site-specific engineering, safety, or legal advice, and it does not reflect any particular facility. Standards and regulations (for example OSHA, API, IEC, ISO, NFPA, NIST, and NERC CIP requirements) change and vary by edition, jurisdiction, and application. SCADA and remote monitoring cannot verify physical isolation, atmosphere, lockout/tagout, permit status, or a safe go/no-go decision. Qualified personnel must perform site-specific engineering, hazard analysis, and safety review, and confirm current requirements with the authority having jurisdiction, before acting.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.