Oil and Gas Revenue Accounting Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the scope of a revenue accounting build get set too small so often?

The requirement usually arrives as a distribution run: take volumes and prices, apply decimals, subtract deducts, cut checks. Every part of that sentence hides a modelling decision, and the two that get made carelessly are the ones that matter for years.

The first is deducts. Whether you can deduct gathering, compression, dehydration, treating, processing and transportation from a royalty owner's share depends on the lease, and on your state's rules about what condition gas must be in before costs become deductible. Two leases on adjacent tracts, signed six years apart by different landmen, say different things: market value at the well, proceeds, an enhancement clause, or silence, which is its own answer depending on jurisdiction. Almost every package models this as a rate attached to a well or a contract, and producers cope by grouping owners into buckets. The buckets are what a plaintiff's expert takes apart.

The second is the division order deck, which gets scoped as a table of owners and decimals. It is a legal document pretending to be a column of numbers, and it changes retroactively.

The fix is to make the lease provision a first class object before anything else is built. Each royalty interest points to the clause governing its deducts, the clause carries a document reference and a plain summary written by your land or legal team, and the calculation reads from it. Then a court decision or a lease amendment means changing one provision and seeing every affected owner and well before you commit. The cataloguing work is legal work your team must do and no developer can do for you, which is precisely why it gets skipped.

What goes wrong when ten years of decks and distributions are migrated?

Historical migration is the underestimated line item every single time, and in this domain it is not a convenience issue. The whole reason to build the system is to answer audit and discovery questions about past periods, and you cannot answer them from history that arrived flattened.

The specific failure is importing decks as current state. A deck has an effective date range and a recorded date, and those are different concepts. A conveyance recorded in March may take effect back in January, which means eleven owners on a unit have new decimals for three closed months. If the migration carries only the interests as they stand today, you can answer what the deck is for July but never what you believed the deck was when you cut July checks, and that distinction is what an audit turns on.

The second failure is silent rule loss. Every producer has undocumented practice sitting inside the old system or beside it: a minimum pay threshold applied inconsistently, a netback convention on one marketing arrangement, a historical rounding habit. It never appears in a specification because nobody knows it is there.

The fix is to price migration as its own phase and to run both systems in parallel for two or three full monthly cycles, comparing distributions owner by owner and investigating every difference to a cause. Each difference is an undocumented rule. Plan the cutover away from year end, because reconciling two systems during the season when tax forms are produced is the worst timing available.

Why do purchaser, land and severance integrations break after launch?

Revenue starts with what the purchaser says they paid, and the purchasers do not agree on how to say it. Some send clean electronic files. Some send spreadsheets with a header block, a detail block and merged cells. Some send portable document files. Some change the layout without telling you. A pipeline built against last quarter's layouts will break, and it breaks silently, which is the dangerous part: a misread deduction column or a volume that quietly disagrees with your measurement flows all the way to owner checks before anyone notices.

The land system and the measurement feed break differently. Land sends a deck change and revenue applies it, but if the interface passes only the new interests without the effective date and the source document, you have recreated the same history problem inside a working integration. Severance filings break because each state is its own regime with its own forms, rates, exemptions and cadence, and a rate change in one state does not announce itself to your software.

The fix is ingestion as a review workflow with a learned template per purchaser rather than a fixed parser. Every extracted value is compared against your own volumes and expected pricing, and anything outside tolerance goes to a queue showing the source page beside the value. Add a volume monitor per purchaser so a source that stops arriving raises an alert rather than a gap. For severance, treat each state as a separately maintained rule set with an owner and a review date.

What happens when suspense and prior period adjustments are not covered?

Suspense is where money quietly becomes a liability. Interests are held for title defects, unlocatable owners, missing tax identification, minimum pay thresholds and legal holds, and each carries different rules about whether interest accrues, when the money must be released and when it escheats. Packages track the balance. What they generally do not do is manage suspense as a workflow with a typed reason, a responsible person, the release condition and an aging clock, so the balance grows and release happens once a year in a panic. Unclaimed property reporting is state by state with different dormancy periods and due dates.

