Scale your business

Go multi-country

Markets, currencies, tax, languages and classification: the Austrian subsidiary and the Polish buyer.

The first foreign order usually arrives before the international project does. An existing German customer has a plant in Austria that wants to order directly; a Swiss buyer finds you through a search; the purchasing department of a French group asks whether you can invoice their subsidiary. At that point somebody works out the VAT treatment by hand, someone else translates a data sheet in Word, and the arrangement holds for exactly as long as the volume stays small.

Why this is harder than it sounds

"Multi-country" is four different projects sharing one name. They have different owners, different durations and different failure modes: the commercial setup (market, currency, tax, terms, assortment), the linguistic one (translation and its upkeep), the data-standard one (classification and exchange formats for the systems on the other side), and the operational one (shipping, payment, credit, customs paperwork). Budgeting them as one line item is why these projects overrun.

The distinction that saves the most rework is between a market and a language.

	A market is	A language is
What it carries	Currency, tax treatment, price list, assortment, payment and delivery terms	Product texts, category names, storefront content, documents
Driven by	Where the invoice goes and under which rules	What the person reading prefers
Typical mismatch	Switzerland: one market, German and French	Germany: one market, read in German, English and Polish

A Polish buyer at a German customer's plant needs Polish text and German commercial terms. A Swiss subsidiary needs Swiss francs and Swiss tax with the same German text. Model those as one dimension and every later change is a workaround. In the platform they are separate: a market carries its currency, its locales and its tax classes, and a price list belongs to a market.

A foreign price list is a commercial decision, not a currency conversion. Taking your German list and dividing by a fixed rate produces prices that are wrong twice: wrong against local competition, and wrong again as soon as the rate moves. Somebody has to own the foreign price list as a price list (including who reviews it and how often), or the market will be either unprofitable or uncompetitive, and you will not know which.

Tax is the item most often underestimated, and it is not a shop problem. An intra-community supply to a customer with a valid VAT identification number is treated differently from one without; a Swiss delivery leaves the EU entirely; a domestic delivery to a foreign customer's German site is domestic. Your tax adviser decides the rules. The platform's job is that each market carries the right tax classes and rates, and that the buyer's VAT ID is captured where it matters. A mistake here ends up in your accounts.

Translation is a workflow with upkeep attached. The first pass is the visible half; the second, third and tenth passes are the real cost, because every source change reopens the translation and nothing tells you which texts are now stale. Machine translation of technical attributes is a specific trap. A translated thread_size or a converted 10 bar is a wrong specification that a buyer will order against, and nobody notices until the delivery. Translate the marketing text; map the technical values.

Classification belongs in the same conversation, though it sounds like administration. Large customers abroad load supplier catalogues into procurement systems that expect ECLASS, ETIM or UNSPSC. Without it the catalogue cannot be loaded at all, which makes classification a question of market access. The standards also release new versions, and that is maintenance you are signing up for.

One more that surprises people: the assortment is not the same everywhere. Approvals and certifications differ, some products are not permitted in some markets, and where you already sell through a distributor in a country, a direct storefront is a channel conflict you should settle before launch rather than after the first complaint.

The levers

Define the market before you translate anything

What good looks like: each market exists with its currency, its locales, its tax classes and its own price list, and you can state for each one what is different about it commercially. Nothing is inherited by accident.

What it depends on: a decision on how many markets you need. Two well-run markets beat eight that share one price list and a hope.

Add a language as a workflow with an owner

What good looks like: localizable attributes are marked as such, a first pass exists for the assortment that matters, and there is a defined route for what happens when the German source text changes. Someone is named as responsible for the language beyond its launch.

What it depends on: deciding what gets translated. The full catalogue is rarely the right answer for a first market; the articles that carry the revenue are.

Classify for the systems on the other side

What good looks like: the articles you sell into procurement-driven markets carry the classification those customers require, with the features filled, and you know which standard version you are on.

What it depends on: mapping your own attributes to the standard's features once. Done well it is reusable for every customer that asks; done per customer it never ends.

