When two parties dispute how much gas moved through a meter, the argument is settled not by the current reading but by the records the flow computer kept over the period in question. API 21.1 defines what those records must contain so that a measurement can be reconstructed and defended after the fact. This guide explains the quantity transaction record and its companion configuration and event logs, why all three are needed for a custody audit, and why editing a live flow computer without leaving an event trail quietly destroys the defensibility of the measurement.
Quantity Transaction Record (QTR) in one line: A quantity transaction record, defined under API 21.1, is the flow computer's log of the quantities it measured over each averaging period, such as the hourly and daily volumes and energy along with the average process conditions that produced them. It is kept alongside a configuration log of the parameters used in the calculation and an event log of every change, alarm, and alarm reset. Together these three records let an auditor reconstruct and verify a measurement long after the gas has flowed, which is what makes a custody transfer defensible in a dispute.
API Chapter 21, Section 1 governs the electronic flow measurement of gas, and its central requirement is that a flow computer keep enough recorded information to reproduce and audit every quantity it reports. The quantity record is the first of these: for each averaging period it stores the accumulated volume and energy together with the flow-weighted or time-weighted averages of the inputs, typically differential pressure, static pressure, temperature, and the extension used in the calculation. This is the record a shipper and a pipeline compare when they reconcile a month's deliveries.
The configuration record captures the constants and settings the computer used to turn those inputs into quantities. That includes the orifice plate and pipe dimensions, the gas composition or heating value in effect, the calculation methods selected such as the AGA version and characterization method, and thresholds like the low-flow cutoff. Two flow computers fed identical process inputs will produce different volumes if their configurations differ, so the configuration record is what proves which parameters were actually in force during the period being audited.
The event log is the record that ties the other two together over time. It timestamps every operator change to the configuration, every alarm that occurred, and the acknowledgment or reset of those alarms. When an auditor sees that a plate size or a composition changed mid-month, the event log tells them exactly when it happened and who made it, so the quantity record on each side of that change can be interpreted correctly. Without the event log, a configuration record only shows the final state, not the history that produced the reported totals.
Custody transfer is a financial transaction denominated in gas, and like any financial record it has to survive scrutiny. A quantity that cannot be traced back to the exact inputs, configuration, and events that produced it is, for audit purposes, an unsupported number. The API 21.1 record set exists so that months or years later a measurement technician, an auditor, or an opposing party can pick up the logs and independently confirm that the reported volume follows correctly from what the meter actually saw.
The records also defend against honest error, not just disagreement. If a transmitter drifted, an impulse line plugged, or a composition was entered wrong, the combination of quantity averages and event timestamps often reveals it, allowing a corrected volume to be calculated for the affected window rather than the whole period being written off. This is why measurement contracts and regulations lean so heavily on the record set: it converts a black-box total into an auditable calculation whose every step is documented.
Retention matters as much as content. The records have to be preserved for the period the contract or regulator requires, which is typically well beyond the month in which the gas flowed, and they have to be preserved in a form that cannot be silently altered. A quantity record that could be edited after the fact would be no more trustworthy than no record at all, so the integrity and retention of the logs are part of what makes them defensible, not just their existence.
The most common way an otherwise sound measurement becomes indefensible is an undocumented change to a live flow computer. If a technician corrects a plate size, updates a composition, or adjusts a cutoff and the flow computer records the change in its event log, the record set stays whole: the quantity totals before and after the edit can each be interpreted against the configuration that was in force. But if a change is made through a path that bypasses the event trail, the reported quantities no longer match a documented configuration, and the audit chain is broken for that period even though every number looks normal on the screen.
This is why measurement discipline treats every parameter change as an event to be captured, not a convenience to be applied quietly. A change that improves accuracy going forward can still poison the defensibility of the record if it is not logged with a timestamp, because an auditor cannot tell a legitimate correction from an unexplained discontinuity. The rule of thumb is simple: nothing on a custody flow computer should change without leaving a mark in the event log.
A cloud SCADA such as Merobix supports this discipline by centralizing the flow computer's records and by making configuration changes visible and attributable. When quantity records, alarms, and configuration events are polled off the flow computer and retained centrally, a measurement team can see across a whole field which meters changed, when, and why, without visiting each site. Alarms surfaced from the flow computer, such as an input out of range or an accumulator issue, reach an operator in time to investigate before the affected period is reconciled, and the centralized history complements the flow computer's own API 21.1 logs rather than replacing them as the system of record.
The quantity record stores the volumes, energy, and average process conditions the flow computer measured over each period. The configuration log stores the parameters and settings, such as plate size, composition, and calculation method, that the computer used to produce those quantities. You need both because identical inputs produce different quantities under different configurations, so the configuration proves how the numbers were derived.
Because the reported quantities can no longer be matched to a documented configuration for the period. An auditor sees a change in the totals with no logged explanation and cannot distinguish a legitimate correction from an error or tampering. API 21.1 requires every change to be captured in the event log precisely so that the record set stays reconstructable and defensible.
The exact retention period is set by the applicable contract or regulator rather than a single universal number, but it typically extends well beyond the month the gas flowed to cover the window in which a measurement can be disputed or audited. The records must also be retained in a form that cannot be silently altered, since integrity is part of what makes them usable in an audit.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.