Oil and Gas Production Allocation Software: When Back Allocation Lives in a Spreadsheet

Why back allocation is the most expensive spreadsheet in an oil and gas company

Ten wells flow into one tank battery. One LACT unit measures the oil that leaves. One meter measures the gas that goes to the plant. Nothing measures well 7. So well 7 gets the volume the allocation says it gets, and that number becomes the royalty check to a mineral owner, the joint interest bill to a working interest partner, the severance tax return, the state production report, and one row in the reserve database that a bank will lend against.

The number comes from a well test. Somebody put well 7 through a test separator for a period, wrote down oil, water and gas rates, and that test now represents the well until it is tested again. Multiply the test rate by the days on production, do the same for the other nine wells, sum the theoreticals, divide the actual measured sales volume by that sum, and apply the resulting factor back down. That is back allocation. In most mid size operators it happens in a workbook with one tab per battery, maintained by one production accountant, and the formulas have been copied forward every month for years.

The exposure is not subtle. An allocation error does not fail loudly, it distributes quietly to owners and to the state and then sits there. It surfaces when a royalty owner audits, when a partner reconciles their own take, when the plant restates a settlement statement, or when a reserve auditor cannot tie the production history to the filed reports. At that point you are not fixing a spreadsheet, you are restating months of revenue distribution and explaining it to people who have contractual audit rights.

Problem 1: the well test governs everything and nobody governs the well test

Every allocated volume in your company traces back to a test rate. Yet in most operations the test register is a tab, tests get recorded from a pumper's handwritten sheet, and there is no rule about what makes a test valid. A four hour test on a well that was slugging is treated the same as a stable 24 hour test. A test taken the day after a workover is applied backwards to a month when the well was producing at half that rate.

What a real system does is treat the test as a controlled record with acceptance criteria. Minimum duration, stability requirements on rate and pressure, an explicit reject reason when a test fails, and a rule for which valid test applies to which production period. Then the allocation engine selects tests by rule rather than by whoever built the tab, and when someone overrides the rule the override is recorded with a reason. That single change removes the most common source of allocation disputes, because you can now answer the question a royalty auditor actually asks: why does this well carry this rate for this month.

Problem 2: the allocation tree changes and the history quietly changes with it

Facilities are not static. A well is routed to a different separator. A battery is tied into a new sales point. Gas lift injection starts and now some of the gas measured at the meter is recycled rather than produced. Fuel and flare have to come out. A new well comes online mid month and takes ten days of allocation.

In a spreadsheet, changing the tree means editing the tab, which silently rewrites how prior months would calculate if anyone reran them. That is why nobody reruns them. A build fixes this by making the allocation network an effective dated structure: the configuration that applied in June is preserved exactly as it was, so a June rerun in the following March produces June's answer, not today's answer applied to old data. This sounds like an accounting nicety until an auditor asks you to reproduce a filed month and you cannot.

Problem 3: prior period adjustments are where restatements are born

Corrections are normal in production accounting. A test was wrong. A meter was found out of calibration. A well was on the wrong battery for three weeks. The plant sent a revised statement. The question is what your system does with the correction.

The wrong answer, and the common one, is to edit the closed month in place. Now the number you filed and the number in your system disagree, and nobody knows which owners were paid on which basis. The right answer is that a closed month is immutable once filed, and a correction produces a new allocation run whose output is a delta: this well gained 340 barrels for June, this owner is owed this much, this severance tax return needs an amendment of this amount. The delta is what flows to revenue and to the state, and the original run stays exactly as filed forever. Building this properly is the difference between a correction and a restatement.

Problem 4: the gas plant statement arrives late in a format nobody parses

You deliver wet gas to a processor. Six weeks later a settlement statement arrives showing plant volumes, shrink, thermal reduction, NGL yields by product, and proceeds under whatever percent of proceeds or keep whole arrangement is in the contract. Your allocated volumes and the plant's numbers will not match. They never match. Reconciling them by hand is a monthly ritual and, in a lot of companies, an abandoned one: people accept the plant's number because checking it is too hard.

That is money. The reconciliation between what you measured at the meter, what the plant says it received, and what the contract says you should be paid is one of the few places in an operator where a software build finds cash rather than saving hours. It requires ingesting statements in the processor's format, restating them to your own volume basis, and flagging variances above a tolerance per contract. It is unglamorous and it pays.