Make the foreign order deliverable and collectable

What good looks like: the buyer in the new market sees delivery options and costs that are real for their address, a payment method their finance department accepts, and terms that reflect what you are willing to carry in credit risk across a border.

What it depends on: shipping zones, payment methods and credit rules being set per market rather than copied from the domestic case.

A sensible order

Phase 1: one market, existing customers. Start where the demand already exists: the foreign subsidiaries of customers you already serve. Set up that market with its currency, tax and price list, and serve it in the language it already accepts, which for a first market is often German or English rather than the local language. This phase proves the commercial model without the translation cost. It depends on the tax treatment being confirmed by whoever is accountable for it, in writing, before the first invoice.

Phase 2: the language, on the assortment that earns. Translate the categories, the top articles and the storefront content, with the technical attributes mapped rather than translated. Put the upkeep route in place at the same time (the mechanism that tells you a text went stale), because retro-fitting it after two years of drift means re-checking everything. Depends on Phase 1: translating into a market whose prices are not settled is expensive rework.

Phase 3: classification, exchange formats and the second language. Classification for the procurement-driven customers, catalogue exports in the formats those customers require, local payment methods, and the next language. This is also the point to review the assortment per market as a whole rather than by exception. Depends on Phase 2 having a translation process that survives a source change.

Common mistakes

Treating language and market as one thing. The Swiss market with two languages and the German market with three break this model immediately.
Converting the price list at a fixed rate. It is wrong on day one against local competition and wrong again next quarter.
Machine-translating technical attributes. A wrong specification is worse than an untranslated one, because someone will order against it.
Launching a market before the tax treatment is confirmed. Corrections here land in your accounts.
Ignoring classification until a customer asks. By then it is on their timetable, and their timetable is short.
Opening direct sales in a country where you already have a distributor, without deciding the channel question first.

How you know it is working

Orders and revenue per market, from the first month. If a market cannot be reported on separately, it has not been set up as a market.
Catalog completeness per locale. The share of the sellable assortment that is complete in each language, the number that predicts whether the market can work at all.
Zero-result searches in the new language. Each is a vocabulary gap the buyer has named for you; see Working the zero-results report.
Stale translations: texts whose source changed after the last translation. It should be a working queue, not a discovery.
Tax and invoice corrections per market. Any recurring pattern means the market's rules are modelled wrongly rather than applied wrongly.
Share of catalogue carrying the classification each market's large customers require. This is the gate on procurement-system access.

Publish a digital product catalog: the catalogue structure everything here depends on.
Sell through marketplaces and channels: the other reason to keep assortment and price separable per audience.
Reach more customers: a new market is the same argument as the long tail, in another language.

What you're building

One catalogue, one customer model and one order path, served into several markets. Each market carries its own currency, tax classes, price list, payment and delivery rules; each storefront reads one market in one or more languages. Orders from every market land in the same order list and reach the same ERP.

flowchart LR
  ERP["Your ERP"]
  PROC["Foreign customers' procurement systems"]
  subgraph CS["Commerce Studio"]
    M["Markets: currency, locales, tax classes"]
    PR["Price list per market"]
    P["Products with localizable attributes"]
    SP["Shipping and payment per market"]
    O["Orders"]
  end
  subgraph XS["Experience Studio"]
    SF["Storefront per market, languages"]
  end
  subgraph IS["Integration Studio"]
    EX["Export profiles: BMEcat, ECLASS"]
    WF["Workflows"]
  end
  ERP -- "articles, conditions" --> WF
  WF --> P
  WF --> PR
  M --> PR
  M --> SP
  M --> SF
  P --> SF
  SF -- "order with VAT ID" --> O
  O -- "order" --> WF
  WF -- "order" --> ERP
  P --> EX
  EX -- "classified catalog" --> PROC

What you need

