Oil and Gas Field Operations Software: A Buyer's Guide for Operators Still on Paper

Why field operations software makes or breaks an oil and gas services operator

Here is a Monday morning that will feel familiar. A district admin in Midland is keying Friday's work into QuickBooks from a stack of three part carbon field tickets. Some are smudged with drilling mud. Two are missing because they are still under the seat of a Kenworth that will not be back from location until Thursday. The price column comes from a spreadsheet named MSA_Rates_v9_FINAL, except the operator amended the MSA last month and half the office is still quoting v7. Dispatch is a whiteboard and a group text. The Veriforce binder is two drawers of a filing cabinet, and nobody is certain whether the night crew's H2S certs expired in March or May.

Run the math on that office. A services company doing $30 million across five yards produces somewhere between 15,000 and 40,000 field tickets a year. Each one is written by hand at the wellsite, signed by a company man, driven back to the yard, keyed by a clerk, priced from a spreadsheet, invoiced, then submitted through the Enverus OpenInvoice portal where the operator's coding rules get their first real look at it. When we audit this workflow during discovery at Digital Heroes, the pattern repeats: cash lands 60 to 90 days after the work, a meaningful slice of tickets get disputed or never billed at all, and two to four full time back office salaries exist purely to move paper.

At multi district scale, this software decides your DSO, your dispute rate, and whether the next operator audit costs you a master service agreement. The real choice is between off the shelf tools built for someone else's business and a platform built around your ticket.

Problem one: signed tickets ride around in truck cabs while your cash waits

The ticket is the money, and in a paper operation the money spends its first week of life as carbon paper in a truck. A wireline crew finishes Tuesday, the company man signs at 2 am, and the ticket physically travels: cab, yard, admin desk, pricing, invoice, OpenInvoice submission. Ten to fourteen days is a normal lag before the operator even sees an invoice, and their 45 or 60 day payment clock has not started yet.

GreaseBook is built for pumpers logging production data, not service tickets with negotiated price books. FieldCap and similar generic ticketing tools get you a digital form, but they struggle the moment your pricing has customer specific discount tiers, mileage bands, standby rates, and fuel surcharges, so field hands write "see office" in the rate column and the rekeying continues.

A custom build treats the ticket as a live financial record from the first keystroke. The crew lead builds it on a tablet at the wellsite, offline, with your actual price book resolving rates line by line. The company man signs on the glass, the app stamps GPS position and time, and when the truck rolls into signal the ticket syncs, generates a PDF that mirrors your existing ticket format, and lands in an approval queue. Companies we have built this for submit to OpenInvoice inside 48 hours of the work instead of two weeks.

Problem two: AFE and PO coding errors bounce invoices for weeks

Every operator wants tickets coded their way: an AFE number here, a cost center and well API number there, a PO line reference for the majors. On paper, the crew lead writes whatever the company man mutters at 2 am. Three weeks later the invoice bounces out of OpenInvoice with a rejection code, and your office is emailing a drilling clerk in Houston asking which AFE the stage 14 work belonged to. Each rejection cycle adds 15 to 30 days to payment on that ticket.

Off the shelf ticketing apps cannot fix this because the coding rules are not theirs to know. The rules live per customer, per contract, sometimes per pad.

A custom platform encodes them. Each customer gets a validation profile: which fields are mandatory, what format the AFE number takes, which well list is current. Reference data syncs from the customer where an interface exists, or gets maintained by your office once instead of guessed in the field forever. A ticket cannot be closed and signed until it passes its customer's rules, so the invoice that reaches OpenInvoice is already coded the way the operator's AP system expects. Rejection handling becomes a dashboard with aging, not inbox archaeology.

Problem three: compliance lives in binders and expired certs stop work

Veriforce, ISNetworld, and Avetta audits do not care that your safety record is good if the documentation is scattered. JSAs get filled out at the tailgate and filed in a truck door pocket. H2S, well control, and forklift certs live in a spreadsheet someone updates quarterly. DOT hours for your CDL drivers live in the ELD system and nowhere else. When an operator's compliance team pulls your file before renewing an MSA, you spend two weeks assembling proof, and one expired cert on a dispatched crew can shut down a location and sour the relationship.

Safety apps like SafetyCulture or KPA Flex digitize the form but not the operation. They do not know who is dispatched where tomorrow, so they cannot stop a crew with a lapsed cert from being sent to a sour gas location.

