Codelayer Technologies enables organisations to scale with clarity and control by integrating people, process, and technology into a unified enterprise ecosystem.


Office
Kinfra Film And Video Park, 33,
Kazhakkoottam,
Thiruvananthapuram, Kerala 695585

Follow Us

Odoo Channel Partner 600+ Clients 25+ Years
Our Blogs

From Blasting to Billing: Mapping the Complete Quarry & Crusher Workflow in ERP

Join a team of passionate engineers, consultants, and innovators who are reshaping how industries operate — from the quarry floor to the boardroom.

Posted on Aug 17, 2026

Home Blogs From Blasting to Billing: Mapping the …
From Blasting to Billing: Mapping the Complete Quarry & Crusher Workflow in ERP

 

Ask any quarry owner where their business actually loses money, and you rarely get a single answer. It's not one broken step. It's the gaps between steps.

A blast happens on one register, excavation gets logged in another, crusher output is estimated rather than measured, stock is counted by eye, and by the time material reaches the weighbridge, nobody can say with certainty how the numbers connect back to the rock that came out of the ground that morning.

This is what a genuine quarry and crusher ERP workflow is built to solve. It is not about adding one more tool to the pile, but about connecting every stage of the operation, from Planning through Billing, into a single continuous chain of data.

Codelayer's own Quarry & Crusher ERP scope, covering extraction tracking, plant production, weighbridge, gatepass, dispatch, fleet, maintenance, and financial reporting, was built directly around this eleven-stage sequence.

Here's what that chain actually looks like, stage by stage, and what breaks down at each point when it's handled in isolation.

 


Stage 1: Planning

Before any drilling happens, a quarry has to plan what it intends to extract: which bench, how much volume, over what timeframe, and against what customer demand.

This is a distinct operational stage in its own right, not a footnote to drilling.

In an ERP-driven workflow, planning data, including target volumes, site allocation, and projected output, becomes the baseline record that drilling and blasting decisions are built against.

When planning exists only as a verbal instruction or a whiteboard note, there is no benchmark left behind to compare against later. Nobody can say afterward whether a blast, a crushing run, or a dispatch actually performed to expectation.

 


Stage 2: Drilling & Blasting

Once a plan is in place, drilling and blasting execute it.

Operators drill blastholes according to a defined pattern and load them with explosives to fracture the rock face.

This stage produces the first physical data point in the entire chain: the blast record, including how much rock was broken loose, from which bench, and on which date.

In an ERP-driven workflow, this blast record becomes the specific input that excavation planning is built on, determining how much material excavation crews should expect to move and from where.

Handled manually, this information typically lives in a blasting officer's personal logbook, disconnected from the excavation team's own paperwork. This means excavation often proceeds based on assumption rather than an actual, verified blast record.

 


Stage 3: Excavation to Crushing: The First Critical Handoff

Excavation is where blasted rock is physically loaded and hauled from the pit to the crusher feed.

The specific record generated here, including excavated volume by load and by trip, tied back to the originating blast block, is what should become the crusher's feed-tonnage input.

In a connected workflow, each load delivered to the crusher hopper is logged against this excavation record. The crusher's starting feed figure is therefore a verified number, not a guess.

Where this handoff is missing, where excavation is tracked on a loader operator's tally sheet and crushing simply starts without a matched feed record, a business has no way of knowing whether the tonnage reaching the crusher actually matches what was hauled out of the pit.

A shortfall anywhere in that gap can go completely undetected.

 


Stage 4: Crushing to Screening: The Second Critical Handoff

Crushing is the first stage where raw rock starts turning into a sellable product.

Primary crushing reduces large excavated rock down to a manageable size, and this process generates its own specific record: the crushed output tonnage, distinct from the excavation feed tonnage that entered it.

That crushed-output record is exactly what needs to become the input feeding into screening. The next stage cannot accurately grade material it has no verified starting quantity for.

When crushing output isn't recorded as a discrete figure and simply flows physically onto the next conveyor without a corresponding data entry, screening effectively begins with an unknown input.

Any yield or grading calculations made afterward are therefore estimates layered on top of an estimate, not real numbers.

 


Stage 5: Screening

Screening is a separate stage from crushing, not a continuation of it.

This is where crushed material is separated into distinct commercial grades, including different aggregate sizes, sand, and dust, based on particle size.

A single batch of crushed rock doesn't become one product here. It splits into several products, in proportions that shift depending on feed quality and machine condition.

Without a system that records each graded output separately against the crushing input it came from, a business is left estimating how much of each individual grade it has to sell, rather than knowing it.

This becomes a direct problem the moment stock and sales orders enter the picture.

 


Stage 6: Stock

Everything that comes out of screening lands in stock. This includes multiple material grades sitting in a yard, constantly being added to by production and drawn down by dispatch.

The specific handoff here is that each graded output recorded during screening should post directly as a stock addition, by grade, the moment it's produced.

