GEO-080·Issue 07·Technical Foundation·80 / 132

Localized Feeds and Pricing: Currency, Tax, and Shipping

Feed prices, tax basis, and shipping decide whether AI quotes you or drops you. A per-market offer model, a validation playbook, and honest limits.

5 min readGEOTechnical Foundationcross-border

Issue focusAcross Markets: Multilingual, Localization, and Regional Semantics

On a Friday, a support ticket arrives from a buyer in Munich: a chat assistant quoted less than checkout and promised free shipping. Operations checks the page: price right, shipping note right. The error sits in the feed — a net price before VAT, plus the US store’s free-shipping line. She does not complain. She closes the tab and opens another brand.

A localized feed is not a translated product list but one complete offer per market — currency, tax basis, shipping, delivery window — and if one of the four is unclear, a model will hedge or name someone else.

The row key is product plus market

The same machine in Germany, the UK, and the US is three promises, not one record.

Agents read fields, not page layout. Price, currency, stock, shipping, and a delivery window let them compute a total. Withhold any of it and they either caveat the answer — handing comparison back to the buyer — or drop the row.

So change the grain: one row per SKU per market, self-consistent, nothing borrowed from a neighbor. A receiving system that converts your global price is pricing for you without knowing your cost structure. Sequence markets first; the feed records the decision.

Localize the transaction fields, not the copy

Localization budgets go to headlines; the comparison layer ignores copy. Five fields decide whether you are comparable.

FieldWrite it asCommon failure
PriceA bare number, no symbol, no “from”“From €89”
CurrencyISO 4217 code for that marketA € symbol only; GBP pages in EUR
TaxExplicit inclusive or exclusive, matching the pageLeft to inference; exports disagree
ShippingAmount, currency, threshold, destination“Calculated at checkout”; “free worldwide”
DeliveryA window from the warehouse actually usedCopied from the home warehouse

The table is not for humans; it is for a validation script. Once a cell may say “calculated at checkout,” every downstream comparison stops being falsifiable. For the copy layer around it, see five traps in local buying language.

The number being compared is the landed price

A buyer asking what something costs gets the price to the door.

Tax basis comes first. EU consumer prices are generally VAT-inclusive; most US states add sales tax at checkout, so the same 299 resolves to two totals. An omitted basis forces a guess, and the wrong guess lands in your inbox.

Shipping is a promise, not a state. Thresholds and surcharges differ by market. A row reading “free worldwide” promises what you cannot afford where freight costs most — and models repeat it verbatim.

Duty comes third. DDP and DAP (still written DDU by many sellers) look the same before checkout and diverge when an agent prices the order. If you cannot compute it, make “duty not included, payable on delivery” a field: a partial answer can be annotated, a vague one only guessed.

Of an offer’s four copies — page, structured data, feed, checkout — the feed is the one most often missed, and all four must share one currency and tax basis. See the four copies of price and stock.

Four steps: one source, failing assertions, alerts

The goal is not a one-time fix but wrong rows that fail before publication.

StepActionOwnerPasses when
1 Define the matrixMarkets, currencies, tax regimes, warehouses; one row eachGrowth, financeEvery live market has rows
2 One sourcePrice, tax, shipping computed from one master record; no exporter editsEngineeringOne price edit updates feed, page, checkout
3 AssertRules encoded as release-blocking checksEngineeringA deliberately broken row is rejected
4 Alert and retestDiff a daily sample; re-ask monthly in-marketGrowthEvery diff traces to a named field

Split assertions into missing and contradictory, never one pass rate:

  • Currency code present and matching page and checkout
  • Tax flag populated and identical to the local page
  • Shipping and threshold computable; no “calculated at checkout”
  • Delivery window from the warehouse used locally
  • Price and stock timestamps inside the agreed TTL

Syntax validation only proves the file parses: a syntax error rejects it loudly; a semantic error drops you from a shortlist quietly. The second kind needs alerts. For the retest, reuse the sampling of an AI visibility baseline.

Example: one machine, four rows

Example — the brand, prices, and shipping terms are invented; no real product is described.

MarketPriceTaxShippingDelivery
Germany349 EURVAT includedFree over 50 EUR, else 4.95 EUR2–4 days, local warehouse
UK309 GBPVAT included4.95 GBP, no threshold3–5 days, local warehouse
US379 USDTax excluded, by state at checkoutFree over 75 USD2–5 days, local warehouse
Canada519 CADTax excluded, duty separateFrom 12 CAD5–8 days, cross-border

The rows differ in fields, not copy: Germany quotes tax-inclusive with a threshold, the US tax-exclusive with a lower one, Canada crosses a border and must state duty separately. Collapse them into one row and the model returns a vague range; the agent hits the mismatch at checkout.

Where this breaks

Do not build the matrix for one market; maintenance scales with markets and the return arrives with the second. Fix the shipping threshold and delivery window instead.

Marketplace-only sellers do not own the spec: fill the platform’s fields and defer the self-built feed.

Quote-based, custom, and B2B lines should not manufacture a landed price; a quote range with a validity window beats a fabricated number that gets cited back.

Tax display, duty thresholds, and discount disclosure are finance and local-adviser decisions. This is field structure, not tax advice.

Fast-moving prices should not be chased in real time; promise only the stability your refresh cycle can honor.

This month, pick one non-default market that already has orders, export its feed rows, and reconcile them against checkout on five columns: price, currency, tax, shipping, delivery window. Fix the top 20 disagreeing SKUs by units sold, then automate the reconciliation monthly. The rest of the lane is on the technical foundation hub.