Multi-Country Merchant Center: Currencies, Shipping, Taxes and Returns

Multi-country Merchant Center: currencies, shipping, taxes and returns

Going from one country to two in Google Merchant Center is the moment most catalogs break. Domestic feeds with rounded prices, a single shipping table and a generic returns page survive only because nothing tests them. Add a second target country and the system audits everything at once: the currency declared in the feed against the currency in the shipping service, the price on Shopping against the price on the landing page, the returns URL against the language of the destination, the VAT inclusion against the local rule, the GTIN against the manufacturer registry. A working domestic setup is not a working multi-country setup; it is a setup that has not yet been measured against the rules of any country other than its own.

This guide covers the architecture and the operational details. We discuss the choice between a single multi-country account and separate accounts, the country and language target attributes on the feed, the currency-display rule that gets most cross-border catalogs disapproved, the EU VAT inclusion rule and the IOSS one-stop-shop, US sales tax and the post-Wayfair nexus and marketplace facilitator regimes, GST in Australia, India and Canada, the post-Brexit UK VAT split, shipping zones with rate tables versus carrier-calculated rates, returns under the EU Consumer Rights Directive, country-specific product disapprovals, feed rules to derive country variants from a single source, and the operational cadence for adding a new country without setting fire to the rest.

Architecture decision: one account, multi-country, or one account per country

The first decision is whether to run a single Merchant Center account targeting multiple countries or to split into one account per country, all linked under a Merchant Center hierarchy (the structure formerly known as Multi-Client Account). Google Merchant Center Help allows both. The right answer is operational, not theoretical, and it depends on three variables: catalog overlap, payout currency, and the blast radius of a suspension.

A single account is correct when catalog overlap is high (the same SKUs ship to all targeted countries), the merchant of record is the same legal entity, payout currency is consistent, and the team accepts that a policy violation in any one country can disable Shopping ads across the entire account while review proceeds. Search Engine Land has documented several cases where a single product disapproval cascade in Germany (regulatory wording on a supplement label) forced a French and Italian feed offline for weeks because the account-level warning escalated into account suspension. The lesson is not to avoid multi-country accounts; it is to understand that the account is the unit of suspension.

Separate accounts under a hierarchy are correct when catalogs differ materially per country (different SKUs, different brand names, exclusive distribution agreements), when local entities invoice in local currency and want clean accounting, when one country requires a category of products that another country bans, and when the team explicitly wants suspension isolation. Tinuiti has published case studies on cross-border retailers who moved from a single account to a hierarchy precisely after a UK alcohol-related disapproval threatened a US Shopping campaign that had nothing to do with alcohol. The cost of the migration was real (rebuilding shipping policies, re-verifying domains, re-uploading feeds) and the benefit was a cleaner blast radius.

The rule of thumb is: if you operate two to four countries with the same catalog and the same legal entity, run a single account and use country-targeted feeds. If you operate five or more countries, or if any country sells regulated categories (alcohol, supplements, financial products), run a hierarchy with one account per country. Hybrid architectures (one account for the EU, one for the UK, one for the US) work well in practice because they align with VAT regimes and with payout currencies.

The country target attribute on the feed

Every Merchant Center feed has a target country, declared at the feed level in the feed settings. The country is the country to which products in this feed are sold, not the country where the merchant is established. A French merchant selling to Germany declares Germany as the target country on the German feed. The target country drives currency expectation, language expectation, VAT inclusion rule, shipping eligibility and the set of policies the products are evaluated against.

You can also target multiple countries from a single primary feed by adding additional countries in the feed settings. This is the simplest setup and Google supports it for most country combinations, but it carries one constraint: every product in the feed must be eligible for every targeted country. If one product is restricted in one of the target countries (a supplement banned in France while allowed in Germany), the entire feed produces a disapproval for that product in the restricted country and a warning at the feed level. The warning is recoverable; recurrence is not.

The cleaner pattern, recommended by Search Engine Journal in their multi-country Merchant Center guides, is one primary feed per country plus supplemental feeds that override country-specific attributes. Each primary feed declares one target country. Supplemental feeds layer on top to inject local prices, local descriptions, local shipping costs. The benefit is that a disapproval in one country never crosses to another feed, and feed-level metrics (impression share, click-through rate, disapproval count) are visible per country.

