Stripe Customer Tax Exempt Status

none, exempt and reverse: what each tells Stripe Tax

none is the default. Stripe Tax calculates as usual from the customer’s location, the product tax code, your registrations and any tax ID on the customer. A none customer can still end up with no tax, for example when its tax ID triggers the reverse charge or you are not registered where it is.

exempt tells Stripe Tax to charge nothing and to give the reason customer_exempt. Stripe describes exempt customers as "those who, under a jurisdiction’s rules, can make tax-exempt purchases," and names non-profit organizations and government entities as common examples. Each taxing jurisdiction decides who qualifies, so an organization exempt in one place is not automatically exempt in another.

reverse tells Stripe Tax to charge nothing and to give the reason reverse_charge, and the invoice and receipt PDFs say "Reverse charge." In Stripe’s words, in a reverse charge transaction "the customer must calculate and remit the tax." It is most common on cross-border sales of business services.

The status belongs to the Customer, so it travels with that customer. Stripe’s instruction is to set the status and "provide the customer ID when creating a subscription, invoice, or Checkout Session." For a one-time Checkout payment, the status used is recorded in the Checkout Session’s customer_details. With the standalone Tax Calculations API, a saved customer’s exemption fills customer_details.taxability_override, and without a saved customer you pass taxability_override yourself as customer_exempt or reverse_charge.

Tax status or tax ID: two routes to the same zero

Stripe Tax "automatically applies the reverse charge based on the presence of a tax ID and the jurisdictions involved in the transaction." Stripe adds that you "can also set a customer’s tax status to reverse charge using the API or the Dashboard." Those are two different routes, and they fail in different ways.

The tax ID route works only for types marked Yes in the Impact in Tax Calculation column of Stripe’s tax ID table. Egypt’s eg_tin and South Africa’s za_vat are Yes. Kenya’s ke_pin is No: Stripe stores and prints it, and the calculation ignores it. A Kenyan business customer whose only number is a PIN is taxed like a consumer unless something else changes the result.

The status route is that something else. Stripe’s Tax API guide says that when "you might not have your customer’s tax IDs, or you’ve separately determined that the reverse charge scheme applies," you can use the override to "force Stripe Tax to apply the reverse charge scheme." The difference is who decides. With a Yes-type tax ID, Stripe Tax applies the reverse charge "according to applicable laws." With the status, you decide, and Stripe takes your word for it.

That makes the status the riskier of the two to leave unattended. A tax ID is judged sale by sale. A status stays until someone changes it, so review it when a customer’s circumstances change.

Inclusive prices: Stripe Tax and manual tax rates do opposite things

With Stripe Tax and a tax-inclusive price, the customer’s total does not move. Stripe: "For transactions with inclusive tax behavior, the customer exemption doesn’t affect the total amount paid by the customer." An exempt customer buying a 100.00 USD inclusive price pays 100.00 USD, and with no tax inside it, all 100.00 USD is revenue. A taxed customer pays the same 100.00 USD and some of it is tax.

Manual tax rates, the txr_ objects you attach to invoices yourself, work the other way. Stripe’s tax rates guide says that if the customer is exempt or reverse, then for invoices with inclusive tax rates "the customer pays the unit_amount price minus the tax that would’ve been paid had the user not been exempt or reverse." Its own example: a 100 price with a 10% inclusive rate costs an exempt customer 90.91 USD, because the 9.09 USD of tax inside it is subtracted. With a 10% exclusive rate, the same customer pays 100 USD.

So one customer and one price can produce two different totals, depending on whether Stripe Tax or a manual tax rate does the calculation. If you are moving from manual rates to Stripe Tax, expect exempt and reverse customers on inclusive prices to start paying more, and your revenue on those sales to rise by the same amount.

Finding exempt and reverse charge sales in Stripe’s reports

Stripe Tax’s itemized export has two columns that matter here. taxability_reason holds customer_exempt or reverse_charge on the untaxed lines. customer_taxability_override holds "the customer’s tax status used for taxability of the tax transaction," with values customer_exempt, reverse_charge or none.

The names change on the way. The Customer field says exempt and reverse, while the export and the Tax Calculations API say customer_exempt and reverse_charge. They mean the same two statuses. Stripe also notes that tax_type is not guaranteed to be set when the reason is reverse_charge, so filter those rows on the reason, not the tax type.

Refunds need care. Stripe warns that if you refund a tax amount so that the tax is no longer proportional to the subtotal, the export will not reflect the reason for the reversal, "such as product exempt, customer exempt, or reverse charge," and recommends fully reversing the transaction instead of refunding part of a line’s tax.

The export tells you which sales relied on a status. It does not hold the evidence for it. Keep exemption certificates, or the records that justify a reverse charge, alongside the customer, because Stripe will not ask for them and a tax authority might.