Liquid custody transfer has its own accounting problems that gas does not: liquids move in ticketed batches, a meter's accuracy is captured in a meter factor that changes over time, and volumes must be corrected to standard conditions before they mean anything. API Chapter 21.2 is the standard that governs how electronic liquid measurement systems handle all of that and prove it afterward. This page covers what a liquid flow computer and a LACT unit must record under 21.2, how meter factors and correction factors enter the volume, and how a SCADA system collects that audit trail remotely.
API 21.2 Electronic Liquid Measurement in one line: API 21.2 is the industry standard for electronic liquid measurement, the liquid counterpart to API 21.1 for gas. It governs how liquid flow computers and LACT units record ticketed batches, apply meter factors and correction factors to bring measured volume to standard conditions, and maintain the configuration, event, and quantity logs that make a liquid custody-transfer volume auditable and defensible.
Liquid measurement carries accounting concepts that gas measurement does not, and API 21.2 exists to standardize them electronically. Liquids are frequently measured and transferred in batches rather than as continuous flow, with each batch corresponding to a ticket that records the volume moved during a defined delivery. A liquid flow computer therefore has to open, accumulate, and close batch records, capturing the totals and conditions for each ticketed transfer, which is a different bookkeeping shape from the rolling hourly totals typical of gas.
The meter factor is another liquid-specific idea. A liquid flow meter's accuracy is established by proving it against a reference, and the resulting meter factor is a multiplier applied to the meter's raw readings to correct for its actual performance. Because a meter's behavior drifts, the meter factor is updated periodically through re-proving, and the standard expects a record of which meter factor was in effect for any measured volume. A wrong or out-of-date meter factor directly biases the booked quantity, so tracking it is central to liquid measurement integrity.
Correction factors add the final layer. Measured liquid volume depends on temperature and pressure, so it is corrected to standard conditions using established correction factors before it can be compared or sold, since a barrel measured hot is not the same as a barrel at reference temperature. API 21.2 governs how the flow computer applies these corrections and records the inputs and factors used, so the path from raw indicated volume to net standard-condition volume is transparent and reconstructable for every batch.
Much automated liquid custody transfer happens at a LACT unit, a lease automatic custody transfer skid that measures crude or other liquids as they leave a lease, often unattended. The LACT unit's flow computer is exactly the kind of electronic liquid measurement device API 21.2 addresses: it meters the liquid, applies the meter factor and correction factors, and produces the batch or ticket records that document each transfer. Because LACT units frequently run without an operator present, the electronic record they keep is often the only evidence of what was delivered.
The records a compliant liquid measurement point maintains parallel the gas world but reflect liquid's needs. There is a configuration log capturing the parameters, constants, and meter factor the device uses, and an event log timestamping every change and significant event, including meter factor updates and parameter edits, so any alteration is traceable. The quantity records document the measured volumes, structured around the batches and tickets that liquid transfer is organized by, along with the average conditions that fed the correction.
What an auditor looks for in a liquid measurement audit trail is the ability to reconstruct each batch from raw indication to net volume: the indicated volume, the meter factor applied, the temperature and pressure inputs, the correction factors, and the resulting net standard-condition quantity, together with any events that touched the configuration during the period. API 21.2 defines these records so that trail exists, letting a delivered volume be verified and defended the same way API 21.1 does for gas, but around batches and meter factors instead of hourly gas totals.
As with gas, the records only stay useful if they are pulled off the flow computer and preserved, and remote liquid sites make this pressing because LACT units are often unattended and far from anyone. A SCADA system polls each liquid flow computer to retrieve its configuration log, event log, and batch and quantity records, then stores them centrally. A cloud platform such as Merobix can gather these from many LACT units and meters across a lease or a gathering system, so the batch history, meter factors in effect, and events for every transfer point are retained in one place rather than sitting only in field memory.
Central collection changes how a measurement team works. Instead of visiting each skid to read tickets, an analyst can review batches, watch for a meter factor that is overdue for re-proving, and catch a bad correction input or a missed poll from the office. Because liquid volumes hinge on the meter factor and the correction inputs, surfacing those alongside the batch totals lets errors be spotted before they propagate into settlement, which is harder to do when the evidence lives only on a remote device that eventually overwrites its logs.
For custody transfer the outcome mirrors the gas case: defensibility on demand. When a batch volume is questioned, the operator can produce the configuration and meter factor in effect, the correction inputs, the event history, and the resulting net volume for that ticket, all consistent with what API 21.2 requires. A cloud SCADA system that reliably polls and retains these liquid records makes the standard a routine result of normal monitoring, so the full batch-by-batch audit trail is ready whenever a counterparty or auditor asks for it.
API 21.1 governs electronic gas measurement and centers on rolling hourly and daily volumes, while API 21.2 governs electronic liquid measurement and centers on ticketed batches, meter factors, and correction to standard conditions. Both require configuration, event, and quantity records for a defensible audit trail, but 21.2 reflects liquid-specific concepts such as batch records, the meter factor from proving, and temperature and pressure correction that gas measurement handles differently.
A meter factor is a multiplier applied to a liquid meter's raw readings to correct for its actual proved performance, and it is updated periodically by re-proving because meter behavior drifts. API 21.2 expects a record of which meter factor was in effect for any measured volume because a wrong or out-of-date factor directly biases the booked quantity. Tracking it in the configuration and event logs keeps the volume defensible.
It contains the records needed to reconstruct each batch from raw indication to net volume: the configuration and meter factor used, the temperature and pressure inputs, the correction factors applied, the indicated and net quantities per batch or ticket, and an event log of any changes during the period. A SCADA system collects these from the flow computer or LACT unit and retains them centrally so the trail survives beyond the device's own memory.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.