You're managing wells against numbers that already changed

A field ticket gets written at the wellsite on a warm summer Wednesday. Not by anyone on your payroll, but by the supervisor of the workover crew you called out, documenting two days of rig time, crew hours, a rental pump, fluid consumed, and the hot oiler they subcontracted for half a day. Your company man signs it. Then it travels.

It comes back as a photo, a PDF exported from a portal, or a piece of paper carried in at the end of a hitch, and it lands in an inbox or a stack on a desk. By the time somebody in the office has worked out which of your wells the supplier meant, which cost component the charge belongs to, and whether the rate matches what was agreed, the supplier's invoice has already cleared.

None of that work happens in your systems. It's someone's judgment, supported by reference files that live outside your ERP. That's Shadow ERP™: the layer of work your business depends on that your systems were never built to hold.

The usual framing is that this is a paperwork problem and the fix saves time. Both are true, and neither is the real cost. The real cost is that the numbers you run a well on are always describing a moment that has already passed.

A field ticket has to be right three times

Coding a ticket and entering it are different acts. Entering it is keystrokes. Coding is deciding where the money lands, and that means answering three questions your ERP can't answer on its own.

Which well is this? The supplier's name for a location and yours are frequently different. Resolving it means knowing your own well master well enough to translate.

Which AFE was open? Not which authorization for expenditure (AFE) is open now. Which one was authorized and active on the date the work was done.

What was the rate? The price book in force on the service date governs. A rate that changed last month doesn't apply to work performed before it changed.

All three are point-in-time questions, which is what makes them slow to answer by hand. The right answer depends on when the work happened, not when the paperwork got processed.

Get one wrong and nothing breaks. A ticket coded to the wrong well, or paid at a rate that was never contracted, produces a number that looks completely fine.

Why the AFE is always looking backward

Every coded ticket is a charge against an AFE. That's the mechanism: the AFE authorizes an amount, and the tickets are how actual spend accumulates against it. So the AFE only tells you something useful if the coding is current.

When coding runs behind, it isn't. Committed and actual spend reflect the tickets that happen to have been processed, not all the work that really happened. The tickets still sitting in the queue are real costs the budget can't see.

So an operator approaching the ceiling on an AFE learns about it after the fact. The invoice cleared, so it was paid. The conversation about whether to keep going, revise the estimate, or stop happens with hindsight instead of the runway to make a call.

And the off-contract rate from a moment ago? Nobody catches that either. The check that would have caught it runs after the payment has already gone out, if it runs at all.

The answers already exist

Here's what's strange about those three questions. Your well master knows your locations. Your AFEs are approved and dated. Your price book carries rates and effective dates.

The reason a person has to answer them is that the ticket arrives as an image and the answers live in systems that can't see it. So a coordinator ends up standing between the two, holding one in their head while they look up the other. Nobody was hired to be the integration.

That's the gap. The data is there and so is the expertise. The connection between them was never built.

Build the connection

Start by turning the ticket into a record instead of an image. Reading it is genuine work. Photo, PDF, portal export, handwriting done fast in bad weather, all of it has to land in your system as data before anything else is possible.

Once it does, and once the platform holding it can reach your well master, your AFEs, and your price book, the lookups have somewhere to run. An AI agent resolves the well, proposes the cost component, checks the rate as of the service date, and posts to your ERP with the original ticket image attached to the transaction.

Where your coordinator sits in that is a setting you control. Review every ticket before it posts, let clean ones through and surface only the exceptions, or draw the line somewhere specific, like a supplier who always gets a look or anything over a dollar threshold. Operators land in different places and they should.

Either way, what arrives on the coordinator's desk is a ticket with a proposed well match, a proposed cost component, a rate check already run, and a flag on the one thing that didn't reconcile. The unmatched well and the rate that came in off-contract are the part of the job that needed their judgment all along, and now they show up with the ticket, the AFE, and the coding history already attached.

And because the ticket is data, the AFE stops being a monthly reconciliation. The number your team manages against can be current.

What the auditor gets shown

Sooner or later somebody asks you to trace a charge back to whatever authorized it.

Right now that answer is often a person's memory plus an email thread where somebody confirmed the rate looked right. Somebody did verify it. The verification just wasn't the kind of thing the system could hold onto.

The alternative is a posted transaction with the source ticket image linked to it, and, where an AI agent did the work, a run you can open and read step by step: what it checked, what it proposed, what a person decided, and what the run cost. The record doesn't claim it was handled correctly. It shows how.

Start where the lag costs the most

Shadow ERP lives in the spaces between systems, so closing it is a matter of closing spaces rather than consolidating systems. Your ERP keeps the general ledger, which is what it was built for. The portals your suppliers submit through keep working the way they work. What's new is the layer in between, the part your team has been holding together by hand, now built as software you can see, change, and audit.

Every upstream operator has a workflow where the delay between the work happening and the number showing up is expensive. For most, field tickets are it, because they sit directly between field activity and the budget the business is managed against. That's the one to start with. One workflow, closed properly, with the trail intact.

That's the argument, and here's the pitch. Nextworld is the platform where the software in between gets built, connected to your field and your ERP, governed the same way as everything else you run. We don't touch your ledger, and we don't ask your suppliers to standardize their paperwork. If the gap above is one you recognize, closing it is what we do.