What ProCount, Energy Components, Enertia and eLynx actually cover

Be accurate about the incumbents before you decide. Quorum ProCount is the most widely deployed field data capture and production accounting system in North American operations, and it does allocation properly. The friction operators describe is that allocation configuration is specialist work, changes tend to route through consultants, and getting your own granular data back out for analysis usually means nightly extracts into a warehouse you then maintain anyway.

TietoEVRY Energy Components is enterprise hydrocarbon accounting sized for large international operators with complex processing and ownership structures. It is capable and the implementation is scoped accordingly, which is often a mismatch for a mid size domestic operator. Enertia is an integrated oil and gas ERP (Enterprise Resource Planning) where production accounting and the general ledger are one system, which is a genuine strength for smaller companies; the limitation is that the model is the model, and if your facilities or contracts do not fit it, you adapt rather than it adapting. eLynx is field data acquisition and SCADA hosting. It feeds allocation with good measurement data. It does not do the allocation.

Our position: if you are a conventional operator with straightforward facilities, buy. The build case is specific and it is about the joins. When the same volume has to satisfy an allocation engine, a revenue system, a state filing, a partner's audit and a reserve database, and those five things live in five places, the coordination logic between them becomes the actual job. That coordination logic is what you should own.

What a custom allocation build must include

• An effective dated allocation network covering wells, completions, separators, batteries, sales points, injection, fuel, flare and vent, with the June configuration preserved as it was
• A well test register with validity rules, reject reasons, automatic test selection and recorded overrides
• Measurement ingestion from electronic flow computers with an audit trail that preserves the original value alongside any edit and the reason for it, consistent with electronic flow measurement practice under API 21.1
• Theoretical calculation, allocation factor derivation and a hard reconciliation to the sales meter with variance tolerances that alert rather than silently absorb
• Shrink, BS&W and thermal handling as configured contract terms rather than hardcoded constants
• Gas plant settlement statement ingestion and reconciliation against your own allocated volumes with per contract variance flags
• A prior period adjustment engine that reruns a closed month, produces deltas per well and per owner, and never mutates the filed version
• Outputs to revenue distribution, joint interest billing volumes, severance tax and state regulatory reporting, plus a warehouse feed for engineering and reserves
• Immutable as filed snapshots with a one click reproduction of any prior month

What this costs and how long it takes

From Digital Heroes delivery experience on financially consequential data systems of this shape, a first release covering the allocation network, well test governance, measurement ingestion and monthly allocation with reconciliation runs $90,000 to $180,000 across 16 to 22 weeks. The full production accounting build adding plant settlement reconciliation, prior period adjustments, tax and regulatory filings and downstream revenue and billing volumes runs $250,000 to $600,000 phased over 9 to 18 months.

What drives cost up in this category: the number of distinct states you file in, because every state defines its own production report and severance calculation. Gas processing complexity, particularly multiple plants with different contract structures. Federal and tribal leases, which add their own reporting obligations. Historical conversion, because loading and validating several years of prior allocations is a project in itself and you will want it for the reserve database. What keeps cost down: one state, one plant contract, and a decision to leave revenue distribution in the existing system for phase one while the allocation engine proves itself in parallel.

How to choose a developer for production accounting work

Ask them to draw the allocation model on a whiteboard before you sign. You want to see effective dating on the network, a test record with validity rules, and an immutable run output. If they draw wells and volumes and nothing about time validity, they will build you a faster spreadsheet.

Ask what happens when a June test is corrected in March. The answer must be a new run producing a delta, with June's filed output untouched. Any other answer is a restatement generator.

Ask whether they have handled electronic flow measurement data and what they do about edits. Preserved original, recorded reason, and a reviewable edit history is the only acceptable design, because that trail is what an audit examines.

Ask who owns the code, the cloud accounts and the data, and get it in writing before kickoff. At Digital Heroes the client owns the code from the first commit. A practical next step: take one battery with a shared sales meter and a plant contract, and ask whoever you are evaluating to model just that battery end to end. If they can reproduce last June to the barrel, they can build the rest.