Pricing, Tax & Currency

Pricing and Currencies

Price sits on the variant, with its currency, and everything else adjusts it.

Where to find it

Architect Panel → Commercial:

• Carts — the cart itself and its options

Architect Panel → Data:

• Datastores — then View Data on the cart table, and look for the row actions

The layers

1. The variant price — the base.
2. Special prices — time-limited, replacing the base.
3. Volume pricing — a lower price above a minimum order quantity.
4. Discounts — codes and multi-buy, applied at the basket.
5. Tax — added according to the product’s tax type.

Knowing the order matters when a total is queried, because the answer is almost always that two layers combined in a way nobody expected.

Other currencies come from exchange rates

Rather than from a price per currency. Each additional currency has a rate against the base, so one price maintained centrally produces prices everywhere.

That is much less work, and it means a rate that has not been updated quietly misprices your entire catalogue.

Update rates deliberately

A stale rate is a systematic error across every product, in a direction you will not notice if it favours the customer. Decide how often rates are refreshed and by whom, and record when it last happened.

Converted prices look converted

Because they are. If presentation matters in a market, consider setting a deliberate rate that produces round numbers rather than using the interbank rate exactly.

Price changes are per variant

So a catalogue-wide change is a bulk operation. Plan it as one — a spreadsheet, an import, a check — rather than as an afternoon of manual edits, which is how a decimal point moves.

Check the total, not the price

When testing, look at what the customer pays: base, less any special price, less any volume break, less any discount, plus tax, plus shipping. Each layer is right on its own far more often than the total is.

Showing prices at all is a choice

The cart can hide them entirely, which is how a trade catalogue or an enquiry site works. If prices are only for signed-in customers, that is the cart’s pricing option plus its permissions, not something to solve per product.

Worked example

A shop prices in sterling and derives euro and dollar prices from rates refreshed monthly, with the date recorded. Price changes are done as an import with a printed check of the twenty highest-value lines. Testing looks at basket totals rather than at product pages.

Recommendations

• Know the order the layers apply in.
• Refresh exchange rates on a schedule and record when.
• Treat catalogue price changes as an import, not manual edits.
• Test the basket total, not the price.

Special and Volume Prices

Two ways to charge less than the base price, with quite different purposes.

Where to find it

Architect Panel → Commercial:

• Carts — the cart itself and its options

Architect Panel → Data:

• Datastores — then View Data on the cart table, and look for the row actions

Special prices

A replacement price for a product, in a currency, with a start and an expiry. And critically, a flag deciding whether the product is excluded from offers while on special.

That flag is what stops a promotional code stacking on top of a sale price — which is how a discount campaign turns out to have been unexpectedly expensive.

Always set the expiry

A special price without an end date is a permanent price reduction that nobody decided to make. Sales end; put the date in when you create it, not later.

Volume pricing

A price that applies above a minimum order quantity, set per product. Several tiers can exist, so ten, fifty and a hundred can each have a price.

This is the trade mechanism — it is how you offer a case price without maintaining separate case products.

Check the tiers make sense

Tiers are entered independently, so nothing stops a hundred costing more per unit than fifty. Read them back as a list after entering them, because the error is invisible on a single row and obvious in a column.

Volume pricing and minimum order quantity are different

Minimum order quantity says the customer cannot buy fewer. Volume pricing says buying more costs less each. Confusing them produces either a shop nobody can buy from or a trade discount everybody gets.

Watch what they cost together

A special price plus a volume break plus a discount code is three reductions on one line. Model the worst case before running a promotion, and use the offer exclusion where the combination would be unprofitable.

Review what is on special

Periodically. Special prices accumulate — set for a campaign, extended, forgotten — and a shop where a third of the catalogue is permanently reduced has simply repriced itself without deciding to.

Worked example

A shop runs seasonal special prices with fixed end dates and offers excluded, and volume tiers at 10, 25 and 100 for trade lines. A quarterly review of active special prices found four that had been extended twice and were now simply the price, which were made the base price instead.

Recommendations

• Always set an expiry on a special price.
• Exclude specials from offers unless you mean to stack.
• Read volume tiers back as a list.
• Review active specials quarterly.

Tax Rates

Tax rates are defined per country and linked to products, so each product is taxed at the rate it should be.

Where to find it

Architect Panel → Commercial:

• Carts — the cart itself and its options

Architect Panel → Data:

• Datastores — then View Data on the cart table, and look for the row actions

What a rate carries

A country, a name, a description, a percentage, and whether it is the default for that country. The description matters more than it looks — it is where the rate’s scope is written down, and that is what somebody reads when deciding which rate a product needs.

UK rates are supplied

Standard at twenty per cent, Reduced at five, and Zero, each with a description of what it covers — children’s car seats and domestic fuel for reduced; books, most food, children’s clothing and prescribed pharmaceuticals for zero.

They are a starting point, not tax advice. Categorisation is genuinely difficult at the margins and getting it wrong is your liability.

Products are linked to rates

Explicitly, as a row action on the tax rate showing its applicable products. So assigning rates can be done from either end — per product, or by working through a rate and adding everything that belongs to it.

The second is usually faster and more accurate, because you are making one decision at a time rather than remembering it per product.

The default is a fallback, not a decision

Products with no explicit rate get the country default. That is sensible behaviour and a trap: a product that should be zero-rated and was never linked is silently charged at standard, and nobody notices until a customer does.

Audit for products with no explicit tax type before launch.

Take advice

Which rate applies to which product is a question for your accountant, not for a platform administrator. The platform applies what you tell it; deciding what to tell it is a professional judgement.

Rates change

Governments change them, sometimes with short notice and sometimes temporarily. Know who watches for that and how quickly you can act, because the change applies from a date whether you updated the shop or not.

Selling abroad multiplies the problem

Rates are per country, so international selling means a rate set per destination and rules about which applies. That is a decision to take before opening a market, not after the first order.

Worked example

A shop assigns tax rates by working through each rate’s applicable products list rather than product by product. Before launch it ran a check for products with no explicit rate, which found eleven zero-rated items about to be charged at twenty per cent. The rates were reviewed with its accountant.

Recommendations

• Assign from the rate, not product by product.
• Audit for products with no explicit rate.
• Take professional advice on categorisation.
• Name who watches for rate changes.