Mining Operations Software: Closing the Tonnage Reconciliation Gap

Why mining operations software makes or breaks a multi pit operator

Walk into the dispatch trailer at 5:40 a.m. on a mid sized aggregate or hard rock operation and you will find the same picture almost everywhere. There is a whiteboard with truck numbers and pit assignments in dry erase marker. There is a laptop running an Excel workbook called something like SHIFT_PLAN_v4_FINAL_USE_THIS.xlsx. There is a radio. The dispatcher, who has been doing this for 14 years and is the single point of failure for the entire day, is reconciling last night's scale tickets against what the loader operators claim they moved. The numbers do not match. They never match. He writes down the difference and moves on because the crews are waiting.

The tool stack underneath is rarely one system. It is Wenco or Modular Mining DISPATCH on the big fleets, or nothing at all on the mid sized ones. It is Caterpillar VisionLink or John Deere JDLink for equipment hours, which does not talk to your maintenance system. It is a scale house running Scale Softworks, WeighPay, or a 20 year old DOS era ticketing package the vendor stopped patching in 2016. It is Deswik or Surpac or Vulcan for the survey and the plan, exporting a PDF that gets printed and pinned. It is Sage 100 Contractor or Viewpoint Vista for the financials. It is Fluke eMaint or UpKeep or an HxGN module for maintenance. It is SafetyCulture iAuditor for pre shift inspections, producing PDFs nobody reads until an inspector asks. And it is at least four spreadsheets that a superintendent maintains personally and that will leave with him.

The leak is not dramatic. It is a dispatcher spending 90 minutes every morning on manual reconciliation, a superintendent rebuilding the same production roll up three times a week, a maintenance planner discovering a haul truck is 400 hours past a service interval because the hour meter reading lived in VisionLink and the PM schedule lived in eMaint. On a 40 truck operation moving 3 million tons a year, a 3 percent reconciliation gap between surveyed volume and sold tonnage is 90,000 tons of ambiguity. At a $14 a ton sell price that is $1.26 million you cannot explain to your CFO, your royalty holder, or your bonding company. The software question is not a productivity question. It is whether you actually know what came out of the ground.

Problem: the reconciliation gap between survey, load count and scale tickets

Here is the scenario that ends careers. Month end close. The survey crew flew the pit with a drone and Propeller or Stockpile Reports gives you an end of month volume. Your loader operators reported 1,180 buckets across the month. Your scale house sold 94,000 tons. Convert the survey volume at your assumed density and you get 97,800 tons. Where did 3,800 tons go? Was it density assumption drift because the material got wetter? Was it a bucket factor that has not been recalibrated since 2019? Was it the stockpile you drew from that was never surveyed as a separate entity? Was it a haul truck that went out the gate without a ticket because the scale operator was in the bathroom? You genuinely do not know, and by the time anyone asks, the evidence is gone.

The incumbent tools cannot fix this because each one owns exactly one leg of the triangle and none of them owns the reconciliation. Wenco knows load counts. Your scale software knows sold tons. Your survey package knows volume. Three systems, three timestamps, three different ideas of what a "stockpile" is, and no common identifier for a load. You can export all three to Excel and a smart person can force them together, which is exactly what your superintendent does every month, badly, at 11 p.m.

What a custom build does: one canonical material movement event with a single ID, written the moment a load leaves the loader, carrying source (pit, bench, blast block), destination (crusher, ROM pad, stockpile 4), operator, truck, timestamp, and estimated tons from the loader payload scale. That event is the spine. Scale tickets attach to it by truck plus time window. Survey volumes attach to it by stockpile entity and date range. Reconciliation stops being a monthly forensic exercise and becomes a live variance number the dispatcher sees on his screen. When the gap opens, the system tells you which day, which pit, which shift, which truck. We build the variance engine to flag drift the same shift it happens, not 30 days later. On one operation, that alone moved reconciliation from a 4.1 percent unexplained gap to under 0.8 percent inside two quarters, because the operator finally knew where to look.

Problem: equipment hours and maintenance live in different universes

Your 777 haul truck has an OEM telematics feed pushing SMU hours to VisionLink. Your PM schedule lives in eMaint. A planner types the hour reading into eMaint on Mondays, when he remembers, from a screen he has to log into separately. Miss two Mondays and a 500 hour service interval quietly becomes a 640 hour interval. Then the final drive goes at 6,800 hours instead of 12,000, and you eat a rebuild that lands in six figures plus 11 days of a truck out of the fleet during your highest tonnage month.

Off the shelf cannot fix it because the OEM telematics vendors have no commercial interest in feeding a competitor's CMMS cleanly, and your fleet is mixed anyway: Cat, Komatsu, Volvo, a couple of Doosans, and two Hitachi excavators. Four telematics portals, four data models, four sets of fault codes that mean different things. VisionLink has an API. Komatsu KOMTRAX has a more limited one. The 2011 Volvo has nothing but a wire. The generic CMMS assumes you will type it in.