The country attribute in a shipping service entry, in a tax setting, or in a feed rule is always an ISO 3166-1 alpha-2 code (DE, FR, IT, ES, GB, US, CA, AU). Mixing alpha-2 with full country names (“Germany” instead of “DE”) in feed rules is a frequent cause of silent rule failure. Validate every code against the ISO list before pushing.

The language target attribute

The content language attribute on the feed declares the language of titles, descriptions and other text fields, not the language of the customer. Google enforces a strict mapping between target country and accepted languages. Germany accepts German (de). France accepts French (fr). Belgium accepts French and Dutch (fr, nl). Switzerland accepts German, French and Italian (de, fr, it). The full list is in Merchant Center Help under “Languages and currencies supported by country”.

The language must be the language of the text in the feed. A feed declared as French (fr) targeting France with English titles is rejected with “Language mismatch” disapprovals. A feed declared as English targeting France passes the language check but loses Shopping eligibility because Google does not show English Shopping ads to French users when French alternatives exist. The correct setup is one feed per language even if the language serves multiple countries: a single French-language feed serves France, Belgium (French part) and Luxembourg (French part) by enabling those countries in the feed targeting tab.

Localization is not just the title and description. Brand, color, material, size, gender and product type all need to be in the target language for ranking. A leather jacket described as “100% leather, full-grain, cognac brown, size L” in the English feed must be “100% Leder, vollnarbig, cognac-braun, Größe L” in the German feed. DataFeedWatch has measured a 15 to 30% impression-share improvement on accurately localized attributes versus auto-translated ones, because Google’s matcher uses the localized values for query understanding, not just for display.

Currency display rules

The hard rule, documented in Merchant Center Help under “Currency requirements”, is that the currency in the feed must match the currency expected for the destination country. Germany expects EUR, the UK expects GBP, the US expects USD, Switzerland expects CHF. A product priced at 100 EUR cannot be shown to UK customers in EUR; it must be shown in GBP. Two mechanisms exist: automatic currency conversion at the Merchant Center level, or manual pricing per country in separate feeds.

Automatic conversion uses Google Finance rates. The merchant uploads prices in one currency, the system displays the converted price to customers in countries with a different currency. The conversion is an estimate, not a binding price; the actual charge depends on the customer’s payment method and the issuer’s exchange rate. Search Engine Land’s coverage of cross-border Shopping ads has noted the two main risks: visible price-mismatch disputes when the customer’s bank applies a less favorable rate at checkout, and margin compression for products in the 5 to 12% margin range when EUR-GBP volatility runs at 3 to 5% within a quarter. Automatic conversion is acceptable for high-margin, low-volatility categories and for new-country pilots; it is not acceptable for thin-margin commodity products at scale.

Manual pricing per country is the production pattern for established multi-country operations. The merchant maintains separate feeds, each in the target currency, with prices set strategically rather than mathematically. A French apparel brand might price a dress at 89 EUR in France, 92 EUR in Germany (premium positioning), 79 GBP in the UK (rounded for retail psychology, not 76 from auto-conversion), 85 EUR in Spain (competitive pressure). DataFeedWatch and similar feed-management platforms (Channable, GoDataFeed, Feedonomics) execute this with rules: base price in EUR, country multiplier, currency conversion if needed, retail rounding. The same base price flows to five country feeds with five different end prices, all updated within the daily feed cadence.

The shipping service currency must match the feed currency. A German feed in EUR with a shipping service declared in USD is rejected at validation. The same applies to the tax settings and to feed rules that compute shipping cost. Currency consistency across price, shipping cost and tax is the single most frequent cause of cross-border feed rejections.

EU VAT and the IOSS one-stop-shop

