Quarry Scale House and Ticketing Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does a scale house get scoped as a point of sale (POS)?

Because from a distance that is what it looks like. A customer arrives, picks a product, a price applies, a document prints. Every developer has built that. So the quote comes back cheap, the design is a catalogue with a price field, and it collapses on contact with the second customer.

Aggregates pricing is not a rate table. The same material for the same customer carries one price at this pit and another at the pit forty miles away. It is priced per ton if the customer is set up by weight and per yard if by volume. A negotiated contract rate applies on one job and list price on the next. Freight applies by haul zone if you deliver with your own trucks and not at all if they collect. There are tier breaks, effective dates, and a fallback list price for the walk-up cash customer at 7am who has never bought from you before.

Get this wrong and you do not find out at launch. You find out five weeks later when a contractor's accounts payable clerk queries an invoice, and everybody involved spends an hour on a load worth a few hundred dollars. Multiply across a season.

The fix is a scoping test you can run in one meeting. Describe your most awkward real customer to the developer: negotiated rate at one pit, list price at another, on a job with its own freight zone, buying two materials of which one is sold by weight and one by volume. If they need a week to think about it, the pricing engine will end up as a pile of conditional statements nobody can maintain. Ask to see how the price is resolved, in what order, and where the audit trail of which rule applied is stored.

What goes wrong when you migrate customers, jobs and stored tares?

Duplicate customers are the visible problem and stale tares are the expensive one.

Every producer has two entries for the same paving contractor, one from a job three years ago carrying a rate that was fair then. An attendant picks the wrong one at 6am with a driver waiting, and the price error is invisible until the invoice is queried. Importing both records preserves the trap permanently, so the reconciliation has to happen before go-live, run by whoever knows the customer base rather than by the developer.

Stored tares are worse because nothing surfaces the error at all. A tare set when a truck carried a different body is off by hundreds of pounds on every load that truck hauls, in somebody's favour, all season. If you import tares blind you inherit the whole set. The fix is to import them with the date they were last verified, then run a drift alert from day one: when an actual empty weight differs from the stored tare beyond a threshold, flag it and make the attendant confirm. Within a month the bad ones surface themselves.

Jobs are the third piece and the one teams forget. Contractor job records carry the freight zone and often the contract rate, and if they arrive as free text typed differently at each pit, your reporting by job is worthless from the start.

Why do the scale, accounting and portal integrations break after launch?

The scale indicator is the one that fails first, and it fails on motion. Makes such as Rice Lake, Cardinal and Mettler Toledo each expose their own serial or network output with their own behaviour around zero and motion detection, so this is specific work per make rather than a generic driver. A weight captured while the truck is still settling produces a ticket that is defensibly wrong, and the dispute arrives from a customer who checked it on their own scale. Ask any developer which indicators they have actually read, by make, and how they handled stable weight capture. A vague answer here predicts a season of arguments.

Accounting breaks on re-issues and credits. A ticket voided and re-ticketed, or a credit memo raised against a disputed load, looks like new revenue to a naive export, and month end no longer ties. Ask what happens when the same ticket is exported twice.

Customer portals and contractor data feeds break on format changes that nobody tells you about. Large contractors consume ticket data into their own project systems, and when their layout changes your file starts failing silently. Validation that fails loudly, with a named person receiving the exception each morning, is the difference between a two hour fix and a month of missing data.

What happens when royalty terms and certified weight records are not covered?

These are the two obligations that outlast the software, and they are the ones most often left out of a first release because neither is visible on the scale house screen.

Royalties first. Tonnage leaving 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. Most producers reconstruct this quarterly from sales reports, and the reconstruction rarely matches what the tickets actually said. If royalty accrues from the same tickets that produce the invoice, what you owe and what you billed come from one record and the two cannot disagree. If it does not, you are having an uncomfortable conversation with a landowner using numbers you cannot fully defend.

Certified weight records second. The ticket is not only an invoice line. It comes off a scale certified for trade, it may be the document a public agency wants for material supplied to their job, and it is your evidence in a weights and measures question. That means scale identity, calibration date and operator belong on every ticket as data, not as a note. Retention needs to outlast any software relationship, which is why ticket history sitting in a vendor's tenancy is a poor position. Confirm the specific retention expectations with your own counsel and with the agencies you supply, then build to the longest of them.

Should you build custom or configure what you already own?

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. That is the honest answer and it applies to more producers than want to hear it.

Command Alkon Apex is a mature ticketing product with real depth, and if you are a larger integrated producer running ready mix and aggregates and you want one vendor across both, that is a strong argument on its own. Libra Systems has long roots in scale house automation and unattended weighing hardware, and producers who need the physical side handled properly have used it for years. Neither is a weak product and we would not tell you otherwise.

The build case is a fit problem at the edges rather than a failure at the core. Unusual royalty structures that differ per lease. A yard that also takes inbound recycled material with tipping fees, which turns the ticket into a two direction transaction. Customers who demand data in specific formats per contractor. Or genuinely unattended sites with driver badges and kiosks sharing one price book with staffed sites. Those are the requirements that get answered with a workaround in a packaged product and become a permanent manual step. Three or more pits with different price books or royalty terms, or a month end that regularly finds unbilled loads, is where building starts to pay.

How do hidden costs get into the quote?

Four ways, and all are avoidable by being specific in the brief.

Offline operation, if you did not say it out loud. A cloud design that queues a request and waits is much cheaper to build and will send trucks away twice a day. The scale house must weigh, price, number and print entirely locally during an outage and sync afterwards without double billing. If that sentence is not in the requirements, it is not in the price.

Indicator makes. Each additional make and generation across your pits is separate work. Count them before you ask for a number.

Unattended hardware. A badge or tag reader, a kiosk with a printer, loop or presence detection and a camera capturing plate and load is a hardware project with a software layer, not a feature. It changes the economics of a small pit completely, which is why it is worth doing, and it should be its own line.

Inbound material and other lines of business. Recycling with tipping fees, asphalt, or ready mix sharing the same customers each bring their own rules. For anchoring, our bands: a first release with one central price book, ticket capture integrated to the indicator, offline operation with gapless numbering and accounting export runs $60,000 to $130,000 over ten to sixteen weeks. Adding unattended kiosks, royalty accrual, stockpile inventory, haul zone freight and a customer portal takes it to $150,000 to $350,000 across six to eleven months.

What separates a build that works from one that fails here?

Speed at the scale, measured rather than assumed. The system has to be faster than the pad at 5:40am or the pad wins. That means two or three interactions per truck, weights read from the indicator rather than typed, stored tares, and customer credit status shown before the truck loads rather than after. Time it with a stopwatch during the pilot and treat anything above the old process as a defect.

Gapless numbering per site from day one, so a missing ticket appears as a gap instead of vanishing. Pair it with a hard rule that no material moves without a ticket, including internal and yard transfers, and a daily reconciliation between tickets issued, loader activity and stockpile movement. That combination is what converts unbilled loads from invisible to obvious.

A pilot at your two busiest pits, run alongside the existing process for one full billing cycle so invoices can be compared before anything is switched off. Your busiest sites surface every pricing and workflow edge case, and the remaining pits then become a repeatable deployment measured in days rather than a project each.

And ownership settled before kickoff: the repository, the cloud accounts and every stored ticket. Your ticket history is a certified weight record and the basis of royalty obligations that outlast any software relationship, so it has to remain accessible on your terms regardless of who built the system.