Setting up Adobe Commerce for multiple regions means making hard architectural decisions before a single locale is configured — scope choices, tax compliance requirements, and carrier version compatibility that implementation guides routinely gloss over. This article covers what actually breaks and why.

Selling across borders is one of the most exciting and operationally complex things you can do with Adobe Commerce. Whether expanding from one country to three or managing a portfolio of brands across a dozen markets, the platform gives powerful tools to do it well. But out-of-the-box features only take you so far without a clear setup strategy.

This article draws on real-world implementation experience to walk through the foundational decisions around multistore architecture, how to localize content without duplicating work, and how to configure tax and shipping rules that actually hold up under the pressure of diverse customer expectations and regulatory requirements. The scope decisions described here are the difference between a clean implementation and one full of surprises.

Architecting your multistore setup — decide before you build

Before configuring a single locale or tax zone, the most critical decision is architectural: how many stores do you actually need? Adobe Commerce’s three-tier hierarchy — Website → Store → Store View — gives immense flexibility, but it also creates confusion when teams conflate these levels.

How to configure a new Store View for a new locale

• 1. Create and enable the Store View. In the Admin, go to Stores → Settings → All Stores and click Create Store View. Assign it to the appropriate Store, give it a meaningful code (e.g., de_de, fr_fr), and set it to Enabled.

• 2. Override locale-specific settings. Navigate to Stores → Configuration, select the new Store View from the scope dropdown, and override language, currency, and date format.

• 3. Set locale options. Under General → Locale Options, set the correct locale and first day of week for the target market.

• 4. Lock your scope inheritance strategy before production. Decide which settings live at Global vs. Website or Store View level before any production traffic touches the store. Changing this mid-project creates significant rework.

Localizing content that actually resonates

Localization goes well beyond translation. Customers in Germany have different trust signals than customers in Japan. Payment methods that convert in Brazil may not exist in Australia. Getting localization right means thinking holistically about content, UX, and commerce behavior — not just swapping strings.

Translating CMS content and product data

Three common approaches, in order of scalability:

Manual Store View overrides work for smaller catalogs. Navigate to each product and use the Store View scope switcher to enter translated names, descriptions, and attributes. This does not scale.

Import/Export is suitable for mid-size catalogs. Use System → Import/Export to export product data, hand off to translators, and re-import against specific Store Views.

Third-party Translation Management Systems (TMS) are recommended for any large catalog. Integrate with tools like Phrase for workflow-driven translation at scale.

Localizing currency and formatting

• Set Base Currency at Website scope. Go to Stores → Settings → Configuration → General → Currency Setup. Switch the scope selector to your target Website before setting Base Currency — this setting must live at Website scope, not Global. At the Store View scope, set Display Currency and Allowed Currencies independently per market.

• Configure a currency rate provider. Go to Stores → Settings → Configuration → General → Currency Setup and configure your preferred provider. Supported providers vary by Commerce version — commonly available options include Fixer and Currency Converter API. To manually refresh or view current rates, go to Stores → Currency → Currency Rates.

Configuring tax rules that work across borders

Tax is where many multistore implementations run into trouble. The rules vary not just by country but by product type, customer type, and sometimes the customer’s precise location within a country.

Understanding Adobe Commerce’s tax model

Adobe Commerce calculates tax based on Tax Rules — three-way intersections of:

• Customer Tax Classes: e.g., Retail Customer, Wholesale, VAT-Exempt

• Product Tax Classes: e.g., Taxable Goods, Digital Products, Clothing

• Tax Zones and Rates: the actual percentage tied to a geographic region

Setting up tax rules for a new market: step-by-step

• Create Tax Zones and Rates. Go to Stores → Taxes → Tax Zones and Rates. Create one rate per region/country combination. For EU VAT, this means one rate per member state. For the US, rates change constantly across 12,000+ jurisdictions — use an automated tax service like Avalara or TaxJar. Commerce cannot handle destination-based sourcing rules beyond ZIP granularity, which means manual US sales tax management is not viable at scale.