The EU rule, set out in the VAT e-commerce package effective since 1 July 2021, is that prices shown to consumers must include VAT. The Merchant Center feed for an EU target country must therefore submit VAT-inclusive prices. A French brand selling to Germany at 100 EUR submits 100 EUR; the German VAT (19%) is embedded. Google does not add VAT, does not strip VAT, does not display ex-VAT prices to consumers in EU target countries. Submitting an ex-VAT price and expecting Google to add VAT is a recurring mistake that triggers price-mismatch disapprovals because the landing page (which correctly includes VAT) does not match the feed.

VAT rates are not uniform across the EU. The standard rates as of 2026 range from 17% in Luxembourg to 27% in Hungary, with most countries clustered between 19 and 23%: Germany 19%, France 20%, Spain 21%, Italy 22%, Netherlands 21%, Poland 23%, Sweden 25%. The same product at the same ex-VAT cost requires different gross prices per country. A 100 EUR ex-VAT product becomes 119 EUR in Germany, 120 EUR in France, 121 EUR in Spain, 122 EUR in Italy. Pricing strategy can flatten these (a single 119.90 EUR display price across the EU absorbs the VAT-rate differences into margin), but the feed still has to carry the exact gross price displayed on the landing page.

The Import One-Stop-Shop (IOSS) is the EU mechanism for distance sales of imported goods up to 150 EUR. A non-EU merchant (UK, US, Switzerland, Norway) selling to EU consumers can register for IOSS in one EU member state and remit VAT for all EU sales through that single registration, instead of registering in every country of consumption. Goods in the IOSS regime clear customs without import VAT collection at the border because VAT was already collected at the point of sale. The Merchant Center implication is that an IOSS-registered non-EU merchant submits VAT-inclusive prices in the EU feeds at the rate of the destination country, and the landing page must collect VAT at the same rate. The IOSS number is declared at the customs level, not in the feed.

The One-Stop-Shop (OSS) is the parallel mechanism for EU-established merchants selling cross-border to EU consumers. A French merchant selling to German consumers above the 10 000 EUR pan-EU threshold registers for OSS in France and remits German VAT through the French OSS portal. Same feed implication: VAT-inclusive prices at the destination-country rate. Store Growers has covered the operational tradeoff in detail: OSS reduces compliance overhead from one VAT registration per country to one OSS registration total, at the cost of giving up local VAT recovery for input VAT on local costs.

US sales tax: nexus, marketplace facilitators and feed configuration

The US sales tax landscape is unique. There is no federal sales tax. Each state, and many counties and cities within each state, sets its own rate and rules. As of 2026, 45 states plus the District of Columbia impose sales tax. Five states (Alaska, Delaware, Montana, New Hampshire, Oregon) do not, although Alaska allows local jurisdictions to impose their own. Standard state rates range from 2.9% (Colorado) to 7.25% (California), and combined state-plus-local rates can exceed 10% in parts of Louisiana, Tennessee and Alabama.

The post-Wayfair regime, set by the 2018 South Dakota v. Wayfair Supreme Court decision, is that states can require out-of-state sellers to collect sales tax once the seller has economic nexus in the state. Most states define economic nexus as 100 000 USD of sales or 200 transactions per year into the state, although thresholds vary. Search Engine Journal’s coverage of cross-border Shopping ads has emphasized the operational implication: a seller does not get to choose where to collect tax, the state’s nexus statute does. Crossing the threshold in October triggers a registration obligation that flows back to all sales from that point forward.

Marketplace facilitator laws, now adopted in every state with sales tax, shift the collection obligation to the marketplace (Amazon, eBay, Walmart) for sales made through that marketplace. A seller who sells the same SKU on Amazon and on their own website still has to collect sales tax on the website sales for states where they have nexus, even though Amazon is collecting on the same SKU on the marketplace side. Google Shopping ads point to the seller’s website, so they fall outside the facilitator rule.

The Merchant Center implication is that US feeds submit prices excluding sales tax, and tax is configured at the account level (Tools > Sales tax) per state, with the rate declared per state and a flag indicating whether the state has destination-based or origin-based sourcing. Google calculates the displayed tax in the Shopping ad based on the customer’s destination state. The merchant can also use a sales-tax calculation service (TaxJar, Avalara, Vertex) that integrates with the storefront and applies precise local rates at checkout; the Merchant Center tax settings only need to be approximately correct for ad display, while the storefront enforces the exact rate.

