Richard Cornelisse

SAP add-on: never run out of tax codes

In Indirect Tax Automation, Indirect Tax Strategic Plan, Processes and Controls, SAP add on, SAP add on for VAT, SAP for VAT, SAP SLO renaming tax codes, System Landscape Optimization, Tax News, Technology, VAT automation on 15/09/2014 at 4:02 am

Multi billion Euro companies operate with Taxmarc™ Tax Code solution already for many years

Many SAP clients have multiple VAT registrations (in 10+ countries), principal structures, complex business model for sales of goods, cross-border, drop shipment, shortage tax codes (use of 900 + SAP tax codes) and centralized functions.

These organizations will face difficulties to solve the shortages of tax codes issue causing not only tax compliance, but commercial issues as well.

SAP developed a CDP solution on a 4 digit tax code. We understand that this SAP 4 digit tax code solution will not be rolled out to other customers because of risks around the stability and robustness of the solution.

This means that multinational companies still have limited options when facing issues with the limited number of available tax codes.

Alternative market solutions

  • Use the special characters ($,/,\,& etc.) for the tax code – even with the extended number of tax codes some companies will be running out of available tax codes and tax codes with these special characters are not user friendly to work with.
  • Purchase external tax engine – besides high purchase and maintenance costs as external interface have to be used for certain clients it is in conflict with own IT policy as use of standard SAP is preferred
  • Renaming of tax codes exercise (SLO projects) – downside is that in the future due to global VAT change increases a company will face shortages again

How can above downsides be avoided?

Taxmarc™ has developed – an integrated SAP solution that uses a time stamped rates for tax codes. As a result the tax code structure will always remain the same. The advantage is that SAP tax codes structure does no longer require changes and that maintenance costs and involvement of IT is reduced significantly.

Business case

A single VAT rate change could take (set up, transports across the SAP landscape and test cycles prior to production) about 200 – 300 hours. After implementation this is reduced to 2-3 hours and in order to calculate hard savings the surplus has to be multiplied by the amount of VAT rate changes expected.

How long does this process take within your organization and what will be the amount of annual saving (i.e. Return on Investment period)?

Proven solution: all our Taxmarc™ solutions are ‘implemented’, ‘tested’ and ‘in production’ for many years. This product have been implemented by several listed multinationals and are our client reference for Q&A. One customer has an annual revenue of approximately $36 billion and operations in more than 80 countries.

The solution also covers the important iDoc processes within this type of business with many intercompany transactions.

benefits tax codes

Renaming exercise of tax codes via System Landscape Optimization

One of SAP’s offerings are SLO (System Landscape Optimization) projects. For indirect tax that could mean a renaming exercise of tax codes – SLO renaming project – to set up a more logical tax code structure in which the different tax categories in each country will have the same meaning.

The result should be: a logical grouping of the various VAT tax codes in all countries. Such logical re-design of the tax code structure allows centralization of functions regarding indirect tax compliance in Shared Services Centers, as well as implementing control measures in an efficient and effective way.

This leads to substantial cost savings and improved indirect tax risk management.

The objectives of SLO projects are:

  • Align organizational structures and processes at the system level to meet the needs of corporate restructuring
  • Align with best practices and IT strategies to realize data harmonization and process optimization
  • Reduce IT complexity and centralize disparate IT solutions

SAP’s approach

The SAP approach for SLO projects regarding the tax code structure is not the most effective and efficient way. In order to keep the historical audit trail, the old active tax codes are duplicated and renamed often with the use of special characters ($,/,\,& etc.).

That causes not only an increase in tax codes but as well a potential shortage of tax codes when in the future country specific tax procedures are used.

As the company’s objective is a logical tax code structure, the use of these special characters ($,/,\,& etc.) does not meet that objective when investigation of historical audit trail is needed (e.g during a tax audit).

Our Taxmarc ™ approach

Taxmarc™ uses a different approach to perform such SLO renaming exercise of tax codes.
In our method, for the old active tax codes no new tax codes have to be set up as this will also follow the new tax code logic.

That means the renaming is no longer causing an extra increase of tax codes and that both ‘old active tax codes’ as new ‘renamed tax codes’ will follow the same logic and use of special characters ($,/,\,& etc.) is avoided.

Taxmarc ™ Time Stamped designed Tax Codes

In addition to such SLO renaming project, Taxmarc™ has also developed as describes above  a separate solution: Time Stamped designed Tax Codes. That is beneficial when a company would like to keep the current logic also in case of new VAT rate changes.

Downside of the SAP SLO renaming tax codes is that in the future due to global VAT rate changes the overall designed logic will no longer apply in all cases and could in certain cases cause a risk of tax code shortages.

