How long should it take to invoice a field ticket?

There is no structural reason routine work needs more than a handful of days. The floor is set by your signature process and your invoicing run, not by anything else. Companies capturing tickets in the field and validating them automatically bill in days; companies moving paper through trucks and manual entry rarely get below two weeks.

How do I measure my own billing cycle?

Take fifty recently billed tickets and record four dates: work performed, ticket entered, invoice generated, invoice accepted. That gives you three intervals. Look at the median and the ninetieth percentile of each; the gap between them tells you whether you have a systemic problem or an exception-handling problem.

Field ticket to invoice: where the days actually go

Q: Which part of the ticket-to-invoice cycle takes longest?

Usually the gap between work performed and the ticket reaching the office, because it is a logistics problem rather than an administrative one. Crews work multi-day hitches and paper travels at the speed of the truck carrying it. It is also the block most improved by capturing at the point of work.

Ask a services company how long it takes to bill a job and you will usually get a confident answer that turns out to be wrong by several days. Not because anyone is being dishonest, but because the process has more steps than anyone holds in their head, and the delay is distributed across all of them rather than concentrated in one obvious bottleneck.

Here is the full chain. Most operators are surprised by how many transitions there are.

The actual sequence

Work is performed. The clock starts here, and this is the date your contractual submission window runs from, not the date you decided to bill it.
The ticket is completed. Sometimes on location, sometimes at the end of the shift, sometimes at the yard the next morning from notes.
The customer signature is obtained. Requires the right person to be present and willing. If they have gone home, this waits.
The ticket physically or digitally reaches the office. Photographed and texted, carried in on Friday, dropped in a tray, emailed as a scan.
The ticket is entered into your system. Someone types what the field wrote.
The ticket is reviewed and approved internally. A supervisor or controller confirms it looks right.
The invoice is generated. Ticket data becomes an invoice in your accounting or ERP system.
The invoice is submitted to the customer. Increasingly this is not email. It is a portal.
The invoice is accepted by the customer’s system. Which is a separate event from submitting it, and can fail.

Nine steps. Your DSO clock, from the customer’s perspective, usually does not start until step nine. Everything before it is time you are financing.

Where the days concentrate

Between work performed and the ticket reaching the office is typically the largest single block, and it is almost entirely a logistics problem rather than an administrative one. Crews work multi-day hitches. Paper travels at the speed of the truck carrying it. A ticket completed Tuesday on a location three hours from the yard may not enter your building until the crew rotates out on Friday.

This block is also the one most improved by capture at the point of work. If the ticket is created on a phone in the field, steps three and four collapse into step two, and several days come out of the cycle without changing anything about how the office operates.

Between entry and approval is the block most affected by exception handling. Clean tickets move through quickly. Tickets with a missing signature, an unclear quantity, or a rate nobody recognizes stop moving and wait for a human to resolve them. Companies almost always underestimate this block because they average across all tickets rather than noticing that a minority of tickets consume the majority of the elapsed time.

Between invoice generation and customer acceptance is the block most companies do not measure at all, and it has grown as e-invoicing platforms have become standard in oil and gas. Submitting through an operator’s portal (OpenInvoice, Cortex, Ariba, or whatever your largest customers have standardized on) introduces its own validation rules, its own rejection conditions, and its own queue. An invoice rejected by a portal for a coding error is not a paid invoice, and often nobody on your side finds out for days.

The compounding effect nobody plans for

Each step has a probability of sending the ticket backwards. A missing signature returns it to step three. A quantity question returns it to step two. A portal rejection returns it to step seven.

This matters more than the forward-path duration, because rework is not evenly distributed. A ticket that goes backwards once has a meaningfully higher chance of going backwards again, because the same ambiguity that caused the first problem tends to cause the second. The result is a distribution with a long tail: a median that looks acceptable and a tail of tickets that take five or six times as long, which is where a disproportionate amount of your unbilled value actually sits.

If you only track the average, the tail is invisible. If you track the ninetieth percentile, it becomes the most interesting number in the business.

How to measure yours without starting a project

You do not need new software to find out where your days go. You need timestamps on the transitions you can already observe, for a sample of tickets rather than all of them.

Take fifty recently billed tickets. Use a mix of customers and job types rather than the easy ones, and record four dates for each:

Date the work was performed
Date the ticket was entered into your system
Date the invoice was generated
Date the invoice was accepted by the customer

Three intervals fall out of that: field-to-office, office-to-invoice, and invoice-to-accepted. Look at the median and the ninetieth percentile of each. The gap between those two numbers tells you how much of your problem is systemic versus exceptional, and that distinction determines what kind of fix is appropriate.

If the median is high across the board, your process is slow and the fix is structural. If the median is fine but the ninetieth percentile is terrible, your process is fine and your exception handling is the problem. That is a much cheaper thing to fix, and a much more common finding.

What can actually be compressed

Field-to-office is compressible to near zero with capture at the point of work. This is the single largest available reduction in most services businesses, and it does not require touching your ERP.

Entry is compressible to near zero by extracting structured data from the ticket rather than retyping it. This also removes a category of transcription errors that later become disputes.

Approval is compressible for clean tickets by validating against your rate schedules and contract requirements automatically, so that a human only looks at the tickets that genuinely need judgment. The goal is not to remove the reviewer. It is to stop them spending their day on tickets that were always going to be fine.

Invoice-to-accepted is partly outside your control, but portal rejections are usually caused by a small, repeating set of coding and formatting errors. Catching those before submission is a solvable problem.

Signature timing is the hard one. If your customer’s representative has left location, no software returns them. What software can do is make sure the ticket is complete and correct while they are still standing there, which is the moment the signature is cheapest to obtain.

The number worth putting on the wall

Days from work performed to invoice accepted. Not DSO, which mixes your performance with your customer’s payment behavior and your negotiated terms. Just the part you control, measured end to end, tracked at the median and the ninetieth percentile.

Most companies who start measuring it are unpleasantly surprised for about a month and then get very good at it, because it turns out to be one of the few operational numbers that responds quickly to attention.