Stripe "customer_tax_exempt" none vs exempt vs reverse on invoices

TL;DR

Stripe's customertaxexempt has three values: none (normal taxation), exempt (customer is tax-exempt, no tax charged), and reverse (reverse charge applies, typically EU B2B cross-border). Set it on the customer and it flows onto every invoice automatically. Getting it wrong means charging tax to exempt orgs or missing reverse-charge treatment. Validate the customer's exemption certificate before setting exempt, and use reverse only where your tax rules actually call for it; the invoice then shows the reverse-charge note instead of a tax amount.

The query

Stripe "customer_tax_exempt" none vs exempt vs reverse on invoices

Use this when

• EU B2B customers asking for reverse-charge invoices
• Tax-exempt nonprofits being charged tax in Stripe
• Choosing the right customertaxexempt value

Not for

• Configuring the actual tax rates (use tax rates or Stripe Tax)
• One-off invoice tax overrides (use invoice-level tax settings)

Steps

1. Determine the customer's real status: standard, documented exempt, or reverse-charge eligible.

Expected output: You know which of the three values is legally correct.

1. Collect and store the exemption certificate or VAT ID validation before changing anything.

Expected output: Your audit trail supports the setting.

1. Set customertaxexempt on the customer object.

Expected output: New invoices inherit the correct treatment.

1. Generate a draft invoice and confirm the tax lines show the expected outcome.

Expected output: Exempt shows no tax; reverse shows the reverse-charge note.

1. Backfill or credit-note any recent invoices issued with the wrong status.

Expected output: Past mistakes are corrected, not left to compound.

Variant phrasings

Stripe customertaxexempt exempt vs reverse

Stripe reverse charge invoice setup

tax exempt customer Stripe billing

Root cause

The field is customer-level because tax status is a property of the customer relationship, not of a single invoice; Stripe then applies it consistently across invoices. The common error is treating it as a per-invoice toggle and hand-editing invoices instead.

Edge cases

• Reverse charge still requires a valid VAT ID; validate it with VIES or your provider
• Changing the value mid-cycle does not rewrite finalized invoices; only new ones pick it up

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xRKrAq5PV-nr8077JF3Osg