Auditing an electronic flow measurement system is less about re-doing the calculations and more about confirming that the reported quantities can be traced, without gaps, back to what was actually measured. The records API 21.1 requires exist precisely so this can be done, and a good audit is a disciplined walk through them. This guide lays out that walk as a practical procedure: start from the reported quantity, reconcile it against the configuration in force, follow the event log for every change, check how edited values were flagged, and confirm the calibration evidence supports the inputs. It is the how-to companion to the definitions of API 21.1 and the quantity transaction record, focused on the procedure rather than the concepts.
Auditing an EFM System in one line: You audit an EFM system by reconciling its reported quantities against the recorded inputs and configuration for the same period, then following the event log to confirm that every change is documented, checking that any edited values are flagged and justified, and verifying that calibration and proving records support the transmitter inputs. The goal is unbroken traceability: to show that each reported quantity follows from the raw measured data under a known, logged configuration. Where the trail breaks, that gap is the finding, even if the numbers look plausible.
Start where the money is, with the reported quantity for a chosen period, and work backward. Pull the quantity record, which holds the volume, energy, flow time, and flow-weighted averages for the period, and pull the configuration record that was in force during that same period, which holds the plate and pipe dimensions, the gas composition or heating value, the reference conditions, and the cutoffs. The first test is reproducibility: given those recorded inputs and that configuration, the reported quantity should follow from the applicable calculation method. If it reproduces, the core of the measurement is sound for that period.
The subtlety that trips up a careless audit is time alignment. The configuration that matters is the one that was actually in effect during the period being audited, not whatever is loaded today, because a constant may have been changed since. So before reconciling, confirm from the event log which configuration values applied across the period, and if a value changed mid-period, account for the split. Auditing a period against the wrong configuration snapshot produces false discrepancies and, worse, can mask real ones.
Sample deliberately rather than exhaustively. Pick periods that stress the system, such as a day with a configuration change, an hour that straddles a low-flow condition, and an ordinary steady day for a baseline, and reconcile each. Steady periods confirm the routine case; the awkward ones are where undocumented edits and mismatched constants hide. A handful of well-chosen reconciliations tells you far more about the system's integrity than a large number of easy ones.
The event log is the spine of the audit because it ties configuration and quantity together over time. Walk it for the audited period and confirm that every change to the configuration, every alarm, and every acknowledgment is present, timestamped, and attributed. The test is completeness against the quantities: if the totals shift and no logged event explains why, that is a finding, because a change in reported gas with no documented cause is exactly what an auditor cannot let stand. Conversely, every logged configuration change should have a plausible operational reason and, ideally, a note recording it.
Edited values deserve their own scrutiny. When a bad input is corrected, whether an implausible differential, a plugged-line reading, or a wrong composition, API 21.1 practice is to flag the edited value and retain the original, so the record shows both what was measured and what was substituted, along with who did it and why. Check that edits are flagged rather than silently overwritten, that the original data survives alongside the correction, and that a justification exists. An edit that improves accuracy going forward can still poison auditability if it is applied quietly, so an unflagged or unexplained edit is a finding regardless of whether the new value is better.
Then verify that the calibration and proving records actually support the inputs the quantities rest on. For each transmitter, confirm it was calibrated or verified on schedule for the audited period, that as-found and as-left values were recorded, and that any adjustment was documented and reconciles with the configuration and event trail. A drifting transmitter caught and corrected on time, with the correction logged, is healthy; one that ran past its due date, or whose adjustment does not appear in the event log, is a gap. The aim across the event log, the edits, and the calibrations is a single unbroken story from the physical measurement to the reported number.
The recurring symptom that an EFM audit is designed to catch is a break in traceability, and its likely causes cluster into a few patterns. A quantity that will not reproduce points to a configuration mismatch, a wrong constant, or a calculation using the wrong method. A total that shifted with no matching event points to an undocumented change on a live flow computer. A value that changed with no flag points to a silent edit. A transmitter whose readings the audit cannot vouch for points to a missing or overdue calibration. Diagnosing which pattern you are looking at tells you both the severity and the fix.
Retention is the quiet failure mode. All the discipline in the world is worthless if the records for the audited period were not preserved for the contract or regulatory retention window, or if they were not stored in a way that keeps the timestamps and attribution intact. Part of the audit is simply confirming the records exist, cover the required span, and are complete, because a custody point that cannot produce its trail for a period is indefensible for that period no matter how careful the day-to-day operation was.
A cloud SCADA such as Merobix turns much of this procedure from a site expedition into a desk task and closes the most common gaps before an audit even begins. By centralising the quantity records, configuration snapshots, event and change logs, and calibration status from many flow computers, it lets an auditor retrieve a coherent trail for any period and any point from a browser, and it makes undocumented changes far harder because configuration edits and alarms are captured and attributed as they happen. The formal audit still has to be performed, but continuous centralised records mean the reconciliations reproduce, the event trail is intact, and the edits are already flagged, so the audit confirms integrity rather than discovering its absence.
Start from the reported quantity for a chosen period and work backward, reconciling it against the quantity record's inputs and the configuration that was in force during that same period. If the recorded inputs and configuration reproduce the reported quantity under the applicable method, the core measurement is sound for that period. From there you follow the event log, check edited values, and verify calibrations, so the reconciliation anchors the rest of the audit.
Because a defensible measurement has to show both what was actually measured and what was substituted, along with who changed it and why. API 21.1 practice is to flag an edited value and retain the original rather than silently overwriting it, so an auditor can see the correction and its justification. An unflagged or unexplained edit is a finding even if the corrected value is more accurate, because a quiet edit breaks the traceability the audit depends on.
The most common finding is a break in traceability, usually a total that shifted with no matching event in the log, a quantity that will not reproduce from its recorded configuration, or a value that changed without a flag. Each points to a specific cause such as an undocumented change on a live flow computer, a wrong or mismatched constant, or a silent edit. Retention gaps, where records for a period were not preserved intact, are another frequent and serious finding.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.