Logistics data

Why Units of Measure Are One of the Most Dangerous Logistics Migration Objects

By Dzmitryi Kharlanau · Published · 16 min read

The unit-of-measure migration report looks harmless.

Contents

Reviewed: 15 July 2026

The unit-of-measure migration report looks harmless.

Materials assessed:
120,000

Materials with a base unit:
120,000

Alternative units loaded:
98.9%

Technical conversion errors:
143

The project classifies the remaining work as minor master-data cleanup.

Then the first operational transactions begin.

Procurement orders 100 boxes.

The supplier delivers 2,400 pieces.

The warehouse expects 2,000.

Production consumes in individual pieces.

Inventory is updated using boxes.

Transportation planning calculates pallet weight using a third conversion.

The invoice refers to the supplier’s packaging quantity.

Every system contains a unit of measure.

Every individual value looks plausible.

The network of conversions is wrong.

A unit-of-measure defect does not remain inside the material master. It multiplies quantities as they move through purchasing, receiving, warehousing, production, transportation, inventory and invoicing.

This is why UoM migration is frequently underestimated.

It appears to be a small reference-data topic:

Operationally, it is a quantity-control model.

It determines what the organisation believes it ordered, received, stored, moved, consumed, shipped and paid for.

A conversion error can create:

Managers should not treat UoM as a final data-cleansing task.

They should treat it as a cross-process control.

Martenweave is well suited to this problem because its current architecture is based on canonical objects, relationships, deterministic validation, gap detection, lineage, impact analysis and human-reviewed proposals.

The logistics use case is not to replace ERP or warehouse execution.

It is to preserve and validate the meaning of quantity across the systems that execute those processes.

One material, four interpretations of a box

We use one material throughout the article.

Material:
AX-4711

Description:
Steering Assembly Fastener

Base unit:
EA

Purchasing unit:
BOX

Warehouse handling unit:
CASE

Transportation unit:
PAL

Production consumption:
EA

The intended packaging model is:

1 BOX = 24 EA

1 CASE = 4 BOX

1 PAL = 20 CASE

Therefore:

1 CASE = 96 EA

1 PAL = 1,920 EA

But the migration sources contain three versions.

Legacy ERP

1 BOX = 24 EA

1 PAL = 2,400 EA

Warehouse spreadsheet

1 CASE = 80 EA

1 PAL = 20 CASE

Supplier catalogue

1 BOX = 24 EA

1 CASE = 4 BOX

1 PAL = 20 CASE

The supplier catalogue implies 1,920 EA per pallet.

The legacy ERP says 2,400.

The warehouse spreadsheet implies 1,600.

Every source contains numbers.

The problem is not missing data.

The problem is contradictory meaning.

A conventional migration workbook can copy one of the values into the target.

A canonical model must explain which value is authoritative, for which packaging level, and why.

Why the error survives technical validation

Technical validation often checks whether:

All three source models can pass those checks.

BOX → EA = 24

CASE → EA = 80

PAL → EA = 2,400

Nothing is empty.

Nothing is negative.

The units are recognised.

The contradiction appears only when we evaluate the conversion network.

If:

1 CASE = 4 BOX

and:

1 BOX = 24 EA

then:

1 CASE must equal 96 EA

A direct value of 80 EA contradicts the derived path.

The correct validation is therefore relational:

Every conversion path between the same two quantity concepts must produce the same result within the approved precision and applicability scope.

That is more demanding than checking one row at a time.

It is also much closer to the operational risk.

The first management problem: nobody owns the complete quantity model

UoM data crosses organisational boundaries.

Procurement may own:

Warehouse operations may own:

Production may own:

Engineering may own:

Transportation may own:

Finance may care about:

The migration team is asked to combine these values.

It usually does not have authority to decide which business meaning is correct.

Managers should therefore stop asking:

Who owns the UoM field?

There is rarely one owner.

The better questions are:

For AX-4711:

Base unit authority:
Product Master Owner

Supplier BOX quantity:
Procurement Data Owner

Warehouse CASE quantity:
Warehouse Packaging Owner

Pallet composition:
Logistics Packaging Owner

Production issue quantity:
Production Data Owner

This typed ownership is more useful than assigning the entire material to one data steward.

The second problem: the same code does not always mean the same thing

Two systems can use the code BOX.

That does not prove that they represent the same packaging level.

In one source:

BOX = supplier shipping carton

In another:

BOX = internal picking container

