When a flow computer reports a daily average temperature or pressure, the way it computed that average matters enormously, because the same raw samples can produce very different averages depending on how they are weighted. Flow-weighted averaging counts each sample in proportion to how much was flowing when it was taken, while time-weighted averaging counts every sample equally regardless of flow. For the variables that go into a custody volume calculation, the measurement standards require flow-weighted averaging, because a no-flow period should not drag the daily average toward conditions that were never actually delivering product. Understanding which averaging method a number came from is essential to reconciling a SCADA historian against a flow computer's official report.
Flow-Weighted vs Time-Weighted Averaging in one line: Flow-weighted averaging weights each temperature, pressure, or differential sample by the flow rate at the time it was taken, so periods of no flow contribute nothing to the average, while time-weighted averaging counts every sample equally regardless of flow. API MPMS 21.1 requires flow-weighted (also called flow-dependent) linear averaging for the variables used in the volume calculation, and permits time-weighted averaging only for auxiliary or reporting variables. Getting the method right keeps the daily average representative of the conditions under which product actually flowed.
Imagine a meter station that flows warm gas for twelve hours and then sits idle and cold for twelve hours. A time-weighted average of temperature would count the cold idle hours exactly as heavily as the flowing hours, pulling the daily average temperature far below the temperature at which product was actually delivered. Since temperature feeds the volume correction, using that skewed average would correct the delivered volume as if it had been colder than it really was, introducing an error that has nothing to do with the metering hardware and everything to do with how the average was formed. Flow-weighting solves this by giving each sample a weight equal to the flow at that moment, so the cold no-flow hours, which have zero or near-zero flow, contribute almost nothing.
The mechanism is straightforward: rather than summing the samples and dividing by their count, the flow computer sums each sample multiplied by the flow at that instant, and divides by the sum of the flows. A sample taken during a high-flow moment counts heavily, a sample taken during a trickle counts lightly, and a sample taken during no flow drops out entirely. The resulting average describes the conditions the delivered product actually experienced, which is exactly what a volume correction needs. This is why the standard calls it flow-dependent averaging, because the weight of each sample depends on the flow accompanying it rather than on the passage of time.
The consequence is that flow-weighted and time-weighted averages of the same station over the same day can differ substantially whenever flow is intermittent, and they converge only when flow is steady. On a station that runs flat out around the clock the two methods give nearly the same answer, which lulls people into thinking the distinction is academic. It becomes decisive on batch operations, on stations that shut in overnight, and on any service where flow starts and stops, because that is precisely when the idle periods can distort a time-weighted average and where flow-weighting is doing real work to keep the corrected volume honest.
The electronic gas measurement standard, API MPMS Chapter 21.1, is explicit that the variables used directly in the volume calculation must be averaged in a flow-dependent manner using linear averaging. That means the flowing temperature, the flowing pressure, and the other quantities that the volume equation consumes are flow-weighted, so the average that feeds the correction is the average that product actually saw. Linear here refers to averaging the variable itself rather than some transformed quantity, and flow-dependent refers to the weighting by flow. Together they define the method the standard expects for the numbers that end up on a custody ticket.
Time-weighted averaging is not forbidden; it has its place for auxiliary and reporting variables that do not enter the volume calculation. A variable being trended purely for operational awareness, or a supplementary figure reported for information rather than correction, can reasonably be time-weighted, because for those purposes an even average over the day is meaningful and there is no volume being distorted. The distinction the standard draws is between variables that drive the corrected volume, which must be flow-weighted, and variables that are along for the ride, which may be averaged either way as appropriate. Applying time-weighting to a variable that feeds the volume calculation is the error the requirement exists to prevent.
There is also a handling rule for no-flow periods that follows naturally from flow-weighting. When there is genuinely no flow, there is no product whose conditions need averaging, so the flow-weighted average simply excludes those intervals, and a well-behaved flow computer reports the average of the flowing conditions rather than an average diluted by idle time. Some systems also carry a separate time-weighted average alongside for reference, which is legitimate as long as it is clearly labeled and the flow-weighted value is the one used in the volume calculation. The trouble starts when the two are conflated and a time-weighted average quietly ends up correcting a volume it should never have touched.
A SCADA historian pulling data from a flow computer often stores its own averages as well, and this is where averaging method has to be tracked carefully, because a historian's default rollup is frequently time-weighted. If the historian simply averages the temperature samples it received over a day, it produces a time-weighted number that will not match the flow computer's flow-weighted average whenever flow was intermittent, and a measurement technician comparing the two will chase a discrepancy that is really just a difference in method. The safe practice is to know, for every stored average, whether it is the flow computer's flow-weighted value or the historian's own time-weighted rollup, and not to treat them as interchangeable.
A cloud SCADA platform such as Merobix earns its place here by carrying the flow computer's own flow-weighted averages through as the authoritative custody values, rather than recomputing them, and by clearly distinguishing those from any operational time-weighted trend it also keeps. When the platform pulls the daily quantity transaction record from the flow computer, the flow-weighted averages that produced the reported volume travel with it, so the value shown to an auditor is the value the volume was actually corrected on. Tagging each record with the averaging method that produced it removes the ambiguity that otherwise makes historian data hard to defend.
This matters most at reconciliation and audit. When a custody figure is challenged, the question is often whether the temperature and pressure that corrected the volume were representative of the flowing conditions, and the answer depends entirely on flow-weighting having been applied. A platform that surfaces the flow-weighted averages alongside the reported volume, and that does not silently overwrite them with time-weighted rollups, lets the measurement figures reconcile with the flow computer's quantity transaction record without a forensic exercise. The averaging method is not a footnote; it is part of what makes a corrected volume defensible, so carrying it explicitly through the historian is what keeps the numbers auditable.
They diverge whenever flow is intermittent, because time-weighting counts idle no-flow periods as heavily as flowing periods while flow-weighting effectively excludes them. On a station that runs at steady flow around the clock the two methods give nearly identical answers, which is why the distinction seems academic until you meet batch operations or stations that shut in overnight. That is exactly when idle periods can pull a time-weighted average away from the conditions product actually experienced.
Because the temperature, pressure, and other variables that feed the volume correction should describe the conditions under which product actually flowed, not the average of every moment including idle time. A no-flow period at a different temperature would skew a time-weighted average and correct the delivered volume as if conditions were something they were not. Flow-weighting ties each sample's influence to the flow accompanying it, keeping the corrected volume representative and defensible.
Yes, for auxiliary or reporting variables that do not enter the volume calculation. A value trended purely for operational awareness or reported for information can reasonably be time-weighted, since there is no volume being distorted. The requirement is that variables which drive the corrected volume must be flow-weighted, so the error to avoid is applying time-weighting to a quantity that feeds the volume equation.
This page references the standards, specifications, and official documentation published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.