.png)
Oil and gas teams hear “MRV” in methane meetings, OGMP workshops, vendor demos, and assurance kickoffs. People nod. Then they discover they were not talking about the same work.
Some mean a methane framework. Some mean a third-party review. Some mean a software category. They are using the same letters for different jobs.
This guide is for environmental, air, GHG, and methane reporting teams at oil and gas operators. It defines MRV as the process those conversations are pointing at, then explains what software can support without becoming the thing itself. It is not an OGMP how-to, a Subpart W method guide, or a second emissions management software buyer’s guide.
What is MRV?
MRV stands for measurement, reporting, and verification. In oil and gas, it is the process for turning operational and emissions data into reported information that can be traced, reviewed, and verified. It connects operational inputs, approved methods, review, and evidence so a disclosed value can be reconstructed.
The useful picture is a chain, not three departments that meet once a year:
measurement → context → calculation → review → reporting → evidence → verification
A survey that never attaches to an asset is not yet measurement in this sense. A calculated total with no method version is not yet a result you can defend. A signature on a PDF the week before filing is not verification if nobody can show how the number was made.
This page is about that oil and gas emissions process. It is not a guide to the EU maritime MRV regulation (Regulation (EU) 2015/757), which requires monitoring, reporting, and verification of greenhouse gas emissions from ships. That regime uses the same letters for a different legal job.
Figure 1: MRV is a chain. Lineage is whether each step stays attached to the last one.
What is MRV software?
MRV software supports that process by connecting source data, calculation methods, controls, review, and evidence so reported outputs stay attached to how they were produced. MRV remains the process. Software is infrastructure for it.
If measurements sit in a historian that environmental cannot query, the system is not carrying the first step. If a reporting module exports a total without the method, the exceptions, or the approvals, it is generating an output. If a verification workspace opens after the report is already compiled, the team is reconstructing, not verifying.
After filing, the useful test is whether someone can follow a reported value back to the inputs without digging through email. If they cannot, the organization produced a report. It did not complete an MRV process.
What measurement, reporting, and verification mean in practice
Programs usually agree on what the letters stand for. They differ in the work under measurement, reporting, and verification.
What measurement means
Measurement, in this process, is any governed input that describes what happened at an asset. That can be a continuous monitor, an LDAR find, an aerial or satellite detection, a stack test, a production volume, a lab result, or an engineering estimate the program has accepted as an input. Direct observation and estimation both count. They are not the same quality of input, and they should not be labeled as if they were.
The operational failure is rarely “we do not measure everything.” It is that a measurement exists and never becomes usable: the asset ID does not match, the operating state is missing, the timestamp is wrong, or nobody owns the rule for whether the event should reopen a value the inventory already accepted. When field detection matters to filings, that intake sits beside LDAR software rather than in a side folder environmental discovers in March.
What reporting means
Reporting is the output other people see: an EPA package, a voluntary methane template, a board inventory, a buyer questionnaire. Those outputs can share underlying facts and still differ in boundary, method, and evidence. Forcing one number to serve every regime is how teams spend April reconciling what they already filed in March.
Emissions reporting software is the buyer-facing name for tools that produce those packages. That is one stage of MRV, not the whole process. An export that cannot be traced through review and calculation back to the inputs may meet a calendar deadline, but a reviewer still cannot test how the value was produced. EPA GHGRP and Subpart W are examples of mandatory outputs. They are not another name for MRV.
What verification means
Verification is whether a reported value can be tested. Depending on the program, that work may include internal QA/QC, peer or management review, formal verification, or third-party assurance. Those terms are not interchangeable. Where a framework defines them, that framework’s terminology controls. Across these forms of review, the practical test is whether someone can independently reconstruct how a reported value was produced.
A reviewer is not looking for a confident total. They need the method version, the inputs, the exceptions, and who approved any override. If that package lives in inboxes, the test gets deferred until the week before filing. That is an operating problem, not a missing auditor.
Where MRV workflows usually break
On a slide, MRV looks sequential. In an operating company, it breaks in the handoffs.
The monitor is in the field. Environmental does not know the data exists. Operations installs continuous monitoring after an aerial flyover flags a gap. The files land in a historian the control room can see. The inventory still uses last year’s factor because nobody told the reporting team the new stream was live, or the file names do not match the asset list in the workbook. Measurement happened. It never entered the process.
Operations keeps one asset list. Reporting keeps another. Maintenance knows the unit as K-120. The emissions inventory calls it COMP-120A. A leak tag, a work order, and a calculated emission land on three identities. The reconciliation happens in a meeting, not in the record. Context was never attached, so calculation and review start from a guess.
The calculation changes. The evidence stays behind. Engineering agrees to update a factor after a study. The new value is in the spreadsheet. The method note, the approval, and the prior-period comparison stay in last year’s folder. When a reviewer asks why the number moved, the people who changed it have a different assignment. Reporting still has a total. The support for that total has to be rebuilt.
By verification, teams reconstruct how the number was produced. The value is in the report. The trail is three inboxes, a contractor workbook named final_v7, and a shared-drive folder that still uses the old facility name. This is the same pattern as other industrial compliance workflow bottlenecks: the record is assembled after the work, not while it happens.
The same handoff failure shows up as late production extracts, methods with no owner, and measurement events that never reopen an accepted value. MRV fails when measurement, reporting, and verification are treated as three jobs that meet once a year.
MRV vs an emissions inventory
An emissions inventory is an output: the emissions data an organization is prepared to stand behind for a defined period and boundary. MRV is the process and controls that make that output defensible, including when new measurements arrive, methods change, or reviewers ask how a value was produced.
The failure is treating the inventory as finished work and treating MRV as a label applied at filing. If a line in the inventory cannot show which measurement, which method version, and which review produced it, the gap started in the process, not in the final total.
MRV vs emissions management software
Emissions management software is broader than MRV. It can collect source data, calculate, validate, report, forecast, investigate, and coordinate response. MRV names the measurement-through-verification discipline inside and around that program.
A platform can support MRV without being sold as “MRV software.” A module labeled MRV that does not carry evidence and review is still just reporting. The two overlap, but they are not the same job. If you are buying program software, evaluate the EMS job. If you are trying to understand why a number cannot be explained, you are looking at MRV, whether or not the vendor used the letters.
How MRV relates to nearby programs
Nearby programs use measurement, reporting, and review language. They are not the definition of MRV.
OGMP 2.0
OGMP 2.0 is UNEP’s voluntary, measurement-based methane reporting framework for oil and gas. Its reporting levels move from generic emission-factor estimates toward source-level methods and reconciliation with site-level measurements. Those requirements depend on many of the same measurement, reporting, evidence, and review processes described here. OGMP is one program that relies on MRV. It is not the definition of MRV.
EPA GHGRP and Subpart W
EPA GHGRP is a mandatory U.S. greenhouse gas reporting program. Subpart W is the petroleum and natural gas source category under 40 CFR Part 98. Those rules specify calculation methods, quality assurance, recordkeeping, and how EPA reviews submitted reports. They are not a software category, and they are not “MRV” as a brand. They are one place the process has to hold.
EU shipping MRV
Search results for “what is MRV” often surface the EU maritime MRV regulation (Regulation (EU) 2015/757), which requires monitoring, reporting, and verification of greenhouse gas emissions from ships. That is a shipping legal regime. It is not this oil and gas emissions process.
The path that has to stay intact
By this point the chain should feel familiar, because every break above is a missing link:
measurement → context → calculation → review → reporting → evidence → verification
Lineage is not a separate workstream. It is whether each step still has the last one attached. Context tells you which asset and operating state a measurement belongs to. Calculation needs that context plus a method version. Review needs the exceptions, not only the total. Reporting needs a reviewed result, not a side workbook. Evidence is the package that makes verification possible: method version, input provenance, exceptions, and approvals.
If any link lives only in someone’s head, verification will spend its time rebuilding the chain instead of testing it.
Where automation and AI help, and where humans stay accountable
Automation fits the repetitive preparation: scheduled intake, known calculations, completeness checks, routing, and assembling the evidence pack. AI can help when the information is messy: proposing mappings, surfacing anomalies, summarizing a package, pointing to related records. That is assistance, not a decision.
It should not move accountability. Deciding which method applies, whether an exception is a real change or a data defect, and what the organization will submit remains a human responsibility. A recommendation that shortens the path to evidence is useful. A confident answer with no inspectable trail is not. For how that split works across environmental work, see AI for environmental compliance workflows.
Ask where the system prepares work, what evidence it preserves, and where a named person remains responsible for review and approval.
What operators should look for
If you are evaluating tools that claim to support MRV, keep the test operational. This is not a second buyer’s scorecard. For buying depth, use the emissions management software and emissions reporting software guides.
- New measurements can trigger review of previously accepted values, with the reason and any resulting change preserved on the record.
- Method versions travel with the number, not in a parallel folder.
- Field, operations, and reporting can resolve to the same asset identity.
- Exceptions, comments, and approvals sit on the record, not in email.
- Last year’s result can be reproduced after this year’s methods changed.
- Human review is a required step, not a screenshot of a dashboard.
If a demo cannot show those motions on your messy data, the tool will not help much when a reviewer asks how a number was made.
Frequently asked questions
What does MRV mean?
MRV stands for measurement, reporting, and verification. In oil and gas, it is the process for turning operational and emissions data into reported information that can be traced, reviewed, and verified. It connects operational inputs, approved methods, review, and evidence so a disclosed value can be reconstructed.
What is MRV software?
MRV software supports that process by connecting source data, calculation methods, controls, review, and evidence to the reported output. It does not replace the process, and it is not a separate software category from the emissions work operators already run.
Is MRV the same as emissions management software?
No. Emissions management software is broader and may cover collection, calculation, reporting, forecasting, investigation, and response. MRV is the measurement-through-verification discipline inside and around that program. A platform can support MRV without being sold under that name.
How does MRV relate to OGMP 2.0?
OGMP 2.0 is UNEP’s voluntary, measurement-based methane reporting framework for oil and gas. Its reporting levels depend on many of the same measurement, reporting, evidence, and review processes described in this guide. OGMP relies on MRV. It is not the definition of MRV.
How does MRV relate to EPA GHGRP and Subpart W?
GHGRP is a mandatory U.S. greenhouse gas reporting program. Subpart W is the petroleum and natural gas source category under 40 CFR Part 98. Those rules specify what to calculate, keep, and submit. MRV is how teams keep the path from source data to that submission defensible. Neither rule is “MRV software.”
Does verification always mean a third-party audit?
No. Depending on the program, verification can include internal QA/QC and review as well as formal third-party verification or assurance. Those terms are not interchangeable. Across these forms of review, the practical test is whether someone can independently reconstruct how a reported value was produced.
Can AI replace MRV workflows?
No. Automation and AI can prepare intake, flag anomalies, and assemble evidence. They should not become the party accountable for the reported result. Method choices, exception judgment, and submission still need a named person.
What should oil and gas operators look for in tools that support MRV?
Look for new measurements that can trigger review of previously accepted values, method versions that travel with the number, a shared asset identity, evidence on the record, and required human review.
How Validere fits this work
Validere connects operational data, emissions calculations, review, and supporting evidence so teams can trace reported values back to the work that produced them. It can work alongside existing operational and environmental systems, and replace manual handoffs and scattered workbooks where needed.
See how Validere supports emissions management across measurement and response, regulatory reporting, voluntary reporting, and assurance and verification.
