A Standard for decades

The automated determination of tax codes in the SAP SD sales module, also known as “tax determination”, uses rules to decide how a business transaction should be treated for VAT purposes. Automating the tax valuation of transactions reduces the workload for the sales team, minimizes human errors, and ensures consistent tax valuations. The underlying rule set is technically based on SAP's condition technique, which uses condition tables to derive output parameters (tax codes and tax rates) from input parameters (e.g., departure and destination country, as well as material tax classification and customer tax classification). Just like for many other price components that are mapped using condition types, SAP also offers sample solutions for the calculation of VAT. In this article, I will present various options for configuring tax determination in the SAP system. Please note that the content of this blog article is intended solely for the technical consideration and description of VAT configuration options. This article does not constitute tax advice and does not replace individual advice from tax experts or lawyers. Even though SAP announced the end of maintenance several years ago, many companies today still use the system version “SAP ERP Central Component”, or “SAP ECC” for short, which was introduced in 2005. As with its predecessor SAP R/3, the condition type “MWST” is at the heart of output tax determination in SAP ECC. The logic of the “MWST” condition type and the functionality of the access sequence of the same name are explained below.

Figure 1: Access sequence MWST

Figure 2: Condition tables of access sequence MWST

The access sequence “MWST” uses the three sample condition tables 002, 011, and 078. Basically, the search for a suitable condition record is performed by sequentially processing the condition tables in the stored order, beginning with table 078. However, whether access actually takes place can be dependent on a pricing condition within an access sequence. In the access sequence MWST, each access is linked to either condition “7” or “8”, as can be seen in Figure 1. In the standard configuration, condition records for domestic scenarios are maintained in table 002 under condition “7”, while those for cross-border business are maintained in table 011 or 078 under condition “8”. The check of these two conditions includes a comparison of the departure country and destination country of the respective document item.

Let's take a closer look at the conditions:

• Condition 8 is essentially fulfilled when the two countries differ from each other. If the country of departure differs from the country of destination and both countries are EU member states, it's also checked whether a VAT registration number could be found in the customer's master data that is applicable to the scenario of the current sales document.
• Condition 7 is considered fulfilled when the departure country is identical to the destination country. The check is also positive if both countries are different EU member states and no VAT registration number could be determined for the customer in the current sales document.

Access to table 002 "Domestic Taxes" is therefore not exclusively for domestic transactions. Even cross-border transactions within the EU, where the customer cannot provide a VAT registration number (keyword: substantive law requirement), are treated by the logic of the sample configuration as a domestic scenario for valuation purposes. For example, if a company delivers goods from Germany (departure country) at the regular tax rate to an EU customer for whom the system cannot find a VAT registration number, the rule for determining deliveries within Germany is applied based on table 002. As a rule, a condition record with a tax rate of 19 percent is stored for this scenario. At this point, the question arises whether this system behavior is desired. It may be in the interest of the tax department to first consult with the customer in such a situation before issuing an invoice with German VAT.

Condition 8 is used for access to both table 011 and table 078. Given this, it's worth questioning why the standard configuration provides two separate tables for cross-border scenarios. In my consulting experience, the majority of rules for cross-border transactions are typically mapped via table 011. This table considers the fields departure country and destination country, as well as the customer tax classification (CTC) and the material tax classification (MTC) of the business transaction. In contrast, condition records are rarely maintained in table 078. The reason for this is that this table only considers the departure country and destination country as input parameters, but not the customer tax classification or the material tax classification. Only in exceptional cases can these parameters be disregarded during valuation. An example of this exceptional case is often the use of the MWST access sequence for the transfer of goods from one EU country to another using the "Plants Abroad" functionality.

A New Sample Condition Type in S/4HANA

Let’s now look at the options the SAP system has provided since the introduction of the fourth system generation, SAP S/4HANA. To begin with, the condition technique itself has not been changed. The functionality of the condition types, access sequences, condition tables, and tax codes continues to be based on the proven principles of previous system generations. However, S/4HANA is delivered with new configuration proposals, depending on the exact version number. For VAT determination, S/4HANA offers the condition type TTX1 as an alternative to the condition type MWST whereby TTX1 corresponds to a new naming convention that SAP introduced with the latest system generation for condition types. Like MWST, the condition type TTX1 also has an access sequence of the same name. When comparing the access sequence TTX1 with the access sequence MWST, similarities can be found. TTX1 also uses tables 002 and 011. In contrast to MWST, however, the access sequence TTX1 forgoes the use of condition table 078. TTX1 was supplemented with condition table 165 compared to its predecessor.

Figure 3: Access sequence TTX1

Just like condition table 011, condition table 165 has the input fields departure country, destination country, customer tax classification, and material tax classification. In addition, table 165 provides the "Billing Type" field as an input parameter.

Figure 4: Condition table 165 contains, among other things, the field billing type as an input parameter.