The recurring error documented by Tinuiti in their cross-border audit work is the EU merchant who configures the US feed with VAT-inclusive prices. The US does not use VAT. The price in the US feed must be the ex-tax price, sales tax is added at checkout, and the landing page must display the ex-tax price by default with a tax estimate computed from the customer’s ZIP code. Submitting a VAT-inclusive price to the US triggers a price-mismatch disapproval against the ex-tax landing page within a few hours of the first impressions.

GST and other regional taxes: Australia, India, Canada

Australia operates a 10% Goods and Services Tax (GST) on most goods and services. For imported goods under 1000 AUD, the seller is responsible for collecting GST at the point of sale if the seller’s annual GST turnover into Australia exceeds 75 000 AUD. The seller must register for GST with the Australian Taxation Office and remit collected GST quarterly. The Merchant Center implication is that prices in the Australian feed must include GST, the same VAT-style rule as the EU.

India operates GST since 2017 with a multi-rate structure: 0%, 5%, 12%, 18% and 28% depending on the product category. Apparel below 1000 INR is taxed at 5%, apparel above 1000 INR at 12%, electronics at 18%, luxury goods at 28%. The Indian Merchant Center feed submits GST-inclusive prices and the landing page displays the same. Foreign sellers shipping into India through e-commerce face a separate set of customs duties on top of GST, and the customs treatment depends on the courier mode (postal, express, commercial).

Canada operates a federal GST of 5% combined with provincial sales taxes (PST) that vary by province. Five provinces (Ontario, New Brunswick, Newfoundland, Nova Scotia, Prince Edward Island) have harmonized their PST with the federal GST into a single Harmonized Sales Tax (HST) ranging from 13 to 15%. Quebec operates the Quebec Sales Tax (QST) at 9.975% on top of the federal GST, applied differently from PST. British Columbia, Saskatchewan and Manitoba apply provincial PST separately. The result is that the same SKU sold to Toronto (HST 13%), Montreal (GST 5% plus QST 9.975%), Vancouver (GST 5% plus PST 7%) and Edmonton (GST 5%, no PST) carries four different effective tax rates. The Canadian Merchant Center feed can be configured at the account level with province-by-province rates similar to US states, or with tax-inclusive prices that vary by destination province through feed rules.

UK VAT post-Brexit complexity

The UK left the EU VAT regime on 1 January 2021. Since then, UK VAT applies to all goods sold to UK consumers regardless of where the seller is established, with two distinct regimes split by consignment value. For consignments not exceeding 135 GBP, the seller is responsible for collecting UK VAT at the point of sale and remitting it to HMRC under a UK VAT registration. For consignments exceeding 135 GBP, the import-VAT regime applies and VAT is collected at the border, either from the customer (DDU, delivered duty unpaid) or from the seller (DDP, delivered duty paid).

The Northern Ireland protocol added a second layer. Northern Ireland remains in the EU VAT regime for goods, while the rest of the UK (Great Britain) operates the post-Brexit UK VAT regime. A seller in mainland EU shipping to Belfast follows EU rules with intra-community supply and OSS reporting. The same seller shipping to London follows UK rules with UK VAT registration and HMRC reporting. The Merchant Center setup uses GB as the country code for Great Britain target country and follows UK VAT-inclusive pricing under 135 GBP.

The operational pattern that DataFeedWatch and Store Growers recommend for EU sellers entering the UK is: UK VAT registration at HMRC, UK feed with VAT-inclusive prices, dedicated UK shipping policies in GBP, returns policy URL in English with explicit reference to the UK Consumer Rights Act 2015, and a EORI number for customs clearance. Cutting any of these steps to ship faster usually results in feed disapprovals within the first month.

Shipping zones: rate tables versus carrier-calculated rates

Merchant Center allows up to 100 shipping services per account and up to 20 shipping settings per country, more than any reasonable operation needs. The configuration choice is between flat rate, rate table, and carrier-calculated rate, with each having different operational implications.

