Archive for February, 2014

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

Andrew Bohnet

eBiz Answers LTD

Introduction

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.

Oracle R12 eBTax adding extra values to belgium or portugal allocation tax boxes – JGZZ_VAT_REPORT_BOXES

Ever need to add to the lsit of values for your ‘Tax Box’ number when setting up allocations? You cannot do it from the tax manager lookups, it must be done through the belgium regional localizations!

First you need to assign the belgium AP localizations responsibility to yourself

go to the ‘Define Lookups’

search for ‘JGZZ_VAT_REPORT_BOXES’

Add your own values

Now you can select the value

JGZZ_VAT_REPORT_BOXES

Oracle R12 eBTax, Upload your GL account codes to tax rates from excel!

As part of our eBtax Rapid Install™ solution, (https://ebizanswers.net/ebtax-downloads/Oracle-eBTax-11i-to-r12-Upgrade-Rapid-Install.pdf
We have managed to create a way of uploading all the tax rate GL codes directly form Microsoft Excel into Oracle so that all your rates get updated.

The quickest time to update a tax account manually either for a tax rate or a tax recvery rate is 30 seconds. We can load 7000 records in 10 seconds!

we can even prepare te file remotely for you to load in

contact us if you want further information enquiries@ebizanswers.net

Oracle R12 eBTax – French Deferred (tax encaissement / au debit)


Question

 Hi Andrew
with the move from R11 to R12 it was decided not to retain the double tax rate code deferred / non-deferred ( encaissement / au debit ) anymore reasoning being that it’s a supplier based trigger and therefore filing should depend on supplier  and not tax rate code
so tax rate code   FRNBU is being used for instance for FR Regime , Standard Vat , Business Related transaction and when the FR Regime is filed , non-deferred suppliers transactions are included triggered upon booking and deferred supplier transaction triggered upon payment  
it now happens that the accountants of the FR company came up with the request to have the accounting of the deferred ones different from the non-deferred one, which was inherent  in R11 but not in R12. 
solution is an SLA rule to change tax line accounting ( the account segment ) based upon the deferred / non-deferred identifier which happens to be the registration_reason_code in the zx_registrations record.
Rgds 

Response

Hi,
I would be pushing back to the business to insist that we have a separate rate for the deferred amounts.
If you have done a technical upgrade from 11 to 12 then you really want to rip out the 11i solution and start again. You should only have
FR VAT and FR OFF as your 2 functioning taxes then you will have to manage just one set of rules under FR VAT.
For those suppliers that are deferred, create a simple party classification code that drives the deferred rate. So you can have the normal rules that determine the status, i.e. FR VAT STANDARD or FR VAT REDUCED LOW then a separate rate rule for each of those taxes that drives the deferred rate (FR VAT STANDARD (DEFERRED) based on the supplier using it. I never default taxes from the supplier or customer site, in fact I never default a tax rate from anywhere as its too high risk for getting the wrong code and instead all the tax logic is  handled by the rules.
No SLA would be needed in this case. The users never need to worry about the actual rate as they never have to choose it as it should be automatic, when the rate changes, we are looking at a 5 minute change to the rate rather than changing any default rules and the reporting is much clearer.
In this case, I think the use of SLA is a bad choice as Oracle already has standard functionality with the tax rules to do what you need.