Tax Attribute in Google Shopping Feeds: Format and When to Submit

The tax attribute in a Google Shopping product feed is one of the more misunderstood fields in the Google product data specification. Most merchants either omit it entirely, assuming Merchant Center account-level settings cover everything, or include it inconsistently across their catalog. This article explains when you actually need the attribute, what each sub-attribute means, and how to format it correctly to avoid disapprovals.

When the Tax Attribute Is Required vs. Optional

The tax attribute is accepted for the United States. Its primary purpose is to override the account-level tax settings you configure inside Merchant Center. If your account-level tax settings already cover every state in which you sell, you do not need to include the tax attribute in your feed at all — your account settings will apply by default.

You do need the tax attribute in your feed when:

• You want to set a different tax rate for a specific product than your account-level defaults. For example, if your account applies a standard sales tax rate across all products in a state, but a particular product category is tax-exempt in that state, the feed-level tax attribute lets you override just that product.
• You need to specify whether shipping charges are taxed for individual products (tax_ship sub-attribute), and that setting differs from your account default.
• You are selling products that have state-specific tax rules that cannot be captured cleanly in a single account-level setting.

If none of these situations apply and your account-level settings are correct and complete, omitting the tax attribute is fine. The Google product data specification classifies attributes as required, conditional, or optional — the tax attribute is conditional, meaning you may or may not need it depending on your products and the countries in which they show.

Sub-Attributes: What Each Field Does

The tax attribute contains four sub-attributes. Each one is described below.

country

Specifies the country to which the tax rule applies. Submit as a two-letter ISO 3166-1 alpha-2 country code. For US feeds, this is US. This sub-attribute is optional within the tax group; if omitted, the rule applies to the country associated with the data source.

region

Specifies the geographic region within the country where the rate applies. For US feeds, submit as a two-letter state abbreviation (for example, CA for California, TX for Texas). You can also use a postal code or a range of postal codes if you need finer geographic precision. If you leave region blank, the rate applies to the entire country.

rate

The tax rate expressed as a percentage. Submit as a number — for example, 8.25 for an 8.25% rate. Do not append a percent sign. If the product is fully tax-exempt in the specified region, submit 0.

tax_ship

Indicates whether sales tax is charged on the shipping cost for this product. Submit yes if shipping is taxable, no if it is not. This sub-attribute matters because rules differ by state: some US states tax shipping charges and others do not.

Formatting the Tax Attribute in Your Feed File

Formatting depends on your data source type. The Google product data specification distinguishes between text (TSV/CSV) and XML data sources — a pattern also visible in how the price attribute is submitted. For the price attribute, Google documentation shows that text sources use a plain value (15.00 USD) while XML sources wrap the value in a tag (<g:price>15.00 USD</g:price>), as noted in the price attribute documentation. The tax attribute follows the same structural pattern.

XML example (hypothetical):

<g:tax>
  <g:country>US</g:country>
  <g:region>CA</g:region>
  <g:rate>0</g:rate>
  <g:tax_ship>no</g:tax_ship>
</g:tax>

TSV/CSV example (hypothetical):

In a text feed, sub-attributes are typically submitted as separate columns using the naming convention tax:country, tax:region, tax:rate, and tax:tax_ship.

Note: These are hypothetical formatting examples to illustrate the column structure. Always verify the exact column naming convention accepted by your feed generation tool or the Merchant API documentation.

If a product needs multiple regional rules — for example, tax-exempt in California but taxable in Texas — you can submit multiple tax groups for the same product in an XML feed. In a TSV feed, handling multiple tax overrides for a single item requires checking the specific multi-value formatting supported by your feed tool.

Account-Level Settings vs. Feed-Level Overrides: Practical Decision Guide

Before adding the tax attribute to every product in your catalog, consider whether account-level settings are sufficient. The overhead of maintaining per-product tax rules in a large catalog is non-trivial. Here is a practical way to decide:

1. Start with account-level settings. Configure your standard tax rules inside Merchant Center for the states where you have nexus. This covers the majority of products for most merchants.

2. Identify exceptions. Go through your catalog for product categories that carry different tax treatment — for example, groceries, medical devices, clothing in certain states, or digital goods. These are your candidates for feed-level tax overrides.

3. Add the tax attribute only to exception products. Submitting a tax attribute on a product overrides the account-level setting for that product in the specified region. Products without the tax attribute continue to use account defaults.

4. Set tax_ship explicitly when shipping taxability differs from your account default. If your account-level setting taxes shipping but a specific product's shipment is not taxable (or vice versa), the feed-level tax_ship sub-attribute handles that override.

Submitting incorrect tax data — for example, a rate that conflicts with what a user would actually be charged at checkout — can result in product disapprovals. The Google product data specification is clear that incorrect or inaccurate product information can cause disapprovals and display issues. The same principle that applies to price accuracy — where the price attribute documentation requires that "the price in your product data meets both the landing page and checkout requirements" — applies conceptually to tax data as well: what you submit should reflect what the buyer actually sees at checkout.

Common Mistakes to Avoid

• Submitting a tax attribute for countries other than the US. The attribute is accepted for US feeds. For other countries, tax is typically handled through pricing (prices submitted inclusive of VAT where required) rather than through a separate tax attribute.
• Leaving rate blank instead of submitting 0 for exempt products. A missing value and a zero value are interpreted differently. If a product is tax-exempt, explicitly submit 0.
• Using the percent sign in the rate field. Submit 8.25, not 8.25%.
• Forgetting tax_ship when your state taxes shipping. Several US states require tax on shipping charges. If you do not set tax_ship correctly, the displayed total at checkout can differ from what you declared in your feed.

Keeping Your Feed Clean

Managing conditional attributes like tax across a large catalog requires a structured approach to feed maintenance. Tools like Magicfeedpro are built for exactly this kind of catalog-level control — letting you apply attribute overrides to specific product segments without editing every SKU manually. Whether you are running a Shopify or WooCommerce store, keeping tax overrides in a supplemental feed layer (rather than baking them into your primary feed) makes ongoing updates easier to manage.

If you are troubleshooting broader disapproval issues beyond tax, the Google Merchant Center Errors: 12 Common Fixes article covers the most frequent sources of feed-level problems.

The key takeaway: the tax attribute is a targeted override tool, not a required field for every product. Use it surgically for products whose tax treatment differs from your account defaults, format each sub-attribute carefully, and let Merchant Center account-level settings handle the rest.

Related articles

merchant center

identifier_exists False: What to Submit and When It Backfires

When to set identifier_exists to false in your product feed, what companion attributes you still need, and what causes its own disapproval.

Nov 5, 2026·5 min

merchant center

MPN Attribute in Product Feeds: Rules When There Is No GTIN

Learn when the mpn attribute is required, how to format it correctly, and what to submit when a product has no GTIN.

Oct 12, 2026·6 min

merchant center

google_product_category Taxonomy: How to Choose the Right Value

Learn when and how to set google_product_category correctly, avoid disapprovals, and handle override cases in your feed.

Oct 10, 2026·7 min