Flat rate is one shipping cost per service, optionally with a free-shipping threshold above a basket value. It works for retailers with uniform parcel weight (apparel, accessories, small electronics). The cost is predictable, the configuration trivial, and the customer experience is clear. The drawback is that flat rate over- or under-charges depending on basket composition; a single t-shirt and a heavy boot pay the same shipping fee.

Rate tables compute shipping based on order subtotal, weight, delivery destination (postal code or region) or quantity. Merchant Center supports nested rate tables where the row dimension is one variable (weight) and the column dimension is another (postal code zone). A retailer can set “0-2 kg to zone A: 4.99 EUR; 2-5 kg to zone A: 6.99 EUR; 0-2 kg to zone B: 7.99 EUR; 2-5 kg to zone B: 10.99 EUR”. Rate tables match real carrier pricing more closely than flat rate but require accurate weight data on every product in the feed; a SKU with a missing or incorrect weight will price-mismatch and disapprove.

Carrier-calculated rates pull live shipping costs from FedEx, UPS, USPS or DHL APIs based on origin postal code, destination postal code, package dimensions and weight. The advantage is exact alignment with what the carrier will charge at fulfillment. The disadvantages are operational: every product in the feed needs accurate dimensions and weight, the API integration must be maintained, and rate fluctuations from the carrier flow directly to the displayed shipping cost in the ad. Carrier-calculated rates are the right choice for heavy or oversized goods (furniture, white-goods, building materials) and for marketplaces with many third-party sellers shipping from different locations.

The Cdiscount-style rate-table pattern is useful for European cross-border operations: France mainland 2.99 EUR flat, free above 30 EUR; Corsica 5.99 EUR flat, free above 60 EUR; Germany 4.99 EUR flat, free above 45 EUR; Spain 5.49 EUR flat, free above 50 EUR; Italy 6.99 EUR flat, free above 50 EUR; Belgium and Luxembourg 3.99 EUR flat, free above 45 EUR. Each country reflects the actual carrier cost on the seller’s lane, not a pan-European average that loses money on Italy and overcharges on Belgium.

Returns and EU consumer rights: the 14-day cooling-off period

The EU Consumer Rights Directive 2011/83/EU sets a minimum 14-day cooling-off period for distance contracts. The consumer can return any product without giving a reason within 14 days from the day of delivery, and the seller must refund the full price including original outbound shipping (at the cheapest standard delivery option offered) within 14 days of receiving the returned product or evidence of return shipment. The consumer pays return shipping unless the seller has agreed to bear the cost or has failed to inform the consumer of the obligation.

Merchant Center requires every targeted country to have a published returns policy URL in the local language. Google crawls the URL, parses the returns terms, validates them against country rules, and displays the headline terms (return window in days, return cost, exception categories) directly in Shopping ads. The MerchantReturnPolicy structured data, documented in Google Search Central, is the recommended way to expose the policy machine-readably so the Shopping display matches the page content exactly.

Country variations within the EU are minimal in the headline rule (14 days minimum across all 27 member states) but real in the operational details. France requires the explicit return form (formulaire de rétractation) to be available on the website and shipped with the product. Germany requires the seller to bear return shipping for any defect-related return regardless of value, and most German consumers expect the seller to bear return shipping for all returns, which is why most German retailers offer free returns as a competitive standard. Italy and Spain align with the directive minimum.

The UK post-Brexit follows the Consumer Contracts Regulations 2013, which retain the 14-day cooling-off period from the original EU directive. The substantive returns rules in the UK are similar to the EU; the difference is jurisdictional. A returns dispute between a French seller and a UK consumer is governed by UK consumer law and adjudicated by UK trading standards, not by French law. The returns policy URL for the UK must reference UK consumer law explicitly to avoid Google flagging the policy as non-localized.

The US has no federal returns law. Returns terms are set by the seller, with state-by-state consumer protection rules covering deceptive practices but not mandating a return window. Most US retailers offer 30 days as the de facto standard, with 60 to 90 days for premium retailers and a small number offering lifetime returns as a brand differentiator. The Merchant Center policy minimum is 30 days for the US, enforced by Google as a Shopping ad eligibility requirement since 2022.

