Fully Automating eBTax When Upgrading From 11i to R12 With New e-Business Tax Rules
We will be presenting at Oracle Colaorate 2014 on this topic
eBiz Answers LTD
We go through the stages of a best practice approach, explaining the global design that is scalable, designed to be future proof yet easy to maintain as well as looking at the migration issues. We examine how one legal entity in multiple countries was setup using both Global and Party specific rules, ensuring the right tax was used each time.
The challenge faced by any company implementing a new ERP solution, whether a single entity or a global conglomerate, is to capture the complex business requirements yet to keep the structure as simple as possible. Creating a highly complex organisation structure is likely to lead to greater data processing needs as well as a more labour intensive maintenance requirements but creating a risk that the solution initially designed to help the company, ultimately leads to issues that end up consuming more resource.
This document is intended to highlight the potential issues if the correct number of operating units are not used.
Risk of Non-Compliance
“The EU VAT system is in a mess. It is a dizzying mix of rates with a huge number of exemptions and special cases across its 28 countries. The VAT gap is now a stunning €100b, which is steadily rising due to fraud resulting from the fact that there is no taxation on EU cross-border purchases by businesses.
At the same time, companies, which effectively act as unpaid tax collectors, are facing a growing compliance burden. While governments agree they should reduce such costs and obligations, many are adding more compliance obligations and implementing disproportional sanctions, as they increasingly rely on VAT to help plug their fiscal gaps. Source: EY T-Magazine June 2012”.
With this in mind and the fact that the Oracle R12 e-Business Tax module allows for a fully automated solution, why do so many companies suffer such poorly designed indirect tax solutions? Companies waste so much time error checking after month end and risk being non-compliant because they don’t correctly stop the wrong determination of the tax rate when the transaction is entered.
Tax in Oracle
Prior to the tax module in R12, tax was setup in 11i on a module by module basis and whilst basic tax grouping/rules did exist, the primary way that a tax rate was determined was to default the tax rate from somewhere, most commonly from the supplier or customer site. This of course had many limitations primarily because there are many factors tat drive a tax so just defaulting one tax rate would often lead to a high failure rate. To compensate the wrong tax rate from being defaulted in, the user was able to override the defaulted tax rate with on of their own choice. Allowing a user with limited tax knowledge choose a tax rate is opening the company up to risk of non-compliance.
With the introduction of the tax module with Oracle R12, instead of setting up the tax rates on a module by module basis and defaulting the tax rates, the R12 tax module allows for a central repository for all the tax related information including the ability to create complex tax rules. These tax rules mean that there is no need at all to ever default a tax rate as the tax engine uses logic to determine the tax rate and users a large selection of determining factors to correctly drive the tax rate.
Upgrading from 11i to R12
Oracle designed the upgrade process from 11i to R12 to work with minimal setups and the tax module was also designed to accommodate this. The problem however is that the 11i tax solution is extremely basic providing a manual tax solution where the tax rate was defaulted and allowing the user to override the value. So whilst the rich functionality of the tax module exists, it is also possible for an upgraded solution to ignore this setup and stick with the manual 11i solution. But why would any company want to stay with an inferior tax solution when the opportunity to move to a fully automated solution exists?
If your solution integrator is on a fixed price, then why would they offer to extend the tax solution which does take a large amount of time to do correctly when they can just give you what you had previously. After all, if you don’t know what the tax module can do then you won’t ask for it.
Tax is complex and not everyone is going to be able to understand the tax law and also are not going to know the tax module well enough to be able to set it up and maximise its functionality. The majority of financial consultants will say they know how to set up tax but very few will actually know how to do it correctly. It is one thing to be able to create a tax rate and condition, it is something completely different to create a tax solution!
Some end customers will also have multiple 3rd party solutions that feed into Oracle and there may be concerns that a new tax solution will affect the tax solution too much. Of course this is not the case but without the correct knowledge of how the tax rules work and how the other modules can receive tax related data, how will the end customer know any different?
With 3rd party tax solutions such as Taxware, Vertex, one source or Avalara touting tax solutions outside of the oracle application, particularly for US tax solutions, the end customers may feel that Oracle is not capable of handling their tax requirements. The interesting point is that for any third party solution to work, it needs to be supplied with the correct information to use to determine the tax rate. If Oracle already has this information then why not use the tax module to determine the rate rather than mapping everything to a 3rdparty solution?
The major issue when doing an upgrade is that the time it takes to set up a well structured tax solution will be measured in days rather than hours and if you are doing an upgrade where you only have a small window for cutover then spending 15 days doing tax configuration is not a feasible options. The ‘eBTax Rapid Install™’ solution will however allow for 30 days of configuration to be done in under 4 hours – well within any cutover period!
Fully Automating Your Tax Solution
Every upgrade should undertake a full review and enhancement of the indirect tax solution with the intention of automating and reducing risk. The best approach is to create new tax ‘Regime to Rates’ for each country and not end dating the old upgraded tax regimes, instead, leave the old upgraded solution in place and instead ensure that the old tax regimes are not assigned to any Legal Entity or operating unit. By doing this, any 3rd party interface using an old tax rate will not fail. New tax rules can also be built around the old tax rates meaning that 3rd party products need not be changed for the upgrade and instead the old tax rates can be integrated into the new tax rules.
Now is also the opportunity for creating new tax rates with a better naming convention than was possible with 11i and designed around one module rather than separate tax rates for AP and AR.
Design the solution to minimise risk by minimising user interaction. The less ability a user has to change a tax rate the less risk there is in calculating the wrong tax rate. The end users are often the least educated when it comes to tax and allowing them to choose the tax rate could potentially lead to millions in fines. The tax logic can be setup to reduce the user interaction and automate the solution as much as possible. In fact, for receivables transactions, the tax should be fully automated because we know the product or service that we are selling, where we are selling it from and who we are selling it to and what exemptions or registrations are involved. It is only a very rare case that a user ever need to override a tax rate in the order to cash process. The purchase to pay process is different however. Whilst automation achieved in the majority of cases, until the invoice comes in from the supplier the tax is never truly known. An item could be exempt, a supplier non-registered or the tax amount out by a penny or two because of a rounding difference. For this reason, some manual intervention needs to be built in but not to the extent of allowing the user to always choose the tax rate.