Companies in Europe can have warehouses in multiple countries. Examples are consignment stock at a customer, toll manufacturers in another country or just having a warehouse close to the customers to have the shortest possible delivery times. These customers typically do not have a business / legal entity in those countries. Since there is free movement of goods in the European Union, this occurs more and more. Also with the product growing rapidly towards the enterprise market we see more and more customers with warehouses in different member states of the European Union. In most cases within the European Union, you must register for sales tax in that specific country if you ship goods to and sell from a foreign warehouse. An example. A Dutch company has a manufacturing plant in the Netherlands, but they also have a warehouse in Southern Germany to be able to deliver to every destination in Europe within a day's truck drive. In this case the company is legally located in the Netherlands, but they hold sales tax registration numbers in both the Netherlands and Germany. This leads to the following scenario's. If they replenish the German warehouse using a transfer order this has to be declared for both Intrastat and Sales tax. Intrastat functionality supports the transfer order. However the transfer order is no input for sales tax declaration nor EU sales list. The goods are moved from their Dutch Sales tax registration number to their German Sales tax registration number. If they continue to sell to a German company from the German warehouse this has to be calculated as domestic German sales tax and they have to register and declare this on their German Sales tax number. Current functionality is not able to determine the correct Sales tax group based on the customer master data. This customer has been setup to be serviced from the Dutch warehouse, so the setup on the customer master will trigger a sales tax calculation as if the goods were shipped from the Netherlands to Germany. The sales tax group has to be changed manually which comes with a big risk on picking the wrong value or just forgetting to think about changing the value. It would be ideal if the sales tax group would also be determined by the location of the warehouse where the goods are shipped from. If they sell to an Austrian company from the German warehouse, this has to be calculated as a German EU trade transaction, to be declared on the German Sales Tax number and the German EU sales list at the German tax authority. However, by default this customer has been setup for shipment from the Dutch warehouse. Despite the fact that we are able to setup multiple tax authorities in the system, this doesn't tick all the requirement boxes. A lot of sales tax settings are on the legal entity level and not on the sales tax authority level. An example is conditional sales tax, this means sales tax has to be declared when the invoices are paid. This applies for France and can only be set on a legal entity level. Another example is the EU sales list. This is based on the list of countries as specified in the foreign trade parameters. However, if a country is domestic, "other EU member state" or "rest of the world" can only be set up from the point of view of the legal entity address whereas the legal entity is located in multiple countries for the sales tax. Sales tax and intrastat functionality is supported by localizations that are enabled on the legal entity level. This mean that a Dutch company can only use the Dutch localization features for sales tax and intrastat functionality and declarations. This means that they lack the functionality to electronically declare sales tax, EU sales list and Intrastat in all other countries apart from the Netherlands. Finally, scenario's in which the goods are shipped from another country then the country in which the legal entity has it's primary address are not supported well. Sales tax is dependent on the country which the goods are shipped from, the country where the goods are shipped to and the delivery term. The functionality is highly needed on sales and purchase orders. Projects would also be nice, but this is a less common scenario. A basic overview of the requested functionality would be - Be able to setup multiple Sales tax registration numbers so the correct number can be mentioned on the sales orders, most likely on the sales tax settlement period or the tax authority - Correct determination of the sales tax group on purchase and sales order lines based on the country where the goods are shipped from, country which the goods are shipped to and the delivery term. Also the list code should be determined based on these parameters to ensure a correct EU sales list - Adjust the summary update parameters to prevent sending out an invoice with sales tax calculated for multiple sales tax registration numbers - Move some of the sales tax settings and localization features from the legal entity level to the tax authority level. An example is conditional sales tax on the sales tax tab of general ledger parameters. - Move almost all settings from the foreign trade parameters in the tax module to a lowel level to be able to support multiple EU sales lists and intrastat declarations from one legal entity I am more than happy to discuss further details and to participate in the next steps. Kinds regards, Jasper Schram
Comments
Hello Community,This scenario is already supported by this feature Tax Calculation overview - Finance | Dynamics 365 | Microsoft Docs and quite a few implementation projects already use the feature in Production. If you need any support from Microsoft, please raise the questions in this Yammer Group Yammer : Dynamics 365 and Power Platform Insider Program : Tax Calculation Service : All Conversations. Thank you!
Category: Tax
Has anyone managed to put this in production or at least working on a test system?Sorry, but Docs on this issue are 0% helpful and we're receiving zero support from MS for this...
Category: Tax
Hello everyone, is there are feature already available to support above described scenario or is this solution still in pending status? I am faced with a similar scenario on my implementation project. Any help on this topic would be useful. Kind regards.
Category: Tax
This indeed is a real-must have.
The fact that a lot settings are defined on entity level remains a big problem.
I can add another example to the long outstanding list of issues:
In some countries, when working with cash discounts, the cash discount is deducted from the sales tax calculated. In other coutries, the cash discount is not deducted from the sales tax calculated on the invoice.
The parameter for this is defined on entity level ('Deduct cash discount before sales tax calculation').
We had to customize this to have a compliant invoicing proces & a correct VAT declaration...
Category: Tax
I like the concept with the registration ids in general but I'm heavily disappointed with the poor implementation in terms of eu sales list.
From a birds view it seems to be pretty easy to finish the last mile.
Category: Tax
Hi Jasper,
Thank you for posting this idea. The solution to your request should cover also the principle of "Permanent Estabilishment" for the verification of the presence of the tax payer in a country and, consequently, for the acknowledgement of the subject of the taxation (art. 5 - 7 OECD MC). As far as Italian Tax Code definition of Permanent Establishment can be found in article 162 of TUIR (Testo Unico delle Imposte sui Redditi).
As a consequence, we should manage VAT Report and Tax returns in the foreign country where we have the PE, despite the fact that the PE is not a separate legal entity.
Furthermore, our legal entity is fixed in Italy and for this reason we must consider costs and revenues of the PE in the financial statements published by the Italian legal entity.
Category: Tax
This is a very good suggestion and should be part of the Microsoft solution. It avoid customizations to meet legal requirements
Category: Tax
For customers in the EU, it is really an important requirement to be compliant with the EU rules for Tax and Goods transactions! Hopefully we can see a solution for this issue forward.
Category: Tax
This is really important, hopefully MS can solve this soon.
Category: Tax
I have seen this exact issue as well. I considered creating VAT registration number at the warehouse level but that would only solve issues like being able print the correct the correct VAT number for Sales and Transfer order documents. I also looked at the registration ID's but they are not intended to work with the Sales tax/VAT system.
A total solution for this would need to look deeply at TAX reporting as well, EC sales list, as well as system functionality like summary update (consolidated invoices) to ensure shipments/transfers from multiple tax authorities are not combined in a single update/document. This will be hard to change but how do user companies handle this today. It is very common for companies to have multiple VAT registrations (especially if you only do purchase in that country but not sales, then you claim the input VAT) They must be calculating their VAT manually then, to try and get it right.
Category: Tax
Administrator on 10/29/2021 7:43:44 AM
See our latest announcement of Tax Calculation service Tax calculation enhancements are now available for Dynamics 365 - Microsoft Dynamics 365 Blog. It works for this idea.
Sincerely,
PM, Eric Wang
Microsoft.