Stripe Inclusive vs Exclusive Tax in QuickBooks

Two Stripe accounts can sell the identical product at the identical price and book different revenue. Not slightly different. Different by the entire tax amount.

The setting that decides it is tax_behavior, and most people have never touched it. Stripe picks a default for you based on currency, QuickBooks has no idea what got picked, and the mismatch surfaces months later as a revenue figure that is too high and an invoice total that is off by a cent.

Acodei syncs Stripe invoices, payments, fees, and tax into QuickBooks Online automatically. Start a free trial.

What the two settings actually mean

Stripe defines them by what happens to the price the buyer sees.

Exclusive tax "changes the final purchase price: the listed price the buyer sees doesn't include it, and it's added to the total." US sales tax is the example Stripe uses.

Inclusive tax "doesn't change the final purchase price: the price the buyer sees already includes it." VAT and GST outside the US are the examples.

Here is Stripe's own worked comparison, from its tax rates documentation:

Tax	Subtotal	Tax due	Total
25% exclusive	5.00 USD	1.25 USD	6.25 USD
25% inclusive	5.00 USD	1.00 USD (already in the total)	5.00 USD

Read the bottom row slowly. A 5.00 price with 25% inclusive tax is 4.00 of revenue and 1.00 of tax. The customer pays 5.00. The business earned 4.00.

Now the top row. The same 5.00 price with 25% exclusive tax is 5.00 of revenue and 1.25 of tax. The customer pays 6.25.

Identical number in the price field. A 25% difference in revenue. That is the whole problem, and everything below is a consequence of it.

The arithmetic for inclusive tax is worth keeping in your head, because you will need it to check a receipt by hand:

tax = total × rate ÷ (1 + rate)

At 25% on a 5.00 total: 5.00 × 0.25 ÷ 1.25 = 1.00. The net is 4.00.

The default nobody set

Here is the part that catches people out. Stripe's third option is automatic, and it is the default.

Under automatic, "for the currencies USD and CAD the tax behavior is exclusive. For all other currencies the tax behavior is inclusive."

So if you price in EUR, GBP, AUD, SGD, or nearly anything else, Stripe has already decided your prices are tax inclusive. Nobody chose that. It followed from the currency.

And it is not casually reversible. Stripe is explicit: "You can't change tax_behavior after it's been set to exclusive or inclusive." You can create a new price with different behavior. You cannot flip the one your existing subscriptions are attached to.

That combination, a default you did not set and cannot change in place, is why this is worth verifying before you reconcile a single month.

Where the difference hides in the API

If you are checking your own data, the field that matters is subtotal. Stripe documents it as the total of everything on the invoice "before any invoice level discount or exclusive tax is applied."

Exclusive tax. Not tax. Exclusive tax.

Inclusive tax is already inside subtotal. Exclusive tax is not. One field, two meanings, depending on a setting you may never have looked at.

If you want a number that is genuinely tax free either way, Stripe gives you subtotal_excluding_tax and total_excluding_tax, the latter documented as "the total amount of the invoice including all discounts but excluding all tax."

Each entry in the invoice's total_taxes array carries its own tax_behavior of exclusive or inclusive, plus a taxable_amount, "the amount on which tax is calculated." On an invoice mixing both, that array is the only place the distinction is stated per rate.

Manual tax rates carry the same flag. The Tax Rate object has an inclusive boolean whose entire documented job is "This specifies if the tax rate is inclusive or exclusive."

What Acodei does with each setting

Acodei bridges Stripe Tax amounts into QuickBooks through two main approaches: a Tax Product approach that rolls all tax into a single line item mapped to a liability account, and QuickBooks Tax Rate mapping that assigns individual Stripe tax rate IDs to QBO tax codes. A third path, Admin QBO Tax Mapping, exists for non-US companies that do not use Stripe Tax but still need tax applied in QuickBooks after the fact.

Outside those options, tax tracking from Stripe to QuickBooks is not possible. You need Stripe Tax active so the rates and amounts can be retrieved, or tax applied in QuickBooks after the fact.

The inclusive or exclusive choice lives in the Acodei dashboard under Account Mapping, in the Stripe Tax section, phrased as a direct question: is tax inclusive or exclusive?

