In B2B, hardly anything is ordered by the piece. Cable leaves the warehouse as cut-to-length metres, seals come in bags of one hundred, screws in cases of five hundred, granulate in 25-kilogram sacks and tiles on pallets holding 48 square metres. A shop has to reflect that reality without forcing the buyer to do mental arithmetic and without feeding the ERP with the wrong quantities. That takes three cleanly separated figures: the base unit of measure in which the ERP holds stock and posts movements, the sales or packaging unit that carries price and billing, and the order unit the customer actually buys in. Between them sits a conversion factor, joined by a minimum order quantity and an order increment. How standardised this field has become is visible in international trade: more than 1,800 codes exist for units of measure (UN/CEFACT). German price law, in turn, allows exactly five reference quantities for unit pricing (PAngV), and every packaging level above the base unit gets its own article number – usually a 14-digit GTIN-14 (GS1) that incorporates the number of the item it contains; a separate 13-digit or 12-digit GTIN is equally permitted. This article shows how to anchor units and pack sizes in a Shopware store so that display, price, cart and ERP posting all speak the same language.
Key takeaways
- Three figures, three jobs: the base unit of measure carries stock, the sales unit carries price and billing, the order unit is what the customer puts in the cart. The conversion factor links them and belongs in exactly one leading source.
- The German B2B catalogue standard describes a product's quantity behaviour in six dedicated fields (BMEcat 1.2): order unit, content unit, number of content units per order unit, price quantity, minimum quantity and order increment.
- A classic failure pattern: the price is calculated per metre but billed per roll. The cart shows 1 while the ERP books 250. Such breaks appear at the handover points between shop, PIM and ERP, not in the user interface.
- Unit pricing is a consumer obligation with exactly five permitted reference quantities (PAngV). It does not apply in a pure business-to-business relationship, but it does in hybrid stores serving business and private customers.
- Units are a master data topic, not a display topic. They reach into picking, delivery notes and invoice lines: the European invoicing standard reserves a dedicated field for them on every line (EN 16931).
Why units of measure are more than one field in B2B
In consumer retail the quantity question is usually trivial: one product, one piece, one price. In wholesale and manufacturing the picture is different. The same product is cut to length, sold as a 250-metre coil and shipped on pallets holding twelve coils. A cleaning concentrate leaves the site in ten-litre canisters but is calculated per litre. Seals sit in bags of one hundred while picking still reaches for single items. Anyone who reduces that reality to a single field called quantity moves the conversion into the buyer's head – and from there into the complaints queue.
The resulting effort is rarely spectacular, but it is permanent. An order line with the wrong unit triggers a query at the sales desk, a correction in the ERP, a revised picking list and, in the worse case, a return including freight cost. Because each case looks small on its own, none of them surfaces in a report; together they tie up sales time that is missing for advice. The root cause usually sits in the product data and how it is maintained in the PIM and at the handover points between systems. That is why units belong in master data and in the interfaces between shop and ERP before anyone touches the display layer.
Three figures that are not the same thing
Separating base, sales and order unit cleanly
A robust data model starts with the base unit of measure. It is the reference for stock, stocktaking, valuation and, in many companies, costing as well. It is rarely changed, because every change touches historical postings. Above it sit one or more packaging units, each with its own conversion factor back to the base. So that systems can agree on those units, standardised keys exist: international trade works with three-character codes such as MTR for metre, KGM for kilogram or LTR for litre, more than 1,800 codes in total (UN/CEFACT). For pieces, either C62 or H87 is common depending on the channel (UN/CEFACT) – deciding per channel saves a mapping table later. Maintaining free text such as kg, Kg or kilo instead produces reconciliation errors as soon as a catalogue is exported or an invoice is handed over in structured form.
| Attribute | Base unit of measure | Sales unit | Order unit |
|---|---|---|---|
| Leading system | ERP | ERP or PIM | Shop, derived from the catalogue |
| Typical example | Metre, kilogram, piece | Roll, case, canister | Pallet, case, cut length |
| What it counts for | Stock, stocktaking, valuation | Price, weight, billing | Selection, cart, price tier |
| Visible to the customer | mostly only via the unit price | in price and data sheet | in list, search and cart |
| Frequency of change | very rarely | when range or supplier changes | differs per customer and channel |
| Failure pattern when missing | stock drifts apart | price refers to the wrong quantity | cart calculates with the wrong factor |
The separation sounds like paperwork, yet it pays off as soon as further channels appear. One customer orders through the shop in cases, a second pulls a punchout catalogue via OCI from their procurement system and expects pallets, a third sends structured messages and calculates in base units. All three routes read the same product master. If base, pack and factor are unambiguous there, every conversion is a simple multiplication. If the information is scattered across description texts instead, every new channel turns into its own project with its own special logic.
The conversion factor and what goes wrong with it
The conversion factor answers a single question: how many base units are contained in one sales or order unit? The German B2B catalogue standard holds a dedicated field for it and places five more alongside – order unit, content unit, number of content units per order unit, price quantity, minimum quantity and order increment, together six fields covering a product's entire quantity behaviour (BMEcat 1.2). That structure is not a formality but a proven checklist. Rebuilding it in the PIM and in the shop clears away most of the later error sources before the first order arrives.
Three things tend to go wrong in practice. First, the factor spreads across several places: maintained once in the ERP, once in the shop, once in the sales team's spreadsheet. When the values diverge, the system that wrote last wins. Second, the supplier changes the pack size – 250 metres per roll become 200 – and the price per roll stays as it was. The unit price is then wrong although nothing looks wrong at first glance. Third, some products have a varying quantity per pack, such as sawn timber, natural stone or cheese wheels. Trade numbering covers that with its own marker: packs with a fixed quantity carry an indicator digit of 1 to 8, packs with a variable quantity carry 9 (GS1). Skipping that distinction means posting approximations and correcting them by hand later.
The core in one sentence
Minimum order quantity, order increment and rounding
Minimum order quantity and order increment are two different rules that are readily lumped together. The minimum order quantity defines the point from which a product can be ordered at all. The order increment defines the steps in which the quantity may rise beyond that. A cable with a minimum of 50 metres and an increment of 25 metres allows 50, 75 and 100 metres, but not 60. Both rules belong on the product record rather than in a note, because the cart has to enforce them and the customer needs to see the next permitted quantity instead of reading an error message. Rounding up with a clear label has proven itself: 600 metres visibly become 750 metres, justified by the pack grid of three rolls.
Base unit of measure
The smallest unit the ERP posts in. It is the reference for stock, stocktaking and valuation and is only changed for good reason.
Packaging unit
Roll, case, canister or pallet. Every level gets its own record with weight, dimensions and its own article number.
Conversion factor
How many base units sit in one packaging unit. One field, one leading source, no copies buried in text modules.
Minimum order quantity
The point from which a product can be ordered. It may differ per customer group and belongs on the record, not in a footnote.
Order increment
The steps in which the quantity may rise. The cart rounds up to the next permitted value and shows visibly why it did so.
Price quantity
The quantity the stored price refers to. Without this field price tiers become useless because they apply to the wrong unit.
The care taken here shows most clearly in order lists and quick entry. Anyone typing an article number and a quantity into a form expects the line to be calculated in the unit they have in mind. How to solve that ergonomically is covered in our article on quick order and order lists. And because price tiers build directly on quantity, the tier threshold has to use the same unit as the input field – otherwise a tier starting at 500 pieces hardly ever applies when the customer orders in cases of one hundred. The pricing side of that question is covered in the article on price lists and tier pricing in Shopware.
Getting unit pricing and price quantity right
As soon as a product is sold by weight, volume, length or area, the question of the unit price arises. German price law allows exactly five reference quantities for it: 1 kilogram, 1 litre, 1 cubic metre, 1 metre and 1 square metre (PAngV). For loose goods offered by weight or volume, 100 grams or 100 millilitres are also permitted depending on common commercial practice (PAngV); for goods customarily supplied in quantities of 100 litres, 50 kilograms or 100 metres and above, the unit that matches common commercial practice applies (PAngV). What matters is the scope of the obligation: it applies to offers made to consumers (PAngV). It does not apply in a pure business-to-business relationship, whereas in a hybrid store serving business and private customers it certainly does – and there both worlds have to be separated technically and editorially.
- Base unit of measure set per product and stored with a standardised code
- A separate record for every packaging level, with factor, weight and dimensions
- Price quantity maintained unambiguously so price tiers apply to the right unit
- Minimum order quantity and order increment on the record rather than in description text
- Unit price calculated instead of typed, and tied to changes in pack size
- Units named identically in list, search, detail page, cart and order confirmation
Regardless of the obligation, the unit price is a selling argument in B2B because it makes offers with different pack sizes comparable. What matters is that it is derived from price and price quantity rather than maintained as text; otherwise it will not survive the next change in pack size. Search engines have dedicated fields for it as well: the product data specification knows two attributes for the measure and the reference quantity of the unit price (Google). And because services need a unit too – hour, call-out, flat rate or term – it is worth reading the article on installation and service contracts in the B2B shop. Anyone who wants to anchor unit logic in product data management will find the right framework in our PIM integration.
Display in search, listing and the cart
Buyers decide within seconds, usually already in the result list. If a price appears there without a unit, they have to open the detail page to understand what the amount refers to. That extra step is expensive: across the studies evaluated, around 70.22 percent (Baymard Institute) of visitors abandon a filled cart, and larger stores can typically raise their conversion rate by roughly 35 percent (Baymard Institute) through better checkout design. Part of that friction is self-inflicted in B2B and arises exactly where quantity, unit and price reference do not match. Internal search is affected too: someone searching for a 100-metre cable means one roll, not one hundred rolls – more on that in the article on onsite search with part numbers.
Four failure patterns you can spot immediately
From the ERP through the catalogue to the invoice line
Units are only as good as their consistency across the chain. The path starts in the ERP with base unit and factors, runs through the PIM that enriches pack data, dimensions and media, into the shop – and from there back into the order. At every station the unit can be lost or reinterpreted. That is why every interface needs a fixed mapping from internal abbreviations to standardised codes, plus a check that rejects records without a factor instead of quietly importing them with the value 1. How such an integration is built technically is described in the article on ERP integration in B2B commerce.
At the end of the chain sits the invoice. The European standard for electronic invoicing reserves a dedicated field for the unit code on every invoice line (EN 16931); in Germany the national profile makes filling it mandatory. An order line created in cases in the shop therefore has to arrive here as a code the recipient can process. The same applies to logistics: dispatch units are identified by an 18-digit number (GS1) to which contents, article number and quantity can be assigned. Weight and volume per pack are at the same time the basis of every freight calculation for forwarder shipments. And anyone carrying batches or serial numbers hangs on the same chain – more on that in the article on batches and serial numbers in the B2B shop.
Taking stock of existing catalogues with mixed units
Introducing unit logic step by step
Rebuilding unit logic does not have to be a large programme. Working in waves typically carries further: start with the product groups that generate the most revenue, prove the approach there and only then roll it out across the remaining catalogue. The order matters: first define the leading source, then fill the fields, then touch the display. Starting with the interface means rebuilding the conversion in the frontend and merely moving the problem somewhere else.
- Define the leading source: base unit, packaging levels and factors come from the ERP, all other systems read.
- Agree on a code list: map internal abbreviations to standardised unit codes once and keep that mapping versioned.
- Enforce mandatory fields: products without a base unit, without a factor or without a price quantity do not enter the catalogue export.
- Activate the rules: set minimum order quantity and order increment on the record and enforce them in the cart, including visible rounding.
- Harmonise the display: identical naming in search, list, detail page, cart, order confirmation and invoice.
- Check the aftermath: sample order lines against the ERP posting and feed deviations back into the master data.
The effort depends less on the number of products than on the number of exceptions. A catalogue with tens of thousands of products and three pack patterns is sorted faster than one with a few thousand products and forty special cases. That is why the starting point is an inventory rather than an estimate. We look at existing catalogues with mixed units in a free shop check and name which fields are missing and which rules can be mapped with the built-in means of Shopware development. Occasion, scope and timing are clarified beforehand through the enquiry form.
Sources and Studies
Related Articles
Daily prices and index-linked surcharges in B2B shops
Base price, alloy surcharge, energy share and freight all move separately. How to model daily prices, surcharges and index linkage in a Shopware shop - with.
Selling Services and Maintenance Contracts in B2B Shops
Installation, inspection and maintenance contracts as bookable items in a B2B shop: product type without stock, pricing, service data and ERP handover.
Batch and Serial Number Traceability in B2B Shops
Batch, serial number and certificate in the B2B shop: how traceability moves from the ERP into shop and portal, and how a recall takes minutes, not days.