Per Piece, per Pallet, per m²: Why Building-Materials Catalogs Break on Unit of Measure

In building materials, one product usually carries several units at once: a base unit (piece), a purchase unit (pallet), a sales unit (m²), and sometimes a delivery unit (m³ or tonne). Errors happen at the conversion factors between them—pieces per pallet or pieces per m² at a stated joint width—not at the units themselves.

Four units, one product

Take a 240 × 115 × 71 mm NF clay facing brick. The physical item is one piece, the manufacturer supplies a pallet, the merchant quotes wall coverage, and transport plans against pallet mass.

The labels are standardized vocabulary. Unit of measure explains the concept, while UNECE Recommendation 20 unit codes give systems an interoperable representation. But codes do not tell an ERP that this pallet contains 500 pieces or that this square-metre calculation assumes a 10 mm joint. Those are product-specific conversion facts.

Brick format makes the problem concrete. A DF brick at roughly 240 × 115 × 52 mm, an NF at 240 × 115 × 71 mm, and a 2DF at 240 × 115 × 113 mm do not produce the same pieces-per-m² coverage. Changing format or joint width changes the factor even when the commercial unit remains MTK.

Where the conversion factor actually lives

Often, nowhere reliable. Pieces per pallet may sit in a footnote in a seasonal price list. Pieces per m² may appear in a PDF technical sheet beside a joint-width assumption. Gross weight may live in a logistics workbook. Bulk density may be known by an experienced trade-counter colleague but absent from every system.

The supplier feed commonly carries a unit label and a price, but not the relationship between that unit and the distributor’s base unit. A correct normalization therefore requires evidence from multiple sources, a timestamp, and a product-variant match. It cannot be reconstructed safely from the price alone.

Four failure modes we see repeatedly

1. The supplier changes pallet quantity mid-year. A line moves from 500 to 460 pieces per pallet while the ERP retains 500. Purchase quantities, availability, and landed unit cost are now wrong by about 8.7% relative to the new pack.
2. Two suppliers describe the same product at different levels. One feed prices a piece and another prices a pallet. Without identity and unit normalization, the ERP may create duplicate items with incomparable prices. That compounds the damage from duplicate SKUs in pricing workflows.
3. The webshop and ERP use different sale bases. The webshop displays €/m², the ERP stores €/piece, and the conversion’s joint-width assumption is undocumented. A quote may look precise while delivering insufficient material.
4. Volume and mass are treated as interchangeable. Aggregate is priced per tonne and ordered per m³, but density varies by product, grading, and sometimes moisture condition. A generic factor silently distorts the delivered quantity and margin.

What a conversion error costs

Do not begin with an invented industry-wide percentage. Calculate the mechanism on one failed line:

Multiply that per-error result by the number of unit-related credits, redeliveries, and manual corrections in your own period. The guides to margin leakage in supplier price files and product-data controls for pricing errors show where to look without claiming a universal loss rate.

Fix it as a data problem, not a training problem

Training people to remember that one NF brick uses one factor and another uses a different factor does not scale across suppliers, formats, and refreshes. Instead:

1. Normalize incoming units to canonical codes. Map “pc,” “each,” “ST,” and local abbreviations to the approved representation. See data normalization.
2. Store conversions as first-class attributes. Keep numerator unit, denominator unit, factor, applicable variant, conditions such as joint width or moisture basis, source, effective date, and confidence in the canonical product record.
3. Map supplier fields explicitly. A field named pack, qty/pal, or Verpackungseinheit must map to a defined concept, not merely a similarly named ERP column. Use the supplier-attribute mapping playbook.
4. Validate on ingest. Flag a changed pack factor, an impossible dimensional conversion, or a price-per-base-unit outside the category’s plausible band before release. See SKU validation before catalog entry.
5. Re-check every refresh. Pallet configurations and price bases change silently. Accepted corrections must support controlled write-back to ERP, PIM, commerce, and quoting systems.

This is the same multi-source discipline used in complex distribution catalogs such as plumbing distribution product data: identity first, category-specific attributes second, then validation and monitored updates.

Before and after normalization

The after state does not collapse all measures into one number. It preserves the legitimate commercial units and makes every conversion explicit, conditional, and traceable.