A single quantity transaction record tells you what a meter measured, but on its own it does not let anyone prove the measurement was computed correctly. For custody transfer, the standard expectation under API 21.1 is not just the record of quantities but a complete audit package: the quantity transaction record together with the configuration log, the event log, the alarm log, and enough averages and constants that an auditor can independently recompute the volume from scratch. Each of those components answers a different question about the measurement, and together they make the reported volume defensible rather than merely asserted. This guide explains what each part of the audit package must contain and roughly how long it is expected to be kept, and how a cloud platform can assemble the whole package on demand instead of forcing someone to pull each piece from every flow computer by hand.
QTR Audit Package in one line: A quantity transaction record audit package under API 21.1 is the full set of records needed to independently verify a custody measurement: the quantity transaction record of measured quantities plus the configuration log, the event log, the alarm log, and the averages and constants required to recompute the volume. The QTR gives the quantities, the configuration log gives the parameters in effect, the event and alarm logs give every change and abnormal condition, and the averages and constants give the inputs, so an auditor can reproduce the volume without trusting the flow computer's total. It is distinct from any single one of those records because its purpose is complete, independent recalculation.
The quantity transaction record is the backbone. It carries the measured and computed quantities for each accounting period, the volumes and, where applicable, the energy, along with the period averages of the live inputs such as differential pressure, static pressure, temperature, and the relevant gas properties. It is the record that says how much moved and what the average conditions were while it moved. But averages alone do not prove a calculation; they are only the top layer, and the audit package exists because verifying a custody volume requires more than the flow computer's own summary of what it did.
The configuration log records the parameters that were in effect during the measurement: the meter and plate dimensions, the calculation standard and method, the base conditions, the fixed constants, the units, and every other setting that determines how raw inputs become a volume. Two of these are needed for recalculation because the same inputs produce different volumes under different configurations, so an auditor has to know exactly which configuration was active. The event log complements this by recording every change to that configuration, with what changed, when, and by whom, so that if a parameter was altered mid-period the auditor can see it and account for its effect rather than being misled by a single end-of-period configuration snapshot.
The alarm log records abnormal conditions during the period, such as inputs going out of range, a transmitter failing, a value being held or substituted, or a calculation limit being hit. This matters for an audit because an alarm can mean the measurement during that time was compromised or that a substituted value was used in place of a live one, and a defensible volume has to account for those episodes rather than silently include them. Finally, the averages and constants, which overlap with the QTR and configuration log, are the concrete numbers an auditor feeds back into the calculation: the period-average inputs and the fixed constants that, run through the stated method, must reproduce the reported volume. Together these components let someone recompute the volume independently, which is the whole point of the package.
Each component of the audit package carries a retention expectation, because a record that has been discarded cannot support an audit no matter how complete it once was. The general expectation is that the audit trail, including the quantity records, the configuration and event history, and the alarm history, is retained long enough to cover the period over which a measurement might be questioned or reconciled, which is typically driven by contract terms and regulatory requirements rather than by convenience. The practical consequence is that a custody measurement operation has to keep not just the latest values but the historical record of quantities, configurations, changes, and alarms for a defensible period.
The reason the whole package matters, rather than any single record, is that each piece closes a gap the others leave open. The QTR alone could be correct or could be the output of a misconfigured calculation, and nothing in the QTR distinguishes the two; only the configuration log reveals the parameters, and only the event log reveals whether they changed during the period. A correct-looking volume computed with a wrong plate size or a wrong base condition would pass unnoticed with just the QTR, and would be caught immediately with the configuration and event logs. The alarm log then reveals whether the live inputs behind the averages were trustworthy throughout or were degraded and substituted.
This is why the audit package is treated as a single deliverable even though it is assembled from distinct records. Its purpose is not to store data for its own sake but to make the reported volume independently reproducible and to expose anything that would undermine that reproduction, whether a configuration change, a substituted value, or an out-of-range input. A package missing any component is not a complete audit trail, because the missing piece is exactly where a discrepancy could hide. The completeness is the point, and it is what separates a defensible custody record from a bare number.
Assembling this package the traditional way is laborious and error-prone. The quantities, the configuration, the events, and the alarms often live inside each flow computer, and producing an audit package has historically meant connecting to each device, extracting each log, and stitching them together for the requested period, one meter at a time. When an auditor asks for a package covering many meters over several months, the effort is substantial, and the risk of missing a log or grabbing the wrong period is real. The manual process is also fragile because the raw records sit in the field, exposed to device failures and overwrites, until someone pulls them.
A cloud SCADA platform such as Merobix changes this by continuously collecting the quantity records, the configuration state and its changes, the events, and the alarms from every flow computer into a central store as they happen, rather than pulling them only when an audit is requested. Because the components are already gathered and time-aligned in one place, the platform can assemble a complete audit package for any meter and any period on demand, combining the QTR, the configuration log, the event log, the alarm log, and the averages and constants into a single deliverable without a technician visiting or dialing into each device. What was a multi-day extraction exercise becomes a query.
Centralizing the collection also strengthens the integrity of the package. When the records are captured continuously and stored in a system designed to preserve them, the audit trail is tamper-evident, meaning changes and events are recorded as they occur with their timestamps and origins rather than reconstructed after the fact, and the historical record is protected from the device-level overwrites and failures that can lose field-resident logs. An auditor receiving a package assembled this way gets a consistent, complete set of records that reproduces the volume and exposes every relevant change and alarm, produced from a store that has been holding those records safely all along rather than scraped together at the last minute.
It includes the quantity transaction record of measured and computed quantities and period averages, the configuration log of the parameters in effect, the event log of every configuration change with when and by whom, the alarm log of abnormal conditions, and the averages and constants needed to recompute the volume. Together these let an auditor independently reproduce the reported volume and see anything that would undermine it, which is why the package is more than any single one of those records.
Because the QTR reports quantities and averages but does not reveal the configuration those numbers were computed under, whether that configuration changed mid-period, or whether the inputs were healthy throughout. A correct-looking volume computed with a wrong plate size or base condition would pass a QTR-only check, and a substituted value used during an alarm would be invisible. The configuration log, event log, and alarm log close those gaps, which is why a full audit package is needed to verify the measurement.
By continuously collecting the quantity records, configuration state and changes, events, and alarms from every flow computer into a central, time-aligned store as they occur, rather than pulling them from each device only when an audit is requested. Because the components are already gathered together, the platform can produce a complete package for any meter and period as a query, without visiting each device, and the continuously captured, tamper-evident record protects the audit trail from field-level overwrites and losses.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.