0003063: Sales tax: Buyer-origin tax rules - Composr CMS feature tracker

ID	Project	Category	View Status	Date Submitted	Last Update

0003063	Composr	ecommerce	public	2017-02-03 15:14	2017-03-25 20:47

Reporter	Chris Graham	Assigned To	Chris Graham
Severity	Feature-request
Status	resolved	Resolution	fixed
Product Version
Fixed in Version

Summary	0003063: Sales tax: Buyer-origin tax rules
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.
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.
Tags	No tags attached.

Time estimation (hours)	16
Sponsorship open

Chris Graham 2017-02-14 21:56 administrator ~0004791 Last edited: 2017-02-14 22:02 View 2 revisions	Add config options for broken down business address (This probably replaces the invoicing address config option I added recently). 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.

Chris Graham 2017-02-15 12:04 administrator ~0004792	form_input_tax form input element, that has separate radio button + field for each tax input type 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

Date Modified	Username	Field	Change
2017-02-03 15:14	Chris Graham	New Issue
2017-02-03 15:42	Chris Graham	Additional Information Updated	View Revisions
2017-02-03 16:16	Chris Graham	Description Updated	View Revisions
2017-02-03 16:16	Chris Graham	Additional Information Updated	View Revisions
2017-02-03 16:17	Chris Graham	Additional Information Updated	View Revisions
2017-02-03 17:47	Chris Graham	Additional Information Updated	View Revisions
2017-02-12 00:29	Chris Graham	Relationship added	has duplicate 0002949
2017-02-14 21:56	Chris Graham	Note Added: 0004791
2017-02-14 22:02	Chris Graham	Note Edited: 0004791	View Revisions
2017-02-15 12:04	Chris Graham	Note Added: 0004792
2017-03-09 15:14	Chris Graham	Relationship added	related to 0003120
2017-03-25 20:47	Chris Graham	Status	non-assigned => resolved
2017-03-25 20:47	Chris Graham	Resolution	open => fixed
2017-03-25 20:47	Chris Graham	Assigned To	=> Chris Graham