Oil and Gas Land Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does lease abstraction blow up the schedule every time?

The project is scoped as software. The thing that decides its timeline is reading. Somebody has to open three thousand recorded instruments and capture, in structured form, the shut in royalty amount and window, the continuous development interval, the presence and type of any Pugh clause, the depth limitation language and the option terms. That work is not a data load, it is abstraction, and it is where land projects overrun.

It is specific to this industry because the source of truth is a scanned legal document in a county clerk's office, and because clause language differs between two leases in the same section signed a month apart by different brokers. There is no canonical feed to import. Enverus is genuinely good for sourcing courthouse documents and will help you find the instruments, but it does not tell you what your obligations are under them.

Price abstraction as its own workstream with its own staffing and its own timeline, separate from the software line. Then sequence it by exposure rather than alphabetically: leases in your active development areas, leases with continuous development obligations, leases approaching a primary term expiry. Extraction from scanned documents can produce draft clause records for a landman to confirm or correct, which turns a reading marathon into a reviewable queue, but a human still verifies every one because the output has legal consequences. Anyone selling extraction as a way to skip that verification is describing a liability.

What goes wrong when you migrate the land spreadsheet into a real lease model?

The spreadsheet stores a lease as a row: lessor, start date, end date, acreage, status. The model stores it as a legal instrument. Moving between the two surfaces problems that were always there and were simply not representable.

• One row, many tracts. A lease covering four tracts with different gross and net acres has been carried as a single acreage number for years. Splitting it correctly requires going back to the instrument, and the total will often not match what the spreadsheet claimed.
• Status as a legal conclusion. Held by production, expired and released are conclusions somebody reached, not facts that were recorded. Migrating a status column without the reasoning imports opinions as data. Keep an immutable history of status changes with the event that caused each one, because these will be questioned later.
• Burden stacks flattened. Lessor royalty, overriding royalties carved out in later assignments, and interests several assignments deep get compressed into one net revenue interest figure. Once flattened, the arithmetic cannot be re derived or audited.
• Depth limits absent entirely. A two dimensional acreage number cannot express that you hold one formation on a tract and not another. There is no field to migrate from, so the information has to come from abstraction.
• Documents disconnected from data. Scans organised by whoever did the scanning, with no county, book and page or instrument number attached. Without that link, landmen will not trust the record and will keep a parallel spreadsheet, which is where you started.

Why do the drilling schedule and accounting links break after go live?

The integration that matters most in this category is also the one most often deferred, and deferring it is what makes the system a calendar rather than a control.

Obligations are dated. The drilling schedule is dated. They are managed by different people in different systems and, in most companies, they only meet after something has gone wrong. The build should run the schedule against the obligations continuously and answer one question: if the rig slips, what breaks. Move a pad three weeks and the system should say that two leases fall out of continuous development, one option deadline passes unexercised, and a shut in royalty comes due on a well that will not be back on production in time. That gives the land manager the number they never have in the scheduling meeting.

What breaks it after launch is drift. The schedule moves in a planning tool that nobody connected, so the obligation engine is checking against a version from last quarter. Well identifiers differ between the land system, the drilling schedule and the accounting system, so operations do not attach to the right lease. And when an operation is spudded on a unit rather than a lease, the continuous development clock needs to know which leases that unit holds, which is a mapping that decays as units are amended.

Reconcile identifiers on a schedule and alert on staleness. If the drilling schedule feed has not updated in a defined period, that is an alert, not a silent assumption that nothing changed.

What happens when depth severances and shut in royalty clocks are not covered?

These are the two coverage gaps that turn a land system into an expensive contact list.

Depth severances make your position three dimensional. You hold one formation on a tract and not the one below it, because a vertical Pugh clause released everything below the deepest producing formation at the end of the primary term. If the system cannot represent that, your development plan is built on fiction. A two mile lateral crossing four leases is not drillable if one of them severed above your target, and you will learn that during title opinion review three weeks before spud, which is the most expensive possible moment to learn it. A system modelling tracts by depth interval answers the question at planning time instead.

