Electronic Flow Measurement Software: Why Your Meter Validation Backlog Never Clears Before Close

Why gas measurement software decides what you actually get paid

It is the third business day of the month at a gas gatherer. One measurement tech has 480 meters to close. Overnight polling pulled most of them, but 31 came back with gaps, six flow computers rolled their records when a field tech swapped a battery, and one pad has reported the same differential pressure for nine days because the transmitter port is plugged. Accounting wants final volumes by Friday because statements go out and the revenue run follows. The tech opens Excel, because Excel is where estimates get made and Excel is where they stay.

The stack around that desk is usually Flow-Cal or Quorum PGAS holding validation and gas accounting, a hosting and SCADA layer such as eLynx Technologies pulling from the field, a shared drive of chromatograph results and third-party meter proving reports as PDFs, and a set of spreadsheets carrying everything the packages could not represent. Each piece is competent inside its own boundary. What nothing owns is the object your business actually runs on: a meter-day that knows its raw record, its edit history and who made each edit, the gas composition applied to it, the calculation standard and operator options used to recompute it, the contract it allocates to, and the invoice line and royalty decimal it eventually becomes.

The cost of that gap is not abstract. In measurement projects we have delivered, the pattern repeats: a tech spends most of a week each month chasing gaps and typing estimates, a meaningful share of meter-days close as estimated and never get trued up, and prior period adjustments land on revenue two or three months later when someone finally corrects a composition or a plate size. Measurement error does not stay in measurement. It becomes a volume, then a payment, then a royalty check, then a letter from a counterparty's auditor asking you to prove a number you can no longer reconstruct.

Problem 1: ten brands of flow computer, ten definitions of a record

A field with any history has ABB Totalflow devices, Emerson ROC and FloBoss units, Thermo Fisher AutoPILOT, maybe some Bristol ControlWave, and whatever the last acquisition brought in. Each stores hourly and daily records with its own field names, its own event and alarm logs, its own idea of what happens when the clock is set backward, and its own behaviour when a configuration change is written mid-day. Polling is the easy part. Interpreting is the problem.

Flow-Cal handles a wide range of device formats and does it better than anything you would write from scratch, so do not rebuild that. The gap shows up around it. When a device reports a partial day because a tech was on site, does the record represent 14 hours of real flow or 24 hours of a bad clock? When an event log shows an orifice plate size change at 10:42, which hours need recomputation and which do not? Those answers depend on your field practice, your contractors, and your device firmware versions, and no packaged tool ships with your answers.

What a custom build does: normalise every device into one meter-day record with the raw values preserved untouched, then attach a device profile per make and firmware that encodes the known quirks. Configuration events become first-class objects rather than a log you read by hand, so a plate change automatically flags the affected hours and proposes the recomputation window. The result is that the tech stops asking what happened and starts approving what the system already worked out.

Problem 2: validation rules live in one tech's judgement

Ask a good measurement tech why they estimated a particular meter-day and you will get a real answer: the static pressure tracked fine, the DP looked frozen against a well that should have been flowing, the chart from the neighbouring meter on the same pad showed the expected decline, so they backfilled from the seven-day average. That reasoning is correct and it is completely undocumented. When that tech leaves, the operation loses its validation logic and inherits a backlog.

The packaged tools give you limit checks: high, low, rate of change, missing. Those catch the obvious and miss the interesting. They do not compare a meter against its own pad, against upstream compressor run status, against the last calibration, or against the well's expected decline curve. So the exception list is long, mostly noise, and the tech works it by eye.

What a custom build does: express validation as rules you can read, version, and argue with. A rule has a condition, a severity, a suggested correction, and an owner. Frozen DP against non-zero static with a running upstream compressor is a different rule from a genuine shut-in, and the system can tell them apart because it has the compressor status. Estimation methods get named and stored on the record, so the statement says this meter-day was estimated by seven-day rolling average and here is why, rather than leaving a number with no parentage. Machine learning is worth exactly one job here and only after a year of clean history: flagging meters whose behaviour has drifted from their own established pattern, which is how plugged taps and drifting transmitters get caught before month end instead of after.

Problem 3: recalculation is a standards question with your fingerprints on it

Volume is not measured, it is computed. AGA Report No. 3 for orifice, AGA 7 for turbine, AGA 8 for compressibility, with API MPMS Chapter 21.1 governing how electronic gas measurement data is handled. Inside those standards sit operator choices: which compressibility method, how heating value is applied between chromatograph samples, how you treat a spot sample taken on the 14th when the composition clearly changed on the 3rd, what you do with a meter whose calibration report shows it was reading two percent high for the whole month.

Quorum PGAS and Flow-Cal both recalculate competently against the standards. What they do not do well is carry your specific policy consistently across every contract and every counterparty, or show a counterparty's auditor exactly which composition record and which calibration certificate produced the number in front of them. That linkage tends to live in a spreadsheet tab called BACKUP.

