Search “
best ERP for oil and gas industry” and you get listicles. Ten vendors, a paragraph each, a comparison table nobody validated, and a link to book a demo with whoever paid for the placement.
That’s not how the decision gets made.
The companies that choose well do something different. They work out what their operation needs before they look at a single vendor. By the time they call a vendor, most of the market has already been ruled out by two questions.
Here is the sequence that works.
Start with what breaks
Before you evaluate anything, write down the five things that go wrong most often in your current setup. Be specific. Not “billing is slow.” Something like: “invoices go out 18 days after the job, and three to five tickets go missing every month.”
That list is your requirements document. It’s more useful than any feature comparison, because it’s yours.
Common entries for an oilfield service or rental company:
- Tickets that never make it from the field to billing. Industry average leakage is 2 to 4 percent of revenue.
- Invoices that miss the operator’s submission window and become unbillable, not just late.
- Month-end close that runs into week three because the data is still being chased.
- Nobody can say what a specific customer or job actually earned.
- Equipment availability that lives in a dispatcher’s head and a whiteboard.
The first question: replace or extend
Most companies looking for oil and gas ERP software already run an ERP. QuickBooks, Sage, Business Central, NetSuite, sometimes SAP.
So the real question isn’t which ERP to buy. It’s whether the gap you have is a finance gap or a field gap.
A finance gap means your accounting system can’t do the job. It won’t consolidate entities, it won’t handle your reporting requirements, your auditors keep flagging it. That’s an ERP replacement, and it’s a big project.
A field gap means the accounting is fine and everything upstream of it is held together with spreadsheets. Ticketing, dispatch, equipment status, rental billing, job costing. That’s the far more common situation, and replacing your ERP won’t fix any of it.
Answering this one question eliminates most of the vendor list before you’ve taken a single call.
The second question: how specialized is your fleet
We ran a pattern analysis across two years of our own closed deals. Geography barely predicted anything. Whether a company sat in the Permian, the WCSB, or the DJ Basin had almost no bearing on implementation speed or first-year results.
Product specialization predicted everything. Single-specialization rental shops, generators for frac power, downhole tools, water transfer, frac valves and iron, implemented faster and got more out of the system than diversified fleets did.
The reason is the data model, not the basin. A specialized fleet has consistent units, consistent rates, and consistent job shapes, so the system fits it on day one. A diversified fleet needs configuration work before anything fits.
This matters when you evaluate. Ask every vendor which specialization they have implemented most often, and ask to speak to that customer.
What to check in a demo
Vendors demo their strongest workflow. Your job is to make them demo yours.
Bring one real job from last month. Pick a messy one. A multi-well pad, a rate that changed mid-job, a piece of equipment that came back needing recertification. Ask them to build it in front of you.
Then check these:
- Rental billing by day and unit, including subrentals and cross-hires. Not products and hours.
- Multi-well allocation, with master and sub-invoices that tie to the operator’s AFE.
- Offline field capture that works with no signal and resolves conflicts when two crews edit the same record.
- Native submission to the operator portals you use, OpenInvoice or Cortex or whatever your customers require.
- Job costing that shows margin by customer and by job, not just revenue.
- Equipment lifecycle states: out, dirty, cleaning, recertification, available.
- Accounting integration to the system you already run, with a clear boundary about which system owns which data.
If a vendor can’t show six of those seven with your job on the screen, they’re selling you a roadmap.
The questions that reveal more than the demo
- What happens when two crews edit the same equipment record while both are offline?
- How long from contract to our first live field ticket, and what does your team do during that time?
- When an operator changes its portal requirements, is that a product update or a project we pay for?
- Which customer closest to our profile can we call without you on the line?
That last question separates real references from managed ones.
What the price tag leaves out
The license fee is the smallest number in the decision.
Implementation time is the real cost, and it varies enormously by how well the system fits your operation out of the box. Configuration that takes weeks in one system takes months in another.
Then there’s the cost of not deciding. A rental company running 1,000 units with paper-driven billing loses somewhere between $480K and $720K a year to leakage, write-offs, mandate penalties, and DSO drag. That’s the number to weigh the license against, not the license against zero.
Work out your own version of that number before you negotiate. It changes how the conversation goes.
Where most evaluations go wrong
Three failure patterns show up in almost every evaluation we watch go sideways.
Buying on feature count. The longest feature list usually belongs to the system with the shallowest implementation in your specific workflow.
Leaving the field out of the decision. If the techs won’t use it, nothing else matters. Get a tech into the demo and watch his face.
Treating it as a finance project. The finance team feels the pain most visibly at month end, but the pain starts at the ticket. A project owned only by finance tends to buy reporting and skip capture.
The short version
Write down what breaks. Decide whether it is a finance gap or a field gap. Match the vendor to your specialization. Make them build your ugliest job in the demo. Price it against your cost of inaction, not against zero.
Do that and the shortlist is usually two names, not ten.
What about building it yourself
Some companies decide to close the gap with internal development, extending the ERP with custom modules. It works. It also costs more than the business case assumed, every time.
The build cost isn’t the developers. It’s the maintenance: every ERP version upgrade, every new operator portal requirement, every regulatory change, and the fact that the two people who understood the customization will eventually leave. Custom code that runs the billing for a $50M service company becomes a permanent liability on the operations team, not a one-time project.
Buy the industry system if the requirement is standard across your peers. Build only where you have something proprietary.
The framing that actually works
The choice is not RigER instead of your ERP. It is RigER upstream of it.
The clean architecture looks like this. The field ops system is the source of truth for operational events: what happened, when, on which unit, for which well, approved by whom. The ERP is the source of truth for posted financials: the general ledger, the statutory reporting, the audit trail. One system feeds the other, on a daily cadence rather than a month-end scramble.
Confusion about which system owns which data is the root cause of nearly every reconciliation headache an OFS controller deals with. Clarity about it is what makes a five-day close possible.
RigER integrates with QuickBooks, Sage, Business Central, and NetSuite. We have no plans to compete with them.
How to run the evaluation?
Four questions worth asking any vendor, generic or specialized:
- What happens when two crews edit the same equipment record while both are offline? A specific answer means the architecture handles it. A pause means it doesn’t.
- Show me a multi-well invoice with allocation by well, generated from field data. Not a mockup. A real one.
- Which operator portals do you submit to natively today? Which need a file export?
- When Pioneer changes its requirements next year, is that a product update or a project I pay for?
The answers separate the two categories faster than any feature matrix.
The generic ERP is not the problem. Asking it to run the field is.
