What we have seen is this: pricing compliance problems rarely begin with a missing line of theme code. They begin when pack size lives in a title, price lives in Shopify, promotional logic lives in an app and nobody owns the relationship between them. Shopify unit pricing UK implementation therefore needs a data model and operating process, not a decorative label.
Explore StoreBuilt Shopify audits and support.
Table of contents
- Keyword decision
- What changed in 2026
- Model the data
- Place the unit price
- Handle promotions
- Test and govern
- StoreBuilt point of view
Keyword decision
Primary keyword: Shopify unit pricing UK. Secondary intents include UK ecommerce unit pricing, Price Marking Order 2026 and price per 100g on Shopify. Intent is compliance-led implementation at the consideration stage. Current UK agency libraries favour broad platform, app and growth guides; the current GOV.UK update creates a timely gap for a Shopify-specific delivery framework. The right page type is a practical article supporting StoreBuilt’s audit and development services, not a replacement for legal advice.
What changed in 2026
The current GOV.UK Price Marking Order guidance describes the amended rules applying from 6 April 2026. It states that the regime covers goods sold by traders to consumers, including online sales, and distinguishes the selling price from the applicable unit price. The unit price helps a customer compare value using a standard quantity.
That sounds simple until ecommerce presentation multiplies. One SKU can appear in a product page, collection card, predictive search, recommendations, bundle builder, cart drawer and a campaign landing page. A retailer can fix the product page yet leave the customer comparing incomplete prices everywhere else.
Start by obtaining category-specific advice on scope, measurement units, exceptions and promotional presentation. Then translate that interpretation into a written technical rule. This article helps with that translation; it is not legal advice.
| Decision | Owner | Evidence |
|---|---|---|
| Products in scope | Legal/commercial | Approved category matrix |
| Standard measurement basis | Trading/compliance | Written rule by category |
| Source quantity | Product data | Metafield or structured system |
| Calculation and rounding | Finance/engineering | Test cases |
| Display locations | Ecommerce | Template inventory |
| Ongoing exceptions | Trading operations | Audit log |
Model the data
Do not make the theme parse “500 ml” from a marketing title. Product names change, translations differ and multipacks create ambiguity. Create structured fields for declared quantity, quantity unit, comparison basis and any approved exemption. Where variants have different sizes, store the data at variant level or use a model that resolves the selected variant correctly.
A robust calculation separates inputs from output:
unit price = current selling price ÷ declared quantity × comparison quantity
The difficult words are “current” and “declared”. Current price may change with a sale or market. Declared quantity may represent net weight, volume, length, area, count or a multipack total. Establish whether a six-pack should compare using total volume, per item or another prescribed basis before development begins.
An anonymous health-and-beauty retailer had pack size repeated in titles, descriptions and an ERP export. Values disagreed after several supplier changes. The useful fix was not another content clean-up: the team selected one approved quantity source, mapped exceptions and made every storefront output consume it.
Place the unit price
The safest principle is proximity: a shopper should not need to open an accordion or infer which selling price the unit value belongs to. Design a price component that renders selling price, previous price when relevant, unit price and tax context in a stable hierarchy.
Audit at least these surfaces:
| Surface | Common failure | QA question |
|---|---|---|
| Product page | Value does not update with variant | Does size selection recalculate it? |
| Collection card | Unit price absent | Can shoppers compare before clicking? |
| Search and quick buy | Old price component reused | Is the same governed component called? |
| Recommendations | Compact layout hides context | Is price meaning still unambiguous? |
| Cart | Discount changes effective price | Is displayed information still accurate? |
| Market/language view | Unit or separators break | Is localisation intentional? |
Accessibility matters. Keep the information as real text, maintain contrast and ensure screen-reader order connects the value with the relevant item and variant. Do not encode meaning only through colour or an icon.
Ask StoreBuilt about a governed Shopify price component.
Handle promotions
Static unit-price text becomes unreliable when a sale price changes. Test compare-at prices, automatic discounts, discount codes, quantity breaks, subscriptions, bundles and customer-specific catalogues. Some discounts are only known at cart or checkout; decide what can truthfully be shown earlier and how the final price information is communicated.
Avoid claiming a universal “from” unit price unless the range and qualifying variant are clear. For multi-buy offers, document whether the unit comparison reflects the normal selling price, promotional selling price or both under the approved interpretation. Your promotional engine and theme cannot be governed separately.
Build a test catalogue that includes a straightforward item, multiple sizes, multipack, sale item, percentage discount, fixed discount, bundle, subscription and an exempt product. Expected outputs should be written before the code is tested.
Test and govern
Run automated checks for missing quantities, zero values, unsupported units and suspicious outliers. Add visual regression checks to the theme release process so a new card design cannot silently remove the output. Sample the live site after every theme, pricing-app or catalogue-import change.
Measure operational quality rather than only page presence:
- percentage of in-scope SKUs with valid measurement data;
- percentage of buying surfaces using the canonical price component;
- failed calculations and stale promotional values;
- customer-service contacts about unclear value comparisons;
- time from pack-size change to verified storefront update.
Create a named owner for exceptions. A merchandiser should not invent a workaround in rich text because a launch is urgent. Give them a documented escalation route and a controlled temporary state.
Ask StoreBuilt to audit unit-pricing data and storefront coverage.
StoreBuilt point of view
We believe unit pricing should be built once as a dependable commerce capability and reused everywhere a customer compares products. The visible line is the final output; trustworthy data ownership, promotion-aware calculations and repeatable QA are the real work.