Reserves and Well Economics Software: Making the Year End Report Traceable

Why the year end reserve report cannot be traced back

The report goes out in February. It supports a public disclosure, a borrowing base, and in some companies an impairment test. A third party auditor such as Netherland Sewell, Ryder Scott or Cawley Gillespie has signed off on some portion of it. Six weeks later somebody asks a simple question: why did the operating cost assumption on this package go from $4.80 to $6.20 between the fall bank case and the year end case.

Nobody can answer. The fall case is a database copy on a shared drive named with the evaluator's initials and a date. The year end case is a different copy. Between them sat forty conversations, a spreadsheet of updated field level costs from accounting, an email from the asset team about a workover programme, and one evening where the evaluator went through and cleaned things up. The delta exists. The reason does not.

This is the actual problem in reserves systems, and it is not a modelling problem. The decline curves are fine. The economics arithmetic is fine. What is missing is the system of record around the model: who changed which assumption, when, on whose authority, and against which approved case. Every other symptom, the parallel copies, the reconciliation that takes two weeks, the auditor's list of open items, follows from that gap.

Problem 1: assumptions are copied, not versioned

The working practice at most operators is file based. Take last quarter's database, save as, start editing. That is version control by filename, and it has three consequences. You cannot diff two cases at the assumption level, only at the result level, so you know the value moved but not why. You cannot run last year's case with this year's price deck to isolate price effects from performance revisions. And when two evaluators work in parallel on different packages, merging is manual.

The fix is not exotic. Assumptions become records with effective dates and an owner: price deck, differential by product and area, fixed and variable operating cost, gathering and processing deductions, severance and ad valorem rates, capital cost by well type, abandonment cost, working interest and net revenue interest. A case is a named, immutable selection of assumption versions plus a well set. Copying a case copies references, not values, so when accounting revises field level operating costs you can see every case that used the superseded version rather than hunting for them.

Problem 2: the year over year reconciliation is assembled by hand

Disclosure requires you to explain the change in proved reserves in categories: revisions of previous estimates, extensions and discoveries, improved recovery, purchases and sales of reserves in place, and production. In practice this reconciliation is built in a spreadsheet in January by someone comparing two databases and using judgement about which bucket a change belongs in.

That judgement should be a property of the change, not a retrofit. If an assumption edit is recorded when it happens with a classification attached, the reconciliation computes itself and the categories are defensible because each one traces to specific edits on specific wells. This is the single feature that most shortens the audit, because the auditor's request list is largely a request for exactly this trail.

Problem 3: development scheduling and the five year PUD rule live outside the model

Under SEC rules, proved undeveloped locations generally have to be scheduled for drilling within five years of first booking, and locations that will not be reached have to come off. That means your reserve report depends on a development schedule that lives in the planning group's spreadsheet, in a rig scheduling tool, or in the capital budget.

When those are disconnected, two failures follow. Locations get carried year after year with a nominal date that keeps slipping, until an auditor asks for the development plan supporting them and there is not one that matches. And the capital in the economics does not match the capital in the budget, so the corporate cash flow forecast and the reserve report describe different companies. A build that links the PUD inventory to a real, dated development schedule, and flags every location whose scheduled date now falls outside the window, removes an argument you otherwise have every single year.

Problem 4: three audiences want three cases and there is only one truth

Your bank wants its own price deck at redetermination. The disclosure requires the prescribed pricing basis, which is a trailing twelve month average of first day of month prices rather than a forecast. Management wants strip pricing for planning. The asset teams want their own type curves.

Those are four cases on one well set, and they should differ only in the assumptions that are supposed to differ. In file based practice they diverge in ways nobody intended, because each case was edited independently over months. A properly structured system makes the case an overlay: same wells, same forecasts, explicitly different price and cost assumptions, with a report that shows exactly which assumptions differ between any two cases. When the bank asks why your internal value differs from the reserve report, that report is the answer and it takes ten seconds.

What ARIES, PHDWin, Val Nav and PRISM actually do

