On this page
- The short answer
- Which parts of the chain you own
- Cement vs Manufacturing and FMCG
- Map the operating lifecycle
- RAW MATERIAL ≠ CLINKER ≠ CEMENT
- Inward weighbridge
- Supplier vs weighed quantity
- Vehicle identity
- Raw materials
- Quarry and stockpile
- RM consumption to clinker
- Clinker as its own state
- Clinker factor
- CLINKER PRODUCED ≠ AVAILABLE
- CONTROL THE GRADE
- Grinding production
- Standard vs actual mix
- Cement grades
- Quality and the production state
- Quality release
- Cement silo inventory
- Silo movements
- PRODUCED ≠ DISPATCHABLE STOCK
- BAG CEMENT ≠ BULK CEMENT
- Packing by grade, line, shift
- Packing-material consumption
- Bag rejection and rework
- GROSS ≠ SALEABLE PACKED OUTPUT
- RECONCILE THE TONNE
- Dispatch planning
- Committed stock
- Truck allocation
- Outward weighbridge
- Outward net vs invoice
- Inter-plant movement
- TRADE SALE ≠ PROJECT SALE
- Project cumulative control
- Truck and rake
- Freight
- Standard vs actual freight
- Cost per MT
- Energy
- Contribution
- Schemes are a core requirement
- SETTLE THE SCHEME
- Distributor schemes
- Dealer and retailer schemes
- Consumer schemes
- Beneficiary class
- Scheme eligibility
- DEALER LIFTING ≠ SCHEME EARNING
- Progressive slabs
- Benefit forms
- Transaction-backed qualification
- Consumer scheme evidence
- Earned vs settled benefit
- Scheme liability
- Scheme approvals
- Scheme settlement
- Closed scheme history
- Overlapping schemes
- Credit before dispatch
- ERP, weighbridge, plant, lab
- The difficult scenarios
- Standard or custom?
- Red flags
- Evaluation record
- What customer proof?
- How exactllyERP fits
- Checklist
- Go Deeper
One company may own limestone quarries, produce clinker, grind and pack cement, and distribute through dealers. Another may buy clinker and operate only a grinding unit. Some sell mainly through trade channels. Some supply large infrastructure projects. Some dispatch mostly in bags. Others handle substantial bulk cement. Many operate several plants, depots, dealers and project customers at once.
That is why an ERP should not be judged simply by asking whether it supports production, inventory, weighbridge, dealer schemes or dispatch.
The buyer needs to know whether the system can preserve the relationship between raw material, clinker, cement grade, silo, packing or bulk stock, weighment, dispatch, freight, scheme earning, customer credit and the final commercial result.
The useful question is not “Does your ERP support Cement?”
It is “Can you prove what grade we produced, where every tonne went, who qualified for which scheme, what it cost to serve them, and what remains commercially unresolved?”
The short answer
A Cement company should evaluate ERP by following the complete grade-to-market operating chain.
A useful generic lifecycle is:
- raw material / limestone / additives
- inward weighbridge
- raw-material stock
- kiln / clinker where applicable
- clinker stock / transfer
- grinding / blending
- cement grade
- quality release
- cement silo
- bag packing or bulk loading
- dispatchable stock
- dealer / distributor / project order
- applicable price / scheme / credit
- truck / rake allocation
- outward weighbridge
- dispatch / invoice
- freight
- lifting / scheme achievement
- collection / scheme settlement
- actual cost / contribution
Not every Cement business uses every stage.
The important test is whether the proposed ERP can connect:
- the raw material actually received;
- the quantity accepted at weighbridge;
- clinker production and balance where applicable;
- grinding input and cement-grade output;
- quality status;
- silo inventory;
- bag or bulk stock;
- dispatch commitments;
- actual truck/rake movement;
- outward weighment;
- project-order fulfilment;
- freight;
- distributor/dealer/consumer scheme eligibility;
- scheme achievement and settlement;
- credit and collections;
- and the resulting cost/contribution per tonne.
A feature list cannot prove that.
First identify which parts of the Cement chain your business actually owns
Before comparing ERP vendors, define the operating model or combination of models you actually use.
Possible models include:
These models can overlap.
A company may manufacture clinker at one plant, transfer it to another grinding unit, dispatch bags through a dealer network and supply bulk cement directly to large projects.
Do not force the entire business into one “Cement ERP” process simply because the vendor has one standard demo.
Ask:
Where does our ERP responsibility begin and end — raw material, clinker, grinding, silo, packing, bulk loading, depot distribution, trade schemes, project supply or some combination?
That answer should shape the evaluation.
What makes Cement different from general Manufacturing and FMCG?
Manufacturing already asks:
- plan the work
- capture the actual
- explain the variance
FMCG already asks:
- move the SKU
- control the scheme
- close the receivable
Cement adds a different material-flow and commercial problem:
What grade and quantity did we actually produce?
Where did each tonne go between clinker, silo, bag, bulk, depot, dealer and project?
What did actual energy, packing and freight do to cost per tonne?
Who — distributor, dealer or consumer — actually earned a scheme benefit, on what transaction evidence, and what remains to be settled?
That is why Cement ERP evaluation should not simply repeat a Manufacturing checklist plus an FMCG scheme checklist.
It should test grade control, tonne reconciliation, dispatch economics and scheme settlement as one connected operating record.
Map the complete Cement operating lifecycle before choosing software
Do not begin with the sales-order screen.
Begin with the real material and commercial lifecycle.
At minimum, map the stages that apply to your business:
Then ask:
At which points can grade, physical quantity, dispatchability, freight, scheme entitlement or commercial contribution change?
Those are the points the ERP evaluation must test.
RAW MATERIAL ≠ CLINKER ≠ CEMENT
A Cement company can simultaneously hold:
These are materially different inventory and production states.
The buyer should ask:
When management says “we have 20,000 MT available”, what material, grade, location and operating state does that number actually represent?
Do not collapse all tonnes into one generic stock figure.
Inward weighbridge should be part of the ERP transaction
Confirmed exactllyERP Cement capability includes capture of inward:
- gross weight;
- tare weight;
- net weight;
linked to the relevant purchase/GRN.
exactllyERP can also connect to the weighbridge through API so weighment values can be captured automatically into the ERP.
The buyer should test:
Can the actual weighbridge result enter the ERP transaction directly, without an operator retyping the weight?
The integration should preserve the link between:
- vehicle
- weighment
- receipt
- accepted inventory
Do not treat the weighbridge as an isolated machine record.
Supplier quantity and actual weighed quantity may differ
Confirmed exactllyERP capability includes comparing supplier/challan quantity with actual weighbridge net quantity and identifying short/excess.
The buyer should test:
The supplier challan says 48.5 MT and the plant weighbridge says 47.9 MT. Which quantity becomes inventory, where is the difference recorded and what commercial consequence follows?
Do not assume supplier quantity and actual received quantity are always identical.
Keep vehicle identity connected to the inward
Confirmed exactllyERP capability includes vehicle/truck identity linked to the inward weighment and RM receipt.
The buyer should be able to ask:
Which vehicle delivered this raw-material quantity, against which receipt and at what measured weight?
That connection helps preserve physical and commercial accountability.
Raw materials should remain separately controlled
Confirmed exactllyERP Cement capability includes separately maintaining relevant materials such as:
by material and location.
Do not assume every Cement product uses the same raw-material mix.
Quarry and stockpile requirements should remain operating-model specific
Where a customer operates a quarry/stockpile model, confirmed exactllyERP capability includes quarry/stockpile/location-wise raw-material stock.
Not every Cement company owns or operates a quarry.
A grinding unit may begin its ERP responsibility at clinker inward.
The buyer should ask:
Where does our material-control responsibility actually begin?
Do not make mine planning a universal Cement ERP requirement.
Raw-material consumption should connect to clinker production where applicable
Confirmed exactllyERP capability includes linking raw-material issue/consumption to the relevant clinker production run/batch.
The buyer should ask:
Which raw-material quantities actually contributed to this clinker output?
That relationship should not require month-end spreadsheet reconstruction.
Clinker is its own controlled inventory state
Where clinker production applies, confirmed exactllyERP capability includes:
- kiln-wise clinker output;
- actual raw-material consumption versus clinker output;
- process loss/material-balance difference;
- clinker stock by applicable plant/kiln yard/silo/location;
- transfer of clinker into grinding.
The buyer should ask:
How much clinker did we produce, where is it now, and how much has already moved into grinding?
Clinker factor should be explainable
Confirmed exactllyERP capability includes clinker factor or equivalent raw-material-input-per-clinker-output analysis by run/period.
The buyer should ask:
How much relevant input did we consume to produce this clinker output?
Do not impose one universal clinker-factor benchmark.
The system should explain the customer’s own actual relationship.
CLINKER PRODUCED ≠ CLINKER AVAILABLE FOR GRINDING
Clinker production quantity is not automatically the same thing as currently available mill input.
Clinker may already be:
The buyer should ask:
How much clinker is genuinely available to this mill or plant right now?
CONTROL THE GRADE
The first Cement signature principle is:
CONTROL THE GRADE
A Cement grade should remain connected through:
- production run
- actual material mix
- quality result
- silo
- bag/bulk stock
- dispatch
- actual cost
The buyer should ask:
Can we select one Cement grade and follow it from production through silo, packing or bulk loading, stock and customer dispatch?
Grade should not disappear after production posting.
Grinding production should be grade-specific
Confirmed exactllyERP capability includes grinding production recorded by:
- Cement grade/product;
- production run;
- shift where required.
Confirmed capability also includes actual clinker, gypsum, fly ash, slag or other configured additive consumption against the grinding run.
The buyer should ask:
Which actual material quantities produced this Cement grade in this run?
Standard mix and actual mix should remain distinguishable
Confirmed exactllyERP capability includes planned/standard mix versus actual material consumption by Cement grade/run where required.
The buyer should ask:
What mix did we expect, what did we actually consume and what changed?
Do not assume one universal Cement formula.
Cement grades should remain distinct through the entire chain
Confirmed exactllyERP capability includes maintaining applicable Cement grades/products such as:
separately through:
These are examples, not a universal mandatory list.
Quality should remain linked to the actual production state
Confirmed exactllyERP capability includes quality-test results linked to the relevant:
- Cement production run;
- batch;
- grade.
The buyer should ask:
Which actual Cement stock does this quality result govern?
Do not treat quality as only a product-master specification.
Quality release should affect packing or dispatch where configured
Confirmed exactllyERP capability includes quality status/hold/release controlling whether relevant Cement stock is available for packing/dispatch where configured.
The buyer should test:
If this grade/run has not been released, can it still move into packing or dispatch?
The answer should match the company’s configured quality policy.
Cement silo inventory deserves its own operational view
Confirmed exactllyERP capability includes silo-wise inventory by:
- silo;
- Cement grade/product;
- quantity.
The buyer should ask:
Which silo contains which grade, how much is currently held and what is genuinely available for bagging or bulk loading?
Silo stock should not be confused with packed finished goods.
Cement-silo movements should preserve grade and quantity history
Confirmed exactllyERP capability includes transfer/movement between Cement silos while preserving grade/product and quantity history where required.
The buyer should test:
Move Cement from Silo A to Silo B. Can we still explain the grade and quantity history afterwards?
PRODUCED STOCK ≠ DISPATCHABLE STOCK
Produced Cement may not yet be genuinely available to fulfil a sales order.
Depending on the business, quantity may be:
The buyer should ask:
What quantity of this grade is genuinely free for a new dispatch?
BAG CEMENT ≠ BULK CEMENT
Bag and bulk Cement are two different fulfilment paths.
- Cement silo
- packing line
- packed bags
- finished stock
- truck/rake/depot/customer
- Cement silo
- bulk loader
- bulker/tanker
- outward weighbridge
- customer/project
Confirmed exactllyERP capability includes direct bulk loading/dispatch from silo/bulk inventory without passing through bag-packing stock.
The buyer should ask:
Can the ERP fulfil a bulk Cement order directly from bulk inventory without pretending that the product was packed into bags?
Packing should remain traceable to grade, line and shift
Confirmed exactllyERP capability includes bag-packing production recorded by:
- grade;
- pack/bag size;
- packing line/run;
- shift where required.
The buyer should ask:
Which grade did this packing run convert into which commercial bag format, on which line and shift?
Packing-material consumption should be connected to packed output
Confirmed exactllyERP capability includes packing-material/bag consumption linked to packing output.
The buyer should ask:
How many bags or other packing materials were actually consumed for the saleable Cement output?
This should not remain a disconnected consumables issue.
Bag rejection, damage and rework should remain separate
Confirmed exactllyERP capability includes separately recording where applicable:
- bag rejection;
- damaged bags;
- rework/repacking;
- packing loss.
Do not collapse every packing difference into one inventory adjustment.
GROSS PACKING OUTPUT ≠ SALEABLE PACKED OUTPUT
Confirmed exactllyERP capability includes comparing planned/gross packing output versus actual saleable packed output by shift/run.
The buyer should ask:
How much did the packing line process, how much became saleable stock and what explains the difference?
RECONCILE THE TONNE
The second Cement signature principle is:
RECONCILE THE TONNE
A useful Cement material chain is:
- raw-material inward
- clinker
- grinding
- Cement grade
- silo
- bag or bulk
- outward weighbridge
The buyer should ask:
Where did the tonnes go between each material state?
This is stronger than reconciling only total production versus total dispatch at month-end.
Dispatch planning should use grade-wise available stock
Confirmed exactllyERP capability includes dealer/distributor/project orders planned for dispatch against available grade-wise plant/warehouse stock.
The buyer should ask:
Before promising the order, which grade and quantity is genuinely available at the relevant plant or warehouse?
Committed stock should not remain falsely available
Confirmed exactllyERP capability includes distinguishing stock already committed to existing orders from currently available/free grade stock for dispatch planning.
The buyer should ask:
What quantity is physically present, what is already committed and what remains free for new dispatch?
Truck allocation should stay connected to the dispatch order
Confirmed exactllyERP capability includes truck allocation linked to the specific dispatch order.
The buyer should ask:
Which vehicle is fulfilling which order, for which grade and quantity?
Do not treat truck allocation as a separate logistics spreadsheet.
Outward weighbridge should close the physical dispatch record
Confirmed exactllyERP capability includes outward gross/tare/net weighbridge values linked to:
- dispatch order;
- invoice.
exactllyERP can connect to the weighbridge through API so the weighment can be captured automatically into the ERP.
The buyer should test:
Can the actual outward weighment enter the dispatch transaction automatically and remain linked to the invoice?
Actual outward net MT should reconcile with dispatch and invoice
Confirmed exactllyERP capability includes reconciling actual outward net MT with dispatch/invoice quantity.
The buyer should ask:
What quantity did we intend to dispatch, what did the weighbridge measure and what quantity did we finally invoice?
Those quantities should be explainable.
Inter-plant movement should reconcile both sides where required
Confirmed exactllyERP capability includes verifying inter-plant/inter-location transfers through inward/outward weighbridge movements where required.
The buyer should ask:
What left Plant A and what actually arrived at Plant B?
The two sides should not rely on separate manual statements.
TRADE SALE ≠ PROJECT / NON-TRADE SALE
Trade and project sales can require different operating controls.
- dealer/distributor
- recurring lifting
- scheme
- credit
- dispatch
- collection
- project/customer PO
- committed quantity
- staged dispatch
- site delivery
- freight
- cumulative billing
The buyer should ask:
Which controls genuinely differ between our trade and project business?
Do not force them into one universal order process.
Project orders need cumulative quantity control
Confirmed exactllyERP capability includes project/customer PO with:
- total ordered quantity;
- cumulative dispatch quantity;
- remaining balance quantity.
Confirmed capability also includes multiple dispatches/invoices traced against one long-duration project PO.
The buyer should test:
Take one 20,000 MT project order and part-dispatch it over several deliveries. What has been dispatched, billed and still remains?
Truck and rake movements should remain distinguishable
Confirmed exactllyERP capability includes separate tracking of truck and/or railway-rake dispatch movements where the customer uses those modes.
Do not make railway dispatch universal.
The buyer should ask:
Which dispatch mode carried this quantity and what operational/freight record belongs to it?
Freight belongs inside Cement economics
Confirmed exactllyERP capability includes freight cost per MT analysis by:
where required.
The buyer should ask:
What did it actually cost to move this tonne to this customer or market?
Freight should not disappear into one general expense pool if route/customer economics matter.
Standard freight and actual freight should be compared where required
Confirmed exactllyERP capability includes standard/planned freight versus actual freight variance by dispatch/route where required.
The buyer should ask:
What freight did we expect, what did we actually incur and where did the variance arise?
Do not impose one universal freight standard.
Cost per MT should include the cost drivers the business actually uses
Confirmed exactllyERP capability includes actual Cement cost per MT by grade using relevant actual:
- raw-material cost;
- energy cost;
- processing cost;
- packing cost.
The buyer should ask:
What did this grade actually cost per MT, based on the costing method we use?
Do not impose one universal Cement costing formula.
Energy should be connected to Cement cost
Confirmed exactllyERP capability includes energy consumption/cost allocated or analysed against relevant:
according to the customer’s costing method.
The buyer should ask:
How is actual energy consumption or cost affecting our cost per MT?
Do not claim one mandatory allocation method.
Contribution should include relevant freight and commercial effects
Confirmed exactllyERP capability includes contribution/margin analysis by:
using actual cost and relevant freight/commercial effects where required.
The buyer should ask:
Which grade/customer/region is actually contributing after the relevant cost, freight and commercial effects?
Do not impose one universal contribution formula.
Sales schemes are a core Cement requirement
Cement scheme management should not be treated as a small side feature.
Schemes may be defined for:
Different beneficiary classes may earn benefits for different behaviours.
The buyer should ask:
Who is the beneficiary, what behaviour qualifies them, what transaction evidence proves that achievement and what remains to be settled?
SETTLE THE SCHEME
The third Cement signature principle is:
SETTLE THE SCHEME
A Cement scheme may involve:
- beneficiary
- grade/product
- territory/region
- validity period
- target/slab
- qualifying lifting/purchase
- achievement
- benefit
- approval
- claim/redemption/payment
- outstanding liability
The exact structure differs by company.
The buyer should not ask merely:
“Does your ERP support dealer schemes?”
The better test is:
Can the system prove exactly why this beneficiary earned this benefit and whether that benefit has actually been settled?
Distributor schemes should remain separately controllable
Confirmed exactllyERP Cement capability includes defining and settling schemes specifically for distributors.
The buyer should ask:
Which distributor transactions count toward this scheme and what benefit has been earned so far?
Do not assume distributor and dealer schemes use identical rules.
Dealer and retailer schemes should remain separate from distributor schemes
Confirmed exactllyERP capability includes separately defining and settling dealer/retailer schemes.
The buyer should ask:
What is the dealer’s own scheme basis, independent of the distributor’s scheme?
The two beneficiary levels should not be collapsed if the business distinguishes them.
Consumer schemes should also be supported where the programme requires them
Confirmed exactllyERP capability includes schemes/benefits for end consumers or individual-house-builder-type beneficiaries where the company operates such programmes.
The buyer should ask:
What evidence proves that the consumer actually qualified?
Do not assume every Cement company operates consumer schemes.
Beneficiary class should be explicit
Confirmed exactllyERP capability includes explicitly targeting scheme beneficiary class such as:
The buyer should ask:
Who is eligible for this scheme, and who is not?
Beneficiary type should not be inferred later from transaction history.
Scheme eligibility can use multiple commercial dimensions
Confirmed exactllyERP capability includes Cement scheme eligibility using combinations of:
The buyer should ask:
Exactly which conditions must be true for this transaction or beneficiary to qualify?
Do not assume lifting quantity alone determines every scheme.
DEALER LIFTING ≠ SCHEME EARNING
A dealer may lift Cement without all of that volume necessarily qualifying for one specific scheme.
Eligibility can depend on:
Confirmed exactllyERP capability includes calculating qualifying lifting/purchase and achievement against the relevant scheme target/slab.
The buyer should ask:
Exactly which invoices, dispatches or purchases contributed to this scheme achievement?
Progressive slabs should remain visible
Confirmed exactllyERP capability includes progressive/slab-based achievement levels with different benefits.
The buyer should test:
What happens when the beneficiary moves from one achievement slab into the next?
The system should explain the benefit logic rather than simply display a final amount.
Scheme benefit can take different forms
Confirmed exactllyERP capability includes configured benefit forms such as:
Do not imply every benefit settles financially in the same way.
Scheme qualification should be transaction-backed
Confirmed exactllyERP capability includes tracing the exact invoices/dispatches/purchases contributing to scheme qualification.
The buyer should ask:
Show every transaction that created this scheme achievement.
Scheme earning should not depend only on a manually maintained total.
Consumer scheme evidence needs its own proof event
Where consumer schemes are used, confirmed exactllyERP capability includes capturing a qualifying consumer purchase/claim or another configured evidence transaction against the beneficiary.
The buyer should ask:
What transaction or claim proves that this consumer earned the benefit?
Do not assume the evidence mechanism is identical to dealer lifting.
Earned benefit and settled benefit are different states
Confirmed exactllyERP capability includes keeping:
- earned/accrued scheme benefit;
- approved benefit;
- settled/redeemed benefit;
distinct.
The buyer should ask:
What has been earned, what has been approved and what has actually been paid or redeemed?
Do not collapse accrual and settlement into one status.
Scheme liability should remain visible
Confirmed exactllyERP capability includes pending scheme liability reporting by:
where required.
The buyer should ask:
What benefit has already been earned but remains commercially outstanding?
That liability should not have to be reconstructed after the scheme closes.
Scheme claims and settlements should follow configured approvals
Confirmed exactllyERP capability includes configured approval workflows for scheme claims/settlements.
The buyer should ask:
Who approves this scheme claim, under what rule and what evidence remains afterwards?
Approval should be governed.
Scheme settlement should match the scheme mechanism
Confirmed exactllyERP capability includes settlement through appropriate configured mechanisms such as:
The buyer should ask:
How is this specific benefit actually discharged and how do we know it is no longer outstanding?
Closed schemes should preserve their history
Confirmed exactllyERP capability includes preserving expired/closed scheme history, including:
- original rules;
- eligibility;
- achievement;
- settlement history.
The buyer should ask:
Can we reconstruct why this beneficiary earned or did not earn a benefit after the scheme has closed?
Overlapping schemes need separate eligibility
Confirmed exactllyERP capability includes handling more than one active scheme for the same dealer/distributor/product where business rules permit, with eligibility kept distinct.
The buyer should test:
Take one transaction that could interact with two active schemes. Show exactly how each scheme evaluates it independently.
Do not assume schemes are always mutually exclusive.
Credit still matters before dispatch
Relevant broader exactllyERP capability already includes:
- dealer/distributor credit limits;
- utilisation/outstanding checks;
- holds/approvals;
- advances;
- collections.
The Cement-specific question is:
Can grade availability, dispatch readiness, credit and applicable scheme treatment be considered together before the truck is released?
Do not re-teach the full FMCG credit framework here.
Decide what belongs in ERP, weighbridge, plant, lab, logistics and scheme systems
Not every Cement function has to live in one application.
An operating environment may include:
The buyer should ask:
Which system owns the production quantity?
Which system owns the weighbridge measurement?
Which system owns grade-quality release?
Which system owns silo and finished stock?
Which system owns the dealer/project order?
Which system owns scheme eligibility?
Which system owns consumer claim evidence?
Which system owns scheme liability and settlement?
Which system owns freight and contribution?
What happens when an interface fails?
exactllyERP can connect to weighbridges through API to capture weight automatically into the ERP.
Do not assume every specialist system must be replaced.
The goal is one trustworthy production-to-dispatch-to-commercial record.
Make the vendor demonstrate the difficult Cement scenarios
Do not allow the Cement ERP demonstration to become a tour of production reports, dealer masters and scheme screens.
Give every shortlisted vendor the same difficult scenarios.
Record what is standard, configured, extended or custom
After every important Cement scenario, classify how the proposed result is delivered.
The proposed product supports the requirement as part of its normal capability.
The result depends on masters, workflows, grade structures, scheme rules, costing policies or other configured behaviour.
Another application such as weighbridge, plant/MES, lab, dealer/consumer platform or logistics system forms part of the proposed solution.
Development is required specifically for the requirement.
The claim remains proposed until evidence is provided.
None of these labels is automatically good or bad.
The buyer needs to know what will actually exist in production.
Cement ERP red flags
Weighbridge operates separately from ERP
Actual physical quantity may be retyped or disconnected from the receipt/dispatch transaction.
Weighbridge API exists in the proposal but the live weight is still re-entered manually
The claimed integration is not actually controlling the transaction.
Supplier quantity and actual weighment cannot be reconciled
The received tonne is not trustworthy.
Vehicle identity is lost after weighment
Physical accountability is incomplete.
Raw material, clinker and Cement are collapsed into generic stock
The material state cannot be explained.
Quarry/stockpile quantity is disconnected from production where relevant
Integrated material flow is broken.
Clinker production and grinding consumption are reconciled only monthly
Operational balance is reconstructed too late.
Clinker loss/material balance cannot be explained
Output is visible but the material path is not.
Clinker stock is not location-specific
Available mill input can be overstated.
Cement grade disappears after production
Silo, packing and dispatch cannot preserve product identity.
Standard and actual grinding mix are not distinguishable
Material variance is invisible.
Quality result is detached from the production run
Dispatch eligibility cannot be defended.
Quality hold has no effect on packing/dispatch where policy requires it
Control is informational rather than operational.
Silo inventory is not grade-specific
Bulk custody is unreliable.
Produced stock is assumed to be dispatchable stock
Committed/held/unreleased quantity is overstated as available.
Bag and bulk Cement are treated identically
Bulk fulfilment is forced through the wrong inventory path.
Packing-material consumption is not linked to output
Packing economics cannot be reconciled.
Bag rejection or rework is posted as general adjustment
Saleable packed output cannot be explained.
Outward weighbridge is disconnected from dispatch and invoice
The shipped tonne is not tied to the commercial record.
Inter-plant transfer cannot reconcile dispatch and receipt
Material can disappear between locations.
Project PO does not show cumulative dispatch and balance
Long-duration supply must be reconstructed manually.
Truck and rake dispatches are mixed together where operationally different
Dispatch mode economics and control become unclear.
Freight is posted only as a general expense
Customer/route economics are hidden.
Planned and actual freight cannot be compared
Freight variance is unmanaged.
Cost per MT ignores actual energy
Cement economics are incomplete.
Contribution ignores relevant freight or commercial effects
Market/customer profitability is overstated.
Distributor scheme exists only in a spreadsheet
Eligibility and liability are outside the operating system.
Dealer scheme is treated as the distributor’s scheme
Beneficiary logic is collapsed.
Consumer scheme is treated like dealer lifting
The evidence model is wrong.
Beneficiary identity is unclear
The system cannot explain who earned the benefit.
Scheme eligibility depends on salesperson judgement
Rules are not controlled.
DEALER LIFTING is treated as automatically equal to SCHEME EARNING
Non-qualifying transactions can inflate achievement.
Scheme achievement is not transaction-backed
The earned benefit cannot be proven.
Progressive slabs are calculated manually
Threshold effects are error-prone.
Consumer reward has no evidence trail
The benefit cannot be tied to an eligible purchase/claim.
Earned and settled benefit are one number
Outstanding liability is hidden.
Scheme liability is reconstructed after scheme closure
Finance cannot see exposure while it is being earned.
Claims/settlements bypass approval workflow
Scheme governance is weak.
Closed scheme history loses the original rules
Past entitlement cannot be reconstructed.
Overlapping schemes merge their eligibility logic
The company cannot explain which scheme caused which benefit.
Credit is checked only after dispatch
Exposure is controlled too late.
Trade and project sales are forced into identical controls
Different selling models lose important operating distinctions.
Customer proof consists only of a Cement-industry logo
The reference does not reduce uncertainty about grade, tonne, dispatch or scheme control.
A practical Cement ERP evaluation record
For each critical workflow, record the evidence.
| Evaluation area | What the buyer should establish |
|---|---|
| Operating model | Which parts of the Cement chain the business owns |
| RM type | Which raw material is being controlled |
| RM location | Quarry/stockpile/warehouse/plant location |
| Supplier quantity | What the supplier/challan states |
| Inward gross | What the weighbridge measures |
| Inward tare | What tare is captured |
| Inward net | What actual net material is received |
| Weighbridge API | Whether the weight enters ERP automatically |
| Short/excess | How supplier vs weighed quantity differs |
| Vehicle | Which truck belongs to the receipt |
| Accepted RM | What quantity becomes inventory |
| RM consumption | What material actually enters clinker production |
| Kiln/run | Which production run applies |
| Clinker output | What clinker was produced |
| Clinker loss | What material-balance difference exists |
| Clinker factor | Input/output relationship by run/period |
| Clinker stock | Where clinker is held |
| Clinker transfer | What moves into grinding |
| Grinding run | Which grade/product run applies |
| Actual clinker/additives | What material was actually consumed |
| Standard mix | What consumption was expected |
| Actual mix | What consumption occurred |
| Cement grade | Which grade/product was produced |
| Quality result | Which test result belongs to the grade/run |
| Quality release | Whether stock is eligible to move |
| Cement silo | Where bulk Cement is held |
| Silo grade | Which product occupies the silo |
| Silo transfer | How grade/quantity history survives movement |
| Produced stock | What quantity exists after production |
| Committed stock | What is already promised |
| Dispatchable stock | What is genuinely free |
| Bag packing | Which grade/pack/line/shift applies |
| Packing material | What bags/material were consumed |
| Bag rejection | What output is not saleable |
| Rework/repacking | What quantity re-enters packing |
| Packing loss | What conversion loss remains |
| Saleable packed output | What can actually be dispatched |
| Bulk Cement | What quantity can load directly from silo |
| Bag vs bulk | Which fulfilment path applies |
| Dealer/distributor order | Which trade order is being fulfilled |
| Project PO | Which project commitment is being fulfilled |
| Project cumulative dispatch | What has been supplied to date |
| Project balance | What remains to supply |
| Truck allocation | Which truck is assigned to which order |
| Rake dispatch | Which rail movement applies where used |
| Outward gross | What loaded gross weight is measured |
| Outward tare | What tare is measured |
| Outward net | What actual Cement quantity left |
| Outward API | Whether weighment enters ERP automatically |
| Dispatch/invoice reconciliation | How actual net MT matches commercial quantity |
| Inter-plant transfer | How outward and inward reconcile |
| Freight per MT | What movement cost applies |
| Planned freight | What was expected |
| Actual freight | What was incurred |
| Freight variance | Why cost differed |
| Actual cost/MT | What the grade actually cost |
| Energy cost | How energy affects the relevant cost |
| Contribution | What remains after relevant effects |
| Trade vs project | Which commercial model applies |
| Scheme beneficiary | Distributor/dealer/retailer/consumer/other |
| Scheme product/grade | What product qualifies |
| Scheme territory | Where the scheme applies |
| Scheme validity | When it applies |
| Scheme target/slab | What achievement threshold applies |
| Qualifying lifting/purchase | What transactions count |
| Scheme achievement | What target/slab has been reached |
| Progressive slab | What benefit changes at each level |
| Scheme benefit | What monetary/credit/discount/reward applies |
| Transaction evidence | Which invoices/dispatches/purchases contributed |
| Consumer evidence | What purchase/claim proves entitlement |
| Earned benefit | What has accrued |
| Approved benefit | What has been authorised |
| Settled/redeemed benefit | What has actually been discharged |
| Pending liability | What remains outstanding |
| Scheme approval | Who approved the claim/settlement |
| Scheme settlement | How the benefit is discharged |
| Scheme history | What original rules/achievement remain after closure |
| Overlapping schemes | How separate eligibility is preserved |
| Credit | What exposure exists before dispatch |
| Collection | What remains outstanding |
| System boundary | ERP/weighbridge/plant/lab/scheme/logistics ownership |
| Delivery method | Standard / configuration / extension / custom / not demonstrated |
| Follow-up | What evidence remains unresolved |
Do not turn this into a percentage score.
One unresolved weighbridge, grade, dispatch, freight or scheme-settlement requirement can matter more than many minor feature matches.
What customer proof should a Cement ERP vendor provide?
A useful customer reference is not simply another Cement company.
Ask for proof closest to the uncertainty you are trying to remove.
If your concern is weighbridge control, ask:
Which customer captures actual inward and outward weighments directly into ERP and reconciles them to receipt/dispatch?
If your concern is grade control, ask:
Which customer can follow Cement grade from production through silo, packing/bulk and dispatch?
If your concern is project supply, ask:
Which customer can show one long-duration project PO with cumulative dispatch and balance?
If your concern is freight, ask:
Which customer can show actual route/transporter/customer freight and contribution per MT?
If your concern is schemes, ask:
Which customer can show transaction-backed distributor/dealer/consumer eligibility, scheme achievement, accrued liability and settlement history?
Customer evidence should validate the difficult workflow.
Not decorate the proposal.
At present, do not use an unapproved named Cement customer as proof.
If no approved customer story exists, product truth should be demonstrated directly.
How exactllyERP fits into this evaluation
exactllyERP should be evaluated against the same difficult Cement scenarios.
Do not ask Exactlly only:
“Do you support Cement?”
Bring the actual operating model.
Include:
- raw-material structure;
- quarry/stockpile model where applicable;
- supplier quantity;
- inward weighbridge process;
- weighbridge API requirement;
- clinker production;
- clinker stock and transfers;
- grinding;
- Cement grades/products;
- actual mix;
- quality release;
- silo structure;
- packing;
- packing-material consumption;
- bulk Cement;
- dispatchable-stock rules;
- trade orders;
- project orders;
- truck/rake model;
- outward weighbridge;
- inter-plant transfers;
- freight model;
- cost/MT;
- energy allocation;
- contribution model;
- distributor schemes;
- dealer/retailer schemes;
- consumer schemes;
- beneficiary hierarchy;
- scheme targets/slabs;
- reward/benefit forms;
- consumer evidence model;
- approval;
- liability;
- settlement;
- overlapping-scheme rules;
- credit;
- collections;
- connected-system boundaries.
Confirmed exactllyERP Cement operating capabilities
Confirmed exactllyERP Cement scheme capabilities
Confirmed current Cement scheme capability includes:
- distributor-specific schemes defined and settled;
- dealer/retailer schemes separately defined and settled;
- end-consumer / individual-house-builder-type schemes where the company operates such programmes;
- beneficiary class explicitly targeted as distributor, dealer, retailer, consumer or another configured category;
- eligibility using combinations of grade/product, quantity/lifting, territory/region, validity period, target/slab and other configured commercial criteria;
- qualifying lifting/purchase and achievement calculated against scheme target/slab;
- progressive/slab-based achievement levels with different benefits;
- benefits configured as monetary amount/credit, discount, reward points, gift/reward entitlement or another configured benefit type;
- exact invoices/dispatches/purchases contributing to scheme qualification traced;
- qualifying consumer purchase/claim or another configured evidence transaction captured against the beneficiary where consumer schemes are used;
- earned/accrued benefit kept separate from approved/settled/redeemed benefit;
- pending scheme liability reported by scheme, beneficiary type, distributor/dealer/consumer, region and period where required;
- scheme claims/settlements following configured approval workflows;
- scheme benefit settled through appropriate configured mechanisms such as credit, financial settlement, reward redemption or another configured method according to the scheme;
- expired/closed schemes preserving original rules, eligibility, achievement and settlement history;
- more than one active scheme handled for the same dealer/distributor/product where business rules permit, with eligibility kept distinct.
Confirmed weighbridge API integration
exactllyERP can connect to weighbridges through API so weighment values can be captured automatically into the ERP.
This should be demonstrated against the customer’s actual weighbridge environment.
Do not invent universal support for every weighbridge make/interface without implementation validation.
Relevant broader Exactlly capabilities also apply, including:
- multi-plant / multi-location inventory;
- production/work orders;
- actual material consumption;
- standard-versus-actual costing;
- production loss/rejection/rework;
- quality hold/release;
- actual production costing;
- distributor/dealer schemes generally;
- credit limits/holds/overrides;
- advances;
- collections;
- management reporting;
- mobile/field workflows where relevant;
- finance and receivables;
- integration according to implementation requirements.
These broader capabilities should remain separate from the 40 Cement operating capabilities and the 16 Cement scheme capabilities.
The relevant buyer questions remain:
What grade and quantity did we actually produce, and what did it cost?
Where did each tonne go — clinker, silo, bag, bulk, depot, dealer or project?
Who earned which scheme benefit, on what evidence, and what remains to be settled?
Cement ERP Evaluation Checklist
Operating model
Raw-material inward
Weighbridge integration
Quarry / stockpile
Clinker production
Clinker stock / transfer
Grinding / grade
Quality
Cement silos
Dispatchable stock
Bag packing
Bulk Cement
Dealer/distributor/project dispatch
Outward weighbridge
Inter-plant transfer
Project supply
Truck / rake
Freight
Cost per MT
Energy
Contribution
Scheme beneficiary
Scheme eligibility
Scheme achievement
Scheme benefit
Consumer scheme
Scheme liability
Scheme approval / settlement
Scheme history
Overlapping schemes
Credit / collection
Integration / coexistence
Vendor evidence
the buyer is evaluating ERP as the evidence system for a real Cement production-to-dispatch-to-scheme operation rather than as a list of production, weighbridge and dealer features.