Learning PathModule

Unit-based pricing

Model price-by-weight or price-by-volume for B2B distribution, using a variant-based or smallest-unit approach, and know where downstream systems take over.

Ask about this Page
Copy for LLM
View as Markdown

After completing this page, you should be able to:

  • Explain why unit-based pricing is a modeling exercise rather than a native resource.

  • Compare the variant-based and smallest-unit approaches.

  • Identify where the definitive order is recalculated downstream.

Many B2B distributors do not sell in whole pieces. They sell meat by the kilogram, soil by the cubic meter, cable by the meter, chemicals by the liter. The buyer expects to see a price per unit of measure ("AUD 4.50 per kg") even though the quantity ordered is continuous and the final billed amount depends on what is actually weighed or measured at fulfillment. commercetools has no native unit-of-measure price type, so this is a modeling problem. This page presents two validated approaches and, just as importantly, clarifies where the platform's responsibility ends.

Why this is a modeling exercise

There is no unit-of-measure resource to configure, and one is not required for most implementations. Two facts shape the design:

  • Unit-based pricing is primarily a display concern. The buyer needs to see and trust the per-unit price while shopping. The exact billed amount is frequently recalculated downstream, when the supplier weighs or measures the goods at shipment, by the system that handles fulfillment.
  • Money is stored as integers. Prices are integer-based (cents, or high-precision fractions), so a "per kilogram" price has to be expressed through a model that integer amounts can represent.

So the goal is not to make commercetools compute the final weighed invoice. It is to represent the per-unit price the buyer expects, carry a sensible order through checkout, and let the fulfillment system produce the definitive figure.

Approach 1: variant-based discrete quantities

Model the Product as variants that each represent a discrete quantity, and price each variant for that increment. A meat Product might have variants for 0.5 kg, 1 kg, and a 6-pack; a cable Product might have variants per standard reel length. Each variant carries a normal Standalone Price for its increment.

This is an established pattern among grocery and B2B distribution customers, where buyers select from standard weight or volume increments rather than entering an arbitrary amount. It keeps pricing entirely within native price selection (each variant is just a SKU with a price) and works cleanly with the Channel-based negotiated pricing from earlier in this module. It fits best when the business genuinely sells in a fixed set of increments.

Approach 2: smallest-unit modeling

When quantities are continuous rather than a fixed set of increments, model the smallest indivisible unit and its price in commercetools (for example, one gram) and let middleware or a Custom Field convert that into the per-kilogram figure the buyer sees.
  • Store the price of one gram as the Standalone Price (using high precision if a single gram costs a fraction of a cent).
  • A Custom Field or a middleware layer multiplies up to the display unit, for example presenting "× 1000" as the per-kilogram price.
  • The Cart carries the order in the smallest unit, and the definitive order and invoice are produced downstream when the goods are weighed at shipment.

This approach suits products with variable, continuous quantities where discrete variants would be impractical. It trades a little more integration effort for the flexibility to price any quantity.

Where the platform hands off

Both approaches share a boundary worth stating explicitly to stakeholders: the order created in commercetools may be a preliminary record. For weighed or measured goods, the final billed quantity (and therefore the final amount) is commonly determined by the fulfillment or weighing system at the point of shipment, and flows back as the definitive order or invoice. Designing for that hand-off up front prevents the mistake of expecting commercetools to be the system of record for the exact weighed total.

Worked example: Atlas Corporate bulk materials

Atlas Corporate's APAC division buys two materials from Zen Electron Trade's industrial range:

  • Pre-cut mounting brackets, sold only in packs of 10, 25, and 50. Model these as variants (one per pack size), each with a Channel-scoped Standalone Price. The buyer picks a pack; native price selection does the rest. (Approach 1.)
  • Bulk thermal compound, sold by weight to whatever quantity a job needs. Model the smallest unit (one gram) as a high-precision Standalone Price, and have middleware present "per kg" to the buyer and carry the gram quantity on the Cart. At shipment, the warehouse weighs the dispensed amount and the fulfillment system issues the definitive invoice. (Approach 2.)

The same buyer uses both approaches because the products differ: discrete increments fit variants, continuous weight fits smallest-unit modeling, and in both cases the precise billed figure for weighed goods is settled downstream.

Key takeaways

  • commercetools has no native unit-of-measure price; unit-based pricing is a modeling exercise, and it is primarily a display concern.
  • The variant-based approach models discrete quantity increments as variants, each with its own Price, best for a fixed set of increments.
  • The smallest-unit approach prices the smallest indivisible unit and converts to the display unit via a Custom Field or middleware, best for continuous quantities.
  • For weighed or measured goods, the commercetools order is often preliminary; the definitive amount is recalculated downstream at fulfillment.

Test your knowledge