Skip to main content

Tax attributes

At Taxwire, one of our core values is simplicity. We developed a taxonomy of product categories that is easy to understand and use while offering the ability to express complex tax rules. There are several types of tax attributes that can be used to calculate taxes. Product attributes describe what is being sold or how the product is used. Customer attributes describe buyer-side exemption status.

Categories

Categories like the product categories, often referred to as product tax codes are used to generally identify the type of product being sold. Categories are hierarchical. A category can only be expressed in its valid form. For example, you can use DIGITAL_PROPERTY.DIGITAL_SOFTWARE but not DIGITAL_SOFTWARE. You can see the full list of categories in the Product categories section.

Product attributes

On top of the product categories, we have product attributes that can be used to further refine the tax calculation. Attributes are additive. For example, if you sell a piece of software, you can use the _DOWNLOADED attribute to indicate that the product is downloaded, as opposed to being shipped on a CD or USB stick, which would be the _LOAD_AND_LEAVE attribute. This can materially affect the tax calculation, as the taxability of the product is different for these two attributes in certain jurisdictions. Attributes can be used in any order at the end of a category or by themselves. For example, DIGITAL_PROPERTY.DIGITAL_SOFTWARE._DOWNLOADED is valid but DIGITAL_PROPERTY._DOWNLOADED.DIGITAL_SOFTWARE is not. There is no implied hierarchy or order of importance between attributes, only for categories. Some product attributes describe exemption intent. Other product attributes describe facts about the product itself.

Customer attributes

Customer attributes describe buyer-side exemption status, such as a resale certificate, driveaway certificate, or nonprofit status. Customer attributes are passed on the customer.tax_attributes field for a line item. They usually need to be paired with a product attribute because many exemptions depend on both the customer and the item being sold. The examples below are not exhaustive. Resale and driveaway attributes are jurisdiction-specific, and the valid code depends on the customer’s exemption certificate. Customer attributes are jurisdiction-specific when the exemption certificate is jurisdiction-specific. For example, use RESALE_USA_TX for a Texas resale certificate and DRIVEAWAY_USA_TX for a Texas driveaway certificate.

Force resale

The standard resale exemption is deliberately double-triggered: it applies only when the customer carries a resale attribute (e.g. RESALE_USA_TX) and the line item carries _RESALE. This is the safe default. A resale certificate on file does not mean every purchase that buyer makes is for resale — a buyer can hold a certificate and still purchase items for their own use, and those sales are taxable. Some catalogs cannot carry product attributes, and some buyers genuinely purchase everything for resale. For those cases, each side of the standard pair has a force variant that triggers on its own: Like the standard resale attributes, FORCE_RESALE has jurisdiction-scoped variants (FORCE_RESALE_USA_TX, FORCE_RESALE_USA_MTC, FORCE_RESALE_USA_SST, …). A scoped variant applies only in its own jurisdiction; the unscoped FORCE_RESALE applies in every jurisdiction that has resale rules.
FORCE_RESALE is an unconditional override. Only apply it to customers who never buy for their own use. If a buyer purchases both for resale and for consumption, use the standard RESALE_* + _RESALE pair per line item instead — a force attribute would exempt their retail purchases too.
The same purchase expressed both ways — the standard pair needs a resale attribute on each side, the force variant exempts on the customer attribute alone:
Resale treatment does not always mean zero tax. In gross-receipts jurisdictions — for example Hawaii’s general excise tax — sales for resale are taxed at a wholesale rate instead of being fully exempt. This applies to both the standard and force variants.

Examples

Let’s take the concrete example of a digital software product sold to a customer physically. For example, a video game, sold as a Nintendo Switch cartridge. The category is DIGITAL_PROPERTY.DIGITAL_SOFTWARE and the attribute is _LOAD_AND_LEAVE. So the full expression is DIGITAL_PROPERTY.DIGITAL_SOFTWARE._LOAD_AND_LEAVE. The calculation or transaction API call would include the following line item:
For a resale transaction, pass both a product attribute and a customer attribute. The product attribute says this line item is being purchased for resale. The customer attribute says the buyer has a qualifying resale certificate.
For a driveaway vehicle transaction, pass _DRIVEAWAY on the product and the matching driveaway customer attribute.

Marketplace facilitator

When a sale is facilitated by a marketplace (e.g. Amazon, Etsy, Walmart, Faire, TikTok Shop, Mercado Libre, Rakuten), the marketplace is responsible for collecting and remitting tax — not the seller. This applies across jurisdictions: US sales tax under marketplace-facilitator laws, EU VAT under the deemed-supplier rule, UK VAT, AU/NZ GST, and similar regimes worldwide. Mark such lines by adding the MARKETPLACE attribute to line_item.fulfillment.tax_attributes. MARKETPLACE lines:
  • produce zero seller-side tax, and
  • are excluded from registration thresholds (economic nexus in the US, VAT/GST registration thresholds elsewhere) in jurisdictions that exclude marketplace-facilitated sales from the seller’s own threshold.
The API accepts this flag at face value without further validation. Asserting it correctly is the consumer’s responsibility — misuse is a compliance issue.

Channel sub-attribute

To record the specific marketplace channel (for reporting and filing), append a channel sub-attribute label using the underscore-prefix convention (same shape as DIGITAL_PROPERTY.DIGITAL_SOFTWARE._DOWNLOADED):
Channel labels must be alphanumeric and underscore only ([A-Za-z0-9_]+). Pick any label that matches this charset — there is no fixed enum.

Validation rules

The same validation applies to every tax_attributes field on a line item — product.tax_attributes, customer.tax_attributes, seller.tax_attributes, and fulfillment.tax_attributes. Each entry in the list must match ^[A-Za-z0-9_]+(\.[A-Za-z0-9_]+)*$:
  • single node: MARKETPLACE, B2B, _ETSY
  • dotted path of any depth: MARKETPLACE._ETSY, DIGITAL_PROPERTY.DIGITAL_SOFTWARE._DOWNLOADED, DIGITAL_PROPERTY.DIGITAL_SOFTWARE._DOWNLOADED._FROM_CLOUD
The two list shapes below are equivalent — entries are joined with . into a single ltree path before rule matching:
Rejected at ingest (HTTP 422):
  • empty strings ("")
  • dashes, spaces, or other characters outside [A-Za-z0-9_]
  • leading dot (.LEADING), trailing dot (TRAILING.), or consecutive dots (DOUBLE..DOT)
  • control characters (e.g. null bytes, newlines)
Each tax_attributes list is capped at 20 entries.