Both may contain 24 pieces today.

They can diverge later.

If the migration merges them only because the labels match, the target loses an important distinction.

The reverse problem also occurs.

Two systems can use different codes for the same quantity concept:

BX
BOX
CTN
KAR

The manager should not demand code standardisation before meaning is understood.

The correct sequence is:

Identify quantity concept
→ establish business meaning
→ define source authority
→ map system codes
→ validate conversions

Not:

Match labels
→ copy conversion
→ investigate later

The third problem: base unit becomes an accidental business decision

Changing the base unit can have wide consequences.

It can affect how quantities are:

A migration programme may select a base unit because:

Those are not sufficient business reasons.

For AX-4711, EA is appropriate because the product is counted, consumed and inventoried as individual fasteners.

For a liquid, sheet material, cable or variable-weight product, the correct decision can be more complex.

The programme should preserve:

The base unit is not merely the first row in the UoM table.

It anchors every alternative conversion.

The fourth problem: direct conversions contradict derived conversions

A material can contain:

BOX → EA

CASE → BOX

PAL → CASE

PAL → EA

The direct PAL → EA conversion may have been maintained independently from the packaging chain.

Over time, one value changes while the others remain.

The target now contains several mathematically inconsistent truths.

For AX-4711:

BOX → EA = 24

CASE → BOX = 4

PAL → CASE = 20

Derived:

PAL → EA = 1,920

Direct source value:

PAL → EA = 2,400

Managers need a policy.

Possible policies include:

Derived conversions are authoritative

The system calculates pallet quantity from approved lower packaging levels.

Direct conversion is authoritative

The pallet is managed independently, and intermediate levels are informational.

Applicability differs

One conversion applies to supplier packaging; another applies to internal warehouse packaging.

The system should not choose silently.

The model must record the Decision.

The fifth problem: conversion direction hides errors

These statements look equivalent:

1 BOX = 24 EA

and:

1 EA = 0.0416667 BOX

Operationally, the second introduces precision and rounding questions.

If the system stores limited decimal precision, repeated conversion can create discrepancies.

A purchasing quantity may convert cleanly from BOX to EA.

A return quantity converted from EA back to BOX may not represent a full commercial package.

For example:

25 EA = 1.0416667 BOX

Can the supplier accept that return?

Can the warehouse pick it?

Can the invoice express it?

The numerical conversion may be valid.

The business action may not be.

Martenweave should distinguish:

This prevents one arithmetic factor from being treated as universal process permission.

The sixth problem: rounding rules are hidden

Consider:

1 ROLL = 12.5 M

Production requires 17 M.

The system can calculate:

17 ÷ 12.5 = 1.36 ROLL

But purchasing may allow only whole rolls.

Warehouse handling may allow partial rolls after opening.

Transportation may plan full rolls.

The correct quantity depends on the process.

Purchase quantity:
2 ROLL

Warehouse issue:
17 M

Remaining stock:
8 M

A conversion factor alone cannot express these Rules.

Managers should require:

Without this, the same conversion produces different expectations across systems.

The seventh problem: packaging levels are mistaken for units

A pallet is not always a fixed unit.

Its composition may depend on:

For AX-4711, Supplier A may deliver:

20 CASE per PAL

Supplier B may deliver:

24 CASE per PAL

A single global PAL → EA conversion is therefore unsafe unless the business truly enforces one standard pallet.

The model may need to represent:

Material
+
Supplier
+
Packaging Specification
+
Location
+
Effective Date

SAP EWM supports high-volume warehouse operations and integrates warehouse processes with quality, production and track-and-trace. That operational breadth is one reason packaging and quantity meaning cannot safely be reduced to a single global material field.

The management lesson is direct:

Do not migrate a packaging configuration as a universal unit conversion unless its scope is universal.

The eighth problem: weight and quantity are mixed

A material may be:

If one piece has a nominal weight, the programme may derive:

1 EA = 2.4 KG

But the physical weight can vary.

Packaging adds another layer.

Product net weight:
2.4 KG per EA

Packed box weight:
59 KG for 24 EA

Pallet gross weight:
1,210 KG

These values are related.

They are not interchangeable.

A common mistake is to use material gross weight as a conversion between physical quantity and logistics packaging.

Managers should require the model to distinguish:

Otherwise a transport-planning issue is treated as a simple material-master correction.

The ninth problem: variable-quantity materials need two dimensions

Some products cannot be governed by one fixed conversion.

