The Scale House Handoff Is Where Quarry Revenue Goes Missing

Ask a quarry operator where tickets go wrong and most will point at the scale. Bad tare, wrong product code, a driver who talked the operator into a favor. Those things happen. But they are not where the money usually disappears.

The money disappears in the handoff. Between the moment a ticket prints in the scale house and the moment a line item lands on an invoice, that ticket passes through a truck cab, a clipboard, a dispatch office, a scanner, a shared drive, and a keyboard. Every one of those steps is a place a ticket can stop moving. Nobody notices a ticket that stops moving. That is the whole problem.

One ticket is one billable event

Start with the accounting identity that governs a pit. Every load that crosses the scale is a billable event. Every billable event has exactly one ticket. If you have four thousand tickets for the month, you should have four thousand billable lines, no more and no fewer.

That sounds obvious until you try to prove it. Try this: pull your scale software's load count for a single day last month. Then pull the number of billed lines for that same day. If those two numbers match exactly, you are in good shape. If they do not, the difference is not a rounding issue. It is either revenue you did not bill or a customer dispute waiting to be filed.

Many operators have never run that comparison, because the two numbers live in different systems and neither system was built to reconcile against the other. The scale system counts loads. The accounting system counts invoices. Nothing counts tickets.

The five places a ticket dies

In paper-heavy aggregate operations, ticket loss tends to cluster in a handful of predictable spots.

The truck cab. The driver copy goes in the visor, on the dash, under a coffee. On a broker load or a customer-hauled load, that copy may be the only one that ever reaches your office. Weather, spills, and shift changes finish the job.

The clipboard queue. Tickets pile up in the scale house for pickup. Someone grabs a stack, someone else grabs a stack, and the two stacks arrive at billing on different days. Now your daily counts are wrong in both directions and nobody can tell which day is short.

The scanner. Two tickets fed through stuck together. A page scanned upside down that nobody flips back. A batch scanned twice under a slightly different filename. Duplicates are as expensive as gaps, just in the other direction: they generate credits, disputes, and a customer who now checks every invoice line for a year.

The keyboard. Someone types 24.06 tons as 2.406, or keys the right tonnage against the wrong job number. Miskeys do not look like errors. They look like tickets. They pass every eyeball check because there is nothing visibly wrong with them.

The exception pile. The ticket with no PO, the ticket for a customer who is on credit hold, the ticket with an unreadable job number. Someone sets it aside to ask about later. Later does not arrive. That pile is the most expensive stack of paper on your property because every sheet in it is a load you already hauled, already crushed, already paid a scale operator to weigh.

What a good audit actually looks for

If you are going to check your own tickets, do not start by reading them. Start by counting them.

Sequence gaps. Most scale tickets are numbered. Sort the month's tickets by number and look for holes. A hole is either a void, a missing ticket, or a ticket sitting in someone's truck. Voids should be documented. Everything else is a question.

Date and shift coverage. Did you receive tickets from every operating hour? A second shift that produced forty loads and delivered twelve tickets to billing is not a scale problem. It is a handoff problem, and it will repeat every week until someone names it.

Duplicate detection across the whole month, not the batch. Duplicates usually enter on different days, which is exactly why batch-level checks miss them. Same truck, same ticket number, same tonnage, two entries, two weeks apart.

Rate application against the contract, per ticket. This is where structured billing rules matter. A customer with tiered pricing, a fuel surcharge, a haul rate that changes past a mileage band, and a delivery minimum has four separate ways to be underbilled on a single load. Checking that by eye across thousands of tickets is not realistic. Checking it by rule across thousands of tickets is.

Reference data drift. Product codes that were renamed but not retired. Two entries for the same customer with slightly different names, each carrying a different rate. Trucks assigned to a hauler who left last spring. Bad reference data does not throw an error. It quietly bills the wrong number, correctly, every time.

Why this is not an OCR problem

Reading a ticket and understanding a ticket are different jobs. OCR will give you the characters on the page. It will not tell you that ticket 40219 never arrived, that ticket 40188 was entered twice, that the surcharge tier changed on the first of the month, or that this customer's contract sets a minimum load you did not bill against.

Not just OCR. Not just data entry. The useful work starts after the characters come off the page: structuring each ticket as a billable event, checking it against your rules and your reference data, and flagging the ones that do not hold up.

Where to begin if you do nothing else

Pick your highest-volume customer. Pull one month of their tickets and one month of their invoices. Reconcile them line by line. It is a tedious afternoon, and it will tell you more about your operation than a quarter of dashboards.

Then look at what you found and ask whether the pattern is customer-specific or structural. If it is structural, it is running against every other customer too, and you have been paying for it all year.

If you want a second set of eyes on it, send 10-20 sample tickets to hi@termco.ai. We will structure them, check them against the billing rules you describe, and send back what we find within 48 hours.