What the Drone Saw

The survey report lands in January. A drone flew the yard in December, the software built its surfaces, and the number for the 3/4-minus pile comes back 4,100 tons lighter than your book inventory says it should be. The controller books an adjustment, because that's what the line in the chart of accounts is for. The meeting about it takes ten minutes. Density assumptions, somebody says. Surveys wobble. We lost fines to a wet fall. The base of that pile was always mud.

Every explanation in the room is plausible, and none of them costs anyone in the room anything. Nobody says the other word, which is sales.

Two counts of the same pile

A pit runs on a napkin-simple identity. Tons produced into the pile, minus tons hauled out, equals tons standing. Production has a counter on the crusher. The survey measures what's standing. And tons hauled out is supposed to be your ticket file, because one ticket is one billable event, and a pile is just the running sum of all the events.

That identity is also the only audit of ticket completeness you will ever get. A billing office can check the tickets it has: wrong rates, bad job numbers. What it cannot check, even in principle, is the tickets it doesn't have. A load that left the gate without printing anything is invisible in a stack of paper, because the stack is defined by what printed. Serial numbers don't help; a ticket that was never born leaves no gap in the sequence. The regulars waved through during an outage, the Saturday favor for the loader operator's neighbor: neither is anywhere.

Except in the pile. The pile kept counting. Every bucket that left came off its measured volume, ticketed or not. Read that way, the survey stops being an inventory chore and becomes the one instrument on the property that counts the loads that never printed.

Everyone's favorite explanation

The January meeting never gets there, and the reason is structural: the variance has four candidate causes, and three of them are nobody's fault.

Survey error is real: flyover accuracy depends on the surface, and a rilled, rain-cut pile measures worse than a clean cone. Density is real: the tons-per-cubic-yard factor for your washed stone is an assumption, and a few points of moisture move it. Process loss is real: fines blow, and the pile base drives down into the mud. All three are free to claim, and the free ones get claimed first. The fourth cause, tons that rode out on trucks and billed nobody, has a dollar sign and an owner. It gets claimed last or never.

The three free explanations share a property the fourth doesn't: they're symmetric. A survey wobbles both ways across years. A density factor that's wrong runs long on one product and short on another. Leakage only ever runs one direction, because nobody sneaks material into your pile. So the variance tells on itself, if you read more than one year of it. Error scatters. A leak leans.

That gives you three questions to put to your own history. Does the gap lean short, year after year, instead of bouncing? Does it concentrate in the sellable piles, the clean stone and the top sellers, while the waste piles reconcile? And does it grow in your busiest months, when the gate runs loosest? One imposter passes those tests: a belt scale on the crusher reading a point heavy will also lean short every year and run worst in the busy season. But drift is even-handed in a way a leak never is. It inflates every pile that crusher feeds, base rock and waste along with the clean stone. A leak picks the piles that sell and spares the pond fines, because nobody hauls off your pond fines.

Put numbers on it, yours to redo. A 400,000-ton pit comes up 6,000 tons short across its sellable piles. Grant half, generously, to density and survey. The other 3,000 tons at a $13 blended price is $39,000, and the journal entry that absorbs it takes thirty seconds to post. That entry is the quietest exit money has ever found: the tons weren't stolen, they were adjusted.

flowchart TD
  A["Crusher: tons into the pile"] --> B["Stockpile"]
  B --> C["Ticketed loads"]
  B --> D["Loads that never printed"]
  A --> E["Book: tons in minus tons ticketed"]
  C --> E
  F["Survey: tons standing"] --> G{"Book vs measured"}
  E --> G
  G -- "booked and forgotten" --> H["Journal entry: inventory adjustment"]
  G -- "asked harder" --> I["Which tons never ticketed?"]

The claim your controller will fight

Here it is, stated plainly: a persistent, one-direction survey variance on your best-selling products is unbilled sales until proven otherwise, and it belongs on the billing manager's desk, not in a journal entry. Calling it shrink, an ops number, the cost of running a pit, is a decision too. It stops the investigation at the exact point where it would start costing someone an explanation.

The pushback writes itself, and it's not stupid. Surveys carry a few points of tolerance, so a gap inside that band proves nothing, and chasing it is an accusation with no suspect. True, for one year, for one pile. It stops being true the third year the same pile leans the same way while the pile next to it reconciles. At that point the tolerance argument isn't skepticism anymore. It's a preference for not knowing.

Make your side of the page add up

None of this works if the ticket side of the comparison is soft, and in most pits it is. Ask for ticketed tons of 57 stone for March and you get a weekend of spreadsheet work, because the same product lives in the system as 57s on one screen and 3/4 clean on another. A comparison between a measured pile and a mushy total convicts nobody and gets dropped.

So the ticket side has to be a number you'd defend. Tickets digitized as they print, not at month end. Product names held as reference data, one name per product, so a pile-level total is a query instead of a project. Voids and no-charge loads flagged and reasoned, because a leak loves to hide among legitimate exceptions. Totals assembled by product and period from tickets that cleared. That slice is what Termco builds: digitizing the tickets, flagging the ones that break a rule, structuring the billing rules, managing the reference data, assembling the totals. One boundary stated plainly: Termco doesn't fly the drone, measure the pile, or keep your inventory. The pile's side of the page stays with your surveyor. What changes is that the ticket side finally holds still long enough to be compared to it.

Put both numbers on one page

This year, do one thing differently. Before the survey report lands, have ticketed-out tons by product already totaled and sitting on the controller's desk. When the measured number arrives, write the two side by side, per pile, and make the density conversation happen second instead of first. You paid the surveyor to count your inventory. For the same money, they counted your missing tickets. Read that half of the report too.

If you'd rather have a second reader on the ticket side, send 10-20 sample tickets to hi@termco.ai, tickets from your biggest-variance product especially, and we'll send back what we find within 48 hours: the rule breaks, the name aliases, and the unexplained voids that keep a ticket total too soft to set against a survey.