After a successful implementation of Oracle EBTax, a company still faces the challenge of maintaining the solution. Changes in tax rates and tax rules will require additional configuration and testing and could even require additional design depending on the tax rule changes. And many tax jurisdictions around the globe are raising tax rates and/or taxing additional commodities to increase revenues. So the maintenance effort may be considerable.

During the implementation, the company must research and define all of the tax rates and rules for each jurisdiction in which the company owes indirect tax. The level of effort can be mitigated somewhat with experienced implementation personnel and implementation tools that either provide tax rate and rule data or help to automate the implementation activities.

But once the system is live, the maintenance activities are often manual. All of the same activities required during the implementation still apply: research to identify upcoming rate and rule changes, evaluation of rule changes to determine if they fit into the current solution design, re-engineering if the rule changes need additional solution elements, configuration and testing, and migration to production. These activities become the responsibility of company personnel once the implementation personnel have gone.

Leveraging the built-in integration from EBTax to a third party tax partner, such as Vertex, can significantly reduce both the implementation effort and the ongoing maintenance effort. Regime-to-Rate flow structures can be defined with default level Tax Rates that allow ad hoc rates to be associated. This will eliminate the need for new Tax Rates to be defined each time a rate changes. The tax partner software is responsible for maintaining all of the detail rates as well as the rules that evaluate detailed transaction data elements to determine the appropriate tax result. The tax partner will also provide notifications of pending tax rate and rule updates so that the appropriate, targeted testing can be performed when updates are required to the third party tax software.

Using a third party tax partner can definitely minimize the effort required to implement and maintain an automated indirect tax solution using EBTax within Oracle R12 applications.

This is the final part of a series discussing impacts for tax processing when upgrading from 11i to R12. Part IV will identify some issues and considerations of the tax upgrade.

Because of the new data structures, tax lines associated with migrated transactions need to include data values for the new data structures and are dependent on successful migration of the EBTax data structure components.

After the upgrade, all tax calculations rely on the migrated data structures and associated rules even for adjustments to converted transactions.

Direct Rate rules apply the tax rate associated with the Tax Rate / Tax Classification code to the transaction line amount (taxable basis) to calculate tax amount. There is no functionality to apply other factors or conditions. This method of tax calculation is very limited.

Location-based tax uses address data to identify all geography hierarchy and jurisdiction records for applicable tax for a transaction. The accuracy of these calculations is highly dependent on accurate and valid address information.

Very limited changes can be made to migrated tax structures. No new Tax Rules can be implemented within a migrated Regime structure. The only change allowed is the addition of a numeric rate under an existing Tax Rate (to accommodate rate updates).

Because of the issues and limitations with migrated tax structures and rules, many clients will opt to define all new tax structures for use on new transactions. This allows the structures to be planned and designed with more user-friendly naming conventions and more flexible, complex tax calculation rules. It also provides the ability to use the same Regime-to-Rate flow structures for both Payables and Receivables to stream-line data entry and reporting.

This is the third part of a series discussing impacts for tax processing when upgrading from 11i to R12. Part III will identify naming characteristics and potential issues of migrated tax components.

The migration programs incorporate a naming convention for 11i components to fit into the R12 structures.

Regime naming is based on the Operating Unit location country and the Type associated with the Tax Code with separate regimes for Payables and Receivables (examples: US-SALES [Payables], US-SALES_TAX [Receivables], DE-Tax [Payables], and DE-VAT [Receivables]). All Regimes are shared by all Operating Units.

Numbers, spaces, and special characters are removed from the 11i Tax Code to create R12 Tax code and name. Duplicate R12 Tax names can occur during migration. Duplicate Tax names will occur 1) if 11i Tax Codes with the same name exist in multiple Operating Units or 2) if Receivables and Payables Tax Codes with the same name exist within the same Operating Unit.

Status value will usually migrate as ‘STANDARD’ for all Regimes and Taxes.

Duplicate Tax Rate codes can occur for the same reasons as duplicate Taxes.  The Tax Rate code value becomes the Tax Classification code value.  Users will select the Tax Classification code when applying tax to post-production transactions and using the migrated tax structures so duplicate values may create confusion.

When duplicate Tax or Tax Rate values are migrated, the content owner is assigned as the tax profile identifier for the Operating Unit. This additional field needs to be considered in queries and reports.