Examples include:

A piece or package can have a variable weight or length.

The organisation may need:

Logistics quantity:
10 COIL

Valuation quantity:
12,460 KG

A fixed conversion such as:

1 COIL = 1,246 KG

may be useful as an expected value.

It should not replace the actual measured quantity.

Managers should ask:

A fixed-conversion model applied to variable-quantity products creates false precision.

The tenth problem: GTIN and packaging identity are disconnected

A GTIN or other external identifier can identify a specific trade-item configuration.

The same product can have different identifiers for:

If the migration preserves the GTIN but loses the packaging-level relationship, scanning can identify a code without establishing the correct quantity.

For AX-4711, the target may contain:

GTIN A:
individual item

GTIN B:
box of 24

GTIN C:
case of 96

A scanning process must know which packaging level each identifier represents.

The model should validate:

GTIN
→ packaging level
→ UoM concept
→ conversion
→ effective scope

Not only:

GTIN is populated

The eleventh problem: historical transactions distort future packaging

Migration teams often derive conversion factors from transaction history.

This can reveal actual usage.

It can also preserve old problems.

Historical transactions may contain:

Suppose most historical receipts used 100 EA per CASE.

The future supplier contract specifies 96.

Historical frequency does not make 100 the correct target value.

The programme should use history as Evidence, not as automatic authority.

The target model should reflect the approved future operating state.

The twelfth problem: a conversion can be correct in one location and wrong in another

Warehouse A permits case breaking.

Warehouse B stores only full cases.

Plant DE10 consumes individual pieces.

Plant US20 consumes prepacked kits.

The mathematical conversion can remain the same.

Operational applicability changes.

For AX-4711:

1 CASE = 96 EA

may be globally true.

But:

EA may be picked individually

may be true only for warehouse EWM-WH01.

The model must separate:

Quantity equivalence

from:

Process policy

This avoids overloading UoM data with operational Rules it cannot express alone.

The management solution: model UoM as a governed graph

A flat table is not enough.

We need a graph of quantity concepts and conversions.

EA
↔ BOX
↔ CASE
↔ PAL

Each edge should carry:

Conceptually:

Conversion:
BOX → EA

Factor:
24 / 1

Meaning:
Supplier commercial box contains 24 individual pieces

Applicable to:
Supplier SUP-100
Plant DE10
Purchasing and receiving

Authority:
Approved supplier packaging specification

Effective from:
Cutover

This is not just a number.

It is a governed relationship.

We distinguish canonical and system units

The canonical model should preserve business concepts independently from local codes.

Canonical quantity concept:
Commercial Box

Legacy ERP code:
BOX

Supplier portal code:
CTN

Warehouse code:
CASE24

This gives us a stable meaning layer.

Mappings then connect each system code to the canonical concept.

If a system code changes, the business concept remains stable.

If two local codes have different meanings, they do not get merged simply because both resemble “box.”

We validate the graph deterministically

Useful validation Rules include:

No zero or negative conversion

numerator > 0
denominator > 0

No contradictory paths

Every valid path between the same concepts must produce the same result within declared tolerance.

Reversibility

Where reverse conversion is expected:

A → B × B → A = 1

within approved precision.

No circular inflation

A closed path must return to the starting quantity.

EA → BOX → CASE → EA

must equal the original quantity.

Authority required

Every production conversion must reference an accepted source or Decision.

Applicability required

A supplier-specific packaging factor must not be applied globally.

Precision declared

Conversions producing non-integer quantities must define rounding and process behaviour.

Packaging identity complete

External identifiers must reference a known packaging level and quantity concept.

These Rules catch errors that normal field completeness cannot.

We validate cross-system consequences

A correct canonical graph must be compared with actual systems.

For AX-4711:

Canonical:
1 PAL = 1,920 EA

ERP:
1 PAL = 2,400 EA

EWM:
1 PAL = 1,600 EA

Supplier catalogue:
1 PAL = 1,920 EA

The Finding should not merely say:

Conversion mismatch.

It should explain:

Purchasing consequence:
100 PAL order differs by 48,000 EA
between ERP and canonical model.

Warehouse consequence:
Receipt expectation differs by 32,000 EA
between EWM and canonical model.

Transportation consequence:
Pallet quantity and weight calculations are unreliable.

This gives managers a reason to prioritize the issue.

We classify UoM readiness by process

For AX-4711:

Purchasing UoM readiness:
Ready