In a custom platform, compliance is wired into dispatch. Every employee carries a qualification matrix with expiry dates, and the dispatch board checks it: assign a hand whose H2S cert expires in nine days to a two week job and the board flags it before the truck leaves. JSAs are completed on the same tablet as the ticket and attach to the job record. When the Veriforce audit comes, the export is a filter and a button.

Problem four: dispatch is a whiteboard and your iron is a rumor

Multi yard scheduling on a whiteboard means the Williston yard does not know Dickinson has an idle pump truck 40 miles from the job Williston just declined. Nobody can say what utilization on the coil units actually is, so equipment decisions run on gut feel and the loudest district manager wins the capex argument.

Mainstream field service tools like ServiceTitan and Jobber are built for residential trades: two hour appointment windows, one tech, one van. They cannot model a spread of three trucks, a crew of five with specific certs, and a job measured in days that extends at the operator's whim at midnight.

A purpose built dispatch board treats crews and equipment as separate first class objects paired per job. Equipment carries hour meters fed by the tickets themselves, so a pump crossing its service interval automatically raises a maintenance work order. District managers share one board, and the ops VP finally sees utilization by asset class across yards, which is the number that should drive the next iron purchase.

Problem five: every ticket gets keyed three times before it becomes money

The same data gets typed into the ticket, then the invoice, then QuickBooks or WolfePak, then hand entered into OpenInvoice, and the crew hours from that ticket get keyed a fifth time into ADP for payroll. Five entries, four chances to mismatch, and a month end close that takes your controller ten days because reconciling tickets to invoices to the GL is manual.

Point solutions cannot collapse this because each owns only its silo. In a custom platform a ticket is entered once and becomes everything downstream: the invoice, the OpenInvoice submission via API or formatted upload, the journal entry pushed to WolfePak or QuickBooks, and the hours file for ADP. Your controller reviews exceptions instead of keying volume. In our delivery experience the back office conversation changes within one quarter of go live, usually by redeploying clerks to collections and dispute resolution, which is where the money actually is.

What a custom field operations platform costs and how long it takes

These numbers come from Digital Heroes delivery experience across 2,000+ projects, not a vendor brochure. A focused first release typically runs $60,000 to $130,000 and ships in 12 to 16 weeks. For this category that usually means digital field tickets with your price books, offline capture with signatures, an approval queue, PDF and invoice generation, and one accounting or OpenInvoice integration. That scope alone removes the truck cab lag and most of the rekeying.

A full platform, meaning dispatch, equipment and maintenance, the compliance and qualification engine, per customer coding validation, payroll export, and dashboards, lands between $150,000 and $400,000 phased over 6 to 12 months. Sensible teams ship the ticket to cash path first because it funds the rest.

What pushes cost up in this category specifically: true offline first architecture with conflict handling, because wellsites have no signal and two people will eventually edit the same ticket; the count of accounting and operator systems you integrate; price book complexity across MSAs; the depth of the DOT and safety modules; and hardware rollout if crews need rugged tablets provisioned across districts.

Build vs buy: an honest line in the sand

Off the shelf is genuinely right in specific situations. 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. A production focused operator whose pain is pumper routes and gauge sheets should look hard at GreaseBook before talking to anyone about custom software.

The signals that it is time to build are concrete. Three or more districts. Thirty plus crews. Multiple service lines with different ticket formats. Per customer MSA price books that change midyear. An OpenInvoice rejection rate your office tracks in a spreadsheet because it hurts. DSO above 60 days. A compliance audit that consumed more than a week of someone's life. If three or more of those describe you, our position is plain: you have outgrown configuration, and you are already paying a custom software price every year in labor and float while getting nothing durable for it. The build pays for itself out of DSO and leakage, and you end up owning an asset instead of renting a workaround.

How to choose a developer for oil and gas field operations software

Vet on specifics, because a generic app shop will burn your budget learning your industry.

First, make them whiteboard the field ticket data model in the sales conversation: ticket header, line items, price book resolution, AFE and PO coding, approval states, and revision history after a company man signature. If they cannot explain why a signed ticket must be immutable and corrections must be new revisions, keep looking.

Second, demand offline proof, not an offline checkbox. Ask exactly what happens when two users edit the same ticket while disconnected and how the sync queue resolves it. Teams that have not shipped offline first software will discover this problem on your budget.

Third, ask for integration receipts: Enverus OpenInvoice submission, WolfePak or QuickBooks journal posting, ADP or similar payroll files. The integrations are half the value and the least forgiving part of the build.

Fourth, test their compliance literacy. They should already know what Veriforce operator qualification means, why DOT hours belong in dispatch logic, and why every safety record needs an audit trail. You should be explaining your business rules to them, never the regulatory landscape.