A consumer storefront quotes one number: the price the customer pays. A B2B storefront quotes a different one: the price before tax, because the buyer reclaims it and budgets in ex-VAT terms. A store selling to both is being asked to be two storefronts at once, and Shopify’s pricing model is built on the assumption that you will pick one.
That assumption is not a bug. It runs deep enough that working around it badly produces a store where the product page, the cart, and the invoice disagree — which for a B2B buyer is not a cosmetic problem. It is a reason to phone a competitor.
What Shopify actually gives you
Tax-inclusive pricing is resolved per market, not per customer. A market is configured to either include tax in displayed prices or not, and everything downstream — collection pages, product pages, cart, checkout — inherits that single decision. Liquid hands your theme a price that has already had that decision applied to it.
This means the theme does not have both numbers. It has one number and no reliable way to derive the other, because deriving it requires knowing the tax rate that applied, which depends on the product’s tax category, the destination, and any overrides. The theme knows none of these things at render time.
The rounding trap
Even where the rate is genuinely uniform, computing the second figure per line item and summing is not the same operation as summing and then computing. With a 5% rate and a basket of oddly-priced SKUs, the two methods differ by a few paise or fils — which is small enough to survive testing and large enough that a purchasing manager reconciling your quote against your invoice notices.
Decide which figure is authoritative before writing any code. Everything else is derived from it, displayed to the same rounding rule, and reconciled against the totals the checkout will produce — not against a spreadsheet.
Where the seam is
Checkout is the constraint that shapes the whole design. Whatever a theme does, checkout displays the market’s configured basis and nothing else. A storefront that shows a B2B buyer ex-VAT prices throughout and then hands them an inc-VAT checkout has not solved the problem; it has moved the surprise to the least recoverable moment in the funnel.
The workable shapes are narrow. Either the buyer’s context resolves to a market whose configuration matches what you showed them, so display and checkout agree by construction — or you show both figures everywhere, clearly labelled, with the authoritative one visually dominant, so that nothing at checkout is new information.
What this looks like when it is right
The buyer sees the basis appropriate to who they are, labelled explicitly rather than implied — AED 1,240 ex. VAT beats a bare number and a footnote. The secondary figure sits alongside in a muted weight rather than behind a toggle, because a toggle is a state that can be wrong when the page is shared, printed, or screenshotted into a purchase order. Line totals, cart total, and the eventual invoice all agree to the last unit. And nothing about the number changes after the page has painted.
Buy an app
A dual-pricing app rewrites displayed prices in the browser after the theme has rendered.
Cost US$15–40/mo, minutes to install
Breaks when AJAX cart updates and section rendering repaint the original price; the app has to re-run on every DOM change, and the flash of the wrong number is visible on slow connections.
Hack the theme
Compute the second figure in Liquid from a hardcoded rate and render both.
Cost A day, no recurring fee
Breaks when The moment you sell into a second tax jurisdiction, or a product has a reduced rate, or the rate changes. You now maintain tax law in a theme file.
Build it properly
Drive display off the market and customer context Shopify already resolves, and reconcile the figures against the same totals the checkout will produce.
Cost One engagement
Breaks when Nothing routinely — but it requires deciding up front which figure is authoritative, and accepting that checkout will show only one of them.
