Tax Codes and Tax Procedures in SAP: Country-Specific, Unified, or Hybrid?
The answer determines maintenance effort, reporting quality, and how flexibly the concept can adapt to new foreign VAT registrations. In this article, I explain the relationship between Tax Codes and Tax Procedures, compare the two classic approaches, and show why a hybrid design is often the best solution in practice.
The Relationship: Tax Procedure and Tax Code
In SAP, the Tax Procedure (also referred to as the Calculation Procedure; technically e.g., TAXDE, TAXAT, TAXGB) is the framework in which the calculation logic for a country's VAT is defined. It determines which tax types (technically Condition Types) are used, the sequence in which they are calculated, which base amounts are used for the calculation, and which Account Keys (and thus G/L Accounts) are posted to.
Figure 1: Structure and Control Data of a Tax Procedure in the SAP System (Transaction OBQ3)
The Tax Procedure is assigned to a country in Customizing (Transaction OBBG), and each country can have only exactly one Tax Procedure assigned to it at any given time.
Figure 2: Assignment of Countries and Regions to Tax Procedures
Every Company Code automatically uses the Tax Procedure assigned to its respective country. The figure below illustrates this relationship. For example, Company Code "1000 - German Samples GmbH" is assigned to Germany. Since country key DE (Germany) is assigned Tax Procedure TAXDE, Company Code 1000 uses TAXDE accordingly.
Figure 3: Indirect Link Between Company Code and Tax Procedure via Country
Within a Tax Procedure, the specific Tax Codes are configured (Transaction FTXP). A Tax Code is a two-character key that users and interfaces select in documents to represent a specific VAT scenario – for example, "Domestic transactions 19%", "Exempt intra-Community supply", or "Reverse charge construction services". The Tax Code inherits the structure and calculation logic of the underlying Tax Procedure and populates the defined conditions with specific percentage rates and Account Determinations.
This hierarchical relationship is essential to understand: A Tax Code only exists within the context of a Tax Procedure. The Tax Code DA in TAXDE is not inherently linked to a DA of the same name in TAXAT – they are distinct objects in separate Tax Procedures. Unless, of course, they are intentionally configured identically (see "The Hybrid Approach" below). This leads directly to the central design question: How many Tax Procedures do I actually want to maintain?
The Country-Specific Approach
The classic approach, delivered out-of-the-box by SAP standard Customizing, is to use a dedicated Tax Procedure for each country. Germany is assigned TAXDE, Austria TAXAT, France TAXFR, and so on. Each procedure contains exclusively the Tax Codes that are relevant for Company Codes in that specific country.
The advantage lies in maximum flexibility, particularly regarding local specifics. If a country suddenly introduces a new split payment mechanism (as in Italy) or a mandatory import reverse charge procedure (as in France), the affected country-specific procedure can be adjusted in isolation without impacting Company Codes in other countries. Rolling out a new country is also conceptually clean: you copy an existing procedure, adapt it, and assign it. Historically evolved systems almost always follow this pattern. At this point, it is important to understand that a Tax Procedure like TAXDE does not only contain Tax Codes for German tax scenarios. If a German Company Code needs to register for VAT abroad (e.g., in Poland), additional Tax Codes for the Polish tax scenarios are typically required within the German Tax Procedure.
The downside becomes evident as soon as individual companies operate in multiple countries and the number of foreign VAT registrations grows. Every procedure must be maintained separately, and during major changes – such as an EU-wide reform like ViDA (VAT in the Digital Age) – the maintenance effort multiplies with the number of relevant countries. A sense of chaos can quickly emerge. For instance, in Tax Procedure TAXDE, the Tax Code DI represents an intra-Community supply from Germany. If a French Company Code now needs to register for VAT in Germany to execute intra-Community supplies from Germany, a corresponding Tax Code is required within Tax Procedure TAXFR. While using DI would be intuitive here, it is not uncommon for this combination to already be in use for a different tax scenario in France. Consequently, another combination must be used. As a result, the two-character code alone is no longer sufficient to uniquely define a tax scenario – it only ever holds meaning in conjunction with its specific Tax Procedure.
The Unified Approach
The countermodel is a Tax Procedure that covers multiple countries – in the EU, for example, a shared TAXEU intended for all EU member states. All relevant Tax Codes reside side by side within this procedure, regardless of whether they represent a German, Spanish, or Dutch tax scenario.
The major advantage is consistency. There is exactly one central location where Tax Codes are maintained, and exactly one logic for condition calculation and Account Determination. For example, Tax Code D1 in Tax Procedure TAXEU stands for "Domestic VAT 19% in Germany". Every Company Code assigned to a country that, in turn, is assigned to Tax Procedure TAXEU uses Tax Code D1 for taxable transactions in Germany at 19%. Corporate groups with Company Codes in various countries and numerous foreign VAT registrations benefit noticeably: in international discussions with colleagues, it is immediately clear what is meant when someone talks about Tax Code D1.
The price for this is a loss of flexibility, even though the scope has been expanded by newly permitted characters. The number of possible Tax Codes within a single Tax Procedure remains fundamentally limited. In addition to the 26 letters (A–Z) and 10 digits (0–9), 10 special characters are now available in the Unicode-compatible hex range: $, ", §, &, _, /, =, ?, ,, ( and # (SAP Note 1225346). This increases the two-character combinations from the previous 1,296 to a total of 46 × 46 = 2,116 possibilities. Local special cases existing in individual countries must be mapped within a common framework, which leads either to a bloated Tax Procedure or to compromises in configuration. A very large namespace of Tax Codes can also become confusing, especially when the two-character key logic is stretched to its limit. Furthermore, not every ERP system or connected Tax Engine scenario works seamlessly out-of-the-box with a cross-border Tax Procedure – this should be verified in advance.
The Hybrid Approach: The Best of Both Worlds
In practice, I recommend a third option that has proven highly successful for many of my international clients. This approach combines the strengths of both models. The idea: Everything that can be standardized internationally – particularly scenarios relevant for foreign VAT registrations – is unified. Everything that is locally specific and typically not relevant for a foreign Company Code with a local VAT registration remains within a clearly defined namespace.
The decisive benefit lies in scalability. New foreign VAT registrations no longer require redesigning the Tax Procedure; they involve minimal effort because the required standard Tax Codes are already defined and only need to be created in the relevant Tax Procedure according to their global definition, if they do not already exist. At the same time, the ability to respond selectively to national legislative changes is preserved without disturbing the overall framework. This approach is particularly valuable for multinational companies with centralized tax departments, as it is immediately obvious whether a Code is a standard Tax Code or one that must be interpreted strictly in the context of its specific Tax Procedure. Furthermore, a greater total number of tax scenarios can be represented across all Tax Procedures. Since only the combinations for the standard Tax Codes share identical settings across all Tax Procedures (in our example, 26 × 46 = 1,196 using a letter as the first character), combinations starting with a digit can be configured individually per Tax Procedure (10 × 46 = 460). Combinations with special characters in the first position are excluded here, serving as a flexible buffer. If five Tax Procedures are in use, this concept provides a total of 1,196 + (5 × 460) = 3,496 individual combinations, compared to the 2,116 combinations available under the strictly unified approach.
Conclusion
The choice between country-specific and unified Tax Procedures is not merely technical, but a strategic decision with long-term consequences for maintenance effort and responsiveness to regulatory changes. The country-specific approach offers maximum flexibility and the highest number of combinations, but can quickly become unwieldy. The unified approach provides perfect consistency across numerous foreign VAT registrations, but imposes the greatest restriction on the number of available Tax Codes. The hybrid approach – standardized Tax Codes for all standard tax scenarios combined with a clearly defined namespace for local specifics – combines the best of both worlds and has proven particularly effective for multinational companies whose SAP System Customizing is managed centrally, for example by a dedicated Tax Technology Team. Anyone redesigning their SAP Tax architecture as part of a migration to SAP S/4HANA or consolidating multiple legacy systems into a single SAP system should address the choice of the Tax Procedure model early on – evaluating not only their current country footprint, but also keeping the next five years in mind.
Future-Proof Your SAP Tax Architecture
Whether you are planning an S/4HANA transformation, system consolidation, or international expansion: we bridge the gap between tax strategy and deep SAP technical expertise. The team at kallman helps you design a tailored, scalable tax architecture for your global system landscape.
 Adam Dubielecki Partner |