Richard Cornelisse

Posts Tagged ‘financial’

Indirect tax function effectiveness: SAP’s Transaction Tax Engine

In Audit Defense, Indirect Tax Automation, Indirect Tax Strategic Plan, Processes and Controls on 14/07/2014 at 12:00 pm

The Transaction Tax Engine (TTE), which manages Tax outputs, handles high volumes of transactions often generating billions of dollars of tax revenue. In simple terms, it uses the decision tree to make tax event determination, which in turn generates the applicable tax type and tax rate.

Like other SAP modules the TTE can be customised according to corporations’ specific requirements. The Tax and Finance teams are the end-users of the data and rely on it to generate tax lodgements to tax authorities and to produce financial accounts.

With high turnover, accuracy is critical and any minor inconsistency in the master data set-up can result in tax and accounting errors which can go undetected for long periods of time. While ‘End User Testing’ used in pre implementation stages is designed to prevent this, multiple operational models in a complex organization often produce outcomes that are unsatisfactory and require subsequent manual input to get the right transactional outputs.

What makes the problem even more complex is that implementing SAP over an established tax platform does not necessarily ensure the underlying processes are fully aligned to the new system – contrary this is often left over to the system end-users who are ill equipped to deal with these types of issues.

SAP implementation are drawn out lengthy projects often running into millions of dollars and getting things right upfront is imperative for the end-to-end process to function.The experience with large multinational corporations is that over reliance was placed on post-fact back-end, detective type of controls.

Typically this involves exception reporting used to detect tax data errors once the tax returns have been compiled and lodged with the Tax Authorities. The time frame can range from a few weeks to up to a year before a particular control is implemented, and even then the approach is based on transactional scenarios rather than having assurance all contingencies have been covered off.

In a nutshell, there is a significant room for financial exposure for the Head of Tax and CFO resulting in the underpayment or overpayment of tax – ultimately leading to margin erosion, penalties and reputational impact with Tax and statutory authorities, and customers alike.

The diligence in the approach is required at the front-end, designed to capture any master data inconsistencies in SAP before the transaction even occur. Typically, SAP inputs required for the transaction to interface correctly are wide spread.

Whilst, TTE is often controlled by the respective Tax team, other SAP master data inputs are not. For example, if the process maps and flow charts used to carry out customer set-ups are not done correctly or the system is not equipped to deal with the transaction, an error is very likely to occur.

Front-end controls which can customised to suit the corporations’ operational model and business type are key to ensuring the error free landscape.

They can be designed up-front and tailored to cover a range of different business scenarios. Their optimal performance is in environments where there is emphasis on internal controls and corporate governance.

Via SAP and Transaction Tax Engine Functionality

SAP and Transaction Tax Engine functionality

In Audit Defense, Indirect Tax Automation, Indirect Tax Strategic Plan, Processes and Controls, Technology on 28/05/2014 at 12:02 pm

This article is about SAP’s Transaction Tax Engine that uses decision trees in contrary to SAP’s MWST functionality that uses condition tables.

Get it Right at the Tax Front-End

2c3f2ceMultinationals across the world have embraced SAP as the preferred Enterprise Resource Management (ERM). The idea behind the German designed software was to provide customers with the ability to interact with a common corporate database for a comprehensive range of applications.

Gradually, the applications have been assembled and today many corporations are using SAP products to run their own businesses. SAP applications, built around their latest R/3 system, provide the capability to manage financial, asset, and cost accounting, production operations and materials, personnel, plants, and archived documents. The R/3 system runs on a number of platforms including Windows 2000 and uses the client/server model.The latest version of R/3 includes a comprehensive Internet-enabled package.

In case of most large corporations, SAP can be tailored to meet the specific requirements of the industry they operate in. The Transaction Tax Engine (TTE), which manages Tax outputs, handles high volumes of transactions often generating billions of dollars of tax revenue. In simple terms, it uses the decision tree to make tax event determination, which in turn generates the applicable tax type and tax rate.

Like other SAP modules the TTE can be customised according to corporations’ specific requirements. The Tax and Finance teams are the end-users of the data and rely on it to generate tax lodgements to tax authorities and to produce financial accounts. With high turnover, accuracy is critical and any minor inconsistency in the master data set-up can result in tax and accounting errors which can go undetected for long periods of time.

While ‘End User Testing’ used in pre implementation stages is designed to prevent this, multiple operational models in a complex organisation often produce outcomes that are unsatisfactory and require subsequent manual input to get the right transactional outputs.

What makes the problem even more complex is that implementing SAP over an established tax platform does not necessarily ensure the underlying processes are fully aligned to the new system – contrary this is often left over to the system end-users who are ill equipped to deal with these types of issues.

SAP implementation are drawn out lengthy projects often running into millions of dollars and getting things right upfront is imperative for the end-to-end process to function.The experience with large multinational corporations is that over reliance was placed on post-fact back-end, detective type of controls.

Typically this involves exception reporting used to detect tax data errors once the tax returns have been compiled and lodged with the Tax Authorities.