Choosing inclusive does something specific. Acodei automatically activates what its documentation calls "manual inclusive tax calculation" behind the scenes. The stated purpose is to ensure invoice totals in QuickBooks align with Stripe's final tax calculations. You do not compute the backed-out net yourself. The setting is the instruction.

That matters because the QuickBooks record has to end up carrying a net figure and a tax figure that reproduce a Stripe total which never stated the two separately.

The failure mode: telling QuickBooks the wrong one

Acodei's documentation makes the consequence explicit for the Admin QBO Tax Mapping path. Inclusive is generally the right choice there, because setting it to exclusive "will increase revenue on a QuickBooks receipt."

The arithmetic is the same one from the table above. Stripe collected 5.00 on an inclusive 25% rate, of which 4.00 was yours. If QuickBooks is told the price was exclusive, it records 5.00 of revenue and adds 1.25 of tax on top. The receipt total becomes 6.25 for a sale where 5.00 actually changed hands.

Two things are now wrong at once. Revenue is overstated by 25%. And the QuickBooks total no longer matches the Stripe total, which is the symptom people actually notice first.

It is worth being precise about what each setting does to your profit and loss. In Acodei's model, exclusive tax is generally not counted as revenue, and inclusive tax is generally not counted as revenue either. Tax is a liability in both cases. The difference is never whether tax is revenue. It is where the boundary between net and tax sits inside a number you already agreed on with the customer.

The rounding cent

This is the failure that sends people hunting for an integration bug when the cause is arithmetic.

Stripe supports two rounding strategies for invoices with manual tax rates, configured on the invoice settings page in the Dashboard.

Line item level: "Round at the invoice line item level to the smallest currency unit before summing individual tax amounts across the entire invoice."

Invoice level: "Sum up all individual taxable amounts unrounded per tax rate. Combine them to a subtotal, apply the tax rate on the subtotal, and then round."

On a single line item these agree. On twelve, they can differ by a cent or two, because rounding twelve times and rounding once are not the same operation.

One constraint matters here: that setting only exists for manual tax rates. "Invoices with automatic Stripe tax always sum up the tax amounts first and then round." If you are on Stripe Tax, the strategy is chosen for you.

Inclusive tax sharpens all of this, because backing tax out of a total produces a non-terminating decimal far more often than adding it on top does. A 20% exclusive rate on 10.00 is exactly 2.00. A 20% inclusive rate on 10.00 is 10.00 × 0.2 ÷ 1.2 = 1.6666..., which has to land somewhere.

Acodei documents this honestly rather than claiming it away: inclusive tax requires manual overrides, handled in the backend, and partial or daily summary scenarios can sometimes produce rounding differences.

That is the sentence to remember when you are one cent out on a daily summary. It is a known consequence of the arithmetic, not evidence that your sync is broken.

The validation that runs only when tax is enabled

Acodei compares the final invoice it generates in QuickBooks against the Stripe invoice amount to confirm they match exactly. That check is only applicable when tax is enabled.

The conditional cuts both ways. If you run Stripe Tax, you have an exact-match check standing behind every synced invoice, which is precisely the guard you want when inclusive rounding is in play. If you do not have tax enabled, that particular check is not what is protecting you, and it would be a mistake to assume otherwise.

Daily summary behaves differently from real time

Both modes handle inclusive and exclusive logic, but they arrive there differently.

In real time, each Stripe invoice or charge creates its own QuickBooks record. Each invoice's distinct tax lines map one to one into QuickBooks, which is where advanced rate mapping works best.

In daily summary, one QuickBooks transaction covers the day. When several tax rates occur, Acodei splits line items by product and rate, so a single day might produce Product A with GST 5%, Product A with PST 7%, and Product B with GST 5% as separate lines. For inclusive tax, that breakdown happens at the summary level.

Daily summary is one of the two scenarios the rounding note above calls out by name. If you are inclusive and on daily summary, expect to see the occasional cent, and reconcile on the total rather than chasing individual lines.