This means that rules can be maintained in this table that only apply if the document has the billing type stored in the condition record. As the name of the parameter suggests, it is suitable for identifying specific types of billing documents. This functionality is useful, for example, in the case of down payment requests that a company sends to EU customers. Without going into the legal requirements in detail at this point, it should be noted that, according to §18a of the German VAT Act (UStG), a delivery to another EU member state must be recorded as an intra-community supply in the recapitulative statement. However, this does not apply to a downpayment requested from a customer in relation to a future delivery. In SAP SD, down payment requests have the billing type "P". With condition table 165, you can have a tax code without an EU indicator determined for documents with billing type "P". Due to the exclusive indicator, the search is terminated if a condition record is found in table 165. In all other cases, for example, for tax determination for the final invoice, the system will not find a match in condition table 165 and will continue the search in table 011. The described approach is based on the principle of first checking for possible special cases and then applying the standard case. If the billing document does not have the billing type maintained in table 165, the tax code is determined for all other billing types. Based on the system version, additional access sequences are available as templates in SAP S/4HANA. The TTX2 access sequence builds on TTX1. For instance, tables 002, 165, and 011 are found in accesses 90 to 110. In accesses 10 to 80, TTX2 also includes condition table 166 in the tax determination. In addition to the input fields known from condition table 165, table 166 contains the region of the supplying plant and the region of the ship-to party. These additional fields make it possible to create rules not only for combinations of departure country and destination country, but also specifically for individual regions.

Figure 5: Access sequence TTX2

The reason for the introduction of table 166 and the TTX2 access sequence was the then-new regulations of the Northern Ireland Protocol, as explained in SAP Note 3005574. The Northern Ireland Protocol states, among other things, that deliveries to businesses in Northern Ireland are to be treated like deliveries to an EU member state even after Brexit, while deliveries to the rest of the United Kingdom are to be evaluated as deliveries to a third country. In the SAP system, Northern Ireland cannot be identified by its own country code. The code "GB", valid for the entire United Kingdom, is found in the addresses of Northern Irish business partners. It's only possible to recognize Northern Irish business partners at the region level. Tax determination allows for this distinction, for example, by using condition table 166 as presented above. To treat the Northern Irish regions differently from other regions assigned to the country code "GB", a distinction is also required at the condition level. For this purpose, SAP delivers conditions 88 and 89 with the TTX2 access sequence.

• Condition 89 serves to identify cross-border transactions. Compared to Condition 8, 89 considers Northern Irish regions as part of the EU and requires the presence of a VAT registration number to be fulfilled.
• Condition 88, similar to Condition 7, covers transactions that take place within a single country. Furthermore, Condition 88 is considered fulfilled if the region of departure or destination is Northern Ireland, but no VAT registration number is available.

Access to condition table 166 is made with different combinations of input fields, with some fields partially excluded. This makes it possible, among other things, to create condition records so that the region is maintained either exclusively for the departure country or exclusively for the destination country. For example, if a condition record is to regulate the taxation of a delivery from an EU member state to Ireland, the region is only relevant for the valuation on the side of the country of destination. This is a clear example of how complex logic can be mapped with skilled use of the Condition Technique, without necessarily having to create condition records for every relevant field value combination. As mentioned at the beginning, TTX2 also includes condition tables 002, 165, and 011. This means that rules can also be created without considering the region. Since these tables are called after 166, the principle is once again applied that it is first checked whether a special case, in this context a region-specific one, exists. If this is not the case, the general rules apply. Furthermore, younger releases of SAP S/4HANA contain the access sequences TTX3 and TTX4, which can be assigned to the condition type TTX1 as an alternative. These access sequences are intended for mapping cross-border stock transfers. Mapping cross-border stock transfers in the SAP system is a complex topic, the detailed explanation of which would exceed the scope of this article. In a future article, we will deal with it in detail.

Conclusion

With the condition type TTX1, SAP is replacing its long-standing proposal for a tax determination configuration, the condition type MWST, along with its access sequence. Condition table 078, which is likely rarely used in practice, is now being omitted. Instead, TTX1 offers a solution for the differentiated handling of various billing types, which can be quite useful, for example, in the case of down payment requests to EU customers. With the TTX2 access sequence, SAP also offers an adequate solution for the requirement brought about by Brexit to differentiate at the region level during tax code determination. Based on the innovations presented, it is, in my opinion, worthwhile when switching to SAP S/4HANA to check whether the configurations offered in the current system generation are preferable to the old MWST sample solution. If you find that the condition type still meets your company's VAT requirements, you are, of course, free to integrate the familiar MWST into the new pricing procedures. Finally, it should be noted that the configuration delivered with the system can usually not meet all of a company's VAT requirements for tax code determination. Thus, the sample configuration in many cases merely represents a starting point for an individual tax determination logic.

Need support?

The kallman team has already supported numerous companies in implementing individual configurations for tax determination.

Lars Bohn Partner	Does your company need support with adapting the SD tax determination or advice on VAT topics in SAP? Do you have questions about this article? Contact us - we look forward to hearing from you. Contact Us