Oil and Gas Field Operations Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does offline first get underestimated so often?

Every proposal says offline. Very few price it honestly, because working offline is easy and reconciling offline edits is hard. A crew lead builds a ticket at a pad with no signal, a district admin opens the same ticket in the yard because the company man called ahead, and both save. Whichever write lands second wins, and a signed line item disappears.

This bites harder in oil and gas than in most field trades for one reason: the ticket is the money and it carries a signature. A signed ticket is a financial record, so a sync that overwrites one is not a data quality issue, it is a disputed invoice thirty days later with the operator holding a copy that does not match yours. The related failure is revision handling. Teams build edit-in-place because it is simpler, then discover that a corrected ticket has no history and the company man's signature now sits on content he never saw.

Make three things contractual before kickoff. A signed ticket is immutable and corrections are new revisions with a link to the original. Conflict resolution is defined per field rather than last write wins, with genuine conflicts raised to a queue rather than resolved silently. And the developer demonstrates the conflict case on real hardware during the pilot. Ask exactly what happens when two users edit the same ticket while disconnected. Teams that have not shipped offline first software will discover that problem on your budget.

What goes wrong when price books and customer coding profiles get migrated?

The tickets are not the hard part of this migration. The reference data is.

Your rates live in a spreadsheet with a name like MSA_Rates_v9_FINAL, and there is a v7 still in circulation because an amendment landed midyear and half the office never got the update. Import that as is and the app confidently prices work at rates the operator never agreed to, which is worse than a blank rate column because nobody double checks a number the system produced. Customer specific discount tiers, mileage bands, standby rates and fuel surcharges each multiply the ways this goes wrong.

Coding profiles are the second half. Which fields are mandatory, what format an AFE number takes, which cost centre and well list is current, and which PO line reference a major expects all differ per customer and sometimes per pad. Most companies have never written these down, they live in the memory of one district admin who knows that a particular operator rejects anything without a well API number.

Load and verify all of it before a single crew touches a tablet. Reconcile every rate line against the executed MSA rather than against the spreadsheet, and have the admin who knows each operator's quirks sign off on that customer's validation profile. Clean reference data is what makes the field experience fast, and a slow or wrong first week in the field is how a rollout dies.

Why do OpenInvoice and accounting integrations break after launch?

Submission integrations rot in predictable ways. An operator changes its required coding, adds a mandatory field, or moves a well onto a different AFE, and invoices that submitted cleanly last month start bouncing. The rejection arrives as a code, not as an explanation, and each cycle adds weeks to payment on that ticket.

Accounting integrations fail more quietly. A journal posting to WolfePak or QuickBooks that silently skips a ticket because a cost centre no longer exists produces a month end where tickets, invoices and the general ledger disagree, and your controller finds it during close rather than on the day it happened.

Three defences. First, treat every rejection as data rather than as an email: parse it, categorise it, and show aging by customer and by reason so a new rejection pattern is visible within days instead of at quarter end. Second, monitor posting counts, not just posting errors, because a batch that posts nine of eleven journal entries without complaint is the dangerous case. Third, keep validation rules as editable data per customer so a coding change is an afternoon for your admin rather than a change request and a release. Ask for integration receipts by name before contracting, because these integrations are half the value and the least forgiving part of the build.

What happens when compliance is not wired into dispatch?

Plenty of these platforms digitise the JSA and the certification list and still let a crew with an expired H2S card get dispatched to a sour location. That is because compliance was built as a records module rather than as a constraint on the dispatch board.

The consequences are not evenly distributed. An expired cert discovered by an operator's compliance team before an MSA renewal is a commercial problem. The same cert discovered at a gate is a shut-down location and a phone call you do not want. Veriforce, ISNetworld and Avetta reviews then compound it, because a good safety record with scattered documentation still reads as a weak submission.

Wire the qualification matrix into assignment. Every employee carries their qualifications with expiry dates, and the board checks them at the moment of assignment, so putting a hand whose well control cert expires in nine days on a two week job raises a flag before the truck leaves the yard. DOT hours belong in the same logic rather than only in the ELD system, since a driver who cannot legally complete the shift is a dispatch problem, not a payroll one. And capture JSAs on the same device as the ticket so the safety record attaches to the job rather than to a truck door pocket. The software organises the evidence. Your safety programme still owns the regulatory responsibility, and any developer who blurs that line is overselling.

Should you build custom or configure what you already own?

Some operators should not build, and it is worth naming them. If you run a single service line out of one or two yards with under ten crews, standard rate sheets and one or two operator customers, FieldCap style ticketing plus QuickBooks is defensible and cheap. If your pain is pumper routes and gauge sheets rather than service tickets with negotiated price books, look hard at GreaseBook before you talk to anyone about custom software, because it is built for exactly that work.

There is also configuration you almost certainly have not done. WolfePak and QuickBooks both carry job costing structures most service companies never set up properly, and a week with your accountant will answer more margin questions than a first dashboard will. Enverus OpenInvoice has validation feedback your office may be ignoring in favour of chasing rejections by email.

The build signals are concrete: three or more districts, thirty plus crews, multiple service lines with different ticket formats, per customer MSA price books that change midyear, a rejection rate you track in a spreadsheet because it hurts, and days sales outstanding above sixty. If three or more describe you, configuration has run out. You are already paying a custom software price every year in float and labour while owning nothing durable for it.

How do hidden costs get into the quote?

Five items go missing routinely, and all five are foreseeable.

Offline architecture with real conflict handling, which is design work on day one rather than a feature. Price book and coding profile preparation, which is your data cleanup but must sit in the plan with named owners and dates. Each accounting and operator system integration priced separately, because one submission portal and one general ledger are two projects, not one line. Hardware, including rugged tablets, mounts, cases and provisioning across districts, plus the spares you will need when one goes under a truck. And the parallel run, since rolling out one district at a time with two to four weeks of paper alongside is real coordination time for your own staff.

The honest bands from Digital Heroes delivery experience are $60,000 to $130,000 for a focused first release over 12 to 16 weeks covering digital tickets with your price books, offline capture with signatures, an approval queue and one integration, and $150,000 to $400,000 for a full platform phased over 6 to 12 months. A quote materially under that with the same scope has usually left out the offline work, the hardware, or both.

What separates an oilfield build that works from one that fails?

The successful rollouts ship the ticket to cash path first and let it fund everything else. Digital tickets, price book resolution, signature capture, approval and one invoicing integration is a coherent release you can measure, because cash landing days after the work instead of weeks is visible in your own aging report inside a quarter. The projects that fail try to launch dispatch, equipment maintenance, compliance and payroll export together and are still in testing when the field has lost interest.

The second marker is district by district rollout with paper running alongside for two to four weeks each. That parallel period is where you find the pricing rule nobody documented and the operator who insists on a different ticket layout. It feels slow and it is the cheapest insurance in the project.

The third is domain literacy in the developer. Make them whiteboard the ticket data model in the sales conversation: header, line items, price book resolution, AFE and PO coding, approval states, and revision history after signature. If they cannot explain why a signed ticket must be immutable, keep looking. Then settle ownership in writing before the first invoice. You should own the source code, the database and all field and compliance data outright, in repositories you control, because your price books, coding rules and compliance history are competitive assets and renting them back from a vendor is a worse deal than the paper you started with.