Acodei also handles two or more Stripe tax rates applying to a single transaction, mapping them to a QuickBooks group tax code so the total tax matches Stripe exactly. GST plus PST on one line is the common version.

Three constraints worth knowing before you switch

Quantity Tracking and inclusive tax do not combine. Pushing Stripe quantities instead of a hard-coded 1 per line is not available with inclusive tax. Separately, US-based companies using Stripe Tax can enable Invoice Quantity Tracking. If line-level quantities matter to your reporting, confirm which side of that you land on before committing.

US QuickBooks limits your options. QuickBooks Online's US Sales Tax Center does not allow third parties to create official QBO tax rates, so US accounts map all tax to a liability product instead. Advanced rate mapping often is not fully usable in US QuickBooks. Non-US QuickBooks can map to real tax codes like VAT 20% or GST 5%.

Zero-decimal currencies are not supported. If you price in JPY or another currency with no minor unit, that is a hard limit rather than a configuration question.

A short checklist

1. Check tax_behavior on your prices in Stripe. If it is automatic, work out what your currency implies: USD and CAD are exclusive, everything else is inclusive.
2. Make the Acodei setting under Account Mapping match what Stripe is actually doing. A mismatch inflates revenue and breaks totals at the same time.
3. If you are non-US and not using Stripe Tax, look at Admin QBO Tax Mapping. QuickBooks requires non-US companies to carry tax on every line item, which is why that path exists.
4. Set your default product and fee tax rates to Exempt if you only want tax applied to rates you have explicitly mapped.
5. Handle refunds with credit notes. Credit notes replicate in QuickBooks with the correct tax lines. A payment-level refund with no line breakdown does not always reveal how much tax was refunded, which produces discrepancies.
6. If a historical invoice uses an archived Stripe tax rate, add that txr_ ID manually so it can be mapped.
7. Fix problems by resyncing from the Data Feed rather than editing the QuickBooks record by hand.

Fees are a separate question

One thing never enters this calculation: Stripe's own fees never go on the invoice, because putting them there would mismatch the invoice and payment totals. Fees are handled through sales receipts, deposits, or expenses instead.

Tax on those fees is its own topic. Stripe charges VAT or GST on its fees in some countries, and that tax is not your sales tax. It belongs in fee expense, not in your tax liability.

Frequently asked questions

Is Stripe tax inclusive or exclusive by default?

Neither, exactly. The default tax_behavior is automatic, which resolves by currency: USD and CAD prices are treated as exclusive, and all other currencies are treated as inclusive. If you have never set the field explicitly, your currency chose for you.

Can I change tax behavior on an existing Stripe price?

No. Stripe states that you cannot change tax_behavior once it has been set to exclusive or inclusive. You can create a new price with the behavior you want, but the existing one is fixed.

Why is my QuickBooks revenue higher than what Stripe collected?

The most common structural cause is telling QuickBooks the tax was exclusive when Stripe treated it as inclusive. Acodei's documentation notes that setting exclusive in that situation will increase revenue on a QuickBooks receipt. Check that the inclusive or exclusive setting under Account Mapping matches your Stripe prices.

Why is my synced invoice off by one cent?

Backing inclusive tax out of a total often produces a repeating decimal, and it has to be rounded somewhere. Stripe offers line item level and invoice level rounding for manual tax rates, while invoices using automatic Stripe Tax always sum first and then round. Acodei documents that inclusive tax can produce rounding differences in partial and daily summary scenarios.

Does the subtotal in Stripe include tax?

It depends on the behavior. Stripe's subtotal is calculated before exclusive tax is applied, so exclusive tax sits outside it while inclusive tax is already inside it. Use subtotal_excluding_tax or total_excluding_tax when you want a figure that excludes tax either way.

Can I use Quantity Tracking with inclusive tax?

Not together. Quantity Tracking, which pushes Stripe quantities instead of a hard-coded 1 per line, is not available with inclusive tax. US-based companies using Stripe Tax can enable Invoice Quantity Tracking.

---

Getting this right once, at setup, is worth more than any amount of month-end reconciliation. Acodei reads the tax lines Stripe actually produced and posts them into QuickBooks the way your configuration says they should land. Start a free trial.