Prior period adjustments are the second uncovered gap and they are constant rather than exceptional. A volume correction, a repriced purchaser statement, a retroactive deck change or a severance rate correction all mean the same thing: closed months are now wrong, and the correction has to flow to owner statements, annual tax totals, filings already submitted, any federal reporting, and your own books.

The fix for both is versioning with explicit deltas. Every distribution is a versioned run, an adjustment creates a new version with a stated difference, and downstream obligations are generated as tasks with the delta attached rather than left to memory. Owner check stubs should show the adjustment with its reason, which reduces owner relations calls more than any portal feature. On suspense, give every entry a reason, an owner, a release condition and a clock tied to the relevant state rule, and the balance becomes a shrinking queue instead of a number nobody can explain.

Should you build custom or configure what you already own?

If you operate under roughly one hundred wells in one or two states with conventional leases and a small owner count, do not build. Enertia and the mid-market packages are built for exactly that and will serve you well below a fraction of a build's cost. If your business is primarily non-operated, also do not build this: your revenue arrives on someone else's statements and your problem is checking their maths and chasing missing payments, which is a smaller and cheaper system.

Quorum, W Energy Software and P2 Enterprise Upstream are solid ledgers with real depth, and the honest framing is that they strain in two specific places rather than being bad products. Applying effective-dated deck changes across closed months at volume is one. Representing deducts as lease provisions rather than rates on a well is the other. Those are also the two areas that generate royalty litigation exposure, which is why the workarounds end up in spreadsheets in every producer we have worked with.

The diagnostic is simple and you can run it this week. If your team maintains deck changes, deduct exceptions or suspense reasoning outside the package, list what lives out there and why. If the answer is that the package cannot represent a specific lease, that is the build case. If the answer is that nobody has configured the feature, configure it first.

How do hidden costs get into the quote?

A focused first release covering effective-dated decks, purchaser settlement ingestion with variance review, lease-provision-driven deduct calculation and a reproducible distribution run costs $90,000 to $180,000 and ships in 16 to 22 weeks. A full platform adding suspense workflow and escheat, tax form production with backup withholding, state severance filings, federal reporting, an owner portal and adjustment propagation runs $250,000 to $600,000 over 9 to 15 months. The overruns are all foreseeable.

State count is the first, because each severance regime is its own filing project rather than a configuration row. Federal and Indian leases are the second and bring a separate reporting discipline that is not a small addition. Take-in-kind working interest owners are the third. Marketing arrangements where you sell at multiple points with different netbacks are the fourth. Historical migration is the fifth and is almost never in the original number at the size it actually is.

The sixth is not a software cost at all: lease provision cataloguing. It is legal and land work, it is usually the schedule driver, and a project assuming it will happen alongside the build discovers otherwise in week six. Start it before procurement.

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

Whether the system was designed as evidence or as arithmetic. The packages are good ledgers and poor evidence systems, and a custom build that copies their model just produces a more expensive ledger. At real scale the thing that costs you money is not the arithmetic of a distribution, it is being unable to prove why each number was what it was.

Practically, that means three commitments. Bitemporal decks, so every interest carries an effective date range and a recorded date and nothing is overwritten. Deducts anchored to lease clauses with document references. And every calculation reproducible from stored inputs rather than dependent on a current lookup, so a distribution from four years ago can be rerun and shown to produce the same result.

The test to run before you sign is a whiteboard test. Ask a candidate developer to model a retroactive conveyance affecting three closed months. The right answer includes effective dating and recorded dating as separate concepts, deck rebalancing and generated restatements. Then pull three leases with genuinely different deduct language and ask how each is represented. That conversation tells you more than any demo.

Finally, settle ownership before kickoff: repository, cloud accounts and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit. On a system that carries litigation exposure, a vendor controlling access to your evidence base controls your ability to respond to discovery, and you should accept nothing less than full ownership.