You can tune your MRP parameters for months, harden your interfaces, and pass every reconciliation audit — and still hand your planners numbers that are wrong by a factor of ten. Not because the engine miscalculated, but because the same physical part is stored as "EA" in one plant, "BOX" in another, and "PK" in a third, with no conversion factor tying them together. To SAP, Oracle, or Maximo, those are three different realities for one bolt. And the system will faithfully calculate the wrong answer every single time.
If you sit on a SAP, Oracle, or Maximo team, you already know that your platform only ever returns the consequence of the data you feed it. Unit of measure (UoM) inconsistency is one of those quiet, structural data faults that never throws an error message — it simply produces confident, precise, and completely unreliable output. This article looks at why inconsistent UoM corrupts MRP, inventory, and costing across your landscape, why it's a master data problem rather than a configuration problem, and what it actually takes to fix the underlying catalogue so your systems can finally be trusted.
When the Same Part Speaks Two Different Languages
Every ERP and EAM platform is built on a base unit of measure. In SAP it's the base UoM in the material master, with alternative units and conversion factors held in MARM. In Maximo it's the issue and order units linked by a conversion. In Oracle EBS and Fusion it's the primary UoM with its conversion classes. The architecture is sound. The problem starts the moment the data sitting inside that architecture stops being consistent.
Consider a hydraulic seal kit that one site procures and stocks as "each", while another site catalogues the identical kit as a "set" of five, and a third receives it as a "box". If those records were ever consolidated into a single material number without a verified conversion, the system now believes that one each, one set, and one box are interchangeable. They are not. The same disconnect plays out constantly with lubricants stored as litres in one record and drums in another, cable measured in metres against rolls, gaskets counted individually against packs, and grease ordered by the cartridge against the carton. Each of these looks trivial in isolation. Across a master with hundreds of thousands of line items, it becomes a systemic source of error that no amount of clever planning logic can compensate for.
The reason this is so dangerous is precisely that it's invisible. A missing material number triggers a hard stop. An inconsistent unit of measure triggers nothing — the transaction posts, the planning run completes, the report renders cleanly. The corruption travels silently downstream, and by the time someone notices, it has already shaped procurement decisions, valuation, and stock positions across the landscape.
How a Single Wrong Unit Cascades Through MRP, Inventory, and Costing
The damage from inconsistent UoM is rarely contained to one transaction. It compounds as the bad unit propagates through every dependent calculation, and for an ERP or EAM team, that cascade is where the real pain lives.
MRP and demand planning. When your planning run reads a reorder point expressed in one unit and on-hand stock expressed in another, the netting logic produces nonsense. A min-max set in "boxes" compared against stock counted in "each" will either flood you with purchase requisitions for inventory you already hold or starve a critical asset of the spare it needs. Planners lose trust in the suggestions, start overriding the system manually, and the very automation you invested in quietly becomes shelf-ware.
Inventory valuation and accuracy. Stock value is quantity multiplied by unit price, and both halves of that equation assume a consistent unit. If goods are received in one UoM and issued in another without a correct conversion, your moving average price drifts, your on-hand quantity stops matching the physical shelf, and cycle counts never reconcile. Finance sees a balance sheet number that no longer reflects reality, and your team gets pulled into reconciliation exercises that treat the symptom instead of the cause.
Procurement and spend. Purchasing converts demand into orders using the order unit. When that unit is wrong or inconsistent across duplicate records for the same item, buyers order the wrong pack size, miss volume breaks they were entitled to, and re-purchase parts that are already sitting in another store under a different unit. The organisation pays twice — once for the duplicate stock, and again for the working capital trapped on the shelf.
Maintenance and asset availability. For Maximo and EAM teams, inconsistent issue units mean a work order reserves the wrong quantity of a spare. A technician arrives expecting a full reel of cable and finds a single metre, or a planned job is held because the system thinks stock is short when a full drum is sitting in the warehouse under a different unit. Asset availability — the entire point of the platform — takes the hit.
Each of these failures looks like a different problem to a different department. Planning blames the parameters, finance blames the count, procurement blames the supplier, and maintenance blames the store. In reality they are all reading from the same corrupted page.
Why This Is a Data Problem, Not a Configuration Problem
It's tempting for a systems team to treat UoM inconsistency as a config issue — tighten the conversion tables, add a validation rule, lock the field. Those steps help going forward, but they don't touch the data already sitting in your master, and that's where the damage is.
The honest diagnosis is this: inconsistent units of measure are almost always a symptom of poor material master data quality, not a defect in the ERP itself. SAP, Oracle, and Maximo are doing exactly what they were configured to do. The records they're operating on are the problem — duplicate entries for the same physical part created independently across sites and eras, each with its own description, its own classification, and its own unit, all entered by well-meaning people working without a shared standard.
Once you accept that framing, the path forward changes. You stop trying to fix calculations and start fixing the catalogue underneath them. That means a normalised, deduplicated material master where every physical item exists exactly once, described consistently using a structured noun-modifier convention, classified against a recognised standard such as UNSPSC or NSC, and assigned a single, governed base unit with verified conversions for every alternate unit. When the catalogue is clean, the UoM problem doesn't get patched — it stops existing, because there's no longer a second record with a conflicting unit for the engine to trip over.
This is also why a one-off cleanse never holds. Without governance, new duplicates and inconsistent units creep back in within months, and you're back where you started. The fix has to be structural and sustained, embedded in how material data is created and maintained, not a project that ends.
What Clean UoM Standardisation Actually Looks Like
Standardising units of measure across a large, multi-site landscape is methodical work, but the shape of it is consistent regardless of whether you run SAP, Oracle, or Maximo. It helps to think of it in distinct stages rather than a single sweep.
Establish the base unit. For every material, decide and enforce a single base unit of measure that reflects how the item is genuinely stored and consumed. This becomes the anchor that every other unit references, and it has to be applied uniformly across every plant and storage location, not left to local discretion.
Map and verify conversions. Every legitimate alternate unit — the order unit, the issue unit, the pack — needs a correct, verified conversion factor back to that base unit. A drum is 208 litres, a box is twelve each, a roll is one hundred metres. These factors must be confirmed against the physical reality and the supplier specification, not assumed.
Collapse the duplicates. Where the same physical part exists under several material numbers with conflicting units, those records have to be reconciled into one. This is the step that most directly stops the bleeding, because it removes the conflicting realities the system was choking on, and it's also the step that's hardest to do safely by hand at scale.
Lock in governance. Finally, the rules that produced the clean state have to be enforced at the point of creation, so that no new record can be raised without a valid base unit, a recognised classification, and consistent conversions. Without this last stage, the gains erode and the inconsistency returns.
Done well, the payoff lands exactly where your team feels the pain: MRP runs you can trust, valuations that reconcile, procurement that stops buying what you already own, and maintenance that finds the spare where the system said it would be.
How the Spares Cataloguing System Enforces UoM Integrity at the Source
This is precisely the work the Spares Cataloguing System (SCS®) is built to do — and it's why so many ERP and EAM teams treat clean, normalised material data as the foundation that makes their platform investment finally pay off. Rather than patching calculations after the fact, SCS attacks the root cause inside the catalogue and keeps it clean. A few of its core capabilities are worth understanding from a systems perspective.
Master Data Management and Normalisation. SCS restructures unstructured, inconsistent material descriptions into a standardised noun-modifier format, so the same part is described the same way everywhere. That consistency is what makes a single base unit enforceable in the first place — you can't standardise a unit on a record nobody can reliably identify.
Intelligent Search Engine. A genuine root cause of duplicate records, and the conflicting units that ride on them, is that people can't find the part that already exists, so they create a new one. The SCS search engine lets analysts and end users locate an existing item quickly and confidently, which prevents the next inconsistent UoM from ever being born.
Duplicate Detection. SCS identifies records that represent the same physical item across sites and material numbers, exposing exactly the conflicting-unit situations that quietly break MRP and valuation. Collapsing those duplicates is what removes the contradictory realities your planning engine has been tripping over.
Standardised UoM and Conversion Governance. With a clean, deduplicated catalogue underneath, base units and verified conversions can be applied and enforced consistently, so what flows into your ERP is unit-correct by construction rather than corrected after the damage is done.
ERP, EAM, and CMMS Integration. SCS is designed to feed clean, governed material data into your existing landscape — SAP, Oracle, Maximo and others — so the system of record receives data it can actually calculate on. It complements your platform rather than replacing it.
Dashboards and Reporting. Data quality only stays high if it's visible. SCS surfaces the real state of your material master — duplication rates, classification coverage, unit consistency — so governance becomes measurable and defensible rather than a matter of faith.
You can see the full breakdown of these capabilities on the Spares Cataloguing System key features page, and how they connect to your broader material master data governance picture.
Conclusion
Inconsistent units of measure are the kind of fault that doesn't announce itself. There's no error log, no failed interface, no red flag in a dashboard — just confident, precise output that happens to be wrong, quietly steering procurement, planning, and valuation in the wrong direction. For a SAP, Oracle, or Maximo team, the frustrating part is that the platform is doing nothing wrong. It's calculating exactly what the data tells it to.
That's the reframe worth holding onto: this is not a configuration gap to be plugged with another validation rule, and it's certainly not a failing of your team. It's a material master data quality problem — duplicate records, inconsistent descriptions, and ungoverned units that no planning logic can calculate its way around. Fix the catalogue, and the unit problem doesn't get managed. It disappears. The cost of leaving it unaddressed, on the other hand, only compounds: more duplicate purchasing, more working capital stranded on shelves, more reconciliation hours, and more eroded trust in the very systems you've invested so much to run.
Before Your Next Big System Initiative, Ask the Simpler Question
Before the next ERP upgrade, the next data migration, or the next push to automate planning — there's a simpler question worth answering first: can you actually trust the material master your systems are calculating on?
Because when that data is inconsistent, the consequences land squarely on your team. Planning runs you can't rely on. Inventory positions that never reconcile. Parts purchased that already sit on a shelf under a different unit. Working capital frozen in duplicate stock. And your best people burning hours hunting for the right record instead of making decisions.
The problem, more often than not, isn't your SAP, Oracle, or Maximo configuration — and it isn't your team. It's the quality, governance, and searchability of the material master data sitting underneath: descriptions, classification, and units of measure that were never standardised in the first place.
That's why, at Panemu, we help organisations see the real state of their material master through a free consultation and data analysis — identifying the hidden inconsistencies, assessing data quality, and giving you practical recommendations to build a stronger foundation for procurement, maintenance, and supply chain.
Because better calculations start with better data — and the biggest savings are usually not in cutting stock, but in finally being able to trust the stock you already have.
Curious whether your material master is helping your systems deliver — or quietly breaking them?
Send us a sample of your material master data, and we'll assess it for you. Start your free Material Master assessment at https://panemu.com/scs-key-feature.