When money changes hands based on how much gas passed through a meter, the record behind the number has to be defensible, and API Chapter 21.1 is the standard that defines what defensible looks like. It governs how electronic flow computers on gas meters calculate volumes, what data sets they must keep, and how those records must be preserved so an auditor can reconstruct any period. This page explains what API 21.1 covers, the specific record types it requires, and how a cloud SCADA or electronic flow measurement system polls and retains those records for custody-transfer confidence.
API 21.1 Electronic Gas Measurement in one line: API 21.1 is the industry standard, part of the API Manual of Petroleum Measurement Standards, that governs electronic gas measurement: how a flow computer calculates gas volumes and what records it must produce and retain. It defines required data sets including configuration and event logs, hourly and daily quantity records, and no-flow logging, so that a complete, auditable history exists behind every reported volume for custody transfer.
API 21.1, formally part of the API Manual of Petroleum Measurement Standards, addresses electronic gas measurement, the practice of using a flow computer rather than a mechanical chart to measure gas flow. It sets out how the flow computer should acquire the raw inputs from the meter, such as differential pressure, static pressure, and temperature, and apply the flow equations to turn those inputs into a volume. The aim is that any two compliant systems handling the same inputs produce a result that is consistent and reconstructable.
Beyond the calculation itself, the standard's real weight is in recordkeeping. Because an electronic volume is just a number in memory, API 21.1 defines the accompanying records that give that number provenance: what the device was configured to do, what changed, what it measured, and when. Those records are what let an auditor or a counterparty verify that the reported volume was produced correctly, rather than having to take the figure on trust.
This is why the standard matters so much in custody transfer, where the measured quantity determines payment between parties. A volume without a defensible record trail is difficult to stand behind if it is ever questioned, so API 21.1 effectively defines the minimum evidence an electronic gas measurement point must carry. Meeting it is less about the meter hardware and more about disciplined generation, collection, and retention of the required data sets.
A compliant electronic gas measurement point produces several distinct data sets. The configuration log captures the parameters and constants the flow computer uses in its calculation, such as the meter geometry, the gas composition assumptions, and the ranges of the inputs, so an auditor can see exactly how the device was set up for any period. The event log timestamps changes and significant events, so that any alteration to those parameters is recorded with when it happened and, ideally, who made it. Together these establish how the volume was being computed at every moment.
The quantity records capture the results over time. Hourly quantity records store the accumulated volume and the average or representative input values for each hour, and daily quantity records roll those up into daily totals. This granularity is deliberate: hourly data lets an analyst inspect flow behavior, spot anomalies, and, if a problem is found, recompute or adjust a specific interval rather than a whole day. The quantity records are the measured output the whole system exists to produce.
A no-flow log rounds out the picture by recording periods when the meter registered no flow. This matters because a stretch of zero flow is itself measurement evidence, distinguishing a genuinely idle meter from a communication gap or a failed sensor, and it prevents ambiguity about whether missing volume means no gas moved or the record was simply lost. Taken together, the configuration and event logs, the hourly and daily quantity records, and the no-flow log form the audit trail API 21.1 expects behind an electronic gas measurement.
Meeting API 21.1 in the field is only half the job; the records also have to be gathered from the flow computer and kept somewhere durable. This is where a SCADA or electronic flow measurement system does the work, polling each flow computer on a schedule to retrieve its configuration log, event log, hourly and daily quantity records, and no-flow log, then storing them centrally. A cloud platform such as Merobix can collect these records from many dispersed meters and preserve them together, so the audit trail for a whole gas-gathering system lives in one queryable place rather than scattered across devices in the field.
The value of central collection is both operational and defensive. Operationally, an analyst can see hourly quantities and events from every meter without visiting sites, which makes it far easier to notice a drifting input, a missed poll, or a configuration change that needs review. Defensively, preserving the records off the device protects them: flow computers have finite memory and eventually overwrite old logs, so pulling the data into retained storage before it rolls off is what keeps a complete history available when an audit reaches back months or years.
For a custody-transfer operation the practical outcome is confidence. When a counterparty or auditor questions a volume, the operator can produce the configuration in effect at the time, the events that touched it, the hourly quantities, and the no-flow periods, all consistent with what API 21.1 requires. A cloud SCADA system that reliably polls and retains these records turns the standard from a compliance obligation into a routine byproduct of normal monitoring, so the evidence is simply there when it is needed rather than something scrambled for after the fact.
API 21.1 calls for a configuration log of the parameters and constants used in the calculation, an event log timestamping changes and significant events, hourly and daily quantity records of measured volumes and average inputs, and a no-flow log recording periods of zero flow. Together these give every reported volume a reconstructable audit trail. They are collected and retained so an auditor can verify how any period's volume was produced.
In custody transfer the measured volume determines payment between parties, so the number must be defensible if questioned. API 21.1 defines the records that give an electronic volume provenance, showing how it was configured, what changed, what was measured, and when. Meeting the standard means the operator can reconstruct and defend any reported quantity rather than asking a counterparty to take it on trust.
A SCADA or electronic flow measurement system polls each flow computer to retrieve its configuration, event, quantity, and no-flow records and stores them centrally before the device overwrites old logs. A cloud platform can gather these from many meters into one retained, queryable history. That turns compliance into a byproduct of normal monitoring, so the full audit trail is available whenever an audit reaches back in time.
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.