Oracle ebusiness tax – when to use a tax jurisdiction

Linking a tax jurisdiction to a tax rate.

Whether its R12 eTax, eBTax or Oracle Cloud (Fusion) Tax, with Oracle eBusiness Suite, every Tax created under a Tax Regime needs a ‘Tax Jurisdiction’ if it wants to be enabled for transactions. Under the Oracle tax engine, a tax jurisdiction only applies to certain types of taxes.

In the US, there are a huge number of tax rates that can be determined, usually based on the location of the Ship-To and will calculate a separate STATE, COUNTY and a CITY tax rate based on this location. In a country like Germany where VAT is used, unlike the US, there is only one standard vat rate for the entire country.

 

Oracle provides 2 ways of determining the tax rate, either by tax rules or by jurisdictions. For a country like Germany, there only needs to be one Jurisdiction, and that is for the entire country. By default, a standard rated tax is calculated and then rules are used to determine when the tax is not standard, i.e. zero rated, exempt or an intra EU supply. In the US, if we tried to use rules to determine each possible tax rate, we would need thousands and thousands of conditions. So the clever approach used by the Oracle Tax Engine is to use a tax jurisdiction. The Jurisdiction is often a range of ZIP codes where the same tax rate is used. This means that against each Jurisdiction is a tax rate linked to it and then without any rules, the system can determine the correct tax rate based on the Ship-To location (providing the default place of supply is the Ship-To). This simple approach means no rules are needed to change the actual rate for the different states, counties or cities, the place of supply is all that is needed. So if the Ship-To has the ZIP code of 80020 then the tax rates for Broomfield, Denver in Colorado would be automatically determined. For Germany, selling anywhere within Germany would simply use the standard German tax rate if only based on the place of supply.

 

The issue however is that jurisdictions by their very definition need to be linked to a location and this means that you cannot calculate a jurisdiction linked tax rate unless the place of supply is the same as the jurisdiction.  Nor can you determine tax against a GL journal as there is no geography information on a journal. So when you assign a jurisdiction to a tax rate, you need to make sure a location is being used in the transaction.

 

When setting up the tax rates in the US, they would all be linked to a jurisdiction. In Germany, we would not want to link any jurisdictions to a tax rate and instead we simply make the standard tax rate the default one. This means that we cannot use a US tax rate in a journal but we could use a German tax rate in a journal.

 

So best practice would be to create the tax rates against a jurisdiction for countries like the US where a jurisdiction is needed but not to assign any jurisdictional information to any tax rates where only a countrywide jurisdiction is used such as Germany.

 

It must be noted that if you do not need to use a tax on a journal then having the jurisdiction linked to a tax rate should not cause an issue – its just that there is no need for it.

Andrew Bohnet
Follow Us

Andrew Bohnet

Managing Director and Oracle Fusion Tax / eBTax expert at eBiz Answers Ltd
Andrew Bohnet is the current chair for the Oracle Tax Management SIG. He founded eBiz Answers to offer clients complete tax solutions making the most of the rich functionality of the R12 and Fusion tax modules. Whether it is analysis, design, configuration or support, eBiz Answers provide an unparalleled service when it comes to a complete tax solution. Having worked on one of the first Oracle R12 implementations in Europe, Andrew was exposed to the tax module early on and worked closely with Oracle to fix bugs, enhance functionality and present on numerous occasions on the subject of tax and Oracle. When it comes to presenting on eBTax, you wont find a more experienced consultant outside of Oracle.
Andrew Bohnet
Follow Us