What a field ticket is, and what has to be true before it becomes an invoice
A field ticket is the crew's record of a job: the well, the date, what was done, how long it took, what was used, what was hauled, and a signature from the operator's representative on location. It is written by hand or on a tablet at the end of a shift, often with notes in the margin that matter more than the printed lines. It is the source document for everything the operator will be billed.
For it to become an invoice the operator pays without argument, six things have to line up. The ticket is signed by someone the operator recognizes. The service date is inside the submission window the master service agreement allows, commonly 60, 90 or 120 days depending on the operator. Every line item maps to a rate code on the MSA rate sheet, in the unit the sheet prices, a day rate as a day and an hourly rate as hours. The work is coded to an authorization for expenditure, an AFE, that is open on that well and matches the scope. The dollars are converted to whatever the operator's portal expects, cents or dollars, its own SKU, its own cost center. And the ticket has not already been billed.
Then it goes into the operator's accounts payable portal, OpenInvoice, Cortex, Ariba or the operator's own, which accepts it or rejects it in its own vocabulary. A rejection is not a note. It is a restart of the clock on money you already earned.
The seven places the money leaks
None of these are dramatic. That is what makes them expensive. Each one is a ticket that earned revenue in the field and then lost some or all of it in the office, usually without anyone noticing which one.
- The unsigned ticket. It cannot be billed, and the office finds out when the portal rejects it, weeks after the company man who could have signed it moved to another pad.
- The window. A ticket that sits in a pile past its 60 days is not late. It is unbillable without an operator exception, which means asking a favor to collect money you were owed. Oilfield service companies rarely get days sales outstanding below about 45 days (Trenegy, on the bid-to-bill process), and every rejected ticket pushes that number the wrong way.
- The wrong AFE. One ticket, two scopes of work, two open AFEs on the same well. Code it to one and the operator's AP team rejects it, or worse, pays it and disputes it later.
- The unit mismatch. A wireline unit billed in hours against a rate sheet that prices it per day. Guessing has an even chance of being wrong and a certain chance of sounding confident.
- The duplicate. The same ticket keyed twice, by two people or by one person on two days. If the portal catches it, that is a rejection. If it does not, it is a credibility problem with the operator next quarter.
- The short pay. The remittance arrives smaller than the invoice with no explanation attached. Nobody reconciles it line by line, and the difference is quietly written off.
- The retype. Every one of the steps above involves a person keying numbers from one screen into another. Published studies of human data entry put cell error rates between one and five percent, and people checking by eye catch only about half to four fifths of the errors that are there (Panko, on human error rates). Across industries, about one invoice in five is flagged for exception on its way through accounts payable (Ardent Partners, State of ePayables 2025).
Set that against the money. In the recorded run described below, nineteen tickets produced $137,313 of invoices in a modeled week. One percent of that leaking is larger than the entire clerical saving from automating the typing. The typing is not the case for this work. The leak is.
Why portals reject
Operators' portals reject for reasons that are almost always mechanical: a missing or unrecognized approver, a service date outside the MSA window, an AFE that is closed or does not match the well, a rate that does not match the contract, a line in the wrong unit, a duplicate invoice number, a missing attachment. The oil and gas data standards body publishes a formal vocabulary for invoice responses that most large operators' systems descend from (PIDX invoice response usage guideline). Read it once and the rejections stop looking random.
The useful consequence is that nearly every rejection reason can be checked before submission, on your side, by a rule rather than a guess. A signature is present or it is not. A date is inside a window or it is not. An AFE is open on that well or it is not. None of that needs intelligence. It needs the checks to run every time, on every ticket, before the portal sees it.
What the record shows
I built a fleet of agents to do this job across four systems, an ERP, a field ticketing system, a billing ledger and an operator's payment portal, and recorded the runs. The four systems are small stand-in programs, because you already own the real ones and no demo can have them. Their behavior is real: rate sheets, AFE coding, per-operator submission windows and the specific ways a portal rejects. Every company name and every number on the rate sheet is invented, the right shape for an East Texas wireline and pump-down shop and nobody's real contract, and the demo says so before it shows a figure.
In the run recorded on August 4, 2026, nineteen tickets went in. Sixteen went straight through to accepted invoices. Three stopped before submission, each with a specific question attached: one ticket was unsigned and the operator requires an approved signature; one carried a service date 68 days old against a 60-day window and needed an operator exception; one held a morning of perforating and an afternoon of produced-water hauling that mapped to two different open AFEs on the same well and needed an owner's decision on the split. One duplicate was closed without being billed twice. One short pay was detected in the pay cycle: an invoice billed at $6,666 paid at $6,400, a $266 difference nobody would otherwise have reconciled.
Scored against an answer key written before the run, the fleet got 19 of 19. Four recorded runs of the same configuration scored 19, 19, 19 and 18 of 19; the single miss was a ticket that should have been accepted and was held for a person instead, so nothing wrong reached an operator. The model spend for the run was $1.85, about ten cents a ticket, which is an order of magnitude and not a rate. Watch the recorded run, including the three tickets it refused to answer.
The refusals are the part to look at. A fleet that had submitted all nineteen would have scored worse, not better, because three of those tickets had no valid automated answer. An escalation with a specific question attached is a success. A wrong invoice confidently submitted is the failure.
Three checks that use no AI at all
Of the seven stages between ticket and portal, three make no model call: the triage that drops what nothing can recover before a token is spent, the gate that checks signature, window, AFE and blocking price flags, and the submission step that converts dollars to cents and AFEs to cost centers. That is the design decision worth defending, and it is the one most automation vendors get backwards.
"Is this ticket inside its 90-day window" is a subtraction. "Is it signed" is a boolean. "How many cents is $4,200" is a multiplication. Spending a model on any of them costs money on every ticket, adds latency, and introduces the one failure a compliance check must not have: the ability to be argued out of its answer. A gate that is arithmetic cannot hallucinate a signature and cannot be persuaded that 94 days is inside 60. The models do the reading, the pricing and the coding, where judgment is real, and refuse when it is not.
Do the arithmetic before you buy anything
Here is the honest version of the labor math, using the placeholder inputs the demo ships with: 150 tickets a week, twelve minutes a ticket today, a loaded rate of $34 an hour. The clerical saving lands near $3,700 a month. My operate-and-maintain engagement starts at $3,500 a month and a build starts at $18,000, so on typing alone the engagement roughly breaks even and never repays the build. A controller does that sum in four seconds, and a fast office at six minutes a ticket makes it worse.
That is not a flaw in the arithmetic. It is the reason the labor saving is the floor and never the pitch. The case is the leak: the short pay reconciled, the ticket rescued before its window closed, the duplicate never billed twice, the rejection that never happened. If your real answer is three minutes a ticket and forty tickets a week, you do not need this, and I would rather say so in an assessment report than build you something that does not pay.
A checklist for your own ticket pile
- Count last month's tickets that were rejected by a portal, and the reason the portal gave for each.
- Count the tickets submitted within ten days of the end of their window, and any submitted after it.
- Pull every remittance smaller than its invoice, and find out who reconciled it and when.
- Find any invoice number submitted twice in the last year.
- List every line item billed in a unit the MSA does not price it in.
- Check how many tickets reached the office unsigned, and how long it took to get a signature.
- Total the invoiced dollars for the month, and take one percent of it. Compare that to the clerical hours.
If the first six numbers are all zero, your office is unusually good and you should keep it. If any of them is not, that is the number an assessment quantifies against your real volumes.
Questions buyers ask
Does this replace OpenInvoice or the operator's portal?
No. The portal is the operator's system and it stays. What changes is what reaches it: an invoice that has already been priced against your rate sheet, coded to a real AFE, checked for a signature and a window, and converted to the portal's own units. The portal still gets the final say. The point is that it says yes the first time.
What happens to a ticket the system cannot code?
It stops, with a specific question attached, and a person answers it. An unsigned ticket cannot be signed by software. A ticket outside its window cannot be brought back. A ticket with two scopes of work on two open AFEs needs an owner's decision about how to split it. In the recorded run, three of nineteen tickets stopped this way, and the scorecard counts submitting one of them as a failure, not a success.
How is accuracy measured?
Against an answer key written before the run, by someone who knew what each ticket should become. Four recorded runs of the same configuration scored 19 of 19, 19 of 19, 19 of 19 and 18 of 19. The one miss was a ticket that should have been accepted and was held for a person instead, so nothing wrong reached an operator. I publish the spread and the direction of the miss, not a single best number.
What does it cost to run per ticket?
The recorded run of nineteen tickets spent $1.85 on model calls, about ten cents a ticket, on a rate sheet and ticket mix built to look like an East Texas wireline and pump-down shop. Treat that as an order of magnitude, not a rate. A month of your own tickets would tighten it, and the engagement prices are fixed and published regardless.
Is my rate sheet or my operators' data exposed to anyone?
Your master service agreement and your tickets are your data, held under the data handling terms published on this site, and the system you receive runs against your own systems rather than a shared platform. The demo on this site uses an invented rate sheet and invented company names for exactly that reason, and says so before it shows a number.