The time frame can range from a few weeks to up to a year before a particular control is implemented, and even then the approach is based on transactional scenarios rather than having assurance all contingencies have been covered off.

In a nutshell, there is a significant room for financial exposure for the Head of Tax and CFO resulting in the underpayment or overpayment of tax – ultimately leading to margin erosion, penalties and reputational impact with Tax and statutory authorities, and customers alike.

The diligence in the approach is required at the front-end, designed to capture any master data inconsistencies in SAP before the transaction even occur. Typically, SAP inputs required for the transaction to interface correctly are wide spread.

Whilst, TTE is often controlled by the respective Tax team, other SAP master data inputs are not. For example, if the process maps and flow charts used to carry out customer set-ups are not done correctly or the system is not equipped to deal with the transaction, an error is very likely to occur.

Front-end controls which can customised to suit the corporations’ operational model and business type are key to ensuring the error free landscape. They can be designed up-front and tailored to cover a range of different business scenarios. Their optimal performance is in environments where there is emphasis on internal controls and corporate governance.

by Sasha Savic

via SAP and Transaction Tax Engine functionality.

VAT Control Framework

In Indirect Tax Strategic Plan, Processes and Controls, Technology on 09/08/2013 at 1:53 pm

KEY Group new logo long

Objective of Tax Control Framework

A Tax Control Framework (TCF) is an internal control instrument specifically aimed at the tax function within a company. A  TCF is not limited to the Tax Department, but an integral component of a company’s Business- or Internal Control Framework (hereinafter also ICF).

The ultimate objective of a TCF is to be in compliance with tax laws and reporting requirements and manage the risks that matter (risks that exceed the companies’ risk appetite).

Among other things, this requires a clear understanding of the companies’ material risk areas and includes policy and roles and responsibilities of the tax department and the shadow tax function (anyone who is not formally in the tax function, but has a role managing tax; e.g finance function re indirect tax compliance), internal procedures/processes and control measures (hard and soft controls).

This framework ensures that an organization has adequate control over its tax processes. A TCF can prevent tax errors, identify opportunities in a timely manner and perform correct filings at the right moment.

A company’s VAT control framework system is adequate if it provides insight into where material VAT risks may arise in the company (awareness), while the degree of risk tolerance is established internally and where appropriate control measures are taken with respect to these risks.

Control activity examples in four risk areas:

Focus areas

Risk description

Strategic VAT strategy cannot be tested as to whether this is in line with the entire tax and corporate strategy.
Operational The indirect tax function is not consulted when changes occur.
Financial VAT payments are not made on time.
Compliance The VAT filing is not done on time.

Change Management

Below is an example that relates to changes in the business (strategic) and shows the controls that can be implemented to manage the risks that come up with business changes.

The control activity, the test of control and the frequency are important for an effective and efficient implementation and shows how an organization is in control.

Tabel changes in business - page 1

Tabel changes in business - page 2

The KEY Group‘s normative indirect tax control framework

The KEY Group has extensive expertise in the area of Business Controls / Internal Controls and has developed a normative framework for indirect taxes, the so-called VAT Control Framework.

The actual situation (IST position) within the organization is then measured against this yardstick, generally resulting in a summary of the differences.  Analysis of these gaps and the associated risks may lead to acceptance or to proposals for improvement. It is an efficient and effective approach that challenges the relevant process owners.

The design of the normative framework was realized by the practical experience of the former Indirect Tax Technology Leader of Shell International, a former Ernst & Young partner and a former Executive Director of Deloitte who specialize in the area of Indirect Tax Performance respectively Business/Internal Control and who have supported many multinationals with structure, design and implementation.

The KEY Group uses the experience gained to continuously test and improve the normative framework based on examples and practical solutions.

The collaboration of experts Robbert Hoogeveen, Richard Cornelisse and Ferry Geertman has resulted in an integrated client solution from the various areas of expertise.

Related topics

SAP implementation

In Audit Defense, Business Strategy, Indirect Tax Automation, Indirect Tax Strategic Plan, Processes and Controls, Technology, VAT planning on 20/10/2012 at 7:56 pm

KEY Group new logo long

By Richard Cornelisse of the KEY Group

(In Dutch)

For nearly every company, the accuracy and efficiency of local-country VAT compliance is nearly completely dependent on the functionality of the underlying ERP system.

Operational malfunctions in a system that is used to manage VAT compliance can lead to substantial financial risks.

There are countless examples of the mismatching of VAT treatment of purchases and sales in chain transactions, double payments of VAT and “forgotten” manual adjustments to the VAT filing, all attributable to shortcomings in SAP’s automated VAT solution.

Errors in the basic VAT configuration of ERP systems can also carry consequences for an organization. Without the proper VAT rules, many systems are incapable of processing transaction information correctly, so that transactions may become blocked. This has a great impact on logistics processes, invoicing processes and financial processes.

Tax and financial departments are under increasing pressure to reduce the costs of compliance processes. One result of this is the increasing transfer of VAT-relevant processes from national tax supervision to Shared Service Centers. These Shared Service Centers are not generally manned by tax specialists. They trust the functionality of the group’s ERP system to determine, calculate and report local VAT.

