Co-budget and organization around the tax overhaul dev

International
21

Sorry I’ve been silent - I have been trying to follow this - and I’m not sure I do. But - let me explain the Canadian case –
FIrst - luckily - only a small number of food products traded on OFN are taxed in CAnada - for example, only so called ‘snack’ or ‘convenience’ items - so for our hubs this would mean products like: popcorn - or other things sold in single-use packaging. Plus - we have hubs that sell non-food items - herb plants, vegetable seedlings, soap, flowers - these are all taxed. But still - it is a specific sub-set of products.
Second - we have a ‘double’ tax system that applies to the above taxable products. Each different province or territory (what you call ‘state’ in the above discussion) decides how to integrate these.
There is federal tax (GST or general sales tax - which is the same rate for the whole country and calculated on the same products ) and provincial (state) tax (PST - which varies in percentage, and in the products it applies for each province). To complicate this - in some provinces (like Ontario where we are launching OFN first) these two different taxes are combined into one - HST (harmonized sales tax) . So those provinces are easy. BUT, where the province has decided to keep them separate - so they have 2 tax categories (GST and PST) - we need to be able to calculate them SEPARATELY and show them separately on an invoice.
One option would be to set up different instances with different tax categories at the instance level - that would mean we would set up separate instances for each Canadian province (state) - but then this would curtail trade across provincial borders - which one day we will certainly want to do. Plus there are likely added expenses to set up all these separate instances.

This said - right now in Canada we can make the current system work for us - with the solution suggested above - each province/state has ONE designated tax category. That means combining PST - Provincial Sales Tax and GST - general sales tax - for a single tax percentage). This means that a vendor would need to separate out and hand calculate the PST and GST portions for reporting and remitting purposes (these taxes are paid to different governments) - but since the number of products they have to do this for will be small - it is not THAT problematic. Long term it would be great to fix it - but if a short term solution ‘tables’ the problem for a later fix, that is fine.
@MyriamBoure @oeoeaio @Kirsten @CynthiaReynolds @NickWeir (not sure who else should be pinned)

22

EDIT: I ran this idea by @Kirsten and she picked up a few problems with it… :frowning: I’ll keep working on fleshing it out as an idea, but let’s go with @MyriamBoure’s approach for now. :slight_smile:

Sorry @MyriamBoure, I articulated my idea very badly. My idea was not to set the tax category at the shop level. I am simply thinking about setting the tax category on products in a slightly different way. I will try and explain it better. NOTE: this idea involves a reconfiguration of how products and prices work, but we are talking about that as part of the p/v overhaul. Some of what I am about to say will go off the topic of tax, but I am just trying to provide a context for the idea have had.

I suppose that this is what I am proposing. Tell me if this is wrong for your countries (@MyriamBoure, or @tschumilas, or anyone else), but when a producer sets up a product, they do not need to know whether the tax applied to the product when it is sold will be “included in” or “added to” the price, right? They should be able to just enter the tax-exclusive cost-price (ie. the price they will be selling it to hubs for). If this assumption is wrong then I suppose my idea will not work, but read on and tell me what you think.

I am thinking about the products page as the place where producers do most of their work, and the inventory page as the place where hubs to most of theirs. So, assume that we have a product that has a cost price that has been set up by a producer on the products page. It probably needs a markup added to it before it is sold through a hub. If we think about the inventory page as the place where markups are applied to products, and where tax categories are applied, then we remove the problem of hubs having to think about whether the the prices coming from producers are tax inclusive or exclusive: they know that they are tax-exclusive, and so they can apply tax-categories in a uniform way across products from all producers.

This may even allow us to completely remove tax inclusiveness from the management of products entirely, because we could potentially set up whole inventories as having either tax-inclusive or tax-exclusive prices by convention. Just an idea, but this seems logical to me. What hub manager wants to enter a mixture of tax-inclusive and tax-exclusive prices within one inventory?

SIDE NOTE: by “markup”, I mean something very similar to enterprise fees (they may even be the same thing, I haven’t worked that out yet). If we introduce the idea of “cost-price” (from the products page), we can then add a “markup” that could be a percentage, or a fixed amount, or maybe even a formula to determine the “sale price”, which can then be marked as tax-inclusive or tax-exclusive. I am imagining that these markups could be “pre-canned”, ie. you set them up just like enterprise fees, and then apply them to whichever products you like.

If we implement this separation of responsibilities between the products page and the inventory page, producers who are selling B2B can just not set a markup in their own inventory. If they also want to sell B2C, then they can have a separate inventory for that, where appropriate markups are applied. These different inventories can then feed into their respective order cycles.

