The Problem: Product Costs That Don’t Match Reality
For a manufacturing client running an ERP-driven production process, a recurring question kept coming up at management review: “Why does the system-calculated cost of this product not match what we know it actually costs to make?”
It’s a familiar frustration. Finance sees one number. Production knows, from experience, that the real cost is different. And every time a new product is costed or a variance report is pulled, someone ends up “adjusting” the number manually before it goes into a decision.
The instinctive reaction in situations like this is to question the ERP itself. But when we looked closely at this client’s environment, the system was doing exactly what it was told to do. The real issue was upstream — in how the Bill of Materials (BOM) was structured and maintained, and in how transactional data was being entered day to day.
Digging Into the Root Cause
An ERP costing engine is only as accurate as the BOM and transaction data feeding it. We reviewed the client’s BOM master and a sample of production transactions and found a consistent pattern of gaps, not a single big error:
- Outdated BOMs — several hadn’t been updated after engineering or process changes, so the system was still costing products using an older mix of components and quantities
- Incorrect component quantities — copy-paste habits when creating new BOMs from similar products had carried over quantities that didn’t match actual shop-floor consumption
- Missing or wrong UoM conversions — a handful of BOM lines had conversion factors that were never corrected after initial setup
- Inconsistent data entry at production confirmation — operators sometimes entered round-number approximations rather than actual issued quantities, and byproduct or scrap quantities weren’t always captured
- Overhead and costing method assumptions — some products were costed against standard/default absorption rates that no longer reflected current shop-floor reality
None of this was a system defect. It was the natural drift that happens when BOMs are created once during implementation and then updated informally, without a defined review cycle — combined with data entry that isn’t governed by validation checks.
The Practical Solution
We approached this the same way we approach any process or audit engagement: fix the root cause, then build controls so it doesn’t recur.
1. BOM cleanup and validation
We ran a structured review of every active BOM against current bills of engineering, actual component consumption data, and unit-of-measure setups — correcting quantities, conversion factors, and component lists where they had drifted from reality.
2. Standardized the BOM change process
We defined a clear approval workflow for any BOM creation or revision, so changes go through a review step instead of being copied from a similar product and adjusted on the fly.
3. Tightened data entry at the shop floor
We worked with the client to build simple validation checks at the point of production confirmation — flagging entries where actual consumption deviates significantly from the BOM standard, instead of letting silent overrides accumulate unnoticed.
4. Reconciled costing assumptions
Overhead absorption and costing method settings were reviewed and reset against current actuals, so the system’s calculated cost reflects the business as it runs today, not as it was configured years ago.
The Result
- Standard product costs now reliably match what production and finance both expect
- Variance reports highlight genuine, actionable exceptions instead of noise from bad master data
- New BOMs go through a defined review step, preventing the same drift from creeping back in
- Management can trust the system’s costing output for pricing and margin decisions, without manual adjustment
The Bigger Lesson
Costing issues in an ERP are almost always a data and process story, not a software story. The system calculates exactly what the BOM and the transactions tell it to calculate. When costs look wrong, the more useful question isn’t “what’s wrong with the system” — it’s “what’s wrong with what we’re feeding it, and why.”
Getting this right isn’t a one-time cleanup either. It requires a defined discipline around how BOMs are created, changed, and reviewed, and how shop-floor data is captured — so accurate costing becomes the default outcome, not a periodic firefighting exercise.
Kriarj Business Consultants Private Limited helps businesses strengthen their master data, BOM governance, and shop-floor data discipline to get more reliable, decision-ready output from their ERP systems. If your product costing doesn’t match reality, get in touch, and we’d be glad to take a look.