Supplier BOX conversion:
Approved and current

Warehouse UoM readiness:
Not ready

CASE and PAL conversions:
Contradictory

Production UoM readiness:
Ready

Consumption in EA:
Validated

Transportation UoM readiness:
Not assessed

Current pallet weight Evidence:
Missing

This is more accurate than:

UoM data:
95% complete

We separate corrected data from corrected model

Suppose the team changes the EWM pallet conversion to 1,920 EA.

The immediate record may be fixed.

We still ask:

If the migration file alone is corrected, the next wave can recreate the error.

Martenweave should retain both:

Record remediation

and:

Model or Mapping remediation

We define closure Evidence

The UoM Finding closes only when current Evidence proves:

  1. the canonical conversion graph is internally consistent;
  2. source authority is approved;
  3. ERP and EWM use the intended values;
  4. packaging-level identities are linked correctly;
  5. required rounding policies are declared;
  6. affected materials were reprocessed;
  7. inventory or target reconciliation passes;
  8. critical process tests use the current baseline.

For AX-4711:

Canonical PAL quantity:
1,920 EA

ERP target:
1,920 EA

EWM target:
1,920 EA

Supplier specification:
1,920 EA

Receipt test:
passed

Picking test:
passed

Transport weight reconciliation:
passed

A closed issue or changed spreadsheet is insufficient.

A management dashboard for UoM risk

The Workbench should not lead with the number of alternative units.

It should show operational exposure.

Population

Materials with alternative units:
48,000

Conversion health

Internally consistent:
45,900

Contradictory paths:
620

Missing authority:
480

Supplier-specific factor applied globally:
310

Non-integer conversion without rounding policy:
410

Packaging identifier not linked:
280

Business impact

Purchasing affected:
380 materials

Warehouse execution affected:
740 materials

Production affected:
95 materials

Transportation affected:
520 materials

Inventory reconciliation affected:
260 materials

Critical blockers

This is the information managers need.

A focused Martenweave pilot

The first UoM pilot should not cover the whole material landscape.

Choose:

Example:

Plant:
DE10

Warehouse:
EWM-WH01

Material category:
Externally procured production components

Population:
2,000 materials

Packaging chain:
EA → BOX → CASE → PAL

The pilot should answer:

  1. Which packaging concepts exist?
  2. Which system codes represent them?
  3. Which source owns each conversion?
  4. Which conversion paths contradict each other?
  5. Which packaging factors vary by supplier or location?
  6. Which business processes are affected?
  7. Which current target Evidence proves alignment?
  8. Which fixes require data, Mapping or model changes?

This produces a concrete operational result.

It also proves whether Martenweave can add value without becoming a full logistics platform.

The proposed Martenweave capability

Governed UoM and Packaging Graph

Goal

Preserve quantity meaning across ERP, warehouse, production, transportation and external partner systems.

Initial objects

Initial validations

Initial outputs

A conceptual conversion object

---
id: CONV-AX-4711-BOX-EA
type: Conversion

material:
  AX-4711

from:
  QTY-COMMERCIAL-BOX

to:
  QTY-EACH

factor:
  numerator: 24
  denominator: 1

applicability:
  supplier: SUP-100
  plant: DE10
  processes:
    - purchasing
    - receiving

authority:
  DATASET-SUPPLIER-PACKAGING-SPEC

owner:
  ROLE-PROCUREMENT-DATA-OWNER

effective_from:
  cutover
---

This is a proposed product direction, not a claim about the exact current Martenweave schema.

Proposed commands

A future CLI might support:

martenweave logistics uom-graph \
  AX-4711 \
  --repo ./model
martenweave logistics validate-uom \
  --dataset ./data/material-uom-rc4.xlsx \
  --repo ./model
martenweave logistics contradictory-conversions \
  --plant DE10 \
  --warehouse EWM-WH01 \
  --repo ./model
martenweave logistics uom-impact \
  CONV-AX-4711-PAL-EA \
  --repo ./model
martenweave logistics propose-uom-fix \
  FIND-AX-4711-PAL-CONTRADICTION \
  --dry-run \
  --repo ./model

These commands describe a recommended capability.

They are not part of the currently documented CLI.

The existing Martenweave core already provides canonical files, deterministic validation, gap detection, lineage, impact analysis and proposal-first change handling that could support this slice.

What managers should require

Require one canonical packaging model

Do not allow ERP, EWM and supplier workbooks to remain independent truths.

