By Richard Cornelisse, Robbert Hoogeveen en Arjan Hassing of the KEY Group
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.
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.
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.
- ‘Indirect Tax Automation’ And ‘Plug And Play‘
- Tax Engines – Questions to Ask Before You Commit
- Demonstrate the reliability of your tax administration yourself
- Indirect Tax Trends
- Tax Professionals: A Different Way of Working
- SAP review