Tax Codes in 11i can be manually entered on transactions but can also be defaulted from various sources such as customer site, supplier site, items, System Options, or Financials Options. Default Tax Codes assigned to default source objects in 11i will migrate as default Tax Classification codes to the corresponding source records in R12.

This is the second part of a series discussing impacts for tax processing when upgrading from 11i to R12. Part II will address how Receivables tax components are migrated.

Tax Codes and Tax Groups in 11i Receivables will be migrated in the same manner as those in 11i Payables. A Regime will be created for each Operating Unit. A Tax, Status, and Tax Rate will be created for each 11i Tax Code that exists in the Operating Unit. Tax Classification codes created for Receivables Tax Codes will have a type of ‘Output’. A Tax Rule with type of ‘Direct Rate’ will be created to associate each Tax Classification Code to the corresponding Tax Rate. Tax Group conditions are migrated as additional formulas in Tax Rules. No Offset Tax Code functionality exists in Receivables.

Oracle Receivables application also has the concept of location-based tax in the US with tax structures tied to address components. Location-based structures are migrated to a Regime with the structure ID in the name.  A Tax for structure components (COUNTY, CITY, and STATE) will be created within the Regime. Tax location records for state, county, city, and postal combination are migrated into the geography structures in Trading Community Architecture (TCA). A Tax Jurisdiction is created for each tax location structure and the Tax Jurisdiction is tied to the geography record. Tax Rates will be tied to Tax Jurisdictions for tax calculation so no Tax Rules are created.

Customer exemptions in 11i are migrated to R12 and have the same general capabilities. But the exemption in R12 is actually migrated to a different data element. In 11i, the exemption is tied to the customer or customer site record. In R12, the exemption is tied to the location which represents the party site. Locations for customers exist in the same table as locations for suppliers and employees in R12.

In the throes of a big ERP implementation of Oracle R12 and evaluating business processes and key features, it is easy to overlook the importance of valid addresses for customer sites, supplier sites, and internal locations.

Obviously, a valid address is important for physical logistics when identifying a location for delivery or shipment of goods but valid addresses are critical for accurate tax treatment and tax calculations.

The TCA in R12 now includes the geography hierarchy. This geography structure is defined to include each component of an address for a specific country. The geography hierarchy builds on the components from the highest level to the lowest level. For the United States, the geography structure has five types or elements and geography hierarchy records are built as follows:

A Type of ‘Country’ will have only Geography Element 1 for the country value

A Type of ‘State’ will have Geography Element 1 for country and Geography Element 2 for State (example: US > Texas)

A Type of ‘County’ will have Geography Element 1 for country, Geography Element 2 for State, and Geography Element3 for County (example: US > Texas > Denton)

A Type of ‘City’ will have Geography Element 1 for country, Geography Element 2 for State, Geography Element3 for County, and Geography Element 4 for City (example: US > Texas > Denton > Frisco)

A Type of ‘Postal Code’ will have Geography Element 1 for country, Geography Element 2 for State, Geography Element3 for County, Geography Element 4 for City, and Geography Element 5 for Postal Code (example: US > Texas > Denton > Frisco > 75034)

In R12 EBTax, one of the components of the Regime-to-Rate structures is the Tax Jurisdiction. A Jurisdiction must be associated with a single, existing geography hierarchy record and a Tax Rate will be associated with a single Tax Jurisdiction.

When a transaction is evaluated for tax treatment, each of the locations (addresses) on the transaction is compared and matched to a geography hierarchy record to determine what tax jurisdictions (and subsequently what tax rates) should apply to the transaction. If there are ‘gaps’ in the address such as a missing county or invalid city value, the location address cannot be matched to the lowest level geography hierarchy record and so any jurisdictions or tax rates tied to the lower level geography hierarchy records will not be applied.

It is imperative to define granular geography hierarchy records and to set address validation controls early in the implementation process so that addresses are created with all the necessary and valid components to achieve an accurate and complete tax calculation.

This is the first part of a series discussing the impacts for tax configurations and processing when upgrading from 11i to R12. Part I will address how Procurement tax components are migrated. Part II will address how Receivables tax components are migrated. Part III will identify migration challenges and issues.

Tax data structures and technical architecture between 11i and R12 changed significantly. Migration of the 11i data structures and values is accomplished with automated programs that include built-in assumptions about how to migrate the information so reconciling 11i and R12 configurations can be challenging.

