Multi-Currency Multi-Tax Architecture: Adobe Commerce Patterns for Cross-Border B2B

Cross-border B2B commerce is operationally one of the hardest things to do well on any platform. The merchant has to handle customers in multiple currencies, pricing that may vary by region, taxes that follow different rules in different jurisdictions, customs and duties that complicate the customer-facing total, payment methods that vary by country, and customer expectations that vary culturally. Adobe Commerce is more capable than most platforms at supporting this complexity, but the capability has to be configured correctly, and the patterns that work look different from the patterns that work for single-currency single-jurisdiction operations.

This piece walks through architectural patterns for cross-border B2B Adobe Commerce implementations. It is written for engineering leaders, eCommerce architects, and operations teams supporting international B2B operations. The patterns below come from Bemeir’s work with cross-border B2B merchants spanning North America, Europe, and Asia-Pacific.

The Store Hierarchy Decision

Adobe Commerce supports multi-store, multi-store view configurations that map naturally to multi-region operations. The hierarchy is:

• Website: top-level grouping that owns customers, orders, and a base currency
• Store: middle-level grouping under a website that can have its own root category
• Store View: bottom-level grouping under a store that owns language and presentation

For cross-border B2B, the typical pattern is one website per major region (US, EU, APAC), with stores under each website for sub-region variants and store views for language localization. This gives each region its own customer base, currency, and operational model while sharing catalog and code.

The alternative — single website with multiple store views — works for simpler scenarios but breaks down when regions need genuinely different customer accounts, payment methods, or order workflows.

The right hierarchy depends on the operational reality. Bemeir’s Adobe Commerce multi-store practice typically maps this in the discovery phase based on customer model, finance reporting needs, and operational ownership.

Currency Configuration

Adobe Commerce supports two patterns for multi-currency:

• Base + display currencies: each website has a single base currency for storage and accounting, with one or more display currencies for customer presentation. Conversion is automatic via configured exchange rates.
• Per-website base currency: each website has its own base currency, with all storage and accounting in that currency.

For cross-border B2B, per-website base currency is usually the right choice. Customers in the EU should see prices in EUR, orders should be stored and reported in EUR, and finance should reconcile EUR transactions natively. Currency conversion at display time is appropriate for retail browsing but produces accounting and reporting headaches for B2B.

Exchange rates can be configured manually or pulled automatically from services like the European Central Bank rate feed or Open Exchange Rates. For B2B operations where contracted pricing is the norm, the exchange rate primarily affects display rather than the actual transaction price.

Pricing Strategy for Cross-Border B2B

Cross-border B2B pricing is rarely a simple currency conversion. The merchant typically has:

• Regional list prices that reflect regional market conditions (not just exchange rate translation)
• Customer-specific contract prices that may be in any currency
• Volume discounts that vary by region
• Promotional pricing that may apply only in some regions

Adobe Commerce’s pricing model supports this through several mechanisms:

• Per-website prices: each website can have its own price for each product
• Customer-specific prices: tier prices and customer-group prices can be set per website
• Shared catalogs: in Adobe Commerce B2B, shared catalogs can be assigned per website with customer-specific overrides

The recommended pattern is to manage regional list prices per website and customer-specific prices via shared catalogs assigned to per-website customer accounts.

Tax Engine Selection

Tax handling is the part of cross-border B2B that most often breaks. The challenges:

• Sales tax in the US varies by state, with nexus rules and rate complexity
• VAT in the EU varies by country, with B2B vs B2C treatment differing
• GST in jurisdictions like Australia and India has its own rules
• Reverse-charge mechanisms for cross-border B2B transactions
• Customs duties for cross-border shipments

Adobe Commerce’s built-in tax engine handles simple scenarios but is not sufficient for cross-border B2B. The right pattern is to integrate a dedicated tax engine:

• Avalara AvaTax is the most common choice, with native Adobe Commerce integration
• Vertex covers similar scope, often preferred by enterprise B2B
• TaxJar is popular for US-focused operations
• Sovos is common for VAT-heavy European operations

The integration typically calculates tax in real-time during cart and checkout, posts transactions to the tax engine for compliance reporting, and handles tax exemption certificates for B2B customers who qualify.

For VAT specifically, the EU’s recent VAT-on-eCommerce rules and the OSS (One Stop Shop) reporting model add complexity that the integrated tax engine should handle. The European Commission’s VAT documentation covers the regulatory framework.

B2B Tax Exemptions

B2B customers often qualify for tax exemptions — US tax-exempt resellers, EU intra-community transactions, certain non-profit categories. The tax engine needs to handle these:

