Stop Ticket and Cost Chaos: Well Master Data for Small Operators

Featured image for Stop Ticket and Cost Chaos: Well Master Data for Small Operators

A canonical well master record is the single, authoritative set of facts about a well, its identifiers, ownership, and status, that every field ticket, every cost entry, and every lease operating statement should pull from instead of guessing. Get it right and a pumper’s ticket, your bookkeeper’s cost code, and your investor’s check all trace back to the same API number and the same ownership split. Get it wrong and you’re reconciling three versions of the same well every month. Some operations software builds toward exactly this outcome for Permian independents.

TL;DR:

  • Strictly standardize well identifiers, especially API numbers, to prevent duplicate records and ensure consistent referencing across all systems.
  • Assign clear ownership of each data domain—such as identifiers, location, ownership, and status—to designated teams, and implement response windows for conflict resolution.
  • Build your well master record incrementally, starting with high-impact wells, and leverage automation cautiously for data enrichment while maintaining validation and source tracing.
  • Accurate, complete, and source-backed well data is essential to meet regulatory requirements and avoid audit discrepancies, especially when ownership or status changes occur.
  • Focus on core fields like API number, well name, lease, ownership splits, cost centers, and status to prevent costly reconciliation errors and partner disputes.

Table of Contents

What Is Well Master Data and Why Does It Matter?

Well master data is the fixed, reference-level information about a well that doesn’t change month to month, as opposed to production volumes or daily costs, which do. Think of it as the well’s permanent file. Every other system, your field tickets, your cost book, your LOS, should point back to this one file rather than storing its own copy of the well name or the ownership split.

The fields fall into four groups, and missing any one of them is where operators get burned:

  • Identifiers: API number (10 digit or 14 digit, formatted consistently, no dashes dropped or added inconsistently across systems), well name, and any legacy or cross-system IDs from a prior operator or acquired package.
  • Location and header: Lease name, pad or field, county and state, and surface/bottomhole coordinates. Header and location data anchor the rest of the record, and inconsistent header data is where downstream reconciliation work usually starts, according to Peloton’s guide to well data management.
  • Ownership and accounting: Working interest splits, operator of record, default cost center or GL mapping, and the AFE or expense code the well ties to.
  • Status and lifecycle: Current status (drilling, producing, shut in, plugged), spud date, completion date, and producing formation.

Skip the API formatting rule and you’ll eventually have two “wells” in your system that are really one well, split across a truncated 10 digit number and a full 14 digit number. Skip the default GL mapping and every field hand who writes a ticket has to guess which cost center it belongs to, which means somebody in accounting is guessing too.

How Field Tickets, Cost Books, and LOS Depend on the Master Record

A field ticket that doesn’t carry the right well identifier, cost center, and AFE code isn’t a minor paperwork gap. It’s a coding error waiting to surface at the worst possible time, usually during a partner audit. Here’s the chain of dependency, in order:

  1. The field ticket captures the transaction. A ticket useful to accounting needs a handful of non-negotiable fields: well identifier, cost center, AFE or expense code, vendor, unit of measure, date, and approver, the same short list W Energy’s field ticket reconciliation framework recommends for a clean three-way match against contract and invoice.
  2. The cost book allocates the spend. If the ticket’s cost center matches the master record’s default mapping, the expense lands on the right well automatically. If it doesn’t, someone manually reallocates it later, and manual reallocation is where per-well P&L quietly goes wrong.
  3. The LOS pays the partners. Ownership splits and allocation fields in the master record determine how costs and revenue get divided. When that data is authoritative, investor checks go out on schedule.

Coding errors on field tickets are a common trigger for disputes with working interest partners once an audit starts pulling apart a lease operating statement. A well coded to the wrong AFE for six months doesn’t just misstate one month’s cost book. It misstates six, and the partner who’s been shorted notices before you do.

Who Owns the Record, and How Do You Control Changes?

Technology is rarely the reason master records fall apart. Practitioners who work this problem daily point to something more basic: nobody decided, in writing, who gets to say what’s correct. That’s the real fix, and it costs nothing to implement.

Three moves cover most of it:

  • Name one owner per data domain. Ownership fields belong to accounting or land, header and location fields belong to field ops, and status/lifecycle fields belong to whoever tracks regulatory filings. Give each domain owner a response window, 48 hours is reasonable, for resolving a flagged conflict.
  • Run an exception queue, not an inbox. New wells and updates to existing records should hit a queue with a simple rule: new API number and no existing match creates a new record; anything else routes to the domain owner for approval before it overwrites anything.
  • Log every change with its source. Record what changed, who approved it, and what document (a division order, a completion report, a title update) justified it. That log is your chain of custody if a partner or an auditor ever asks why a split changed in March.

Fixing well identifier chaos, duplicate API formats, conflicting historical records, comes down to naming owners and writing rules, not buying a bigger system, according to InFocus Data’s breakdown of upstream data quality problems. If you want a structural baseline for how fields relate to each other, PPDM’s data model is worth aligning to loosely, even if you never adopt it wholesale.