Country-specific product disapprovals

The same product can be approved in one country and disapproved in another because each country evaluates the catalog against its own regulatory framework. The categories with the highest variance are alcohol, supplements, weapons, healthcare products, financial services, gambling and tobacco. Search Engine Land has published several pieces tracking the regulatory drift between EU member states on supplements: a vitamin supplement compliant with German Lebensmittel-, Bedarfsgegenstände- und Futtermittelgesetzbuch can be disapproved in France for an INCO labeling discrepancy and approved again in Italy with no changes to the listing.

Alcohol is the clearest case. Germany, the UK, the Netherlands and most of central and eastern Europe allow alcohol Shopping ads with age-gating and licensed retailer status. France allows alcohol ads but with strict content rules under the Loi Évin (no lifestyle imagery, mandatory health warning). Sweden, Finland and Norway operate state alcohol monopolies that effectively prohibit private alcohol Shopping ads. The US allows alcohol ads in 41 states subject to retailer license verification; nine states prohibit direct-to-consumer alcohol shipments outright.

Supplements vary by claim. A “boosts immunity” claim approved in the US is rejected in the EU under the Nutrition and Health Claims Regulation 1924/2006 because it is not on the authorized claims list. A claim using exact authorized wording from the EFSA register passes EU review. Submissions that translate a US claim word-for-word into French or German almost always disapprove on the first review.

The operational pattern is to maintain a country eligibility matrix per SKU as part of the product master data, not as a feed-time decision. Each SKU is tagged with the countries in which it is authorized. The feed-generation pipeline filters by tag per country feed. A new SKU starts as authorized in zero countries and is enabled per country only after a regulatory review. Tinuiti has published case studies on retailers who skipped this step, pushed a US catalog into a UK feed, and absorbed a 30 to 50% disapproval rate that never recovered because each country’s review history is sticky.

Feed rules: mapping one source to many country variants

Feed rules in Merchant Center are transformations applied to a primary or supplemental feed at upload time, before validation. A single source feed (the master export from the e-commerce platform) flows through different rule sets per country to produce country variants. The DataFeedWatch and Channable platforms externalize this logic with more flexibility than native Merchant Center feed rules, but the mechanics are the same.

The typical rule pipeline for an EU multi-country setup, derived from the source feed:

• Filter: keep only SKUs tagged as authorized for the target country.
• Transform price: convert from base currency (EUR) to target currency if different, apply country-specific multiplier (1.00 for France, 1.03 for Germany, 0.95 for Spain), round to retail price points (xx.99 or xx.95 depending on category).
• Inject VAT: apply destination VAT rate to ex-VAT base price to produce the gross price expected by the feed.
• Override description: replace base-language description with target-language version from the localization database.
• Override shipping: set shipping service ID for the target country.
• Override availability: set availability based on local warehouse stock, not global stock.
• Inject custom labels: tag with marketing group, margin band, lifecycle stage for downstream campaign filtering.

The rule pipeline runs daily or hourly. Each country produces an output feed that goes to Merchant Center as a primary feed for that country. The benefit of this pattern over manual maintenance of five separate exports is that any change in the source (new SKU, price update, stock movement) propagates to all country feeds within the next pipeline run, and divergences between countries are explicit (encoded as rules) rather than implicit (drifted over time across separate spreadsheets).

The most common feed rule mistake is not validating the output. Rules can transform a 100 EUR price into a 1.00 EUR price if a multiplier was misconfigured, and the bug ships to production silently because the feed validates structurally even though the prices are wrong. Tinuiti’s audit work has uncovered cases where this kind of bug ran for two weeks before a sales team noticed the volume spike. The mitigation is a sanity check on every output feed: comparison of average price per category against the previous run, with a hard block on changes exceeding a threshold (10% category-level shift from one run to the next).

Adding a new country: operational cadence and timeline

The end-to-end timeline for adding a new country to a working multi-country setup, assuming the legal and tax registration is already in place:

• Day 0: business decision to enter the country. Eligibility audit of the catalog (regulatory categories, GTIN coverage, language coverage). Tax registration verified or initiated; for the EU, OSS registration confirmed; for the UK, VAT and EORI confirmed.
• Days 1 to 7: shipping policy negotiation with carriers for the lane. Returns terms drafted in the local language, returns URL published, structured data added.
• Days 7 to 14: feed pipeline extended with country-specific rules. Localization of titles, descriptions and attributes for the SKUs that are authorized for the target country. Validation of currency, language and VAT inclusion against test SKUs.
• Day 14: Merchant Center country added to settings, primary feed created and uploaded, shipping services configured, returns policy URL submitted.
• Days 14 to 21: initial review by Google. Disapprovals investigated and resolved. Country eligibility flag toggled per SKU to remove non-eligible products from the feed cleanly rather than letting them disapprove.
• Day 21: pilot Shopping campaign launched at 10 to 20% of expected steady-state budget. Performance measured against a domestic benchmark with country-specific bidding signals.
• Day 35 to 42: budget scale-up if metrics meet targets, or a debrief and corrections cycle if they do not.

The mistake in most timelines is compressing the days 7 to 14 phase. Rushing the localization, the returns URL or the feed pipeline produces a launch with elevated disapproval rate that takes longer to recover from than the time saved by rushing.

Common mistakes

The recurring failure modes across cross-border Merchant Center deployments, drawn from Search Engine Land, Tinuiti and DataFeedWatch case studies:

• One feed, multiple languages: a single feed with English titles targeting Germany, France and Spain. Disapproved on language mismatch from the first review.
• Currency and shipping mismatch: feed in EUR, shipping service in USD. Silent rejection on impressions.
• VAT inclusion confusion: ex-VAT prices submitted to EU feeds expecting VAT-inclusive, or VAT-inclusive prices submitted to US feeds expecting ex-tax. Both produce price-mismatch disapprovals against the landing page.
• Auto-conversion in production for thin-margin categories: visible price drift between Shopping ad, checkout cart, and customer card statement.
• Returns URL not localized: French returns page served to German customers. Policy violation, ad eligibility lost.
• Fake or guessed GTINs: placeholder values like 12345678901234 trigger automated rejection; brand-name mismatches against the GS1 registry produce repeat disapprovals.
• Single shipping flat rate across all countries: profitable on the cheapest lane, unprofitable on the most expensive lanes, opaque to product managers.
• Catalog pushed to a country without per-SKU eligibility filtering: 30 to 50% disapproval rate that becomes harder to clear with each repeat submission.
• Account-level suspension blamed on a feed when it was triggered by a single SKU’s repeated regulatory violation.

Conclusion

Multi-country Merchant Center is mostly an operational discipline, not a feature gap. The same currency and language must run consistently across feed, shipping settings and tax settings. VAT must be included where the destination requires it and excluded where the destination does not. Returns must be localized in language and in legal reference. Eligibility must be evaluated per SKU per country before the feed reaches Google, not after. Feed rules industrialize the per-country derivation from a single source so that catalog changes propagate cleanly. Adding a new country has a 4 to 6 week cadence when the legal and tax base is in place, and longer when it is not.

The accounts that scale internationally do so because they invested in this operational layer once and then maintained it. They run dashboards on disapproval rate by country, currency mismatch alerts, returns URL crawl status, VAT rate change notifications. The accounts that fail at multi-country usually have a working domestic setup and a belief that the same setup duplicated to a new country will work. It almost never does.

Sources

• Google Merchant Center Help, “Show products in multiple target countries”, “Languages and currencies supported by country”, “Set up shipping settings for an entire account”, “About tax for your products”, “Set up your return policies for Shopping ads and free listings”.
• Google Search Central, “Merchant return policy structured data”.
• Search Engine Land, coverage of Merchant Center country expansion, post-Brexit Shopping ads, EU VAT and IOSS implementation.
• Search Engine Journal, multi-country Merchant Center setup guides, US sales tax post-Wayfair coverage.
• Tinuiti, cross-border e-commerce case studies, Shopping ads multi-country audits.
• Store Growers, OSS and IOSS operational guides for EU and non-EU sellers.
• DataFeedWatch, multi-country feed management guides, localization impact studies.