Require typed source authority

Name the owner of each quantity concept and packaging relationship.

Require graph validation

Do not validate conversions only row by row.

Require applicability

Supplier-, Plant- and warehouse-specific factors must remain scoped.

Require rounding policy

A mathematically valid conversion is not always operationally executable.

Require cross-system reconciliation

Compare the canonical graph with current ERP, warehouse and partner data.

Require business-impact reporting

Prioritize conversions by affected process, not only by record count.

Require evidence-backed closure

A corrected file is not proof that the current target state is aligned.

The questions managers should ask

  1. What does the base unit represent operationally?
  2. Which alternative units are quantity concepts and which are packaging levels?
  3. Who owns every conversion?
  4. Which factors vary by supplier, Plant, warehouse or effective date?
  5. Do direct and derived conversion paths agree?
  6. Which conversions produce fractions?
  7. What rounding and pack-breaking policies apply?
  8. Which GTIN or external identifier belongs to each packaging level?
  9. Which materials use nominal rather than actual quantity conversions?
  10. Which ERP, EWM, production and transportation processes depend on each factor?
  11. Which current Evidence proves that the target systems agree?
  12. Which temporary fixes will recur because the Mapping remains unchanged?

A programme that cannot answer these questions does not have a governed UoM model.

The business value

UoM governance reduces more than technical errors.

It protects:

SAP describes EWM as integrating high-volume warehouse operations with production, quality and track-and-trace processes. Quantity meaning therefore propagates far beyond one material-master field.

SAP also positions MDG around governed models, preserved semantics and relationships, validated values, business Rules and auditability. A canonical UoM graph extends that governance principle across migration datasets, mappings and target Evidence.

Instead of reporting:

98.9% of alternative units were loaded.

the programme can report:

45,900 materials have consistent,
authorised conversion networks.

620 contain contradictory paths.

310 use local packaging factors globally.

95 production-critical materials
remain unsafe for consumption or replenishment.

The warehouse gate remains blocked
for 20 high-volume components.

That is a management result.

Final perspective

A unit of measure is not a label attached to a quantity.

It is part of a business agreement about what the quantity means and how it can move between processes.

The practical test is:

Can we trace every operational quantity back through a consistent, authorised and applicable conversion path—and prove that every consuming system uses the same current meaning?

When the answer is yes, UoM data is governed.

When the answer is:

Every material has a base unit and the target accepted the conversions,

we have proven technical completeness.

We have not proven that the business will order, receive, store, consume, transport and invoice the same quantity.

About the authors

Martenweave is maintained by Dzmitryi Kharlanau.

We are building Martenweave so that quantity conversions become traceable model relationships rather than hidden multipliers spread across spreadsheets and systems.

Our operating model is:

Canonical concepts define quantity meaning.

Mappings connect system codes.

Rules validate conversion networks.

Lineage shows process impact.

Evidence proves current alignment.

AI proposes corrections.

Humans approve authority and applicability.

Martenweave is an open-source, backend-first model-governance and evidence layer for SAP migration, MDM, data governance, logistics and AMS teams.

Sources and notes

This article was reviewed on 15 July 2026.

Martenweave Core currently describes a backend-first model-governance pipeline that turns datasets, validation reports, Decisions and SAP context into canonical model files, deterministic validation, dataset-gap reports, lineage, impact analysis and human-approved proposals.

Its current principles keep canonical files authoritative, generated indexes disposable, validation deterministic and AI-generated changes proposal-first.

Its documented workflow moves from source Evidence through validation, gaps, lineage and impact analysis to reviewed proposals and GitHub delivery.

SAP describes SAP EWM as supporting high-volume warehouse operations and integrating warehouse and distribution processes with quality, production, track-and-trace and automation. The article uses this breadth to explain why UoM and packaging errors propagate beyond a single material-master record.

SAP describes SAP Master Data Governance as a governance layer that preserves semantics and relationships across governed models, supports matching and reconciliation, applies validated values and business Rules, and maintains an audit trail. The proposed UoM graph applies those governance principles to cross-system quantity relationships and migration Evidence.

The QuantityConcept, Conversion and PackagingLevel objects, graph validations, capability-readiness states and proposed commands are product directions. They should not be interpreted as guarantees of the exact current Martenweave schema, Workbench behaviour or CLI until implemented and released.

Martenweave is independent and is not affiliated with or endorsed by SAP.

Primary sources

Related articles