## TL;DR

Stripe's customer_tax_exempt 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

```text
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 customer_tax_exempt 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.
2. Collect and store the exemption certificate or VAT ID validation before changing anything.
   Expected output: Your audit trail supports the setting.
3. Set customer_tax_exempt on the customer object.
   Expected output: New invoices inherit the correct treatment.
4. 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.
5. 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 customer_tax_exempt 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