Shut in royalty is the quieter one and it terminates leases. The clock starts when production ceases, the payment must be tendered to the right owners at the right addresses inside the window, and in companies without a system this depends on somebody remembering that a specific well sits on a specific lease with a specific clause. Cover it properly: the obligation is generated from the clause parameters, the payment issuance happens inside the system, and the proof of tender attaches to the obligation record. That attachment is the point. If termination is ever claimed, your defence is the cancelled payment tied to the deadline it satisfied, not a recollection that it was probably sent.

The alert design matters as much as the coverage. An unread email is not a control. Alerts need escalation to a named person, mandatory acknowledgement, and a record when nobody responds.

Should you build custom or configure what you already own?

Some readers should buy and stop reading. If you hold under roughly 200 leases in one state, mostly paid up, with no continuous development obligations and no depth severances, iLandMan will serve you well for lease acquisition and records at a fraction of a build, and the difference is better spent on land staff. If you are a mineral owner rather than an operator, your problem is revenue verification and not obligation tracking, and that is a different system entirely.

If you already run Quorum Land System or P2 Land, audit the configuration before commissioning anything. Both model this domain properly, including tracts, depths and obligations. The friction is that configuration is specialist work and changes tend to route through vendor services, which is manageable when your lease forms are stable and painful the week you enter a new play area with different forms. Establish which of those two situations you are in before deciding, because if your obligation logic is stable, the answer is configuration.

The pattern we recommend most often is a split. Buy the records layer if a product fits your leasing workflow, and build the obligation and planning layer around it, because the obligation logic is where your specific clause language lives and it is the part that loses acreage when it is wrong.

One honest caution. If the real problem is that nobody has read your leases, software will not fix it. Abstract first, then automate what you found.

How do hidden costs get into the quote?

• Abstraction volume. The largest single line in most land projects and the one most often left out of the software quote entirely. Count your leases and be honest about how many have never been abstracted.
• State count. Lease forms and statutory rules differ by state, so each additional state adds clause types, computations and edge cases rather than just records.
• Depth severance modelling. Representing tracts by depth interval roughly doubles the complexity of the acreage engine compared with a flat model. It is worth it, and it is not free.
• Unitization and pooling. If you operate where forced pooling and unit designation are central, this is a subsystem with its own rules, not a field on the lease.
• Tract geometry. If your tracts exist only as legal descriptions rather than as polygons, converting them for mapping is its own scoped effort. Worth doing once, but budget it.

What separates a build that works from one that fails here?

The evaluation is simple and most firms fail it. Pick your ten most complicated leases, the ones your land manager cites when explaining why the spreadsheet is hard, and ask whoever you are considering to model those ten. That is the whole assessment.

Specifically, ask them to model a lease with two tracts, a depth severance and a continuous development clause before you sign anything. If they produce a table called Leases with a date column, they will build you a calendar and you will keep the spreadsheet next to it.

Ask how a clause becomes an obligation. The answer that ages well is a clause type carrying a parameterised computation, so a new lease form in a new basin is configured rather than coded. If every new clause type needs a developer, the system stops keeping up the moment your land team moves into a new play.

Ask what the alert does when nobody responds, and accept only acknowledgement plus escalation with the non response recorded.

Ask how the document links to the data: county, instrument number and recording date, with the scanned image one click away and a record of who verified the extracted clause. Landmen do not trust systems they cannot check against the instrument, and an untrusted system grows a parallel spreadsheet within a quarter.

Finally, put ownership in writing before kickoff: the code, the infrastructure accounts and all abstracted lease and document data. At Digital Heroes the client owns the code from the first commit. Lease abstraction is expensive work product that supports title positions for decades, and it should never sit somewhere you cannot extract it in full.