What a custom build does: a normalization layer that ingests from every OEM API you have, plus AEMP 2.0 ISO 15143-3 feeds where the OEM supports it, plus a cheap aftermarket telematics box on the assets that have nothing, and writes every asset to one equipment record with one hour meter, one fuel burn, one fault stream. PM intervals trigger off actual machine hours, automatically, at 3 a.m. every day. Work orders open themselves. The planner's Monday morning data entry job disappears entirely. Where AI does real work here is failure pattern detection across your own history: once you have 18 months of normalized hour, fault code, fuel burn and repair records in one place, a model trained on your fleet flags the specific combination of rising fuel burn plus a particular transmission fault frequency that preceded your last three final drive failures. Not a generic OEM alert, your machines, your material, your haul profile. That is only possible because the data is finally in one schema.

Problem: pre shift inspections and safety records that cannot survive an inspection

An MSHA inspector arrives unannounced. He wants pre shift examination records for the last 90 days on the highwall. Under 30 CFR Part 56 you are required to have them, examined and recorded before miners begin work, with hazards noted and corrective actions documented. Your records are in iAuditor as 90 individual PDFs, some of which were filled out at 8:40 a.m. for a 6 a.m. shift because the operator did it after the fact on his phone in the truck cab. The GPS stamp says he was in the parking lot. That is a citation waiting to happen, and a 104(d) order is not a fine, it is a shutdown.

Generic inspection apps cannot fix this because they treat every checklist as a document, not as a legal record tied to a specific working place, a specific examiner with a specific certification, and a specific corrective action with an owner and a close out date. iAuditor does not know what a working place is. It does not know your examiner's certification expired last month. It cannot show an inspector a continuous chain from hazard noted to hazard corrected to hazard verified.

What a custom build does: examinations modeled against your actual working places, geofenced so the record cannot be created outside the pit boundary, tied to an examiner whose certification status the system checks before it lets him sign. Hazards become tracked objects with an owner, a due date, and an escalation path to the superintendent if they age past 24 hours. When the inspector asks, you produce a single continuous record for the working place he named, in about 40 seconds, with photos and corrective action close outs attached. Document extraction earns its place on the intake side: MSHA correspondence, third party inspection reports, and blast records arrive as PDFs and scans, and a well tuned extraction pipeline pulls the dates, working places, cited standards and abatement deadlines into structured records rather than a shared drive folder called SCANS_2026.

Problem: the shift plan is a whiteboard and the whiteboard has no memory

Your dispatcher assigns 14 trucks to three loaders across two pits at shift start. By 9 a.m. the crusher is down, so he re routes to the ROM pad. By 11 a.m. a truck has a flat, so the ratios are wrong and one loader is waiting. Nobody records any of this. At the end of the quarter you want to know why your loader utilization is 61 percent when the equipment supplier's model says 78 percent, and there is literally no data. The whiteboard was erased 90 shifts ago.

Full fleet management systems like Wenco or DISPATCH solve this at the top end, and if you are a 100 truck open pit copper operation you should just buy one. But the onboard hardware, the pit network, and the integration services make a real deployment a capital project rather than a software purchase, and the assignment logic assumes a mine that looks like a big mine. If you run 3 pits, 22 trucks, a mobile crusher that moves quarterly, and you sell 60 percent of production over a scale to third party haulers you do not control, that model does not fit you and the vendor will tell you to change your operation.

What a custom build does: capture the assignment and every change to it as an event stream, not a state. The dispatcher's screen looks like his whiteboard on purpose, because he will not use anything else, but every drag of a truck from pit 2 to pit 3 writes a record with a reason code. Six months later you can answer why utilization is 61 percent: 14 percent of loader time was queue starvation caused by re routes after crusher downtime, concentrated in a specific 90 day window. That is an actionable number. AI helps concretely on the forward looking side, forecasting tomorrow's truck requirement from your own history of material type, haul distance, weather, and operator, and flagging when the plan the superintendent built cannot physically move the tons he committed to. Not a black box optimizer that the dispatcher ignores, a second opinion that shows its work.

Problem: third party haulers and the gate you do not control

Half your outbound tonnage goes on trucks you do not own, driven by people you did not hire, for brokers who pay on their terms. The driver shows at 6 a.m., the scale house writes a ticket, and you invoice against the ticket. Except the broker disputes 40 tickets a month claiming short loads. Your scale software prints a ticket. It does not photograph the load, it does not tie to a purchase order, it does not know the broker's contract rate, and it certainly does not know that this same truck number has shown up with a suspiciously light tare weight 11 times this quarter.