So that is the context for my comment that “Having producers set tax categories on their products that then need to be overridden by shops seems like a very confusing way to set this up.” I just didn’t explain myself at all. Sorry. :grimacing:

I think in this regard we are culturally much more similar that you think. :wink: In general retail prices in Australia always include GST (our version of VAT). For example the bill at a restaurant, the total will always be given as GST inclusive. The only difference here is that at the moment most unprocessed food products are not taxed at all, but things may not stay that way forever. For the few foods that are taxed, my understanding is that this works in a very similar way to European VAT, both culturally and technically.

Same goes for B2B, because most business expenses are tax deductible, prices for most commercial (B2B) products and services are provided as an amount “plus GST” ie. tax-exclusive.

23

@tschumilas I think that that this is only partially (or temporarily) true:

For provinces with two separate tax rates, you should be able to add both rates to the tax-category for that province, and they will be calculated separately. At the moment, these separate rates are not split out on the invoice, but it is my understanding that they should be visible separately in the sales tax report? If I am wrong, we should be able to get the system to do this, particularly after the Spree upgrade is complete. Splitting them out in the invoices is a priority for France too I believe, and @MyriamBoure and @pierredelacroix will be working on a solution.

At the risk of adding confusion to this discussion: I have been thinking about the Canadian case, and there is an alternative and possibly simpler way of setting up taxes (more closely modelled on the US approach, which is the system Spree was initially designed around). Am I correct in understanding that the tax-exempt status of a product does not vary between provinces? By that I mean, are there examples where a particular product would be subject to tax in one province but not in another?

If the only difference between how a product is taxed in one province vs another is the tax rate(s), then I think you may be able to use just one tax category, which is loaded with all of the different rates for each province (each province is set up as a tax-zone). If you then apply this tax category to a product, the system should just automatically work out which rate(s) to apply based on the zone that the order is being shipped to.

Perhaps this setup is problematic if you wanted to display the prices inclusive of tax in the shopfront (this is standard practice, yes?), because there is no way of knowing which tax rate to apply without the customer somehow specifying where they are located before they place their order - though I suppose this could be achievable.

24

Oh, if it were that simple :wink: The federal tax (GST) applies to the same products and at the same rate (%) across the country. BUT, provinces are empowered to set different provincial taxes (PST). So this can result in the same product being zero rated in one province, but taxed in another. (Muffins would be an example - and I was just chatting with a hub about this. This is a hub in a large workplace, and they want to sell single muffins when they do their delivery in the afternoons. (nice idea). This is considered a snack food (vs a basic grocery). In Ontario this is taxable (13 % HST), but in BC I believe this incurs tax.

These taxes are getting so ridiculously complicated here - and they are constantly changing. so I’d say for the sake of a ‘easy’ future - planning from the premise that different provinces will have different tax exempt products AND different tax rates is the best approach.

But i want to say again - don’t let the Canada situation hold back something that works for everyone else because in the end, very few products traded on OFN will be taxed anyway.

1 Like
25

You are correct. And I like your approach here. A ‘producer’ on OFN, in essence might wear 2 hats - one as a ‘pure’ producer who sets the ‘cost’ price (I’d call this a ‘base’ price ) . This is the money they expect to get when they sell to another enterprise (who adds a ‘markup’…). But in addition, for some (but not all) producers, they also become B2C sellers in a shop. So in a way they become like another ‘middle’ enterprise, and (at least in Canada) usually add a ‘markup’ to their base price when they sell directly to consumers. So they’d add a tax here too for taxable products.

just as an example to be clear - i am a flower farmer. flowers are taxable in Canada. . I vary the base price (you call this the cost price) based on the quantity they by - but in no case do I add taxes. The hub adds the taxes. In Canada, a consumer must only pay the tax (whether it is provincial or federal) once. There is to be no ‘double taxing’, and no ‘taxes on taxes’. (And consumers watch for this.) So, when I sell flowers in my own shop, I add the tax for the consumer, and I remit this to the government(s).

Theresa

26

@oeoeaio the work has already been done by @pierredelacroix on seperating the different tax rates on the invoice and sales_tax report, it’s been pushed and just waiting or approval. Si this should be available for the community in the next release.

Thank you @tschumilas for those new elements. We need to find a system that works for the Canadian / French / Scandinavian instances as well as stay ok for UK and Australia… basically find a “one fits all” solution… So the system we set up needs to work for Canada, it’s a good use case.
We have the same issue on the French instance where already hubs based in Spain are trading and soon from Belgium maybe. Tax rates vary also from type of products between countries in Europe :-o

Also on your flower case, what I see is that there is a cultural factor here that we should also consider… Technically in France a producer could set up his price excluding tax, so we could set this as a rule for the whole instance. BUT we already had negative reactions from farmers/hubs who only sell in BtoC and don’t even know their price excluding tax… so it would mean for 90% of our users they would have to recalculate all their price to exclude VAT before filling them in. This is no acceptable for our users I’m afraid… for most European countries it will be the same.

I found for Ontario (I guess it’s the same for other states) “Usually, HST is added at the cash register so the amount on the price tag may not be the final price.” but it doesn’t seem to be ALWAYS the case… @tschumilas can you confirm that some people might want to display price in the shopfront including taxes? In which case for example? (for our understanding)

Also I have a question @tschumilas, culturally speaking how do people usually talk about VAT in Canada? Do you talk in term of products (Food VAT) or in terms of rates (12%) or …
Like in France, we say that for Food the rate is 5,5%, but no one know about the tax category (“reduced rate” here)
It seems in Canada people will say that Food is taxable or not taxable and GST/PST/HST and not in terms of rate… am I right? You won’t say that “this muffin is taxed 12%” but “this muffin is taxable and the VAT that applies is HST” but you won’t talk in terms of rate. Am I right?
I think it’s important that the way we overhaul the tax system “talk to the people”, so that tax categories should be designed in that prospective. In France we need the name of taxe category to be “Reduced 5,5%” but for Canada it could be only “HST” or “PST+GST”.

It seems in Canada the rate that applies in trans-province sales is the one of the buyer so the default Spree set up could apply. But this doesn’t work in the case of France. A hub based in Spain selling in France, until his turnover is below 100K€ the VAT rate he has to apply it the one from the origin country, above the threshold he has to collect French VAT. So basically the rate that apply is not the one of the consumer zone until he sells for more than 100K… the Spree tax system doesn’t consider that case…

Here is a modelisation attempt raising also some issues and comparison with needs in Europe:
’ https://docs.google.com/document/d/1MYJMZxIeLDMYCwjeBFUW7Vu9Lz1l33LXTkAnm9Xrn3g/edit
Feel free to comment on it :slight_smile:

@oeoeaio the main issue I still see in the last version we came up with (https://docs.google.com/document/d/1xr27DEnGzmuh2WA74gRPZ90J7w-nZMatr8VJKQ6WPS0/edit) is that for a hub selling trans-provinces or trans-countries he might need to set up a different entreprise for each zone he sells to… I explain it at the end of the document.

If you have another idea on how to move forward in that super messy VAT festival… Unless rethinking it from scratch and accepting to change all the calculations :-o

27

Sorry I replied before having read your last post @oeoeaio!

I’m afraid your assumption doesn’t work for France and most European countries @oeoeaio :frowning:
As I said by default in France some people talk and think in tax-inclusive prices (those working mainly in BtoC = small producers, buying groups) and other will talk and think in tax-exclusive prices (those working mainly in BtoB = distributors, wholesalers) So a hub can have in his inventory products that have been filled up as tax-exclusive and products that have been filled up as tax-exclusive…

28

I see an issue here, with tags. We have shops setting up to outgoing distributors with different markup depending on customer tags… so that can’t be done at the inventory level :frowning:

This is technically possible but hard to apply in France at least as explained before… a hub managing a catalog producers on his name will usually receive an excel spreadsheet or a PDF with tax-inclusive prices… The hub always pay the tax-inclusive price to the producer.

  • If the hub is not within the VAT scheme (2/3 of our users so far) he will just add up the markup to the tax-inclusive price he has paid to the producer (he does’t deduce nor collect tax so he can’t add up a markup only on a tax-exclusive price…)
  • If the hub is within the VAT scheme he will write in his accounting the amount he has paid as “tax deduction”. he will add the markup on the tax-exclusive price of the products and collect VAT on (original tax-excl. price + markup) and write the amount in “tax collection” in his accounting, so in his accounting he will pay to the state VAT collected - VAT paid to the producer.

That makes me think that we might have also to add in an entreprise fee set up if the fee applies on the base price incl. or excl. VAT… I forgot that point.

##Other idea building on your proposal

I will try to think more in your direction @oeoeaio as I understand the interest of your point of separating the pure “product list” and tax excl. price manage by the “producer hat” and the markup and VAT added by the “distributor hat”… there might be a way maybe to allow a producer to import a list of products with tax-inclusive price + the VAT category info and that the system “retreat” that information to register the tax-exclusive amount + VAT rate in the default inventory information… (@lin_d_hop I guess this is connected also to the data import discussion… so I ping you here.)
Then for the info to be super clear to the user I think in the product info should appear both the default tax rate, tax excl. price AND tax-incl.price (they might be surprised if they import a tax incl. to see that the price displayed is different… so they should see both prices and they would understand clearly).
By default every “distributor hat =hub” would have an inventory, which would be the same info as in the producers catalogs he is connected with (as it is today).
With my “distributor hat” I could add a mark-up to my own products, and I could check a checkbox saying “apply on: 1- tax excl. price or 2- tax-incl. price”… but that should be done in the OC-outgoing section as the markup could vary depending on tags.
Would something in that direction be possible?

It doesn’t solve our problem on how to set up the tax categories though (and we still have the issue if we follow my proposal that a hub selling to different VAT zone will need one inventory/hub/shopfront per zone), but it removes the tax-inclusive/tax exclusive thing though.

29

I think one of our underlying issues here is that when I talk about tax - I mean ‘retail sales tax’ and when @MyriamBoure talks about tax (and likely all the EU) she means ‘value added tax’. These are different in subtle ways and that is our challenge. I had never even heard of ‘VAT’ before OFN - I just assumed it meant the same thing as ‘sales tax’ as we call it. so - I finally googled it - https://tax.thomsonreuters.com/blog/onesource/sales-and-use-tax/difference-sales-tax-vat-2/

Sales tax is collected by the retailer when the final sale in the supply chain is reached via a sale to the end consumer. End consumers pay the sales tax on their purchases. No part of this money goes to the producer or seller. but sometimes its hard to know when someone is the ‘end consumer’. so for example: A small sized flower shop (like me) might ‘buy in’ flowers I don’t have to re-sell. The supplier I buy from might consider that I am the ‘end consumer’ because my order is small. So - i paid a tax on something I want to re-sell. As a retailer, I should not have to pay this tax - it is not one of my costs. So - I list the product, with the tax in my shop - the consumer pays it. (Now that tax has been paid twice - once by me when I bought it, and once by the consumer when they bought it). SO - I ‘claim’ it and get the tax i paid back. The burden is on the consumer not the retailer. So thats why in a sales tax system - the easiest thing for us - is for the producer to have no tax on their products when they sell to the hub, and have the hub add the tax where applicable. That way the hubs don’t have to ‘re-claim’ all the tax they pay.

VAT (Value-Added Tax) as I understand it - is collected by all sellers in each stage of the supply chain. Suppliers, manufacturers, distributors and retailers all collect the value added tax on taxable sales. Suppliers, manufacturers, distributors, retailers and end consumers all pay the VAT on their purchases. Businesses must track and document the VAT they pay on purchases that will be resold in order to receive a credit for the VAT paid on their tax return. Tax jurisdictions receive the tax revenue throughout the entire supply chain as opposed to at the sale to the final consumer chain.
So OFN also needs the capacity for VAT.

So we need capacity for both sales tax (added onto a ‘base’ price by a seller and paid by a consumer) and VAT (included in the producers price, and also added on at subsequent steps in the ‘chain’) - Is that helpful? Does the platform have 2 different ‘systems’ at work - and an instance chooses first - this is a VAT system or this is a sales tax system? (Then what happens when we sell between instances?)

30

If the vendor is a small business (I think the limit is gross revenue less than $30,000/yr or something like that) - they do not have to register as a tax collector. So in that case - a non-registered seller would not add tax to a product. BUT - if you are not registered, not only do you not add on tax and charge the consumer, you also have no possibility of re-claiming taxes you pay. So for example - on my flower farm, I buy lots of inputs (straw, floral packaging, tools, fuel, mobile phone…) and I typically pay taxes of 13% when I purchase these. If I am ‘registered’ with the federal government as a ‘tax collector’ (in other words i charge taxes to consumers on my flowers - REGARDLESS of the fact that I am under $30,000/yr in sales) then I have the opportunity to claim back all the tax I paid. SO - most small businesses (farms and food hubs included) would register and charge tax, even though they don’t have to, because what they can ‘claim back’ (taxes they paid out) is greater than the taxes they charged. So last year for example - I think I received something like $500 is taxes from end consumers - but when i added up all my receipts from inputs I bought for the farm - i paid out over $3000 in tax. So - I got a refund for $2500. So while it is possible that a vendor is not registered and therefore doesn’t charge tax - it is not very typical because it usually works in their favour to be registered.

Regarding shopfont display - I think that sometimes - especially smaller firms/farms want to show their price is competitive with a ‘conventional’ seller (like a big store). So, for things like selling plants (which is taxable) - they would say ‘tax included’ - so the consumer can do a mental calculation and compare the cost with a big nursery’s prices (where tax is not included and would be added at checkout). BUT - this comes about because those small hubs/farms are accustomed to face to face sales (farmers markets, roadside sales, event sales) where no one wants to do the calculation at the checkout because it is primarily cash. So - I’d say OFN is different because the consumer will see that tax is on their invoice.

31

This is a good point - see my post re sales tax vs VAT. For one thing - we have no idea what VAT is (I never heard this before OFN). We would just say - that the muffin is ‘taxable’ - in other words - remind the consumer that this is a food item that incurs tax. (and in that example we’d remind them that if they buy 6 there is no tax - because now this is no longer considered a ‘snack’ purchase - it is a ‘staple food’ purchase and those are not taxable.)
We would not reference that ‘tax rate’ because in a given jurisdiction we would all know what the rate is.

32

Wahou, what a beautiful Canadian / French / Australian cooperation :slight_smile: YES! Theresa, you got it :slight_smile: Now I start to understand better.
SO I think to overcome that issue,the easiest thing could be the last idea I proposed: in the product infos,why not having 3 fields: price excl. tax, price incl. tax, and VAT category, and leave the user choose if he wants to fill in the price inc. or excl. tax and set up the VAT category for the product? And the other one fills in automatically.

That way we would have the info with or without tax.

  • If the producer/hub sells to end consumer:
  • in the Canadian case he can display the price without tax but add the tax at checkout.
  • in Australia and France he can display the price incl. tax and just display clearly what was the tax included at checkout
  • If the producer/hub sells BtoB:
  • in the Canadian case he can display prices without tax and not add the tax at checkout
  • in France he can display prices without tax and add the tax at checkout.

Wouldn’t that solve all our issues @oeoeaio ?

For a buyer selilng both BtoB and BtoC he could manage with tags which shopfront to display to the user. For ex in your flower case @tschumilas your supplier could have a shop for “tax registered clients” and another for end-consumer clients, or manage that with tags.

As you said before @tschumilas the “taxable” quality of a muffin can vary from state to state. So it goes in the direction that every hub selling a product should define in his situation if the muffin is taxable or not… so you could have two tax categories type:

  • taxable

  • non taxable
    And you will have multiple tax rates then to cover the cases of your users and use the default Spree functionality which uses the tax rate corresponding of the zone of the buyer.
    So if a hub sells in Ontario a muffin primarly sold by a producer in BC. The producer in his inventory has set up the muffin as “non taxable” as it’s not taxed in BC. The hub in Ontario will override that info and set it up to “taxable”

  • The tax rates behind “taxable” are set up like this:

  • Tax zones=
    Canada > state type zone, associated with Canada
    GST 5% > region type zone, associated with YT, NT, NU, BC, AB,SK, MB, QC
    PST 7% > region type zone with BC, MB
    PST 5% > … SK
    PST 9,975% > … QC
    HST 15% > … NS
    HST 14% > … PE
    HST 13% > … NL, NB, ON

  • Tax rates=

  • category “taxable”, zone “HST 15%”, tax rate name “HST 15%”, rate “0,15”

  • category “taxable”, zone “GST 5%”, tax rate name “GST 5%”, rate “0,05”

  • category “taxable”, zone “PST 5%”, tax rate name “PST 5%”, rate “0,05”
    etc.

So If I’m in SK and the muffin has the tax category “taxable” the valid tax rates will be the 2 associated with SK zone, which are GST5% and PST5%.
If I’m in ON, only the HST 13% tax rate will be the valid one as the only one associated with ON

Would that work?

The only remaining issue is that a hub selling to multiple VAT zone will have to manage an inventory/shopfront/hub for each region… but I don’t see how to overcome that as VAT rules are so specific from country to country… the case of our Spanish hub who needs to apply the origin rate below a certain turnover and the customer rate above is a good example, I don’t see how to find a rule that fits all…

33

Hi everyone here!
I have launched the co-budget bucket for the estimation stage: http://cobudget.co/#/buckets/1012
One of our French users said he would contribute to this estimation for $500 AUD, so it remains $700 to cover. Can Norway @CynthiaReynolds contribute to it? UK @NickWeir or @lin_d_hop? Canada @tschumilas?
Lets kickstart our first mutli-instance co-budget bucket :slight_smile:
Whenever we have decided on cobudget stewardship we’ll add your promised contribution into co-budget.
As @oeoeaio is going to work on it the money will be to transfer to OFN Australia (unless Rob want us to pay him directly?)
Ping @Kirsten for info.
Cheers :wink:

1 Like