The advantage of this ‘Time Stamped’ solution is also that such a VAT rate change can be implemented beforehand, takes no longer than 2 hours max to set up and has thus a quick Return on Investment.

Taxmarc™ SAP solution2

High level comparison between LRD, Commissionaire and Agent

In Audit Defense, Business Strategy, Indirect Tax Automation, Indirect Tax Strategic Plan, Processes and Controls, SAP add on, SAP add on for VAT, SAP for VAT, Technology, VAT automation, VAT planning on 07/09/2014 at 2:20 pm

If the reason of a business model change is to optimize company’s effective tax rate (tax opportunities), minimizing cash tax effect or cost reduction or realize efficiency overall such standardizing business processes, it is important that with regard to managing such change the indirect tax functions is timely involved (design phase) and also ascertains that proper implementation and executing of indirect tax planning has been taken place. That means that indirect tax issues should be addressed up front during the design phase.

Any change has impact on current processes and controls and its effectiveness. Business model change such as centralized operating model result often in an increased number of transactions and indirect tax obligations across many geographies.

Operational changes have a tax consequence due to the change in transactional flows and the change in a company’s assets, functions and risks profile. Important is to ensure that the new operating model is not only implemented correctly from a tax perspective, but also ensures that business processes are tax aligned realizing support of the business in the areas of compliance, finance & accounting, legal IT systems, indirect tax and regulatory matters. That means teaming is a necessity with with various work streams.

In many Asian countries the Commissionaire concept is not known. In several Asian and Latin- American countries centralized ownership of raw materials, work in progress and finished inventory is not possible. In most countries outside Europe having to register for VAT/GST/Consumption Tax will often results in a full taxable presence, including a liability for Corporate Income Tax.

One of the key processes relate to ERP system. A wrong perception in the design phase can lead to substantial tax and commercial risks. It could also impact the company’s reputation as also customers, suppliers, external auditor, senior management, tax authorities could become stakeholders when it goes wrong.

A condition for success of any ERP solution is involvement by the indirect tax department in design phase, teaming with other workstreams.

The change of a business model can create not only VAT risks, but as well commercial risks such as logistics problems in getting goods into a country and delays and hold off of shipments resulting in disruption of daily business. Some root causes: the company forgot to register for VAT or procurement forgot to agree with supplier who was importing the goods.

SAP change: the perception of Plug And Play

For ‘simple’ business models (AB scenario’s) standard SAP functionality works.

However when business models are more complex, standard SAP VAT functionality is insufficient due to the company’s business model, organizational structures and/or VAT requirements. To manage the correct VAT treatment additional features need to be implemented.

In practice, configuration – the amount depends – is needed when companies deal cross border and/or complex business model are set up such as a centralized principal structure with for example “Limited Risk Distributor” or „Commissionaire”. The latter also known as principal-toller-agent model (PTA).

The company’s principal bears – contractually – from a business deal perspective the major risks (business responsibility). Principals are in the main rule still owner of the goods when these are sent to customers. For corporate tax reasons, such principals have their residence in low tax countries.Tollers are manufacturers that produce on behalf of other parties (e.g. the principal). The toller receives as consideration a tolling fee.

Commissionaires only act as intermediaries to the customers. The principal pays them a commission fee. In a strip-buy-sell model not an agent but a reseller (LRD) is part of the supply. The difference is that a resellers becomes owner of the goods.

VAT Automation of complex business models

In the last decade, companies have increasingly automated their business processes. The most common method is by using an Enterprise Resource Planning (ERP) system. Such a set up can be hugely complex. This is definitely the case where it relates to European based indirect tax. As manual processes are subject to human error, automation could – under circumstances – result in performance improvements and savings.

There are all kinds of business reasons for setting up such centralized models. The challenge from an implementation perspective is indirect tax.

What Makes It Complex?

LRDs and Commissionairs have neither legal ownership to the inventory during storage nor during transport as the Principal is at that stage still the legal owner. It is often the case that the Principal delivers the goods physically and directly to the final customer.

