Chain transactions are one of the more complex constructs in sales tax law and often a stumbling block in the sales tax return. Errors in location determination can lead to temporary double taxation, especially in the case of cross-border transactions, and of course, to expenses for the correction of these cases.
What does the Highlander have to do with chain transactions?
Saying it simple: it is a series of three companies concluding a turnover for the same product. Besides, this product is transferred from the first to the last company.
For such a chain transaction, the right location determination is of decisive importance. Because it plays a primary role in which of the deliveries the “moving delivery” is, in the sense of turnover tax. According to 3.14 para. 2 UStAE, “The carriage or dispatch of the object …is only to be assigned to one of the deliveries (§ 3 para. 6 sentence 5 UStG). Only this delivery is the transport or dispatch delivery. Only in this case can the tax exemption for export deliveries (§ 6 UStG) or for intra-Community deliveries (§ 6a UStG) be considered”. In summary, it is vital to know the moving delivery of a chain transaction with an EU or international reference.
How does SAP support these sales tax issues?
By default, sales tax in SAP systems is determined on the basis of the following criteria:
- departure country,
- destination country
- customer classification (company or private individual)
- type of material (usually for the correct tax rate)
- sales tax ID (for transactions within the EU)
The so-called “condition technique” is used here – a term for the programmatic mapping of tax rate determination in SAP systems. The control keys maintained in the master data table T007S are determined by the program logic and transferred to the accounting-relevant tables, such as BSEG (field MWSKZ – control key, MWSTS – tax amount in local currency). The way to do this is sophisticated and not easy to grasp because of the different possible combinations.
This already existing complexity is further increased by the manual influence of SAP users, e.g. when creating a sales order. For example, you can maintain the departure country, destination country, and the indicator for an EU triangular transaction. No matter how neatly programmed a system may be, it can be countered here – often due to a lack of knowledge of the legal situation.
Why do decision trees help with sales tax?
Decision trees are based on graph theory – a branch of mathematics. Many algorithmic problems can be represented as graphs that contain nodes and edges. You may have heard of the “traveling salesman problem” before. For example, this can be modeled as a graph and then applied to corresponding optimization methods.
The advantage of decision trees lies in the reduction of complexity through the graphical representation of discriminating elements of a data set. In a decision tree containing sales tax, the country of domicile of a company, the place of delivery as well as the tax rate can be found. Trained users use these criteria to question the sales tax assessment and correct it if necessary.
How does this work in practice?
In the test data set used in this article, parameters such as the customer’s country of domicile, place of delivery, country of departure of the delivery/service, type of material (finished product, service, raw product, semi-finished product), the customer’s existing VAT ID, etc. are used. The lowest level in this decision tree ultimately shows the SAP tax code – the tax treatment of the business transaction.
For the used test data record, the decision tree looks the following:
What stands out here:
A total of 7,580 business transactions have been analyzed. The tax code that appears most frequently is AN. Looking up the abbreviation in SAP, “AN” stands for “Domestic output tax”. And on the far left under “DE” (Germany as the customer’s country of domicile), with 4,669 transactions, all transactions with the AN control key are listed. As a result, all business transactions within Germany were treated equally. Therefore no anomalies are found.
Under “CA” there are 11 transactions. All transactions to Canada are marked with the tax code D9 and therefore represent tax-free (export) deliveries for sales tax. This item is also uniquely classified and no longer relevant.
The business transactions with customers in the Netherlands (destination country “NL”) are exciting. There are a total of 16 transactions here:
- 6 with the control key “A9”.
(Output tax 0% Export third countries) - 3 with the control keys “A0,A9”.
(A0 – output tax 0% / A9 – output tax 0% export third countries) - 2 With the control key “D9”
(tax-free (export) deliveries)
Further detail is given here if the delivery location is considered to be the next level.
For six transactions in Germany “DE”, the customer is located in the Netherlands, but the delivery has gone to Germany, which is marked with different tax codes. Even the deliveries to NL – the Netherlands – do not present a unique picture. In total, these 16 deliveries are candidates for the following four possible processes, in which options 1 and 3 would be classified as series transactions. Here, a company D2 based in Germany ordered goods from a Dutch company (NL), which in turn ordered them from our company D1 based in Germany. option 1 of this product is delivered directly from customer D1 to customer D2, i.e. within Germany.
Option 1
According to the Highlander principle, the moving delivery from D1 to NL is to be assigned. The delivery from NL to D2 is stationary. As a result, both deliveries are taxable in Germany – the mapping in the SAP system with a control key A0 (output tax 0%) – must be questioned here.
Option 2
There are two deliveries for option 2. These are not series transactions, but “normal” individual transactions in which the delivery to NL by our company D1 is tax-free. If necessary, it concerns such a procedure – also here applies: look is worthwhile itself.
In the following two options, we exchange the final customer with the entrepreneur in the middle. NL thus moves to the end and D2 to the center.
Option 3
There are two deliveries for option 3. As in option 1, this is a series transaction. The moved delivery is assigned to D1 to D2. For our considered company D1, this leads to a tax-free intra-Community delivery. The delivery from D2 to NL is taxable in the Netherlands. But it raises the question: why was A9 (output tax 0% export third countries) defined in addition to tax code A0 and what is hidden behind the term “export third countries”.
Option 4
There are two deliveries for option 4. Similar to option 2, this is not a series transaction, but a “normal” single transaction, in which the delivery from our company D1 to D2 is subject to tax. Therefore you might ask why tax code A0 exists.
Conclusion
As a result, decision trees make it easier to determine where it is worthwhile to look. Conspicuous events and corresponding business transactions can be identified, investigated and corrected quickly and correctly with the help of the facts regulated by law.