• Create the Tax Rule. Go to Stores → Taxes → Tax Rules and click Add New Tax Rule.

• Assign Product Tax Classes to products. Edit each product and set its Tax Class attribute to the appropriate class (e.g., Digital Goods – EU for VAT OSS purposes).

• Configure display settings per Website or Store View. Go to Stores → Settings → Configuration → Sales → Tax. Switch to the target Website or Store View scope, then set whether prices display inclusive or exclusive of tax. This is critical for EU markets where tax-inclusive display is the norm.

EU VAT: Key considerations

VAT One Stop Shop (OSS): OSS applies to cross-border sales of both goods and digital services to EU consumers — not just digital goods. If you sell into EU markets, you may need to register for OSS and apply the VAT rate of the customer’s country. Adobe Commerce supports per-country rates, but OSS reporting and remittance is entirely the merchant’s responsibility. Adobe Commerce does not automate OSS reporting.

B2B Reverse Charge: When selling to VAT-registered EU businesses in other member states, the reverse charge mechanism typically applies.

VAT number validation at checkout: Adobe Commerce includes native VAT ID validation, configurable under Stores → Settings → Configuration → Customers → Customer Configuration. The system validates against the European Commission VIES server and stores the VAT request ID and date in the order’s Comments History. An extension may still add value for advanced audit or UX requirements, but native validation is available out of the box. (Reference: https://experienceleague.adobe.com/en/docs/commerce-admin/stores-sales/site-store/taxes/vat)

Shipping configuration for multi-region operations

Shipping configuration is the final piece — and often the most visible one to customers. Poorly configured shipping can kill conversion even when everything else is correct.

Structuring shipping methods across stores

Adobe Commerce supports multiple carriers natively — UPS, FedEx, DHL, USPS — and a flexible Table Rates system for custom shipping logic.

Two key principles for multi-region setups:

Scoped configuration: Always switch the scope selector to the target Website before configuring carriers. Shipping settings are generally Website-scoped — configuring at Global scope will apply changes across all websites.

Table Rates for complex rules: If shipping logic depends on weight, price thresholds, or destination region in combination, Table Rates (Stores → Settings → Configuration → Sales → Delivery Methods → Table Rates) gives full control via CSV upload. The CSV import is also scoped per Website — ensure you are at the correct Website scope when importing.

Setting up Table Rates for international shipping

• Switch scope and enable Table Rates. Switch scope to your target Website, then enable Table Rates and set the Condition (by Price, by Weight, or by Item Count).

• Export the template. Click Export CSV to get the template format.

• Build your rate matrix. Each row defines a Country, Region/State, Zip/Postal Code, condition value, and shipping price. Use * as a wildcard for fields where the rule should apply to all values.

• Import and validate. Import the completed CSV at the correct Website scope and place a test order from an address in each target region to validate.

Key considerations for cross-border shipping

Duties and taxes at the border: Decide whether you operate as DDP (Delivered Duty Paid) or DDU (Delivered Duty Unpaid). DDP provides a better customer experience but requires more logistics setup. Communicate the policy clearly at checkout.

Restricted destinations: Go to Stores → Settings → Configuration → Sales → Delivery Methods, switch to the target Website scope, then set Ship to Applicable Countries to ‘Specific Countries’ for each carrier.

Free shipping thresholds: Configure these per Website scope if thresholds differ by market.

Estimated delivery dates: Adobe Commerce does not natively display carrier-based delivery estimates in checkout. MSI Source Selection Algorithms support limited ETA logic for in-store delivery scenarios, but cart and checkout delivery estimates remain non-native. Consider an extension or custom logic factoring in carrier cutoff times and regional handling periods.

Key takeaways

• Architect first. Decide Website / Store / Store View structure before building. Changing this later is painful and disruptive — and the wrong tier choice cannot be fixed with configuration alone.

• Localize beyond language. Currency, payment methods (Website-scoped), tax display, and address formats all need market-specific configuration.

• Do not manually manage US sales tax. Use Avalara or TaxJar. Commerce cannot handle destination-based sourcing rules beyond ZIP granularity.

• EU OSS applies to both goods and digital services. Reverse charge compliance requires VAT ID validation and order-level storage — not just a 0% tax rule.

• Scope everything to the right level. Base currency lives at Website level. Payment methods live at Website level. Table Rate CSVs import per Website. The store_view_code column — not 'store' — targets Store View content in product imports. For more information, see the Adobe Commerce product data attributes documentation.

• Native carrier support requires version verification. USPS, FedEx, DHL, and UPS may require updated modules or API keys depending on your Commerce version.

• Test with real addresses. Tax, shipping, and localization bugs often only surface when you place a test order from an actual address in the target country.

What I'd do differently today

I'd make Website vs Store View a hard gate before any Admin configuration starts

The most expensive mistake I’ve seen in multistore implementations is the wrong scope tier choice — and it almost always happens because that decision gets deferred. A team starts configuring Store Views for what are actually separate markets with different pricing, different payment methods, or different tax behavior. Everything looks fine until it doesn’t.

Today I treat Website vs Store View as a blocking question, not a background assumption. Before anyone logs into the Admin, that structure needs to be decided, documented, and agreed on. Changing it mid-project means rebuilding — and changing it post-launch means rebuilding while the store is live. Neither is a good situation to explain to a client.

I'd stop treating tax as a late-stage configuration item

We caught a serious EU VAT compliance gap in UAT — which is about the best time you can catch it, but not nearly as good as never having the gap. The issue wasn’t that anyone was careless. It was that tax configuration was scoped and scheduled like a checkout setting, not like the compliance requirement it actually is.

For EU markets specifically: OSS reporting, B2B reverse charge, and VAT ID validation are not things you bolt on at the end. They have to be part of the requirements conversation before a line of configuration is written. If you’re implementing for a merchant selling cross-border into the EU and these items aren’t on the functional spec, push back before UAT — not during it.

The same goes for US sales tax. If someone on the project is still suggesting you manually manage state rates, treat that as a project risk, not a configuration question. At any meaningful transaction volume, manual US sales tax management is not a viable approach — full stop.

The platform gives you the tools to get this right. The implementations that go sideways aren’t usually technical failures — they’re sequencing failures. Decide the architecture first. Treat tax as a compliance workstream, not a config task. Everything else in this article follows from getting those two things right.

Actionable next steps

1. Map your Website / Store / Store View structure on paper before touching the Admin. Confirm which markets need Website-level isolation (separate pricing, payment methods, tax behavior) versus Store View-level separation (language only). Changing this after launch is the most expensive mistake in a multistore implementation.

2. Audit your product import CSV columns. The correct column to target Store View content is store_view_code — do not replace it. If any import scripts or documentation in your environment reference a ‘store’ column, that is incorrect and will cause imports to fail silently or write to the wrong scope. Verify imports are writing to the correct scope by checking a product record after import. For more information, see the Adobe Commerce product data attributes documentation.

3. Verify carrier compatibility immediately, not just at go-live. USPS Legacy Web Tools API was retired January 25, 2026 — merchants on 2.4.6, 2.4.7, or 2.4.8 without the migration patch have active shipping failures today. For DHL: 2.4.6+ natively supports MyDHL REST APIs, so the compatibility gap is resolved on current versions. Check your Commerce version and apply the USPS migration patch if you have not done so.

4. For EU VAT reverse charge, do not rely on a 0% tax rule alone. Implement a VAT exemption extension with EU VIES API validation, and confirm that validated VAT IDs are stored with orders for audit purposes.

5. Confirm whether OSS registration applies to your cross-border EU sales — it covers both goods and digital services to EU consumers since July 2021. Adobe Commerce supports per-country VAT rates but does not automate OSS reporting; this is the merchant’s responsibility.

6. Set Base Currency at Website scope, not Global. Configure payment methods per Website. Import Table Rate CSVs at Website scope. Before any production configuration, verify the scope selector is set to the correct level — a single wrong-scope setting can silently affect all websites.