Oracle Fusion Tax For European VAT, Best Practice
The truth of the matter is that the differences between Oracle R12 Tax and that of Oracle Fusion Tax are minimal with the Fusion tax solution being pretty much completely based on the R12 solution – “if it isn’t broke, why fix it” right? Well some of those things that didn’t work quite so well have been iron out but on the whole, the architecture of Oracle Fusion tax is pretty much identical to that of R12. So what is this white a paper about? “Its one thing to be able to create a tax rate and a condition but it is something else completely to be able to create a tax solution”. So the following points should be considered as best practice for setting up Oracle Fusion Tax for European VAT.
In Europe, the VAT gap is estimated to be over $100billion and Governments globally are turning more and more frequently as a way of raising tax revenue that is immediately received rather than waiting until the end of the year. There is a much greater emphasis to ensure the VAT is reported accurately and as such any tax solution needs to be designed to ensure the maximum amount of detail is captured.
Common Issues Faced
The first mistake that is made is the under estimation of the size of the tax module. The amount of setup time needed to set the tax solution up for a single European country is 2-3 days for a complete solution. This is then multiplied out for each additional tax regime that is needed. Mistakes are often made because there is a lack of understanding of the VAT legal requirements and how complex each country can be. VAT in Europe is NOT harmonised, which many of the countries having their own unique localised requirements. The consultant needs to work closely with the clients VAT department to ensure all the requirements are met.
Another issue commonly faced is that the consultant doing the setup often has set up tax in Oracle 11i and therefore their mind set is still around how the tax was setup in 11i. The tax solution in R12 is completely different from 11i and so trying to configure R12 in this way usually results an inferior tax solution that relies on defaulting tax rates rather than an enhanced tax rules based solution.
Whilst VAT across the EU is not harmonised, a good proportion of the setups should be setup following the same structure. This not only allows setup to be shared but also helps with the maintenance of the solution at a later date. The Globalised solution can also be setup across multiple different regimes and not just European one. The same determining factors and conditions structure can be recycled across multiple different countries providing they use the same tax structure such as VAT and GST. A US Sales and Use tax solution cannot be setup the same way as a VAT or GST solution.
Tax is Tax
Tax is tax! It does not matter what company you are implementing the tax solution for, the same tax logic is set for all companies. This means that the same tax solution you setup for one company should be the same solution that you can setup for the next company with the same tax regime. This is why Oracle introduced with Fusion tax the ability to download and upload tax configuration, whether instance to instance or client to client. It is now possible to extract the Fusion tax setups from one instance and then upload to another saving both time and accuracy. This is extremely beneficial due to the huge amount of time it takes to manually configure the tax module.
Best Practice Solution
With Fusion Tax, a fully automated solution should be the only consideration and anything less is a poor solution. The tax solution should be based on the reporting requirements of your client. If there are additional reporting requirements then additional tax rates or tax reporting codes should be considered. Design the solution as if it is a global solution, even if the client only has one tax regime. This will allow the user to easily expand in the future if needed.
To reduce user error, you should be aiming to reduce their involvement. A user should rarely if at all ever need to select the actual tax rate as this exposes the tax solution to risk. Often, the users entering invoices are the least trained with minimal tax knowledge to make the correct tax decisions.
Working with the end users is also important to install confidence in the tax solution that you are implementing.
IT is also advisable to have a solution that calculates tax on every transaction. If you don’t calculate a tax then how do you know if the tax has worked or not and with no tax then the values cannot be reported.
It is also advisable to treat your tax solution as you do the chart of accounts. With possibly several hundred tax rates and thousands tax conditions, the maintenance of the solution is extremely important. If rates are added that fall outside the global design then the structure and hierarchy of the tax solution can start to fall apart very quickly and so will the tax solution.
Latest posts by eBiz Admin & Support (see all)
- Bulgarian Oracle User Group – Spring Conference 2016 - 31/05/2016
- Join eBiz Answers at the UKOUG Financials SIG - 15/02/2016
- Register for Oracle Tax Management SIG webinars - 01/02/2016