• Adobe Commerce stores the customer’s tax exemption status (typically as a custom attribute or via Adobe Commerce B2B’s tax exemption fields)
• The tax engine integration sends the exemption status with each tax calculation request
• The tax engine applies the appropriate exemption rules
• Tax exemption certificates are stored and renewed on schedule (most jurisdictions require periodic renewal)

The workflow for collecting and validating exemption certificates is typically managed in the tax engine, with Adobe Commerce reflecting the validated status. Bemeir’s Adobe Commerce B2B work treats tax exemption workflow as a first-class deliverable when configuring cross-border B2B.

Customs and Duties

For physically shipped products crossing borders, customs and duties are an operational consideration. The merchant needs to decide:

• Whether to display estimated duties at checkout or leave them as a recipient responsibility
• Whether to collect duties at checkout (DDP – Delivered Duty Paid) or have the carrier collect on delivery (DAP – Delivered At Place)
• Which Harmonized System (HS) codes to assign to products for customs classification
• How to handle returns when goods cross borders

For DDP operations, integration with a customs calculation service (Avalara CrossBorder, Zonos, Easyship, or carrier-provided duty calculation) is typically required. The integration runs at checkout to calculate estimated duties and adds them to the order total.

For DAP operations, the storefront should clearly communicate that the recipient is responsible for duties, and the order detail should provide the HS codes and other customs information so the carrier can process the shipment.

Payment Methods by Region

Payment methods vary substantially by region. Adobe Commerce’s payment method configuration per-website supports this:

• US: credit card, ACH, possibly PayPal
• EU: credit card, SEPA direct debit, iDEAL, Bancontact, Sofort, PayPal
• DACH region: specifically, invoice payment is heavily preferred for B2B
• Asia: regional methods like Alipay, WeChat Pay for the right markets
• Latin America: regional methods like Mercado Pago

For B2B, invoice-based payment (net 30, net 60) is common and supported by Adobe Commerce B2B’s payment terms feature. The integration with the merchant’s accounts receivable system needs explicit handling so that customer credit limits and outstanding invoice balances flow back into the order workflow.

Language and Currency Display

Each store view’s language and currency display is configured independently. Translations are managed through Adobe Commerce’s translation files, ideally with a translation management system like Phrase, Lokalise, or Crowdin handling the workflow.

For B2B specifically, technical product descriptions often need accurate translation by domain experts rather than general translators. The translation workflow should support technical review by regional team members.

Logistics and Fulfillment Integration

Cross-border fulfillment integrates with regional 3PLs, customs brokers, and carriers. The patterns:

• One or more sources per region in Adobe Commerce MSI
• Source selection algorithm prefers in-region sources for in-region orders
• Cross-region fulfillment as a fallback for stock-outs
• Carrier integration handles cross-border shipping rate calculation and label generation
• Customs documentation generated automatically from the integration

Adobe Commerce MSI documentation covers the inventory layer, and the major carrier APIs (UPS, FedEx, DHL) cover the shipping layer. The integration with Shopify Plus and BigCommerce for cross-border follows similar patterns where Bemeir maintains regional fulfillment expertise across platforms.

Compliance and Data Residency

Cross-border B2B has compliance dimensions that go beyond eCommerce. The merchant needs to consider:

• GDPR for European customer data
• CCPA for California customer data
• PIPEDA for Canadian customer data
• Data residency requirements (some jurisdictions require customer data to be hosted in-region)
• Tax registration and remittance in each jurisdiction with nexus

These are not technology problems but operational ones. The architecture has to support the operational requirements — multi-region hosting if data residency requires it, separate data stores per region, audit trails sufficient to satisfy regulators.

The IAPP’s privacy regulation database is a useful reference for the regulatory landscape, and most cross-border B2B operations will work with specialized legal counsel for compliance design.

What This Architecture Costs

The cross-border B2B architecture above costs meaningfully more than a single-region implementation. Multi-website Adobe Commerce, integrated tax engine, customs calculation, regional payment methods, translation workflow, regional 3PL integration — each is its own engineering investment.

The investment pays back through addressable market expansion. Cross-border revenue often represents 20-40% of B2B revenue once the operational machinery is in place. The architecture is the foundation that makes that revenue accessible.

Bemeir’s Adobe Commerce B2B practice treats cross-border architecture as a multi-quarter program, not a single project. The patterns above produce architecture that holds up across years of operational evolution rather than collapsing under the first major regulatory change or business-process shift. Cross-border B2B is hard, but it’s not unsolved — the patterns are well-understood, and the platforms are capable. The discipline of implementing them carefully is what determines whether the architecture becomes a competitive advantage or an operational drag.