A written list of the markets you will run and what differs commercially in each — Languages and markets
The tax treatment per market confirmed by your tax adviser — Currencies and tax
A price list per market with a named owner — Price lists
Product attributes marked as localizable or technical before the first translation — Attributes and attribute groups
A translation route that shows stale texts after a source change — How catalog translation works
Shipping zones, payment methods and credit terms decided per market — Shipping methods and zones
A position on classification for the procurement-driven customers in each market — Classification standards
The channel question settled where a distributor already serves the country — Sell through marketplaces and channels

Build it

Write down the markets you need and what differs commercially in each one — Languages and markets
Get the tax treatment for the first market confirmed in writing — Currencies and tax
Create the market with its currency, locales and tax classes — Markets
Create the market's own price list and name its owner — Price lists
Set shipping methods, payment methods and payment terms for that market — Payment methods
Create the storefront for the market and connect its domain — Create a storefront
Run the pre-launch checks and open the market to the subsidiaries of existing customers, in German or English — Pre-launch checks
Mark localizable attributes and add the local language — Add a language
Translate categories, top articles and storefront content; map technical values instead of translating them — Translate the catalog
Put the stale-translation queue in place with an owner — Translation quality
Map your attributes to ECLASS or ETIM once and classify the top assortment — Map attributes to a classification
Set up the export profile the market's procurement-driven customers require — Catalog export profiles
Report orders, revenue and completeness per market and locale from month one — Reports and exports

Decisions you'll need to make

Decision	The trade-off	Where most customers land
How many markets? One per country, one per currency-and-tax situation, or one EU market with local languages.	Every market is its own price list, tax set, shipping table and reporting line. Too few and you build workarounds for the Swiss francs; too many and two people maintain eight price lists.	One market per country where the currency or the tax treatment differs. DACH companies usually end up with three (DE, AT, CH) because CHF and Swiss tax force the third, and treat further EU countries as one market until volume justifies more.
Which language first, and for how much of the catalogue? Local language for everything, local language for the revenue-carrying assortment, or German/English for the first year.	A full translation delays launch by months and creates upkeep for articles nobody abroad buys. A partial one leaves search gaps in the tail.	German or English for the first market, then the local language for the categories and the top articles. The tail gets translated when a zero-result report says it is being searched for.
Where does the foreign price come from? Converted from the German list by rule, derived with a market-specific factor, or maintained as its own list.	A converted list is cheap and wrong twice. An own list needs an owner in sales who reviews it, which is a recurring cost.	An own list per market, seeded once from the German list by rule and then owned by the sales lead for that market. The seeding is a starting point, never the mechanism.
Who computes the tax? Tax classes and rates in the platform for checkout, the ERP for the invoice, or both.	If the two disagree, the buyer sees one figure at checkout and another on the invoice. The platform needs the classes to show a correct total; the ERP stays authoritative for the booked invoice.	Tax classes per market in the platform, mirroring the ERP's logic, with the ERP invoice as the document of record. The VAT ID is captured on the organisation; how you validate it is a process you define with your tax adviser, not a platform automatism.
Direct or through the distributor? Where a country already has a distributor: sell direct, sell only to accounts the distributor does not serve, or give the distributor a storefront.	Direct sales grow faster and cost the relationship. A distributor storefront keeps the partner and gives you less data about the end customer.	Keep the distributor where one exists, run their customers on the distributor's conditions or in a dealer storefront, and go direct only in countries without a partner.
Classification: map once or answer per customer? Map your attributes to ECLASS/ETIM centrally, or produce a classified export each time a customer asks.	The central mapping costs a few weeks up front and then reuses. Per-customer exports are cheap the first time and never stop.	Map once, for the top assortment, when the first large customer asks, and extend the mapping with every further request.

Commerce Studio: Markets · Tax classes · Currencies · Locales · Price lists · Shipping methods · Payment methods · Channels
Experience Studio: Sites · Languages and markets · Domains
Integration Studio: Import/export · Field mapping

Edit this page

Scale your business

More countries, fewer systems, one ERP connection, less retyping, and numbers two departments agree on.

Consolidate systems

Fewer moving parts, fewer licences, fewer integrations to keep alive.