Reserves and Well Economics Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the scope creep into rebuilding the economics engine so often?

It starts as a reasonable observation. If you are building a case management system anyway, and the calculation is decline curves and discounted cash flow, why keep a dependency on an aging tool. The maths is not the hard part and any developer can see that.

The reason to resist is not technical, it is who has to accept the output. A reserve report supports a public disclosure, a borrowing base and sometimes an impairment test. A third party auditor such as Netherland Sewell, Ryder Scott or Cawley Gillespie signs off on some portion of it, and banks read the same numbers at redetermination. Those parties are used to the calculation conventions of the established engines. A new engine is not accepted because it is correct, it is accepted because someone has demonstrated agreement, well by well, with the engine they already trust, and then explained every difference. Rounding, the timing of abandonment, the treatment of negative cash flow months and the ordering of deductions all produce small differences that each need an answer.

The scope that pays is the wrapper. Versioned assumptions with effective dates and named owners, cases as immutable selections of assumption versions and well sets, an approval workflow that locks a case at sign off, a classified change log, and a roll up from well to package to corporate that reconciles at every level. That is the system everybody in your organisation has been asking for and none of it requires touching the calculation.

If a developer is casually willing to reimplement reserve economics, make them justify it against that acceptance problem specifically. In most cases the honest answer is that the wrapper solves the complaint and the engine replacement solves a preference.

What goes wrong when you load historic cases and well data?

Two things, and both are underestimated because the source looks tidy from a distance.

The first is that your historic cases are files. A fall bank case and a year end case exist as database copies on a shared drive named with an evaluator's initials and a date, and the difference between them is real but undocumented. Loading them into a structured model means somebody has to decide, retrospectively, what each case was and what assumptions it used, which is archaeology rather than migration. It is worth doing for a small number of reference cases and it is not worth doing for everything. Decide the cutover point deliberately: which prior cases must be reproducible inside the new system and which are archived as files with their outputs preserved.

The second is well identity. Wells arrive under a regulatory identifier, a company identifier, a lease and well number, and a name that changed after a recompletion or a workover. Ownership changes with acquisitions and divestitures at effective dates that do not align to reporting periods, and working interest and net revenue interest can differ by product and by depth. A load that treats the well as a single key produces a corporate roll up that does not reconcile, and the failure appears at the worst moment because nobody checks the total until year end.

Build the well and ownership model first, with effective dated interests, and reconcile it against production accounting before any case is loaded. If those two do not agree, nothing downstream will.

Why do the production accounting and ledger integrations break after launch?

Feeding actual volumes from production accounting and actual operating costs from the ledger is one of the highest value additions in this category, because it turns assumption setting into an evidence based exercise. It is also the integration most likely to degrade quietly.

Volumes break on allocation. Production accounting allocates measured volumes to wells on a basis that changes when a meter is added, when a well is recompleted or when an allocation method is revised, and prior periods get restated. If the reserves system stores allocated volumes as a snapshot, its history diverges from the accounting system's history and nobody notices until an evaluator disputes a decline fit.

Costs break on coding. Operating cost arrives at a cost centre level that maps to your packages through a convention rather than a field, and the convention changes when the accounting group restructures cost centres or when a workover gets coded to operating rather than capital. Then a package that looked expensive last quarter looks cheap this quarter for reasons that have nothing to do with the field.

The design that survives both is to store the source system's version and effective date on every imported figure, accept restatements as new versions rather than overwrites, and run a reconciliation report that compares totals with the source on a schedule. Then map cost centres to packages explicitly, as maintained data with an owner, and raise unmapped codes as exceptions rather than dropping them into an other bucket.

What happens when the approval workflow and change classification are not covered?

These are the two features most often cut to hit a budget, and cutting them removes the entire reason for the project.

Without an approval workflow that locks a case at sign off, an approved case is still editable, which means the number that supported a disclosure can change after the fact with no record. Every operator we have worked with says this cannot happen at their company. It happens through ordinary good intentions: an evaluator tidies something, corrects an obvious error, or updates a well that came online.

Without a classification attached to each assumption change at the moment it is made, the year over year reconciliation into revisions of previous estimates, extensions and discoveries, improved recovery, purchases and sales of reserves in place, and production goes back to being assembled in a spreadsheet in January by somebody comparing two databases and applying judgement. That judgement is not reproducible, which is precisely what an auditor is testing, and most of an auditor's open item list is a request for exactly this trail.

Both features are inexpensive at design time and effectively impossible to add retrospectively, because they depend on data captured at the moment of the edit. Keep them in phase one even if something else has to go. The one to sacrifice instead is usually multi case comparison reporting, which is valuable and can wait.

Should you build custom or configure what you already own?

Do not build if you run a few hundred wells, one evaluator, one bank and no public disclosure. PHDWin plus disciplined file naming is genuinely adequate at that scale 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 short engagement, not a platform.

Halliburton ARIES stays. The complaint operators have about it is rarely 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 amounts to copying database versions. All three of those are solved by a system of record wrapped around the engine.

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

There is one more honest caution. The point of this system is that it constrains the person who currently has full discretion over the numbers. If your evaluator does not want the change log, that is a management decision before it is a software one, and building over the objection produces a system people work around.

How do hidden costs get into the quote?

Five, reliably. The engine decision, covered above, which is the single largest scope lever in the project and is often left ambiguous in a proposal so that both parties assume the cheaper reading.

Well count and recalculation performance. A five thousand well corporate roll up recalculated across four cases is a performance engineering problem, not a spreadsheet, and it changes the architecture. Quotes that assume interactive recalculation without testing at your well count are quoting a prototype.

International fiscal terms, if you have any. A production sharing contract is a different cash flow model with cost recovery pools and profit splits, and folding it into a domestic quote understates it substantially.

And organisational agreement on ownership of assumptions. Deciding who owns the price deck, who owns operating cost, what requires approval and what an evaluator may change unilaterally is a governance exercise with your finance and asset teams. It is the main schedule risk in these projects and it is never on a developer's plan.

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

Whether the system can answer the question that started the project. Take your fall bank case and your year end case and ask it to show the difference. If the answer is a comparison of values, the build failed. The answer you need is an assumption level difference: the operating cost version changed on this date, by this person, for this reason, and the price deck did not.

Second, how it behaves when accounting revises something already used in an approved case. The correct behaviour is a new assumption version with an effective date, the approved case still pointing at the superseded version, and a report listing every case affected so somebody can decide what to restate. Anything that silently updates an approved case is disqualifying and you should test it before acceptance rather than after.

Third, reproducibility. You must be able to reproduce any approved case on demand years later, including its assumption versions, well set and outputs. Reserve history supports disclosures and borrowing bases long after the evaluator who built it has left, and a case you cannot reproduce is a case you cannot defend.

Fourth, ownership. You should own the repository, the cloud accounts and the full reserve database including historical cases, with the right to hire another firm, written into the contract before kickoff. At Digital Heroes the client owns the code from the first commit.