This creates only one physical departure of goods (`goods issue’) in the ERP system. However, two invoices should be raised (one from Principal to LRDs/Commissionairs and one from the LRD/Commissionaire to the final customer.

In the ERP system, the correct ‘ship from’ information at the LRD and Commissionaire level is missing so that the VAT treatment by the system is determined based on the ‘ship from’ and ‘ship to’ information present at the Principal level. In principle, for cross-border transactions this results in the incorrect VAT treatment.

Therefore, in practice, it is time consuming to correctly configure the ‘tax determination logic’ set up. You need to know your practical workarounds, preferable in the design stage.

Even more bottlenecks in case of a commissionaire structure

A “Commissionaire Model” has some more bottlenecks. Since according to civil law, the “commissionaire” does not have ownership, the commissionaire does not own any inventory not even temporarily. That is different with the LRD as a LRD becomes owner via flash title for a very short period.

A “commissionaire” is never the legal owner of the goods. From a VAT perspective, the commissionaire however acts as though he was the owner and a fictitious supply takes place to and subsequently by the commissionaire. The commissionaire has to issue invoices in his own name which can create problems if there are no bookings with respect to inventory.

High level comparison between LRD, Commissionaire and Agent

A sales Principal located in non-EU country will create more complex registration and trading issues. VAT treatment for Commissionaires and LRDs in principle similar (buy and sell), but with different legal flows.

A LRD creates opportunity to have local inventory on LRD books, provided all relevant aspects have been resolved. Different accounting rules exist for LRDs compared to Commissionaires.





Once a commercial and tax-efficient structure is determined—one that addresses both historical and potential risk—it is time to take the theory behind the structure into the realm of practice.

Will using a classic principal structure in the new entity help keep maximum profits in low tax jurisdictions? If so, one entity will own title to inventory throughout the various jurisdictions and the principal would require a VAT registration in each location where inventory is held.


In some countries, particularly Asia and Latin America, a VAT registration will crystallize a permanent establishment for corporate income tax purposes. This could mean for example an increase in the US corporation’s foreign tax compliance obligation and could increase the amount of tax due as well as the workload.


From Global Indirect Tax Management by Richard Cornelisse

SAP and ABC transaction with drop shipment

In Benchmark, Indirect Tax Automation, Indirect Tax Strategic Plan, Processes and Controls, SAP add on, SAP add on for VAT, SAP for VAT, VAT automation on 29/08/2014 at 3:32 pm

If the aim of an organization is full VAT automation of AP and AR, it is important to understand what exactly makes standard SAP not functioning optimally from an Indirect Tax perspective. Only then it is possible to validate whether company’s objectives can be achieved with upgrading standard SAP functionality and/or implementing a tax engine.

For a correct VAT determination of a cross border chain transaction the VAT relevant data of company code A and B has to be linked real time as Standard SAP itself is only processing a transaction within one specific company code.

SAP and bold-on tax engines exclusively focus on transactions within a single company; it only assesses the underlying individual transactions and fails to link the current transactions to the VAT results of previous transactions. As a consequence, companies with VAT registrations in different countries cannot automatically comply with all VAT obligations.

To realize such ‘birds eye’ view the tax logic should be based and generated on a higher SAP’s hierarchy: at client level combined with implementing the basic tax rules into the logic. Client level includes all the company codes working on the same SAP platform.

Without that approach: the ‘Garbage In’ and ‘Garbage Out’ principle will apply.

Case Study

The business models of many enterprises have radically changed over the last years and have become increasingly complex. SAP, however, has failed to keep up, which has resulted in the standard functionality of SAP being no longer sufficient for complying with VAT obligations.

Practical solutions must be found within the flexibility and static organization of SAP regarding indirect tax. Because of this, SAP Indirect Tax Consultants in the market can only patch up the existing SAP framework (e.g. ‘hard coding predefined VAT treatments’, see below).

  • Cross-border chain transactions with third parties or within a group of company (intercompany transactions) have become the rule rather than the exception
  • For example goods are sold twice but only are shipped once. Standard SAP VAT determination logic and functionality for VAT determination does not work for complex dynamic business models (e.g. Principal-Toller-Agent model) with for example multiple VAT registrations, pick up and drop shipments, chain transactions between legal entities (ABC / ABCD scenarios)
  • Tax logic should in those circumstance be based and generated on a higher SAP’s hierarchy: at client level combined with implementing the basic tax rules into the logic. Client level includes all the company codes working on the same SAP platform

Below you a case study re cross border intercompany transactions. It is representative for overall Standard SAP weaknesses from an indirect tax perspective.


Hard coding predefined VAT treatments

One of the solutions is to work with assumptions and to implement these in the system (hard coding of transactions via a predefined VAT treatment). This means that a VAT treatment is no longer deduced using information present in the system. Assumptions may be incorrectly implemented during the actual execution or may undergo a change after “going live.” An incorrect VAT treatment is the potential risk.

If such solution is used, periodic audits as detective control need to be set up since the risks at hand will likely exceed the company’s risk tolerance. This results in extra man-hours, representing additional costs du to rework and retrospective corrections.

An important question to raise for sound business decision process is what tools are available in the market for still achieving full automation without making use of assumptions and determine the VAT treatment on real time data in the system.


From Global Indirect Tax Management by Richard Cornelisse and Robbert Hoogeveen


Get every new post delivered to your Inbox.

Join 148 other followers

%d bloggers like this: