Every oilfield service company that grows past about $10M in revenue has the same meeting. Someone from finance says the current system cannot keep up. Someone from operations says the crews won’t use another app. And someone asks the question that starts a six-month evaluation: do we buy a real ERP, or do we buy something built for our industry?
The question is fair. The framing is wrong.
A generic ERP and an
oilfield ERP are not two versions of the same product. They were designed by different people, for different jobs, and the gap between them shows up in the exact places where oilfield service companies lose money.
What a generic ERP was built to do
SAP, Oracle, NetSuite, Sage, Microsoft Dynamics. These are excellent products. They were built to give a company financial control: general ledger, accounts payable, accounts receivable, period close, audit trail, statutory reporting.
They are deliberately rigid, because GAAP, IFRS, and SOX demand rigidity. Periods lock. Corrections require approvals. Precision is measured to the cent. The cadence is monthly.
That design is correct for the job it does. It’s also the reason the same system struggles the moment you ask it to run a frac valve yard.
What the field actually requires
An oilfield service company captures its revenue events somewhere very different from an accounting department. A tech at a wellsite at 11 PM, with no cell signal, wearing gloves, recording what happened on a job: hours, equipment, consumables, a customer signature.
That work requires the opposite design choices. Flexible corrections instead of locked periods. Practical estimates instead of cent-level precision. Near real-time capture instead of a monthly cadence. Exact line-item quantities instead of aggregated GL postings.
Ask one system to do both jobs and you get the compromise every OFS controller recognizes: a rigid core system, and a growing collection of spreadsheets around it that hold everything the core system could not.
Every workaround spreadsheet in your AP department is a diagnostic. It tells you exactly which business process your ERP was never built for.
The five places the gap shows up
1. Rental billing that runs on days, not units
Generic ERPs bill for products sold or hours worked. Rental revenue is neither. It accrues by day, by unit, against a rate that may change mid-job, on equipment that might be subrented from a third party and cross-hired to a fourth. Standing up that model in a generic ERP means custom development and, usually, an offline
spreadsheet that tracks what the ERP cannot.
2. Multi-well allocation
One operator, six wells on a pad, three service lines. The operator expects an invoice that ties to their AFE, allocated by well, in the format their AP portal accepts. Generic ERPs handle one customer and one invoice cleanly. The allocation logic is where the AR clerk loses six hours per pad in Excel.
3. Equipment lifecycle, not just asset value
Your ERP knows what a valve cost and how it depreciates. It doesn’t know the valve went out dirty, came back for cleaning, failed recertification, and is now unavailable to rent. That lifecycle state governs your utilization, your maintenance schedule, and whether you can say yes to the next job.
4. Operator mandates and portal formats
Pioneer’s RFID requirements. OpenInvoice and Cortex routing. Aramco’s vendor portal. These are supplier obligations with deadlines attached, and they change. A generic ERP treats them as an integration project each time. An industry system treats them as a product roadmap item, because every one of its customers needs the same thing.
5. Offline field capture
Half the Permian and most of the WCSB has no reliable signal at the wellsite. Field capture has to work with no connection, resolve edit conflicts when two crews touch the same record, and timestamp both the field action and the sync. Generic ERP mobile modules are built for a warehouse with Wi-Fi.
![image]()
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.
