Taxes and SAP HANA

What does "HANA" and "S/4" stand for and how does this relate to taxes?

SAP HANA (“HANA” stands for "High Performance Analytic Appliance“) is a database that is designed to process large amounts of data and works with what is known as an in-memory function (such in-memory functions allows an optimized storage and processing of the data)

S/4 HANA is an ERP system that runs on the SAP HANA database. The “S” stands for “Simple” and the “4” refers to the fourth generation of the so-called Business Suite from SAP. The Business Suite is a package of enterprise applications that integrate data, processes and functions, especially for the areas of finance, sales and human resources.

“So what?” someone may ask.

The potential changes may sound rather “technical”. However, they go along with major changes also in the finance processes such as the introduction of

• one central finance table replacing the various data tables
• a business partner concept replacing the master data concept
• a ledger concept with the possibility to use various ledgers – such as e.g. a tax ledger, local GAAP ledger, IFRS Ledger).

These changes also have a great impact on the processes of the tax department.

For instance the tax department needs to define its requirements regarding the new business partner concept in order to ensure e.g. that

• sufficient information is available to easily identify intercompany transactions by filtering transactions according to partner company numbers
• an additional field is available to record supplementary information concerning the nature of the transaction by adding a so-called TP-flag (to enable to an automatic generation of a transaction matrix).

Another requirement may concern the usage of a tax ledger and the conception of such ledger. In particular it needs to be ensured that several ledgers are available for one period in order to be able to reflect e.g. adjustments which become necessary in course of a tax audit or the requirement to file an amended tax return. Also the tax department needs to consider for which events such tax ledger shall be used and by whom the ledger is booked.

Often companies use the S/4 HANA transformation project to downsize the chart of accounts and to reduce the number of counts to a minimum. This is of course understandable form an administrative point of view, but can lead to great challenges for the tax department as the tax department may need to differentiate between e.g. fully deductible meal expenses, partially tax deductible meal expenses or non-tax deductible meal expenses.

If all expenses are simply booked on one account without providing for the possibility of a further break down, the tax department will hardly be in the position to correctly process the data for tax declaration purposes.

What needs to be done?

These very basic examples show that the tax department needs to involve itself very actively in the project in order to ensure that its needs are duly reflected also in the new system.

In this respect the tax department needs to define so-called requirements or user stories, which outline the aspects that have to be considered from a tax law point of view.

Hereafter is a simplified requirement, which refers to the last example (the possibility to have tax relevant data available with sufficient granularity):

Tax departments needs to be able to identify expenses (such as e.g. entertainment expenses, interest expenses, rental expenses, license fees, remuneration for supervisory board members, etc.) which require an add back for German income tax purposes. If, therefore, these expenses are not recorded on separate accounts, tax department must have the possibility to define tax relevant attributes, which are added to the posting and which enable an analysis based on the various attributes.

Further there needs to be a possibility to add certain relevant information to the master data (such as e.g. the information: ultimate head of a fiscal unity or a company partner number). It must be possible to analyze the transactional data in combination with the additional master data information (e.g. rental expenses paid to a company within the fiscal unity, which does not need to be added back for German trade tax purposes).

After having defined the (local) tax requirements, these need to be discussed with the other workstreams of the projects (e.g. with general ledger) and they have to be further specified in the course of the project great detail. Moreover, it needs to be determined to what extend the (locally) defined requirements deviate from the SAP standard and special technical developments become necessary (e.g. with regard to technical interfaces).

These so-called WRICEFS have to be identified and described in detail in order to enable a technical realization. Of course the tax department also has to involve itself actively into the testing in order to ensure that all functionalities have been duly implemented. 

Often the overall project applies a so-called global approach, which means that the requirements are defined on a global level. This may lead to the assumption that the local tax function can simply rely on the globally defined requirements. However, as the wording “global” already indicates the requirements are indeed of a rather global nature and do not take into account the particularities of each tax jurisdiction.

In this case, each local tax function has to evaluate to what extend the local requirements deviate from the global approach resp. where the global requirements need to be specified in order to sufficiently fulfill local requirements.

Summarizing it can be stated that an S/4 HANA transformation project is a huge project also for the tax departments. However it is also a great change to improve the processes from a tax perspective by anchoring tax requirements in other processes such as e.g. accounting processes. Thereby the overall data quality can be approved and a higher degree of automation can be achieved.