What a custom build does: make composition a dated series with a source, chromatograph or lab or spot sample, and apply it by an effective-date rule you define once. Meter proving and calibration reports become structured records rather than PDFs, so a two percent bias found on the 20th automatically produces a proposed correction for the affected period with the certificate attached. Every recomputed value stores the standard, the method options, the inputs, and the version of the calculation code that produced it. Two years later, that number can be reproduced exactly. That is the entire point.

Problem 4: the edit trail has to survive a hostile audit

API MPMS Chapter 21.1 expects original unedited data to be retained and edits to be traceable, and every gas purchase contract you have signed gives your counterparty the right to audit. The audit is not friendly. It is a person from the other side of the transaction looking for volumes that moved in your favour without documented cause.

The failure mode is not fraud, it is untidiness. Someone corrected an estimate in a spreadsheet and re-imported it. Someone changed a composition retroactively and the old value is gone. Someone recomputed a month after a plate change and the reason field says corrected. None of that is defensible, and the cost of losing a measurement dispute is the volume plus the relationship plus a permanent reputation for sloppy numbers.

What a custom build does: an append-only event store where nothing is ever overwritten. A meter-day is the result of applying an ordered list of events to a raw record. Every event carries who, when, why, which document supports it, and what the value was before. Reproducing what the system believed on any past date takes one query. When the auditor arrives, you export the full lineage for the contested period in an afternoon instead of assembling a defence for two weeks. Operators who have built this describe the audit going from an event to a formality.

Problem 5: measurement ends, and then nothing hands off cleanly

Validated volumes have to become allocated volumes across wells and interests, then feed nominations, imbalance tracking, revenue distribution, and severance reporting. In most operations that handoff is a monthly file, an email, and a person who checks it against last month by eye. When a prior period adjustment lands, it has to ripple through every one of those downstream steps, and usually it does not.

What a custom build does: publish volumes as a versioned dataset with an explicit revision number, and make every downstream consumer subscribe to it. A revision to July measurement automatically raises the affected allocation, the affected revenue detail, and the affected state report as tasks with the delta attached. Nobody discovers a restated volume by noticing a strange variance in a quarterly review.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape. A focused first release covering multi-vendor polling and normalisation, rule-driven validation with an append-only edit trail, and a volume statement your accounting close can rely on runs $70,000 to $150,000 and ships in 12 to 18 weeks. A full measurement platform adding standards-based recalculation with your method options, composition and calibration record management, allocation, counterparty statement delivery, and downstream revision propagation runs $180,000 to $450,000 phased over 6 to 12 months.

What pushes cost up in measurement specifically: the number of distinct flow computer makes and firmware generations, because each one is a real integration and not a config toggle. Legacy polling over serial radio or cellular links with poor reliability, which means retry and gap-fill logic that has to be genuinely robust. Liquids measurement alongside gas, which brings a separate standards family. Any requirement to keep Flow-Cal or PGAS in the picture rather than replace it, since integrating with a system you do not control costs more than owning both sides. And the largest one, which is not engineering: how much of your validation policy exists only in a tech's head, because writing it down is discovery work and it takes weeks.

What keeps cost down: starting with one flow computer brand covering your highest-volume meters, and one contract type. That is where the money is and where the rules are clearest.

Build versus buy, and when buying is right

Buy if you run under roughly 100 meters, mostly one device brand, on simple contracts. Flow-Cal plus a competent accountant will handle it, and a custom build would be an expensive way to feel modern. Buy also if your measurement is nearly all custody transfer at a handful of large points with third-party witnessing, because the volume of judgement calls is low and the packaged tools cover it.

Build when your meter count is past a few hundred, your device population is mixed by acquisition, and your close depends on one person's Excel workbook. Build when a counterparty has disputed a volume and your defence was a story rather than a record. Build when prior period adjustments are a normal monthly event rather than an exception, since that is the visible symptom of validation policy living outside the system. Build when you have measurement obligations under multiple contract structures that the packaged allocation model cannot express without workaround spreadsheets.

Our position, stated plainly: at scale, measurement is not a data-entry function, it is your revenue recognition process wearing a hard hat. Anything that computes what you get paid should be reproducible, versioned, and defensible, and the tools built to serve a generic gatherer will always leave the last twenty percent of that to a human with a spreadsheet.

How to choose a developer for gas measurement software

Ask them to describe a meter-day record before they show you a screen. If they draw a table of volumes, they are building a reporting tool. If they draw a raw record plus an ordered event list plus a computed result with method metadata, they understand what an auditor is going to ask for.

Ask which flow computers they have actually pulled data from and what broke. Anyone who has done this will immediately talk about clock drift, record rollover, partial days, and the specific pain of one vendor's event log format. Vague answers about supporting all devices mean they have supported none.

Ask how they will handle a retroactive composition change that affects three closed months. The right answer involves revisions and propagation, not a script and a database update.

Ask who owns the code and the infrastructure, and get it written down before kickoff. You should own the repository, the cloud accounts, and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit, and we would tell you to walk from any firm that hedges on that.

Start by exporting one full month of raw records from your three most troublesome meters and walking a developer through how you closed them. If they cannot tell you what your validation policy is by the end of that session, keep looking.