In short: A conversion factor is a multiplier sitting between two systems, so an error in one produces a clean multiple rather than noise, and every quality check built around variance and outliers will pass it. The failures that happen in practice are a stale factor after a supplier changed the pack, a factor applied in the wrong direction, one unit code meaning two different physical quantities at two sites, and a conversion applied twice across an interface. Receipt data gives you a free audit: divide the base quantity booked by the pack count on the despatch advice and compare it with the stored factor. Correcting the factor leaves the harder half, a demand history recorded in mixed units, which wants the conversion effective dated rather than overwritten.
The item sells around a thousand units a week. The proposal that came out of last night's run is for twelve thousand, and nobody signs it, because twelve weeks of cover on a fast mover is obviously wrong. Twenty minutes later somebody works out that demand history is held in eaches, the order policy is written in cases, and the conversion on the item record is 1.
That one is harmless because it is loud. The expensive version is quiet. The stored conversion says ten units to a case. The supplier moved to a twelve pack eighteen months ago and told the buyer, who updated the price and nothing else. Since then every replenishment for a thousand units has raised a hundred cases and brought back twelve hundred. Receiving scans cases, multiplies by ten, and books a thousand. The stock record has understated that item by a fifth of every receipt for a year and a half, cycle counting keeps writing the difference back in, and the same adjustment reappears the following month.
Where the factor lives, and how many copies of it exist
The item has a base unit and everything else is a conversion hanging off it. In SAP that conversion is stored as an integer pair, a numerator and a denominator, rather than as a decimal. The planning system holds its own copy, populated at go-live and refreshed by whatever the integration carries. The warehouse system keeps one for picking and put-away, and transport rating works from weight and volume, which are separate fields with conversions of their own. Purchase orders and despatch advices carry a unit code drawn from UN/CEFACT Recommendation 20, the international list where EA is an each and KGM a kilogram. Under GS1 rules each packaging level gets its own item number, so the case and the pallet are distinct records with a stated relationship between them.
That is five or six copies of one physical fact, edited by different people on different days, with no test anywhere that checks they still agree. The copy that matters is whichever one the planning run reads, and that is frequently not the one the buyer edits when the supplier calls.
The four failures that actually happen
The stale factor. The supplier changes the pack and ships it under the same item code, because issuing a new code triggers work in six systems. The conversion in the master keeps describing a pack that no longer exists. Nothing breaks on the day it goes stale, which is why this one survives for years.
The inverted factor. Twelve entered where one twelfth belonged, or kilograms per pound where pounds per kilogram was wanted. Large inversions get caught in the first run. The ones that survive sit close to one: a factor of 1.2 stored as 0.833, or a conversion between two similar box sizes. NASA's mishap board on the Mars Climate Orbiter in 1999 found ground software producing impulse in pound-force seconds where the spacecraft expected newton-seconds, which is the same failure with a longer flight time.
The overloaded code. CS means the inner carton at one plant and the outer shipper at another. PAL is forty cases in one distribution centre and forty-eight in the one that was acquired. A unit code is a label, and the physical definition behind it lives in the heads of the people at that site. Recommendation 20 gives you a shared vocabulary, which is a different thing from a shared definition of what your case contains.
The conversion applied twice. The source system sends quantities already converted to the base unit and the interface converts them again on the way in, usually after a change to a mapping that had been quietly correct for three years. It is worth naming separately because the item master is clean, the ERP is clean, and only the planning copy is wrong.
The error is a multiple, so it hides from every variance check
Most data quality tooling looks for the unexpected: outliers, breaks in a series, values outside control limits, records that changed when nothing should have changed them. A wrong conversion factor produces none of that. The series is smooth, internally consistent, and wrong by the same multiple in every period.
Forecast accuracy review will not find it either. MAPE is scale free, so a series that is uniformly twelve times too large scores exactly the same as the correct one, and so does the forecast built on it. The error becomes visible when the number meets something physical: a truck that will not hold what the plan says it holds, a count that keeps disagreeing, a supplier asking why the order doubled.
The damage lands on every calculation that mixes items or crosses a boundary. Any sum across a catalogue in a common unit is wrong by an unknown amount, because the errors sit on individual items and do not cancel. Value classification shifts, since an item recorded at twelve times its true movement lands in the wrong band and inherits a policy meant for something else. Capacity checks in pallets or cubic metres fail at the level where the constraint binds.
Weight, volume and the items with no fixed pack
Conversions to weight and volume are trusted least and checked least. The item master carries a net weight, the carrier prices on gross weight including packaging and the pallet, and the two fields are populated by different functions. Plan truck fill on net weights and the loads run light in the plan and heavy in the yard by a margin that never moves.
Catch weight items make this structural. Meat, cheese, produce and cut metal are ordered in cases and invoiced by actual weight, so the case has a nominal weight in the master and a real weight that varies with every lot. Planning in the nominal unit is usually right, since it is the unit the customer orders in, and the gap then has to be carried explicitly rather than treated as an error to be chased. A standing difference of a few percent between planned and invoiced weight on a catch weight range is normal, and someone will still open a ticket about it every quarter.
The practical rule is to plan in the unit the binding constraint is expressed in. If the truck fills on volume, the cube conversion has to be right and the weight can be approximate. If the line is limited by kilograms an hour, the weight conversion carries the plan.
Rounding is a separate error with the same cause
Order multiples and conversions get confused with one another because they act on the same number in the same step. The conversion says how many units are in a case. The multiple says you may only order whole pallets. One of the two is a physical fact and the other is a policy somebody chose.
Take an item needing 1.3 pallets a week against a pallet of forty-eight cases. Rounding to two pallets carries a 54 percent overshoot on that order, every order, indefinitely. On a slow mover the same rule can make the minimum order a year of cover, which is a decision somebody should make deliberately rather than inherit from a default set at go-live. The cost hides in the aggregate because it looks like ordinary cycle stock.
Storage precision adds a smaller version of the same problem. A factor of 22.5 cases to a pallet held as the integer pair 45 over 2 is exactly right in the system that understands the pair, and an interface reading the numerator alone sees 45. Half-pallet and layer conversions are where this surfaces.
Checks that need one query and last month's receipts
Sampling by hand is worth more than it sounds. Nagle, Redman and Sammon reported in Harvard Business Review in 2017 that when managers scored a hundred of their own recent records against a basic quality bar, only three percent of the samples came out acceptable, an afternoon of work that beat every dashboard those companies already had.
Receipt reconciliation. For each receipt line, divide the base quantity booked by the pack count on the despatch advice. Compare the implied factor with the stored one and list every item that disagrees by more than a tolerance you set. This finds stale factors, and it dates them.
The default value tell. Conversion factors of exactly 1 on items that are not picked as eaches. Factors of 10, 100 or 1000 in a business that does not pack in tens. These are the values a system writes when a field was left empty at creation.
The cross-system diff. Full outer join the item file across ERP, planning and the warehouse system, compare the factor for each unit, count the mismatches by category and by creating user. A morning of work, and usually the highest yield of anything on this list.
Implied physical sanity. Item weight multiplied by case pack multiplied by cases per pallet gives a pallet weight. Anything implying a pallet over 1,200 kilograms or under fifty is wrong somewhere upstream, and the weighbridge file says which items to open first.
Change without a code change. Items where the implied factor from receipts shifted at an identifiable date while the item code stayed the same. That is the signature of a supplier pack change, and the date is what the next section needs.
Correcting the factor leaves the history in mixed units
Fix a factor that has been wrong for eighteen months and you have introduced a step change in the demand series at the date of the fix. Half the history describes one physical pack and half describes another, and the forecast model will read the join as a level shift and carry it forward.
Three options, and the choice depends on what the receipt data can tell you. Restate history using the factor in force at the time, which works where the check above gave you a date for the change. Truncate before the break and accept a shorter series, tolerable on a fast mover with weekly data and painful on anything seasonal. Or leave history alone and flag the break so the model treats it as an intervention.
Going forward, hold the conversion with an effective date rather than overwriting the field. Most ERPs treat it as current state with no history, so any question about what this item's pack size was last March becomes unanswerable the moment somebody types over the value. Kimball and Ross made the general case for tracking dimension changes over time in the 2013 edition of The Data Warehouse Toolkit, and a pack size is an attribute whose old value still has work to do.
One operational detail catches people on the day of the fix. Open purchase orders raised under the old factor arrive after the change, and unless the order carries its own conversion, receiving books them with the new one and the error flips direction. Correct the master and the open order book in the same window.
Where this stops
No amount of querying tells you the physical truth. Every check above infers the factor from something else that could also be wrong, and when receipts, the master and the warehouse system all disagree, the tiebreak is a person in a building with a scale and a list of item numbers. Budget for that on the top few hundred items. Catch weight ranges will not reconcile exactly and are not meant to, so set a tolerance, agree it with finance, and stop working on it.
A single global base unit is the clean answer, and most businesses cannot get there, because the plant plans in kilograms, the warehouse moves pallets and the customer buys cases. The conversions have to exist somewhere. What is achievable is one owned copy of each with a stated source, rather than five copies and an assumption that they agree.
None of it repairs an item file where one code covers two physically different products, or where one product carries three codes across two regions. Those break planning in a different way and need the item file sorted out first.
Pull last month's receipt lines, divide the base quantity booked by the pack count on the despatch advice, and list every item where the implied factor sits more than two percent away from the one your planning run is reading.