Quarry Scale House and Ticketing Software: How Do You Make Sure Every Load That Leaves the Pit Actually Gets Invoiced?

Every load is a revenue event and a legal weight record

5:40am at a pit that opens at six. A truck is already on the scale. The scale house attendant has not arrived, the loader operator wants to keep the yard moving, so he writes a ticket on a pad: contractor name, material, guessed tonnage, no scale weight. The truck leaves. That pad sheet may reach the office. It may not. Nobody notices either way, because there is no sequence to break.

Later that morning a driver pulls up and says the load goes on the ABC Paving account. There are two ABC entries in the system, one from a job three years ago with a stale rate, and the attendant picks the wrong one. The ticket prints, the truck leaves, and the price error surfaces when the customer's accounts payable clerk queries the invoice five weeks later. Everyone involved will spend an hour on a load worth a few hundred dollars.

Then there is the load with the wrong tare. The stored tare for that truck was set when it had a different body on it. Every load that truck hauls this month is off by several hundred pounds in someone's favour. Multiply across a fleet and a season.

None of this is exotic. It is the ordinary daily leakage of a business where the transaction happens at a scale, in the dark, in a hurry, in front of a driver who wants to go. And the ticket is not only an invoice line. It is a legal weight record from a scale that is certified for trade, and it may also be the document a state agency wants for material supplied to a public job, plus the basis of the royalty you owe a landowner per ton removed.

Why this breaks on general software

A point of sale (POS) system prices an item. It does not know that this material at this pit for this customer on this job carries one price, that the same material for the same customer at the pit 40 miles away carries another, that the price is per ton if the customer is set up by weight and per yard if by volume, and that a third rate applies if the material is being hauled to a job in a specific freight zone with your trucks rather than theirs.

An ERP (Enterprise Resource Planning) knows about revenue and inventory. It does not know that the network connection to a pit in a valley drops for 20 minutes twice a day, and that during those 20 minutes the scale must still weigh, the ticket must still print with a valid unbroken number, and the transaction must reconcile without duplication when the link returns. That single requirement disqualifies most cloud first designs that were not built for it.

And neither knows about royalties. The tonnage that leaves a pit creates an obligation to a landowner on terms specific to that lease: a rate per ton, sometimes tiered, sometimes with a minimum, sometimes only on certain materials. Producers reconstruct that quarterly from sales reports, and the reconstruction rarely matches what the ticket actually said.

What Command Alkon Apex and Libra Systems actually leave you doing

Command Alkon is the established name across aggregates and ready mix, and Apex is a mature ticketing product with real depth in dispatch and in the connections to concrete operations. If you are a large integrated producer with ready mix and aggregates and you want one vendor across both, that is a strong argument and it is a good product.

Libra Systems has long roots in scale house automation and unattended weighing hardware, and shops that need the physical side handled properly have used it for years.

Where we are usually called in is not a failure of either product. It is a fit problem at the edges. Producers with unusual royalty structures per lease. Producers who also run recycling and asphalt operations where the same yard handles inbound material with tipping fees, which turns the ticket into a two direction transaction. Producers whose customers demand data in specific portal formats per contractor. And producers who want the scale house to be genuinely unattended at some sites, with a driver badge, a kiosk and a camera, integrated with the same price book as the staffed sites. Those are the requirements that get answered with a workaround in a packaged product and become a permanent manual step.

What a custom build has to include

One price book, centrally maintained, applied everywhere. Customer, material, pit, job, unit of measure, effective dates, tier breaks, contract rates and the fallback list price, plus freight by haul zone if you deliver. This is the piece that pays for itself first, because pricing errors are the largest quiet leak and they are entirely preventable.

Ticket capture built for a scale house at speed. Two or three interactions per truck, indicator reading pulled from the scale rather than typed, stored tare with an alert when the actual tare drifts beyond a threshold, and customer credit status shown before the truck loads rather than after. Gapless numbering per site, so a missing ticket is visible as a gap instead of vanishing.

Offline as a design principle, not a feature. The scale house runs locally, prints locally, numbers locally within its allocated range, and syncs when it can. Reconciliation on reconnect has to be idempotent so a slow sync cannot double bill a customer.

Then the obligations side. Royalty accrual per lease, computed from the same tickets that produce the invoice, so what you pay a landowner and what you billed a customer come from one source. Production and inventory movement by stockpile, so the pit knows what it has without a survey. Certified weight record retention with scale identity, calibration date and operator on every ticket, because that record is your defence in a weights and measures dispute.

Then the customer experience, which increasingly decides who gets the next job. Tickets emailed or pushed to the contractor in real time rather than at month end. A portal where their accounts payable clerk pulls their own tickets. Data in the formats their project management system consumes. Contractors notice this. It is one of the few places where a custom build is visible to the person writing your cheque.

Unattended weighing is worth its own paragraph. A badge or tag, a kiosk with a printer, loop detectors, a camera capturing the plate and the load, and rules for which customers and materials may be self served. It changes the cost structure of a small pit completely, because a site that could not justify an attendant can still sell material at 6am. It also raises the stakes on price book accuracy, since there is no attendant to catch a wrong entry.

Cost, timeline and what moves them

The first release runs $60,000 to $130,000 and ships in 10 to 16 weeks. That is the price book, ticketing at the scale with hardware integration, offline operation, gapless numbering and accounting export. Scale indicator integration is real work: makes such as Rice Lake, Cardinal and Mettler Toledo each have their own serial or network output, and reading a stable weight reliably is not a one afternoon job.

The full platform with unattended kiosks, royalty accrual, stockpile inventory, haul zone freight, customer portal and dispatch runs $150,000 to $350,000 across 6 to 11 months. What pushes it up: many sites, unattended hardware at multiple pits, inbound recycled material with tipping fees, and asphalt or ready mix operations sharing the same customers. What holds it down: rolling out to your busiest two pits first and treating the remaining sites as a repeatable deployment rather than a project each.

When you should not build this

One pit, a short material list, a stable customer base and an attendant who has run that scale house for a decade. Buy a packaged ticketing product, connect it to your accounting, and spend the money on the yard instead. The build case starts at three or more pits with different price books or royalty terms, at the point where month end regularly discovers unbilled loads, or when you want unattended weighing at sites that cannot support staff.

How to choose a developer

Ask what happens when the internet drops mid weigh. If the answer is a queued request, walk. The scale house must function completely offline, including numbering and printing, and the sync must be idempotent. This is the single most common reason these systems get abandoned.

Ask which scale indicators they have read. Ask for the make, the protocol and whether they handled motion detection and stable weight capture, because a weight read while the truck is still settling is a dispute waiting to happen.

Ask how the price book handles a customer with a negotiated rate at one pit and list price at another, on a job with its own freight zone. If they need a week to think about it, the pricing engine will end up as an if statement pile you cannot maintain.

Ask who owns the code, the repository and the cloud accounts, and settle it before kickoff. At Digital Heroes the client owns all three from the first commit. Your ticket history is a legal weight record and the basis of royalty obligations that outlast any software relationship, so it must sit somewhere you control.