Operators who produce oil and gas from federal or Indian leases owe the Office of Natural Resources Revenue a monthly accounting of what each lease produced and where every barrel and Mcf went. The Oil and Gas Operations Report, filed on ONRR Form 2014 and known universally as the OGOR, is that accounting. It is not a royalty payment; it is the production and disposition record that sits underneath the royalty, telling the government how much was produced, how it was disposed of, and how the wells contributed. Because royalties are calculated on sold volumes, the OGOR has to reconcile with the sales an operator reports and pays on, and any gap between them invites an audit. This page explains what the OGOR reports, how its parts map to metered volumes and run tickets, and why clean field data is the best defense against a royalty audit.
ONRR Form 2014 (OGOR) in one line: ONRR Form 2014, the Oil and Gas Operations Report or OGOR, is the monthly report federal and Indian lease operators file with the Office of Natural Resources Revenue documenting the production and disposition of oil, gas, and associated products from each lease. It is organized in parts covering production, disposition, and well-level detail, and its volumes must reconcile with the sales reported for royalty purposes. Mismatches between the OGOR and sales reporting are a common trigger for royalty audits, so accurate metered volumes and run tickets are what keep the filing clean.
The OGOR is structured in parts that separate the different questions the government is asking. The production part, often called OGOR-A, reports how much of each product a lease produced in the month, the raw volumes coming out of the ground before they are sold, used, or lost. The disposition part, OGOR-B, accounts for where those produced volumes went, breaking them into categories such as sold, flared, vented, used as lease fuel, or held in inventory, so that every produced barrel and Mcf is accounted for rather than simply reported as produced.
The well part, OGOR-C, ties production back to individual wells and their status, reporting well-level information including days on production and the disposition of each well's output where required. This part exists because the government needs to attribute production to specific wells for lease management and verification, not just to know the lease total. Together the three parts give a complete picture: how much came out, where it went, and which wells it came from.
The reason the parts have to be understood together is that they must be internally consistent. The production reported in the production part has to be fully accounted for in the disposition part, with opening inventory, production, dispositions, and closing inventory balancing over the month. If the produced volume does not equal the sum of everything that was sold, used, lost, and left in inventory, the report does not balance, and an unbalanced OGOR is both a rejected filing and a red flag. The structure is deliberately a closed accounting where the pieces have to sum.
Every number on the OGOR should trace to a physical measurement in the field. Oil sold typically maps to LACT meter totals or to run tickets written when a truck hauls a load from a tank, each ticket recording the gauged volume moved. Gas volumes map to sales meters and allocation metering that apportions a lease's share of commingled production. Lease fuel maps to the gas actually consumed on the lease to run equipment, ideally metered. Flared and vented volumes map to flare meters and vent estimates. The OGOR, in other words, is a monthly rollup of measurements that the field already generates.
This mapping is where reporting quality is won or lost. When the field measurements are complete and accurate, the OGOR is an aggregation: sum the run tickets and LACT totals for sales, read the fuel meter for lease use, read the flare meter for flaring, and the disposition side balances against the metered production. When measurements are missing or unreliable, the operator has to plug the gaps with estimates, and the report becomes a construction whose balance depends on assumptions rather than on measured reality.
Run tickets deserve particular attention because they are the primary record for trucked oil, and they are also the document a royalty auditor is most likely to compare against the OGOR and the sales report. A run ticket records the tank gauged before and after a haul, the temperature and gravity, and the volume moved, and the sum of run tickets for a lease should reconcile to the oil shown as sold on the OGOR and to the volume the purchaser reports buying. When those three records agree, the disposition is defensible; when they diverge, the operator has a reconciliation problem before an auditor ever arrives.
Royalty is paid on sold volumes, and the government cross-checks the sales an operator reports and pays on against the disposition the operator reports on the OGOR and against what purchasers independently report buying. When these agree, there is nothing to question. When the OGOR shows more sold than the operator paid royalty on, or when the disposition does not balance against production, or when purchaser data does not match the operator's sold volumes, the discrepancy is exactly the kind of signal that opens a royalty audit. Most audits do not begin with suspicion of wrongdoing; they begin with numbers that do not tie out.
The way to avoid that is to make the OGOR, the sales reporting, and the underlying measurements all draw on the same clean field data, so they cannot diverge. If the sold oil on the OGOR comes from the same run tickets and LACT totals used to invoice the purchaser and to pay royalty, the three records agree by construction. If the disposition side balances against metered production because the fuel, flare, and inventory figures are all measured, there is no unexplained gap. The reconciliation that an auditor would otherwise perform has already been done, continuously, by the operator.
A monitoring and measurement platform is what makes that continuous reconciliation practical across many leases. Where a cloud SCADA platform such as Merobix captures LACT totals, tank levels, fuel and flare meter readings, and run-ticket data in one place, the monthly OGOR can be built from measured records that already balance, and the same figures feed sales reporting so the two cannot contradict each other. Beyond easing the filing, this leaves an operator able to answer an auditor's request with traceable measurement rather than reconstructed estimates, which is the difference between an audit that closes quickly and one that turns into a lengthy dispute over volumes.
The OGOR is organized into a production part reporting how much each lease produced, a disposition part accounting for where that production went as sold, flared, vented, used as lease fuel, or held in inventory, and a well part tying production to individual wells and their status. The parts must be internally consistent, with production fully accounted for in disposition and the monthly inventory balancing. Together they show how much was produced, where it went, and which wells it came from.
Royalty is paid on sold volumes, and the OGOR reports the disposition of production including how much was sold, so the two must reconcile. The government compares the operator's sales reporting and royalty payments against the OGOR disposition and against what purchasers report buying. When these records disagree, the discrepancy is a common trigger for a royalty audit, which is why the sold volumes on the OGOR should trace to the same measurements used to invoice and pay.
OGOR volumes should trace to physical measurements: LACT meter totals and run tickets for oil sold, sales and allocation meters for gas, fuel meters for lease use, and flare meters for flaring. Run tickets are especially important for trucked oil because auditors compare them against the OGOR and purchaser statements. When these measurements are complete and reconcile, the OGOR is a defensible aggregation rather than an estimate-driven construction.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.