Halliburton ARIES is the entrenched reference for reserve economics in North America, and its calculation conventions are what auditors and banks are used to seeing. The complaint is not accuracy. It is that the data model is old, the economics are driven by text based configuration that is powerful and opaque, and change control in practice is copying database versions. PHDWin is a capable evaluation tool that smaller operators and consultants like for good reasons, and it is fast to work in; concurrent multi user editing with an enterprise change log is not what it was designed for.

Quorum Aucerna Val Nav does handle the corporate roll up, case management and workflow properly, and it is the honest buy answer for a large operator willing to run an enterprise implementation. Enverus PRISM is excellent for type curve benchmarking, offset performance and external data, and it should sit alongside whatever you build, but it is not your internal approval chain or your assumption history.

What a custom build should include, and what it should not rebuild

Our position: do not rebuild the decline and cash flow engine unless you have a concrete reason. Not because it is hard mathematically, it is deterministic arithmetic, but because your reserve auditor and your bank recognise output from known engines, and a home grown engine has to be validated well by well against the incumbent before anyone accepts it. That validation is a real project and it buys you nothing your evaluators asked for. Wrap the engine instead. Build the system that everybody actually needs:

• Versioned, effective dated assumptions with named owners and mandatory reason text on change
• Cases as immutable selections of assumption versions and well sets, with a case to case assumption diff report
• An approval workflow that locks a case at sign off and records who approved what on which date
• A classified change log that computes the year over year reconciliation by category rather than reconstructing it in January
• PUD inventory tied to a dated development schedule, with automatic flagging of locations that fall outside the booking window
• Roll up from well to package to area to corporate that reconciles at every level, with no manual aggregation step
• Ownership handling for acquisitions and divestitures with effective dates, so a mid year deal does not require a rebuild
• Feeds from production accounting for actual volumes and from the ledger for actual operating cost, so assumptions can be tested against outcomes
• Full reproduction of any approved case on demand, years later

What this costs and how long it takes

From Digital Heroes delivery experience on audit sensitive financial modelling systems, a first release covering case management, versioned assumptions, approval workflow, change log and roll up runs $80,000 to $160,000 across 14 to 20 weeks. The full platform adding development scheduling, multi case comparison, hedge overlays, transaction handling and a validated economics engine runs $200,000 to $450,000 phased over 6 to 12 months.

What moves the number: well count, because a five thousand well corporate roll up recalculated across four cases is a performance problem and not a spreadsheet. Whether you replicate the economics engine or wrap the existing one, which is the single biggest scope decision in the project. International fiscal terms such as production sharing contracts, which are a different cash flow model entirely. And historical case loading, if you want prior years reproducible inside the new system rather than archived as files.

When you should not build this

If you run a few hundred wells, one evaluator, one bank and no public disclosure, PHDWin plus disciplined file naming is genuinely adequate and a build is a distraction. If your complaint is that reserves reporting is slow rather than untraceable, the fix is probably a reporting layer over the existing database and a two to three week engagement. And if your evaluator does not want the change log, understand what you are asking: the point of this system is that it constrains the person who currently has full discretion, and that is a management decision before it is a software one.

How to choose a developer for reserves and economics systems

Ask them how they would show the difference between two cases. If the answer is a value comparison, they have missed the point. You want an assumption level diff that says the operating cost version changed and the price deck did not.

Ask what happens when accounting revises a field operating cost that is already used in an approved case. The correct behaviour is a new assumption version with an effective date, an approved case that keeps pointing at the old version, and a report listing every case affected. Anything that silently updates an approved case is disqualifying.

Ask whether they intend to rebuild the economics engine and make them justify it. A developer who is casually willing to reimplement reserve economics has not yet met a reserve auditor.

Ask who owns the code, the cloud accounts and the reserve database, and get it in writing before kickoff. At Digital Heroes the client owns the code from the first commit. A sensible next step: hand whoever you are evaluating your fall bank case and your year end case and ask them to describe how their design would have explained the difference between them. The quality of that answer is the whole decision.