The 11i structure for Procurement consists of a Tax Code and a Tax Group. A Tax Code may have an Offset Tax Code (to record self-assessed or self-accrued tax liability). A Tax Group may be used to apply multiple taxes for a single transaction line (such as Canada GST and PST).

The R12 structure is a Regime-to-Rate hierarchy: Regime > Tax > Status > Tax Rate.

A Regime will be created for each Operating Unit and Tax Type. A Tax, Status, and Tax Rate will be created for each 11i Tax Code that exists in the Operating Unit. In addition, a Tax Classification lookup code will be created for each 11i Tax Code. Tax Classification codes created for Payables Tax Codes will have a type of ‘Input’. A Tax Rule with type of ‘Direct Rate’ will be created to associate each Tax Classification Code to the corresponding Tax Rate.

The conditions defined in a Tax Group are migrated as additional formulas on Tax Rules to determine when each Tax Rate should apply.

An Offset Tax Code would be migrated in the same manner as a Tax Code but the R12 Tax would be set as an Offset Tax. Offset Tax Rates will also be flagged and will be linked to the appropriate ‘base’ Tax Rate.

Tax Codes with a recoverable rate that is not equal to 0 will also create R12 Recovery Rates linked to the associated Tax Rate.

I am in beautiful, sunny Florida attending the Vertex Exchange conference with 300 or so other tax technology folks. The people attending this conference are mostly tax managers and tax analysts from companies that are based in the US but may operate around the globe.

I was discussing certain challenges I encountered recently on a project with some colleagues from “across the pond”. Coincidentally, as service providers assisting companies in the US, they are seeing the same challenges.

Given free trade and the internet, it is much easier to get global exposure these days with respect to providing goods and services to customers outside the US. So we are seeing US-based companies branch into international markets. They recognize right away that they need to address the VAT consequences of those business ventures … VAT rules can be very interesting depending on the countries involved!

But US companies suddenly launched into international trade often don’t recognize the other aspects of these international business transactions that will affect them. Things like tracking the origin of components used in configured products, packaging and labeling, identifying where shipments are going and how to clear customs, determining international terms for shipping and financial responsibility, language requirements for documents being sent outside the company to suppliers and customers, and even how external documents like purchase orders and invoices are required to be numbered.

My colleagues agreed that those of us involved in international tax technology projects often find ourselves providing education on a broad range of business and system design initiatives.

Best case scenario is that these requirements get identified early and the appropriate business processes and system components are designed to meet requirements according to the company’s business footprint. Worst case is that we are happily building and shipping our products but they are stalled at the border of the intended customer’s destination country. So we must scramble to get compliant … and quickly! But we all love a challenge, right?

With Oracle R12 applications, indirect tax (sales, use, VAT) functionality has been transformed from independent and simplistic setups within a few applications to a centralized tax service or engine. Initially, that sounds great! Especially to those of us who have tried to implement tax complexities with limited features in 11i. Dig in and what you find is an engine capable of performing complex functions … except you have to define everything to make that engine function. It’s like having somebody ship you a frame for a car. You get to figure out what all the other parts are that you need, order them, and put them together! That can be challenging, whether you are building a Porsche or a Mini!

There are a few ready alternatives for partial content information … we can get rate files from some of the tax software vendors and use them to load rates, jurisdictions, and geographies. We can also use some of the content libraries provided by Oracle but they don’t cover all jurisdictions and some of the content is already outdated. And all that does is give us rates. We still have to determine all of the rules needed to use those rates correctly given the nature of each transaction.

Even if we know all of the rates and all of the rules that apply to every product we buy or sell in every jurisdiction in which we do business, is that really what we want our tax personnel and/or IT personnel spending their time researching and maintaining?

One of the features that is provided with R12 e-Business Tax (eBTax) is the ability to integrate with a third party tax software package like Vertex, Sabrix, or Taxware (tax provider). Those companies have done all the research to identify tax situations and legislation for each of the jurisdictions they support, they have programmed their engines with the rules that apply, and they perform ongoing research to update those rules as well as supply current rates for each jurisdiction and product category.

Maybe the best choice we can make is to use the service features of eBTax that allow it to integrate with a tax provider and let the tax provider do the heavy lifting!

Read More about “Making Sense of EBTax and Oracle R12” in our Perficient Perspective on the subject.