Produced Water Logistics Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the network model get cut from scope so often?

The scope that gets approved is almost always the ticket. It is visible, it demos well, drivers can use it next month, and it removes a stack of paper from somebody's desk. So the first release becomes a driver app, a back office queue and a report. Eight weeks later you have digitised the paperwork and changed nothing about where the barrels go.

The network model is the part that decides. Every tank battery with its storage volume and typical fill rate. Every transfer point and interconnect, with the direction it can flow and the party that owns it. Every gathering segment with a capacity. Every disposal well with its three separate constraints, meaning permitted daily volume, physical capacity at current injection pressure, and volume already committed to someone else today. Recycling facilities with inventory and quality. Without that graph a ticket is just a record of a decision somebody already made badly.

It gets cut because it looks like data entry rather than software, and because the information is scattered across a midstream engineer's spreadsheet, a supervisory control and data acquisition (SCADA) screen and a folder of contracts. Nobody owns all of it, so nobody can hand it over in week one.

The fix is to make the network model the first deliverable, not a background task. Walk one area of interest, name every source, sink and connection in it, and load it before the app is built. If a developer proposes ticketing first and network later, be clear about what you are buying: a faster way to record the wrong route.

What goes wrong with hauler ticket data and volume reconciliation?

Field ticket data arrives in whatever each hauler's system produces. One sends a comma separated file nightly. One has a portal you log into. Two still send scans of paper. The gathering system operator sends a monthly statement as a PDF. Your own SCADA holds transfer meter volumes on a historian tag structure nobody has documented since the engineer who built it left.

The failure is silent averaging. A file arrives with a malformed row, the loader coerces it, and a battery quietly gains a few hundred barrels of production that never existed. Nobody sees it because nothing broke. Six months later the water balance for that area of interest is wrong and no one can say when it started.

Treat every inbound feed as untrusted. Normalise to your own ticket model, validate on arrival, and quarantine anything that fails rather than letting it through with a best guess. A quarantine queue that a person clears every morning is a feature, not an admission of weakness.

Then run the three way reconciliation explicitly and daily: what the battery says it produced, what the ticket says was hauled, and what the receiving disposal well or facility says it accepted. Set a variance threshold, report every break above it with a named owner, and keep the history. Water disappears in the gaps between those three numbers, and so does money. Operators who only reconcile at month end find the variance after the dispute window on the invoice has closed.

Why do SCADA and hauler feeds break after launch?

Because none of them are yours. A hauler changes billing systems and the file layout moves. A portal rotates its credentials and nobody tells the person who set up the scrape. An instrumentation contractor renames historian tags during a turnaround because the new naming convention is tidier. A disposal well operator switches to a new statement template. Every one of these is routine work for the other party and an outage for you.

The pattern that survives is boring. Version the parser for each source rather than writing one flexible importer that tries to cope with everything. Write a contract test per feed that runs against a stored sample, so a format change fails loudly in your system before it fails quietly in your numbers. Alert on silence as well as on error, because a feed that stops arriving looks exactly like a quiet week.

The driver application has its own version of this problem. A large share of tank batteries have no usable signal, so offline capture with local storage, a sync queue and conflict handling on the ticket is a hard requirement rather than a refinement. Systems that assume connectivity revert to paper within a month, and the paper then gets keyed in later by someone who was not there, which is where wait time claims stop being verifiable.

What happens when state injection reporting is not covered?

You end up with two sets of numbers. The operating system produces tickets and billing, and a separate person assembles the regulatory report from a different extract, on a different cadence, with their own corrections applied along the way. Both are defensible in isolation. Neither can be reconciled to the other on demand, which is the exact question you will be asked during an inquiry.

Injection volume by well by period is a reporting obligation with a prescribed format. In Texas that means the Railroad Commission's injection reporting, and other states have their own equivalents with different periods and layouts. Multi state operators discover late that this is not one report with a flag, it is several reports with different underlying definitions of a period and a well.

The fix is structural rather than clever. Generate the regulatory report from the same records that drive your billing, with the underlying tickets and meter readings traceable behind every figure. If a number on the report cannot be clicked through to the tickets that produced it, you have built a spreadsheet with better fonts.

Permit limits belong in the same conversation. A disposal well that is permit compliant on paper can still be unable to take today's load because injection pressure has climbed, and a well with pressure headroom can be fully committed contractually. Routing that models capacity as one number sends trucks to a gate that turns them away, and the driver's wasted trip is billed to you.

Should you build custom or configure what you already own?

For a lot of operators the honest answer is do not build. If you have a few dozen wells, one commercial disposal contract and no owned or committed pipe, the routing decision has exactly one answer. The hauler's tickets plus a spreadsheet are proportionate, and a project will cost more than it recovers. Keep a market subscription for planning and spend the money on the wells.

Sourcewater is genuinely good at what it does, which is market intelligence on water, disposal capacity and infrastructure across a basin. If your question is where should we contract disposal next quarter, it earns its subscription. Enverus is the same category at larger scale with a data and analytics centre of gravity, and it is excellent for benchmarking and market context. Neither runs your dispatch, holds your permit and pressure limits per well with today's remaining headroom, or checks a hauler invoice against your own captured wait times. That is not a criticism, it is a description of the product category.

The build case appears when you have genuine choice in the network. Owned or committed pipe alongside trucking, several disposal outlets, or recycling competing with disposal for the same barrel. Roughly 100,000 barrels of water a day is where operators tend to cross the line, but the better test is whether anyone in the business could answer, this afternoon, which dispatches had a cheaper piped route available.

How do hidden costs get into the quote?

• Network data loading. Quoted as configuration, delivered as weeks of walking pads and reading contracts. Ask who does it and whose hours it consumes.
• Offline capture. Frequently priced as if it were a checkbox. Local storage, a sync queue and conflict resolution on a ticket that two people touched is a subsystem.
• The second basin. Different state, different reporting, different hauler mix. A quote scoped on one area of interest rarely survives the second without a change order.
• Live SCADA versus daily files. Reading a nightly export is a week. Consuming a historian in near real time, with tag mapping and calibration checks, is a different project.
• Third party billing. If you are the party charging others for interconnect or disposal, that is revenue software with dispute handling, not a report.
• Driver hardware and rollout. Devices, mounts, replacements, and the training week where dispatch runs both systems.

Ask for these to be priced explicitly and named in the statement of work, even at zero, so the omission is a decision rather than a surprise.

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

The working builds start with the network model and treat the exception report as the product. The screen that matters is not the ticket list, it is the short daily list of dispatches that should not have happened, in front of the coordinator who can still change tomorrow's. Everything else is bookkeeping around that.

They scope one area of interest with your top haulers and your own disposal wells, prove the loop, then extend. They put the pumper, the hauling coordinator and the midstream engineer in the room during design, because the three of them hold the routing logic between them and none of them has written it down.

They handle the money end from the first release. Hauler rate structures with per barrel, per mile and wait time components applied automatically to your own captured ticket, so invoice checking becomes an exception queue rather than a monthly argument. That single feature usually funds the rest.

And they settle ownership in writing before kickoff. You should hold the repository, the cloud accounts and the right to hire any other firm to continue. At Digital Heroes the client owns all three from the first commit. Your network model, with its permit limits, interconnect rules and commercial terms, is a description of how your water business actually works, and it should never live somewhere you cannot reach.