Production Allocation Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the allocation network get scoped without effective dating?

The requirement everyone writes down is that the system must allocate measured sales volumes back to wells using test rates. That sentence is true and it is missing the hardest word, which is time. A facility diagram is a photograph of today. Wells get rerouted to a different separator, a battery gets tied into a second sales point, gas lift starts recycling volume through the same meter, fuel and flare change, and a new well takes ten days of a month. If the network is stored as one current structure, a rerun of June performed the following March silently applies today's configuration to June's data.

In most industries a rerun that differs slightly is an inconvenience. In production accounting the June number went out to royalty owners, onto a joint interest bill, onto a state production report and severance return, and into the reserve database a bank lent against. Five parties hold a copy of a figure your system can no longer reproduce, and every one of them has the right to ask about it.

The fix is cheap if you specify it before the first sprint and expensive afterwards, because it changes the shape of nearly every table. Require an effective dated network: wells, completions, separators, batteries, sales points, injection, fuel, flare and vent all carry validity periods, and every allocation run records the exact configuration version it consumed. Then make the acceptance test concrete. Ask the team to demonstrate a June rerun executed in March that returns the filed figures to the barrel. If that demonstration is in the plan, the foundation is sound. If it is not, you are buying a faster spreadsheet.

What goes wrong when you load historical allocations?

Historical conversion is the schedule risk operators price at zero and pay for twice. You need history because the reserve database wants a continuous production record, because your engineers compare decline curves against it, and because a royalty auditor will ask about years you would rather not discuss. So you load it, and the loading surfaces every undocumented decision the last decade of spreadsheets contains.

The specific problems repeat. Well identifiers change over a well's life through recompletions, renumbering after an acquisition and inconsistent state identifiers, so the same physical well appears under three keys. Old months contain manual plugs where the allocation did not balance and someone forced it, and those plugs have no reason recorded. Facility configuration for prior years exists only as marked up printouts. Units differ, with some periods in thousand cubic feet and others in million British thermal units after a contract change nobody flagged.

Treat conversion as its own workstream with its own acceptance criteria rather than a task inside development. Load a small number of representative batteries first, including one with a plant contract and one with a shared sales point, and reconcile them line by line against what was filed. Where a historical month cannot be reproduced, record that fact against the month rather than adjusting it to fit. A history that is honest about which periods are unreproducible is far more defensible in an audit than one that has been quietly smoothed.

Why do flow computer and gas plant feeds break after launch?

Two integrations carry this category and both fail in ways that are invisible for weeks. The first is electronic flow measurement. Data arrives from flow computers through a SCADA host or a polling service, and the failure is rarely a dead connection, because a dead connection is obvious. The failure is a meter that goes to a default value, a configuration change at the site that shifts a tag name, a time zone or daylight saving offset that shifts an hour of gas into the wrong day, or an edit made in the measurement system that overwrites the original reading with no trace. Under electronic flow measurement practice consistent with API 21.1, the original value, the edited value, the reason and the person belong in the record permanently. Systems that store only the current value cannot survive an audit of a disputed month.

The second is the gas plant settlement statement. It arrives weeks after the production month, in the processor's own layout, and processors change that layout without telling you. A parser built against last year's file will either fail loudly, which is fine, or match the wrong columns, which is not. Build every inbound feed with schema validation and a quarantine queue: anything that does not match the expected shape stops and waits for a human rather than flowing into an allocation run.

What happens when prior period adjustments are not covered?

Corrections are normal in this business. A test was invalid. A meter was found out of calibration. A well sat on the wrong battery for three weeks. The plant issued a revised statement. The question is what your software does with them, and if the answer was not designed on purpose, the answer will be that someone edits the closed month.

A correct design makes a closed month immutable at the moment it is filed. A correction produces a new allocation run whose output is a delta rather than a replacement: this well gained 340 barrels for June, this owner is owed this amount, this severance return needs an amendment of this amount, this partner's billing changes by this much. The original run stays exactly as filed forever, and the delta is what flows downstream. Ask any developer to describe this workflow before you sign. If they propose an edit screen for closed periods, they have not built for an audited environment, and the first correction after go live will teach you the difference at your expense.

Should you build custom or configure what you already own?

Configure, honestly, if you are a conventional operator with straightforward facilities. Quorum ProCount is the most widely deployed field data capture and production accounting system in North American operations and it does allocation properly. If you run under roughly 150 wells on simple batteries with no processing plant and no working interest partners, a packaged system will serve you and cost far less than a build. Enertia is worth a serious look if you want production accounting and the general ledger in one system and your facilities fit its model. TietoEVRY Energy Components is built for large international operators with complex processing and ownership, which is usually a mismatch for a mid size domestic company. eLynx gives you good field measurement data and does not do the allocation.

The build case is narrower than most vendors admit and it is about the joins. When the same volume has to satisfy an allocation engine, a revenue system, a state filing, a partner audit and a reserve database, and those five things live in five places, the coordination logic between them is done by a production accountant with a workbook. That coordination is what you should own. Many operators reach the right answer by keeping the packaged allocation system and building the reconciliation, plant settlement and reporting layer around it, which costs a fraction of a replacement and removes the actual bottleneck.

How do hidden costs get into a production accounting quote?

The line items that get left out of a fixed price are predictable, so check for them before you sign rather than after.

• Additional states. Every state defines its own production report and severance calculation. A quote written for one state and a project that files in four are different projects.
• Each processing contract. Every processor needs its own statement parsing, mapping and reconciliation rules. Two plants is not twice one plant in effort, but it is not free either.
• Federal and tribal leases. These carry reporting and royalty obligations on top of state requirements and deserve their own scope line with their own acceptance criteria.
• Historical conversion. Frequently quoted as a data load and frequently the largest single overrun in this category.
• Parallel running. Two or three closes with the new engine alongside the spreadsheet while your production accountant reconciles both outputs.

For reference, Digital Heroes delivery experience on systems of this shape puts a first release covering the allocation network, well test governance, measurement ingestion and monthly allocation with reconciliation at $90,000 to $180,000 across 16 to 22 weeks, with a full production accounting build at $250,000 to $600,000 phased over 9 to 18 months. A quote materially below that band is usually a quote that has not read the processing contracts.

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

Four things, and they are all visible before the contract is signed.

The first is whether the well test is treated as a governed record. Every allocated volume in your company traces back to a test rate, yet in most operations tests are recorded from a handwritten sheet with no acceptance criteria. A build that works defines minimum duration, stability requirements, an explicit reject reason, and a rule for which valid test applies to which production period, with overrides recorded and attributed. That single change removes the most common source of allocation disputes, because it lets you answer the question an auditor actually asks.

The second is whether variance is surfaced or absorbed. Theoretical volumes will not equal measured sales volumes. A system that silently applies whatever factor makes the arithmetic balance will hide a failed meter for months. A system that alerts when the factor moves outside a tolerance you set will catch it the same week.

The third is proving reproduction rather than promising it. Pick 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 against last June. If they can reproduce the filed month to the barrel, they can build the rest. If they want to start with a dashboard, they have misunderstood the job.

The fourth is ownership. Get the repository, the cloud accounts and the data in your name in writing before kickoff, with an unrestricted right to hire another firm. At Digital Heroes the client owns the code from the first commit. Your allocation history is evidence in royalty and partner audits for years after the fact, and it should never sit behind another company's access controls.