Rounding, defaults and resolution rules

You run the annual price round, apply 7 % to 40,000 entries, and the storefront shows €21.293. Or two lists tie for one buyer and the price differs between two identical calls. Both are settings, and both were decided by a default nobody looked at.

A handful of settings sit underneath every price the platform computes. They are quiet, and expensive to discover late, because each one changes numbers that have already been quoted.

The settings, and what each one changes

Rounding, in the order it happens

Three separate things are often confused. They apply at different moments.

Price decimals applies to amounts the platform computes: net from gross, gross from net, line totals. Stored catalogue prices are returned exactly as typed, which is why a price of 0.0185 per piece for a list sold per 1,000 keeps its four decimals instead of collapsing to 0.02.

Rounding mode decides how that rounding lands. Half up is the commercial convention. Half to even, banker's rounding, is required on invoices in some jurisdictions, and rounding twice does not reproduce it, so if you need it, set it.

Price endings after a bulk change is different in kind: it is a merchant rule, not an arithmetic one. A 7 % increase turns €19.90 into €21.293, which nobody prints. Snapping to x.99, x.95, x.50 or whole units is the difference between a bulk change you can ship and one that has to be corrected by hand afterwards.

When two price lists tie

Specificity decides first, then priority. If both tie, this rule decides. The point is that something decides, deterministically, rather than whichever row the database happened to return first.

Cheapest for the buyer is the default and the one you can defend in a customer conversation. The others are useful mainly while you are cleaning up an overlap you already know about.

An explicit On request entry in any of the tied lists still stops resolution. "Ask us" outranks every number.

Prices for anonymous visitors

Two controls answer the same question at different scales:

• Logged-in buyers only, per price list, skips that one list for anonymous callers.
• Show prices to anonymous buyers, once for the tenant, turns every price into "on request" for a visitor with no contact or organization.

Use the tenant setting if your policy is "prices only for customers". Relying on the per-list flag means remembering it on every list anyone ever creates, and one forgotten flag publishes your price book to the open web, competitors included. They do look.

If you leave anonymous prices on, then your standard list is a public price book. That is a legitimate choice, it helps new buyers and search engines, but make it deliberately.

Fallback currency and standard list code

Two small settings that only matter at the edges:

Fallback currency is the last resort for a price call that names no currency and whose market cannot be determined. The buyer's market decides first and stays the source of record. Getting this wrong means no prices at all, because resolution only considers lists in the resulting currency.

Standard price list code is the code of the list created when the app is installed. Set it to whatever your ERP calls its base list (standard, BASE01, VK01) before anything is seeded, so you do not end up with a second base list nobody asked for.

What to check

• Run one bulk adjust in preview mode and confirm the endings look like prices you would print.
• Confirm Stored prices are matches your actual convention, then state the basis explicitly on every list anyway.
• Ask yourself whether an anonymous visitor should see prices, and set the tenant switch to match the answer.

Next

• Adjust a whole price list — where the rounding settings become visible.
• Check which price a buyer sees.