Tax: Organization setting to exclude or include taxes in prices

[birkjernstrom]

Organization setting to enable developers to configure:

• Taxes included in prices. We still calculate taxes, but deduct it from the product price vs. add it and pass it on to the consumer
• Taxes excluded (current) in prices. We calculate taxes and add it on top at checkout for consumers to pay.

Original description (for the context/discussion below)

Currently, all prices on Polar exclude taxes (sales tax, VAT). However, we should allow developers to configure their price to either:

• Exclude taxes (current)
• Include taxes, i.e developer eats the cost based on local taxes from their price.
• Auto, exclude in US/Canada and include everywhere else

[emilwidlund]

Hmm. I’m not 100% this is the right path to go down.

This will make the price situation be quite complicated from an integration standpoint. You would need to take this tax setting into account when you display prices, etc.

I would rather want Polar to go down a simplicity route (opinionated, but simple) than giving users multitude of options (complex and Stripe-like).

[stursby]

@emilwidlund Stripe already offers this https://docs.stripe.com/tax/set-up#default-tax-behavior and it would be great to be able to set a "flat" price for a subscription and then if there's VAT/Tax based on the customers region, then that could be deduced from the total? Sorry if I don't understand it correctly.

[birkjernstrom]

Great pushback @emilwidlund, I agree on the pursuit of reducing complexity. However, in full transparency how I thought about this vs. how I wrote it up does not match due to 1) haste during the latter and 2) quick influence from Stripe 🙊

How I see it: It would be an organization vs. per product setting. Since...

• In 99.9% of cases an organization would consider it a binary decision across their store, e.g do they want to cover taxes or pass it on to consumers?
• Integrations would therefore not care about differences. They would set their organization setting and their integration would simply reflect (hard coded) whether taxes are included or excluded.

So the complexity would live in our storefront and checkout vs. integrations. I think that's the right principle: Maximize simplicity of integrations and delegate complexity to our checkout.

Of course, only having 1 global case would be ideal, but I think it's a lose-lose-lose bet in reality.

• Developers who want to offer a simple "$9/month" subscription regardless of taxes (common) would be deterred to use Polar or use us with lower satisfaction, resulting in...
• Customers churning at checkout upon taxes being added (unnecessarily given above)
• Polar ends up not serving either above

But I wrote the issue quickly after hearing the request from some use-cases and looking at how Stripe handles it – resulting in the sloppy description.

[timkinnane]

In Australia and probably a number of other countries, it's a legal requirement for displayed prices to be inclusive of tax. So the opinionated but simple route may exclude a lot of users in this case.

[stursby]

@timkinnane Got it. It looks like Stripe handles that by still showing the tax amount, even it you decide it's "inclusive" pricing. ie: if the product is $10, it'll show, for example, VAT $1.20, but they still get charged $10 total, meaning you'd be left with $8.80.

Also, for context, here's a nice Lemon Squeezy article talking about the benefits on inclusive pricing: https://www.lemonsqueezy.com/blog/new-tax-inclusive-pricing-feature (cc @emilwidlund )

[frankie567]

Like Emil, I was a bit reluctant to add this feature which adds lot of complexity. However, I like the global setting approach; which makes total sense.

Also, for context, here's a nice Lemon Squeezy article talking about the benefits on inclusive pricing: https://www.lemonsqueezy.com/blog/new-tax-inclusive-pricing-feature (cc @emilwidlund )

Nice to see that LS also has this global setting approach.

[birkjernstrom]

Great :) Apologies for the initial confusion. Updated the description/title to better reflect intent here given the discussion above. Thanks everyone for contributing – awesome to see the community engaging and helping shape the future of Polar and for these decisions to happen in the open 💪🏼

[Mizokuiam]

Thank you for raising this issue! I'll look into it and try to help if I can.

[birkjernstrom]

Thank you @Mizokuiam - excited you want to contribute! However, I'd recommend starting with another issue and that the core team need to tackle this one. Changing price/tax dynamics would touch a lot of places in the codebase including our transactions model and ledger which is a bit hairy and not a good starting issue, I'm afraid.