Internationalization in SAP Commerce: Global Versus Local, Decided Per Concern

"We are rolling out to Europe" sounds like one decision. It is closer to thirty, and the projects that struggle are the ones that answered them implicitly: whichever behaviour the first market's implementation happened to encode became the accidental global default, and every subsequent market has been patching around it since. The discipline this guide teaches is simple to state: for every concern (content, pricing, tax, payment, fulfilment, search, support) decide explicitly whether it is global or local, per region, and write the matrix down.

That matrix looks like this, and producing it is the first deliverable of any internationalization workstream:

Note what the table implies: it is never one-size-fits-all across regions either. Region 1 might be a strategic market with full local autonomy while regions 3 and 4 are lightweight global-template rollouts, and the architecture must carry both simultaneously. (The multi-site guide covers how the site/store/catalog model expresses these decisions; this guide is about making them.)

Know the Market Before Modeling It#

The unglamorous research that precedes the technical design, because several architecture decisions hang on it: internet penetration and device profile (mobile-first markets change frontend priorities), buying preferences and price sensitivity (which drive the promotion strategy per market), category-level online buying behaviour, and the customer journeys of the target segments. And one deceptively deep question: how is a customer assigned to a region? Billing address is the common answer; IP-based assignment and explicit selection are the alternatives; and the choice ripples into tax, pricing, and compliance behaviour, so it is a design decision, not a frontend detail.

Language: A Pipeline, Not a Property#

Adding a language is trivially easy in the platform (lang packs, localized attributes) and operationally expensive everywhere else. The considerations that turn into recurring work:

• Which languages per region, and the default per storefront (the region's dominant language, with free customer choice preserved)
• Professional translation with legal review for critical content, wired into the publication workflow (the content catalog guide's approval workflows are the natural enforcement point), not batch-exported to a spreadsheet twice a year
• Template strategy: shared templates localize; diverging templates fork the maintenance cost per market
• Post-launch reality: translation is a standing operational process from day one of live content editing, and the teams and budget for it belong in the operating model, not the project plan

Business Processes: The Local/Global Audit#

The recurring list, each with its trap:

Taxes. Markets split into simple regimes manageable inside commerce and complex ones (the US being the canonical case) demanding third-party calculation services. Two cost controls when a tax service is involved: call it only where legally necessary (checkout, not every cart render, because you pay per call and donate its latency to your funnel), and encode the display rules per market: some markets require tax shown during checkout, others show it only on the invoice, and cross-border adds customs handling to the design.

Pricing and promotions. If commerce owns international pricing, expect real complexity in currency conversion, rounding, and per-market markup rules; if an ERP owns it, the integration owns those rules instead (decide which, explicitly). Promotions carry per-market strategy (discount-driven markets versus convenience-driven ones), per-market regulation (some jurisdictions restrict what may be discounted or how prices must be denominated), and the governance question of who creates them, which maps onto the promotion engine's site and module scoping (see the promotion performance guide's per-site KIE module advice).

Payments. Payment method expectations are fiercely local: cards here, bank transfer there, e-wallets, cash on delivery. Most PSPs handle multiple regions under one merchant setup, usually: verify it during design, not integration, because "we need a second PSP for market X" discovered late reprices the project.

Shipping and fulfilment. Delivery types (home, click-and-collect, lockers), speed expectations, and free-shipping economics all vary by market, and the honest technical note from years of these projects: the out-of-the-box zone-based delivery cost calculation rarely survives a serious multi-region requirement; budget a custom FindDeliveryCostStrategy implementation from the start rather than discovering its necessity in UAT. Returns policy periods and restocking-fee legality also differ per jurisdiction, and belong in the requirements matrix, because they change order process flows.

Search. Every language needs its own Solr analysis setup: stop words, synonyms, stemming configuration (the analyzer chains from the query tuning guide, per language), and business-user synonym maintenance per language forever after.

Customer service. Central versus local support is a cost-versus-satisfaction decision per market, with channel expectations (chat, phone, market-specific social networks) as local as payment methods.

And the architectural rule that keeps all of the above maintainable: centralize regional variation behind an internationalization service. Nothing out of the box provides it; the pattern is simply a service that answers "how does region X handle Y" from one registry, so regional behaviour is data plus one seam, instead of if (region == "DE") conditionals metastasizing through the codebase. Every multi-country codebase without this seam grows it eventually, painfully; build it in month one.

The Central Trade-Off: Shared Versus Dedicated Product Catalogs#

The single highest-stakes internationalization decision in the data model, because it is nearly irreversible at scale. The honest comparison:

The pattern that wins in practice is the combination: a shared catalog for the markets that are genuinely similar (most of them, usually), dedicated catalogs only for the regions whose assortment, regulation, or release timing truly demands them. The failure mode to design against is symmetric: all-dedicated collapses under its own duplication at scale, all-shared contorts itself around the one market that needed real isolation. Decide per region, against the matrix.

Web content follows the same logic with better tooling: the multi-country content catalog features (the multi-layered global-plus-local hierarchy, managed in SmartEdit) are exactly the combined approach, and the content catalog guide covers them in depth. Watch the BaseStore-to-catalog relation while designing: one catalog per store is typical, but multiple catalogs per store and shared catalogs across stores are both legitimate shapes when the matrix says so.

Deployment Geography#

One data center with a CDN, or regional deployments? For most, CCv2 plus a well-configured CDN answers latency adequately, and the operational cost of multiple regional production instances (each with its own data, sync, and release train) is dramatically underestimated. The cases that genuinely force regional deployments are data-residency law and extreme-latency markets, and both should be named in the compliance and market research, not assumed. (Some markets are different in kind, not just configuration: China-scale differences in channels, payments, and hosting are their own project and their own analysis, beyond this guide.)

Rollout Order#

Phased rollout is the norm; the strategic choice is which market first. Most-complex-first buys architectural certainty at the price of a slow, hard first launch; least-complex-first ships early wins but risks baking simple-market assumptions into the platform (the exact accidental-defaults failure this guide opened with). The compromise with the best track record: a representative market first: complex enough to exercise the local/global seams (local pricing, local payment, local language), small enough to launch inside a quarter, followed by waves grouped by similarity from the matrix.

Which returns to the thesis: internationalization is not a feature you add but a dimension you design along, and the matrix (concern by concern, region by region, global or local, decided out loud) is the whole method. Everything else in this guide is that table's consequences.