Our added value is that we help clients free up resources, reduce manual activities and manage risks.

Distinguishing capability

The KEY Group possesses considerable practical experience and understands SAP’s possibilities, but also its limitations.

With respect to the possibilities, we can express the wishes to the external SAP consultant in his own language and we can demonstrate how these can actually be achieved in SAP. In practice, we note that certain functionality intended for the support of indirect tax objectives does not get used – due either to reluctance (not within budget) or to a lack of knowledge in this area.

From an indirect tax standpoint, the realization that you are part of a larger team in which each of the participants has other priorities is key. This means that effective communication and agreements are essential. Instructions must be understandable and so short and compact that they can also be used as a reference framework and material for the tests.

In practice, Excel is often used to record all transactions and to indicate what the VAT treatment, etc., should be for each transaction individually. This cannot be imported and is difficult to evaluate for this reason. Moreover, the use of Excel carries the risk of making copy/paste errors.

The question is: what is the best format for providing instructions to other work streams and for making the test phase efficient and effective? It turns out in practice that decision trees are a particularly effective communication resource with the IT consultant. In addition, an SAP implementation is not “Plug and Play.”

SAP has its limitations and not all transactions can be implemented in the systems in an automated fashion.

For example, in the standard configuration, it is not always possible to have SAP automatically determine the VAT treatment of chain transactions within a concern or with third parties (3 parties or more).

One of the solutions is to work with assumptions and to implement these in the system. 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.

The advisor should be asked which functionalities are available in the market for still achieving full automation without making use of assumptions.

If this solution is selected, periodic audits are still essential since the risks exceed the company’s risk tolerance. This results in extra man-hours, representing additional costs.

As of January 1, 2013, invoicing requirements will be harmonized and the legal objections of practical thresholds will be removed. From an SAP perspective, there is still an important battle to be fought for the system’s processing of VAT.

From within the standard SAP settings, how do you get iDocs/OBCD to handle VAT treatment automatically? For complex business models with VAT registrations in various countries, SAP’s standard iDoc/OBCD design does not allow the derivation of the proper tax code for AP for cross-border transactions. In which countries should the acquisition be reported? This is another question to ask the adviser.

The indirect tax objective of an SAP implementation should not be only that everything functions at the moment of “going live,” but that the maintenance and logic of the structure and the persistence of that logic in case of changes have been considered.

Example:

In a given country, tax code VI is used for the standard VAT rate at the moment of “going live.” This means that a print can be made of the standard VAT rate used in various countries using the simple tax code selection, essential for monitoring the function and for the selection of the proper tax code for AP coding.

If a rate increase occurs, a tax code for the new standard rate must be created – VD, for example – one that deviates from the chosen standard. VAT rate increases are a worldwide trend and the result is that the logic of the tax code structure will no longer be present after the increase. This increases the chance of errors when selecting the correct tax code.

So the question is: how do you implement the rate changes in SAP without this having an impact on the logic of your tax code structure?

Examples of possible errors in SAP

  • Not making use of the proper partner functions in SAP for a supplier who provides services in multiple countries and invoices VAT locally. Result: the standard VAT calculation generates incorrect results.
  • Missing/improper VAT registration numbers in customer master data, such that invoicing requirements are not satisfied for cross-border transactions.
  • Master data is adjusted and tested in the test environment, but the changes are not included in the final upload to the production system.
  • The logic of the tax code structure is disrupted by VAT rate changes, something that could have been prevented using the SAP configuration.
  • When performing reverse charge bookings, VAT rate changes do not get changed.
  • For cross-border A-B-C transactions, a VAT mismatch between the VAT on procurement and the VAT on sales arises for party B.
  • Blocked so-called iDoc (electronic interface documents) because of errors in the OBCD design.
  • Suppliers with invoices in other currencies and the VAT amount in Euro, so that the booked VAT amount is incorrect due to an incorrect exchange rate.
  • Incorrect derivation of VAT registration numbers for cross-border transactions caused by incorrect SAP configuration.

Related Topics:

 

VAT – European Commission

In EU development, Processes and Controls, Tax News, Training on 26/07/2012 at 9:00 am

VAT: Overview of EU legislation currently in force and eLearning course

The essential piece of EU VAT legislation since 1 January 2007 has been Directive 2006/112/EC. That ‘VAT Directive’ is effectively a recast of the Sixth VAT Directive of 1977 as amended over the years.

The recast brings together various provisions in a single piece of legislation.

Directive 2006/112/EC in turn was amended several times in the last few years and a consolidated version without legally binding value was published in January 2010 in the EU Official Journal.

An eLearning course has been developed by the European Commission to help tax officials and others get a good basic knowledge of the VAT Directive.

The course is freely available for download from our web page.

Table Of Content

Key documents

Traders

Control and Anti-Fraud

New administrative co-operation regulation

Combating tax fraud

Conferences and other events

e-learning

LinkedIn | Twitter | Facebook

Follow

Get every new post delivered to your Inbox.

Join 143 other followers

%d bloggers like this: