#3063 - Sales tax: Buyer-origin tax rules
-
By Chris Graham
- Added
- 1 view
| Identifier | #3063 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Sales tax: Buyer-origin tax rules |
| Status | Completed |
| Handling member | Chris Graham |
| Addon | ecommerce |
| Description | We have a number of situations where a different non-zero tax rate should be charged based on where a customer is:
1) In the EU when a digital good is being sold (e.g. a German user buys from a French store, and the French store must charge the German VAT rate). This is only for digital goods, it's a special rule. 2) In the US in a "destination based" tax state. States don't have a single tax rate, different districts and cities within the state can levy their own taxes. So if you are in a state X, which follows destination taxing rules, and you are selling to someone else also in state X (so sales tax is due), then you need to charge the right taxes for that particular customer's city etc. Some eCommerce-friendly states like California have origin-based pricing, which is easier to comply with. 3) In the US if you have "nexuses" across multiple states then you need to simultaneously apply the tax rules of all those states. For example, if someone runs their online business from state X, employs their main programmer from state Y, and has their main warehouse in state Z, then the correct rules from states X/Y/Z must be applied based on which state the customer is in (whatever they are, be they origin or destination based). 4) In the US there are a few federal-level sales taxes, e.g. for tyres and motor fuel. Therefore tax for customers across state boundaries would not zero out, it would just go down. In the future there could be a federal "Internet tax". 5) If you are selling internationally and have major "nexuses" in multiple countries (e.g. you are a European seller, but have a warehouse in the US). (Composr has built-in support for zeroing out taxes when selling across tax regime borders, in which case import duty would become the applicable regime, and that's handled at import rather than at sale) It's not feasible for us to support configurability of all these rules. We can make official integrations with Taxcloud and https://euvat.ga/, free web service APIs for calculating tax. We can then allow each eCommerce product declare what tax category it is in rather than giving an exact tax figure. The appropriate would take the seller address, the buyer address, the price, and the tax category, then come back with the right figure. |
| Steps to reproduce | |
| Additional information | You have a responsibility to pay the correct tax. Sales tax is self-reported and any government attention would probably focus only on those with large sales, especially when jurisdiction boundaries are concerned.
You might think a workaround is to retroactively pay any excess tax (city and district taxes) out of pocket. However, you are supposed to give customers a receipt showing exact tax paid, so this is only valid as an emergency measure. Philosophically I don't love relying on 3rd-party APIs for this, it should be open source. But practically speaking, if the APIs are free to use, it's good enough - especially considering the amount of maintenance they need to do on their data. |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
In any tax field allow input of either:
- float number
- "EU" (gets standard rate from https://euvat.ga/rates.json)
- "TIC: <number>" (uses TaxCloud)
There must be field validation for that.
The eCommerce hooks would fill in the 'tax' field by looking up the tax for if the customer is buying from the business address.
However it would also carry a 'tax_code' field, and the correct tax would be worked out after the customer address is entered, and carried through.
I think TaxCloud will also tell us details of the exact taxes charged. We need to carry this through all the way to the transaction log. For EU taxes we should say the country it is for. This should be structured as a list of taxes. For the CSV import we should have each one be its own column, so it can be tallied.
This should all be documented.
post_param_tax function to read in tax value and verify
have a tax field type instead of list for catalogues, uses form_input_tax (so no pre-defined tax rates, except the written category descriptors that TaxCloud provides); should default to the most common category descriptor, assuming taxcloud is enabled