Scale ticketing packages are built for the scale, not for the commercial relationship around it. WeighPay and similar tools handle the weight and the print. Your AR lives in Sage. The contract terms live in a PDF in someone's email.

What a custom build does: the ticket becomes a transaction with the contract attached. Rate, material spec, and destination validate at the scale, not at invoicing. Tare weight anomalies flag in real time against that truck's own history. A driver mobile flow with a photo of the load and a signature closes the dispute loop before the truck leaves the yard. Tickets post to Sage or Vista nightly through a real integration rather than a CSV someone imports. Where AI helps: after hours and weekend booking. Brokers call at 9 p.m. wanting a 6 a.m. slot, and right now that call goes to voicemail or to your dispatcher's personal cell. A booking agent that takes the call or the text, checks the pit plan for available capacity, confirms the material spec against what is actually stockpiled, and writes the reservation, is a solved problem now and it recovers loads you are currently losing to whoever answered the phone.

What this actually costs and how long it takes

Across 2,000 plus projects, Digital Heroes delivery experience for this category lands in two bands. A focused first release, meaning shift planning and dispatch capture, the material movement event spine, scale ticket reconciliation, and pre shift examination records with MSHA ready export, runs $60,000 to $130,000 and ships in 12 to 16 weeks. That is a real system your dispatcher uses every shift, not a prototype. A full platform, adding multi OEM telematics normalization, maintenance and PM automation, grade control integration, third party hauler commercial flows, ERP (Enterprise Resource Planning) posting, and forecasting, runs $150,000 to $400,000 phased across 6 to 12 months.

What drives price up specifically in mining: the number of distinct OEM telematics sources, because each one is its own integration with its own auth model and its own idea of an hour meter. Whether your scale house software has any API at all, or whether we are reading a serial port off an indicator head, which is a real thing we have done and it costs more. Whether you need offline capability, and in a pit with no LTE coverage below the second bench you do, which means conflict resolution and sync logic rather than a simple web app. Survey package integration, because Deswik, Surpac and Vulcan each export differently and block model integration is genuinely hard. And regulatory scope: MSHA Part 46 versus Part 48 training records, state reclamation reporting, and royalty calculations for multiple mineral rights holders each add real surface area.

What keeps price down: starting with the reconciliation spine and refusing to build the fleet optimizer in phase one. Every operator wants the optimizer. Almost nobody has clean enough data to feed one on day one.

Build versus buy, and where the line actually sits

Buy if you run a single pit with under 20 pieces of mobile equipment, one scale house, one commodity, and your production plan does not change more than quarterly. A good scale package plus SafetyCulture plus your OEM's portal plus a competent bookkeeper will run that operation fine and you should not spend $90,000 to replace it. Buy also if you are a large single site open pit with 80 plus trucks and a mine plan that looks like the textbook: Wenco and Modular built their products for you, they work, and rebuilding that is vanity.

Build when these signals show up together, and in my experience they arrive as a group. Your reconciliation gap has stayed above 3 percent for two straight quarters and nobody can explain it. You have more than two pits or more than one commodity, so a single site product's data model fights you. More than 30 percent of your outbound tonnage moves on trucks you do not own. Your mine plan changes weekly, not quarterly, because you are chasing spec or a customer or a wet season. And the clincher: there is one person, usually a superintendent or a dispatcher with 12 plus years of tenure, whose personal spreadsheets are load bearing for the whole operation. When that person retires, and he will, you will discover you were not running a mine, you were running him. That is the moment the build pays for itself, and the honest position is you should start 18 months before it, not after.

How to choose a developer for mining operations software

Ask them to model a material movement event on a whiteboard, cold, in the first meeting. If they cannot articulate why a load has a source bench, a destination that might be a stockpile or a crusher, an estimated payload from a loader scale and a separate confirmed weight from a static scale, and why those three numbers legitimately disagree, they will build you a nice looking app that generates the same reconciliation gap you have now.

Ask what they have actually integrated. Not "we do integrations." Which telematics APIs, which scale indicator protocols, which ERP. VisionLink, KOMTRAX, AEMP 2.0 feeds, Rice Lake or Cardinal indicator heads, Sage 100 Contractor, Viewpoint Vista. If the answer is generic, the integration surprises land in month five when your budget is spent.

Ask how they handle offline. A pit with no signal below bench two is not an edge case, it is Tuesday. The answer should involve local write, queued sync, and a specific conflict resolution policy, not "we'll cache it."

Ask who owns the code and the data, in writing, before the first invoice. You should own the repository, the schema, and every row. Any developer who wants to host your production and safety records on terms you cannot exit is selling you leverage over yourself, not software. Get the escrow or the direct repo access into the contract on day one, because renegotiating it after they have your last 400 shifts of data is not a negotiation.