Pro Tip: Don’t let the exception queue become a dumping ground. If it’s not resolved within your SLA window, escalate it to whoever signs the LOS, not because they’re the expert, but because they’re the one who feels the cost of a wrong number first.

How to Build a Well Master Record from Scratch

You almost certainly already have the raw material for a well master record scattered across spreadsheets, old field tickets, and a prior operator’s files. The work is consolidation, not creation. Here’s the order that actually holds up:

  1. Inventory every source. List every spreadsheet, accounting export, and paper file that mentions a well identifier, ownership split, or status. Build a simple mapping table showing which source is authoritative for which field.
  2. Normalize identifiers first. Standardize every API number to one format (10 digit or 14 digit, pick one and stick to it) before you try to match anything else. This single step resolves most duplicate-well problems.
  3. Define match and dedup rules. Decide how you’ll catch the same well listed twice, usually a combination of normalized API number plus a fuzzy match on well name and lease.
  4. Build validation rules and route exceptions. Required fields, format checks, and a routing rule that sends anything ambiguous to the named domain owner instead of letting it sit unresolved.
  5. Pilot on a small, real business need. Don’t try to master every well you’ve ever touched. Start with the wells feeding next month’s LOS or the wells under active partner audit. Operators who anchor the pilot to a concrete deadline, as Velocity Insight’s account of wellmaster projects notes, get further than those attempting to master everything at once.
  6. Scale once the pilot holds. Expand well by well or lease by lease, keeping the source identifier and exception history attached to every record you migrate.

Automation has a real role here. One documented enrichment workflow processed over 150,000 documents using OCR and machine learning and extracted roughly 50,000 master well attributes, adding around 4,500 attributes that had been missing entirely. That’s a meaningful jump in completeness, but the same source is clear that automation without validation and lineage just moves errors faster. Use it to speed extraction, not to skip the owner sign-off step.

What Regulators Expect You to Keep on File

What Regulators Expect You to Keep on File — overview diagram

Federal rules aren’t vague on this point. Operators must keep accurate and complete records covering lease operations and production facilities, and those records have to be retained for the periods the rule specifies, under 43 CFR §3162.4-1. That regulation doesn’t care whether your records live in a filing cabinet or a database. It cares that they’re accurate, complete, and available.

A well master record built the way this article describes maps directly onto that expectation. Your identifiers, status history, and ownership documentation are the backbone of the records a regulator or auditor will ask to see.

The gap between a well record that passes an audit and one that doesn’t usually isn’t missing data. It’s data that contradicts itself across two systems because nobody defined which one was authoritative.

Retention and transfer practices matter too, especially when a well changes hands. A master record with intact source documentation and change history transfers cleanly to a new operator or survives a partner’s audit without a scramble.

Operator Perspective: Start Small, Automate Later

Operator Perspective: Start Small, Automate Later — overview diagram

Most operators overbuild this. They try to master every well, every field, every historical record before touching a single LOS. Don’t. Start with the fields that unblock month end, ownership splits, cost center mapping, and the API number, because those are the three things breaking your ticket reconciliation and your investor checks right now.

Automate validation once your rules are stable, not before. An exception queue with a named owner beats a fully automated pipeline with no human checkpoint, every time a document disagrees with the database. And keep your pilot tied to something you can measure: fewer reconciliation hours, faster LOS close, fewer partner disputes. A pilot with no metric just becomes a permanent side project nobody finishes.

— Pedro

How WellsManager Handles the Well Master in Practice

WellsManager sticks to three jobs: logging field work tickets a against the right well instead of a notebook or a group text, keeping a per-well cost book record that shows what each well actually spent, and running investor checks with a lease operating statement that don’t require a month end scramble. Each of those jobs only works if the well identifier, cost center, and ownership split behind it are right, so the platform requires those core master fields before a ticket or a distribution can post against a well. It doesn’t try to be an ERP or a JIB accounting suite, and it won’t pretend to solve problems outside those three jobs. If your tickets, cost book, and LOS are still running on separate spreadsheets that don’t agree with each other, see how WellsManager handles it and get a demo.

Sources

FAQ

What Fields Are Absolutely Required in a Well Master Record?

At minimum: normalized API number, well name, lease name, ownership/working interest splits, default cost center or GL mapping, current status, and producing formation.

Who Should Own the Well Master Record at a Small Operator?

Split ownership by domain: accounting owns ownership and cost fields, field operations owns header and status fields, with one named person resolving conflicts within a set turnaround.

How Does a Bad Well Master Record Cause LOS Disputes?

Wrong ownership splits or misallocated cost centers show up as miscoded expenses, and those miscoded costs are a common trigger for partner disputes once a lease operating statement gets audited.

Does PPDM Alignment Require a Full System Overhaul?

No. You can borrow PPDM’s structure for identifiers and relationships incrementally, starting with wells and production, without adopting the full model at once.

Can WellsManager Manage My Well Master Data Directly?

WellsManager requires and enforces the core master fields, well identifier, cost center, and ownership split, that field tickets, the cost book, and LOS distributions run on, without functioning as a full master data management system.

Recommended