Unit of Measure Consistency in Distributor Catalogs

Unit of measure consistency means every system that touches a SKU agrees on what one of it is. For each product that is four linked answers: the base unit the warehouse counts, the sell unit the buyer orders, the pack quantity that converts one into the other, and the rule for which unit a price applies to. When the supplier feed, the ERP, the price list, the store, and the quote all give the same four answers, a quantity of 12 means the same thing on the order, the pick ticket, and the invoice.

When they do not, the error is invisible until the invoice arrives. That is what makes this attribute different from the rest of the catalog. A wrong description gets caught by a buyer reading the page. A wrong price gets caught by a rep who knows the account. A unit of measure error passes every check, because the price was right, the part number was right, and the quantity was exactly what the buyer typed. Nobody made a mistake. Four systems just answered the same question four different ways.

Why do each, box, and case drift apart?#

Distribution Strategy Group surveyed 233 North American distribution executives in the first quarter of 2026 for its State of Distributor Technology 2026 report, published April 27, 2026. Two findings from it sit underneath almost every unit of measure problem: 52 percent named poor data quality as a barrier to AI adoption, and 55 percent said they had invested in core technology systems without integrating them.

That second number is the mechanism. Unconnected systems do not fail loudly. They each hold a perfectly reasonable idea of what one of something is, and nothing in the stack is responsible for reconciling those ideas. Four places where the drift starts:

• The supplier feed carries the supplier's own code. BX, CS, PK, DZ, and a pack quantity that may or may not be populated in the same row.
• The ERP base unit was set at go-live, possibly by a consultant, possibly a decade ago, and has not been revisited since, because nothing about it appears broken.
• The contract price list was negotiated in whatever unit the conversation happened in. Very often per each, on a product the catalog sells per box.
• The store imported whichever unit code came through the feed last, because a storefront import is a write, and a write with no precedence rule is a coin flip.

Scale removes the last safety net. In a survey of more than 100 wholesale distributors conducted by Phocas Software and reported by Distribution Strategy Group on March 5, 2026, 70 percent of respondents manage more than 5,000 SKUs, and only 31 percent reported high confidence in their inventory data. At five thousand SKUs nobody is eyeballing units. Either the rule lives in the data or it does not exist.

A worked example: 12 of 6205-2RS#

Take a maintenance buyer ordering a sealed deep groove ball bearing. All prices here are illustrative.

The buyer needs a dozen 6205-2RS. Their contract price is 4.20 per each, negotiated that way two years ago. The supplier feed lists the SKU with a unit code of BX and a pack quantity of 10. The ERP base unit is EA. The store shows the item at 4.20 and the buyer enters 12.

The pick ticket prints 12 boxes. One hundred and twenty bearings ship. The invoice lands at either 50.40 or 504.00 depending on which system won the argument, and both numbers are wrong in a different direction. One of them undercharges by a factor of ten on real goods that left the building. The other charges correctly for a quantity the buyer never intended to order and cannot use.

Now the cross-reference version of the same trap, which is worse because it looks like a success. The buyer types a competitor part number. It resolves cleanly to the house SKU. The part is genuinely equivalent, the interchange is real, and the match is exact. But the competitor number is sold as a single piece and the house SKU is sold in a box of ten. A perfect part match with the wrong unit is still a wrong order, and it arrives wearing the confidence of a verified cross-reference.

The rule worth writing on the wall: the buyer never sees a base unit, a conversion factor, or a landed cost. The buyer sees a quantity, a unit label, and a price. Everything else is the distributor's job to hold steady behind that.

What are the four attributes every SKU needs?#

Four fields, and they are one linked set rather than four independent ones. Changing any one without the others is how a fix becomes a new error.

• Base unit. What the warehouse physically counts and what inventory is held in.
• Sell unit. What the buyer actually orders in, and what the store displays.
• Pack quantity. The conversion between the two. This is the field most often left null, and null is not the same as one.
• Pricing basis. Which unit the price is per. A price without a stated basis is a number, not a price.

Two more catch most of the remaining surprises. A minimum order quantity expressed in the sell unit, not the base unit, because a minimum of 10 means something very different against each than against case. And an explicit broken box rule: can this buyer order in the base unit at all, or is the pack the smallest thing they can have? Distributors usually know the answer per product line and almost never record it per SKU.

This is the specific end of the general problem we wrote about in catalog data quality for distributors. That piece was about where product data rots across the board. This is one attribute, worked all the way through, because unit of measure is the one where the rot converts directly into a credit memo.

How do you keep the four answers from drifting again?#

Give the attribute one owner. Product data or purchasing, named, singular. Not the storefront admin who happened to find the error, because a fix made at the display layer is a fix that survives until the next import and teaches everyone the wrong lesson about where truth lives.

Make imports enrich rather than overwrite. An incoming feed row with an empty or different unit code should not silently replace a unit a human deliberately set. Empty never beats data. A manual correction should outrank the next re-import for that field until someone explicitly releases it back to the source. And when two real sources genuinely disagree, that is a review item for a person, not a coin flip resolved by whichever job ran last.

Keep field-level history. When a unit changes, the record should show what it was, what it became, which source or which person changed it, and when. Without that, the same correction gets made three separate times by three different people, and none of them can tell whether they are fixing a fresh error or undoing someone else's deliberate decision from last quarter.

Treat a unit change as a price change. Changing a pack quantity silently repriced every contract line that references that SKU. It should go through the same review as an edit to a price break, because operationally it is one.

This is where a generic B2B ecommerce suite retrofitted for distribution tends to give up. A consumer catalog has one unit: the item. A distributor catalog has a unit hierarchy per SKU, and a storefront that imports a single unit code from a feed has already quietly decided that somebody's invoice is going to be wrong.

Where Copiara fits#

On a distributor's Shopify store, catalog enrichment on top of Shopify products layers attributes, provenance, and field-level change history over the merchant's own products instead of overwriting them. Applied to unit of measure, that means the attribute carries a source, an owner, and a change record, imports enrich rather than blindly replace, and two real sources disagreeing surfaces for a human instead of resolving itself. Cross-reference resolves competitor and legacy part numbers to the merchant's own catalog, with fuzzy matches held in a review queue, which is exactly where a clean part match with a mismatched pack size belongs. The AI concierge answers cross-reference, price, and stock questions inside what that specific buyer can see, and it does not invent a unit or a price it cannot support from the catalog.

Shopify keeps products, variants, price lists, and checkout. Copiara adds the wholesale layer over the top. Copiara is in early access and you can get in touch here.

FAQ#

Should the storefront sell in the base unit or the sell unit? The sell unit, with the pack quantity shown next to it. Buyers order in the unit their own purchasing system speaks, and hiding the conversion does not remove it, it just moves the surprise to the invoice.

What happens when a supplier changes a pack size? Treat it as a new unit set with its own history entry rather than an edit in place, and review every price that references that SKU before the change goes live. A pack size change that quietly reprices a contract is the most expensive version of this problem.

Can a unit of measure error be a pricing error? Yes, and that is usually how it gets discovered. The unit is wrong for months and nobody notices until the margin on a line looks impossible or a customer disputes an invoice.

Where should the correction be made first? In the system that owns the attribute, then flowed outward. Fixing it only in the store leaves the real record wrong and guarantees the error comes back on the next import.