This is the first point in the workflow where the business holds something it can actually sell.

When production data doesn't feed directly into stock records, when stock is instead updated by someone walking the yard and estimating pile sizes at the end of the day, the yard and the office end up holding two different versions of reality.

Neither version is reliably correct.

 


Stage 7: Sales Order

The Sales Order stage is where an external customer commitment enters the picture for the first time, and it needs to be understood as distinct from stock itself.

Stock is an internal state: what you currently hold.

A sales order is a promise: what you've committed to deliver, to whom, at what price, and under what terms.

The specific handoff here is that a sales order should check itself against live stock-by-grade figures before being confirmed.

Where sales orders are taken over the phone without checking real stock data, a business risks confirming deliveries against material it doesn't actually have on hand.

This mismatch only becomes visible once a truck is already at the weighbridge expecting a load that isn't there.

 


Stages 8 to 11: Weighbridge, Gatepass, Dispatch, and Billing

These four stages form the closing sequence of the entire workflow, functioning as one connected chain rather than four isolated events.

Weighbridge

A vehicle is weighed at the weighbridge, capturing the exact quantity being moved against the sales order that authorized it.

Gatepass

That weighment record clears the vehicle through gatepass, the physical control point confirming that what's leaving the site matches what was authorized, using the weighbridge figure as its direct input.

Dispatch

Dispatch records complete the movement using that same gatepass-verified transaction.

Billing

Billing closes the loop, generating a GST-compliant invoice directly from the same net weight figure that cleared the gate, without anyone re-entering the same number a second or third time.

Where these four stages run as separate, disconnected checkpoints, a paper weighbridge slip, a manually issued gatepass, a dispatch note filled in from memory, and an invoice raised days later, every one of those handoffs becomes a point where a number can be altered, lost, or simply never make it through.

This is exactly how unbilled dispatch and billing disputes happen.

We've written in depth about how weighbridge data flows into an ERP system in Weighbridge Integration in ERP: Why It's the Backbone of Quarry Operations, and about how gate-level control prevents unauthorized material movement in Gatepass Automation: Stopping Material Leakage in Quarry Dispatch.

This post won't repeat that depth, but neither stage functions in isolation. They're the final links in the same chain that started at Planning.

 


The Real Cost Isn't a Missing Feature: It's the Gaps Between Stages

Here's the argument that ties this entire workflow together:

The biggest cost to a quarry business is rarely caused by one badly performing stage. It's caused by the accumulated friction of a fragmented process.

Blasting is tracked in one register, excavation in another, crushing output is estimated rather than measured, screening yields are never individually recorded, stock is counted by eye at the end of the day, sales orders are confirmed without checking real stock, and billing happens days after material has already left the site.

Each individual gap, on its own, might look manageable.

Across eleven connected stages, they compound into:

  • Lost material
  • Disputed invoices
  • Numbers that never quite reconcile between the yard and the office

This is precisely why end-to-end quarry management ERP has to mean exactly that: end to end, not stage by stage.

A system that only digitizes billing, or only automates the weighbridge, still leaves every other handoff in the chain exposed to the same fragmentation risk.

A genuine quarry production management software platform, paired with quarry dispatch management software covering the weighbridge-to-billing sequence, closes the gaps between stages.

This ensures that what happens at Planning is still traceable, in one continuous record, all the way through to the invoice a customer receives.

 


Why Reporting Matters as Much as the Workflow Itself

None of this connected data is useful unless it can actually be pulled together into something a plant owner or operations head can act on.

This is where quarry MIS and reporting software becomes the practical payoff of everything described above.

Key reporting requirements include:

  • Production-versus-dispatch reconciliation reports that surface gaps before they become disputes
  • Stock reconciliation reports comparing book stock against physical stock by grade
  • Consolidated royalty and GST reports built directly from verified weighbridge and billing data rather than reconstructed manually at month-end

 


Making the Workflow Real, Not Just Mapped

Understanding this workflow on paper is one thing.

Getting it running accurately on a live plant, with your specific equipment, staff, and site layout, is another. This is where implementation expertise matters as much as the software itself.

Codelayer's Business Analysis & Consultation work starts by understanding how your specific plant actually operates, stage by stage, before any configuration begins.

From there:

Customization & Development

The system is adapted to your specific operational requirements.

Integration Services

The system is connected with your equipment and existing site infrastructure.

Data Migration

Historical records are brought into the new system without starting from zero.

Training & User Onboarding

The people running each stage, from the blast crew to the accounts team, are trained to use the system as intended.

AMC and Support

Ongoing AMC and Support keep the workflow running accurately long after go-live, not just on day one.

 


Where GrowBiz ERP Fits In

This is exactly what GrowBiz ERP's Quarry & Crusher solution is built around: not eleven disconnected tools, but one continuous workflow from Planning through Billing, backed by 25 years of Codelayer's  documented domain experience in this industry.

 

 

25 Years of Experience 25 Years Strong · Since 2000