Oracle eBTax and Operating units

With the introduction of Oracle R12 and the greater emphasis on shared service centres, can you afford not to use multiple Operating units?


The challenged faced by any company implementing a new ERP solution, whether a single entity or a global conglomerate, is to capture the complex business requirements and yet 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. There is also a risk that the solution initially designed to help the company, ultimately leads to issues that end up consuming more resource.

Any solution architect will be considering this when they design the organisation structure deciding the best approach for the number of ledgers, what legal entities will use these ledgers and how many operating units will be needed to capture the data from the sub ledgers such as the Payables or Receivable modules.

The 11i approach was often to keep things as simple as possible, with one ledger where possible and only one operating unit linked to this ledger. The primary driving factor was the time it would take to run reports, opening and closing the month and entering data across the different legal entities. Each additional Operating unit meant that a new responsibility was required and this meant that a user would have to switch between these responsibilities each time they wanted to enter any data or do any month end processes for example. If you had 10 legal entities, this meant that the same task, if 10 operating units were used, one for each Legal entity, would have to be repeated each time. This of course would take a huge amount of time compared to one operating unit that all 10 legal entities were assigned to!

Oracles’ ‘Release 12’ solution change the playing field and ultimately the way the organisations could be established. First, ledger sets allowed multiple ledgers to be linked together as a ledger set providing that the same calendar and chart of accounts was used. A ledger set could then be assigned to a responsibility effectively giving access to the data in all of those ledger contained in the ledger set! Second, and more importantly, the ability to create security profiles meant that access to operating units and inventory orgs could now be combined together. This means that those 10 legal entities could now have 10 operating units per legal entity and added to one or multiple security profiles. A security profile and not an individual operating unit could now be assigned to a responsibility, giving it access across all 10 operating units! So now the ability to maintain simplicity with one responsibility to enter data and process month end is achieved but with the added benefits of the diversification that multiple operating units can bring.

This document is intended to highlight the potential issues if the correct number of operating units are not used.

Recommended Approach

The minimal number of operating units needed should at least be one per country per legal entity. This means that if a legal entity is established in France and only operates in France then only one Operating unit is needed. If however a similar French legal entity is registered and located in france but also has legal branches in Germany and Italy, then 3 operating units would be the preferred route, one for each of the countries that the legal entity is registered in.

I would also apply this rule if a company had 5 legal entities in France, meaning that 5 operating units would be created, one per legal entity because each legal entity only has one country.

Difficulties faced

So, if a company for example decided to create one EUR ledger for Europe and only one operating unit for Europe instead of following the rule in the recommended approach, below would be some of the difficulties faced that may or may not lead to serious issues further down the path of the implementation project.

Default Data

With each operating unit, it is possible to set defaults which are used when transactions are entered, suppliers or customers created or setup done. The default currency for invoices being entered can be based on the operating unit, as is the accounting, such as the liability account or receivables accounts. With only one Operating unit, only one default can be used and as such either manual intervention is needed to change the value or custom code or SLA to ensure the correct account code combination is sent to the GL.

Party Data

Suppliers and customers when set up assign the sites to operating units. If only one operating unit is used then it is possible for the wrong supplier site to be chosen when an invoice is being entered. This would then lead to incorrect accounting hitting the GL which may not ever be discovered. Multiple Operating units limit the user to select only the sites that are linked to the operating unit that they are working with.Purchase Order Matching – If purchase orders are used then when matched, the purchase order will automatically select the correct operating unit without the user having to first choose the operating unit.

Month End Closing

It is often thought that having one operating unit assigned to multiple legal entities would make the month end close easier as all the month end steps can be applied at once. A responsibility that has a security profile assigned to it containing multiple operating units can perform the same month end tasks across all operating units at the same time making the close time the same as if only having one operating unit. However, as an added feature, if one there was an issue in closing one of the legal entities and multiple operating units were used, then it would be possible to close the other operating units to allow business as usual rather than having to delay the period close whilst the problems were resolved with the legal entity with the issue.

Printed Documents

Particularly in Europe, the printed documents that are sent out to customers such as statements or invoices need to comply to local statutory requirements. If only one operating unit is used then it is far harder to differentiate as to what data to put on to those printed documents. However, multiple operating units will allow for formatting, language and other statutory requirements per operating unit.

Payables Options by OU

Exclude Tax from Discount Calculation is only set once so if there is a legal requirement to not discount the tax then this would be difficult without this option which is set at OU level.

Country Localisations

Whilst Oracle has been designed to work in every country globally, the out of the box solution cannot meet every single statutory requirement for every country. For this reason, Oracle provides country specific localisations which when assigned, need to be differentiated from the ‘common’ solution. In order to do this, the localisations need to be assigned to specific responsibilities and often require a separate operating unit where custom code is needed. Utilising one operating unit for multiple legal entities that span multiple countries could cause issues that would need custom code to resolve.

Transaction Types

If only one operating unit is used then all the transactions types needed will be visible when being chosen potentially making it harder for a user to choose the correct value and risk making a mistake, choosing the wrong transaction type and generating a transaction for one legal entity that should have been for another. Multiple operating units would allow the transaction types, receipt classes, sources etc. to be linked and limited by the operating unit making it easier for users to choose the correct values to use.

Transaction Tax

Without doubt, one of the most import things to get right on any implementation is the transactions taxes being calculated and ultimately reported. Whether Sales and Use tax, VAT or GST, if taxation is not right then a company could be subject to huge fines and time consuming tax audits. The emphasis to get the tax solution correct is paramount for the success of any ERP implementation and the number of operating units can heavily influence the creation of the tax solution. Having multiple operating units, at least by country allows the tax to be easily controlled and confined to just that one country’s tax regime.

Tax ‘Bill From/To’ Address

The Bill from address for AR transactions and the ‘Bill To’ address for AP invoices comes from the address that is linked to the operating unit. This means that if only one operating unit is used then only one country can be used for the ‘Bill From’ and ‘Bill To’ values thus restricting its use for tax determination.

Tax Accounts

When a tax rate is created, it needs at least one tax account assigned to it which is done by linking the account to a ledger and an operating unit. For each operating unit that may use that particular tax rate, a tax account needs to be assigned to the rate. This means that a default tax account will be used for each operating unit. If only one operating unit is used that is linked to multiple legal entities (and we assume that each legal entity has its own balancing segment) then only one tax account can be assign to that rate. Customisation, usually by using SLA will then be needed in order to correctly determine what account to use and push to the GL. This of course can be avoided if an operating unit is used for each Legal entity per country.

Tax place of supply

For a tax regime to be selected to be used, it needs to match the country of the tax regime against the value determined by the place of supply rule linked to that regimes tax rules. The ‘place of supply rule’ will determine the country used in the ‘ship to, the ‘ship form’, the ‘bill from or ‘bill to’ and if this matches the tax regime country then the tax will be activated. As an example, if only one operating unit is used for a European rollout where the Finnish site (who is registered for VAT) sells a product to Sweden and ships from a distribution centre in the Netherlands then it is possible that the single Operating unit (the bill from) is in the Netherlands, the Ship from is also in the Netherlands and the Bill To and Ship To are Sweden, then at no state can the place of supply rule determine Finland and therefore not activate the Finnish VAT.

Tax Rules

Each tax regime needs to be assigned to the operating units that may use them. If only one tax regime is assigned to an operating unit then only that tax regime will ever be called upon. If an operating unit is used for multiple country tax registrations then each of those tax regimes are assigned to the operating unit. The more tax regimes assigned to an operating unit, the more complex the tax rules need to be in order to correctly determine the tax to be used as it is possible for multiple taxes to be determined for each transaction. With one tax regime per operating unit, the rules can be simplified as there is no possibility of the wrong tax regime calculating a tax for the transaction.

Organization Specific Taxes

When a tax solution is designed, it should be set up to not only meet the existing requirements but also those in the future. Oracle’s eBusiness Tax solution allows for taxes and rules to be assigned to the ‘Global Configuration Owner’, used by any operating unit that is assigned to that tax. It also allows for taxes and tax rules to be linked to specific operating units. If multiple legal entities share only one operating unit then it would not be possible to use this functionality and if one of those legal entities had specific tax requirements, then the tax solution has to be designed to apply to all! If each legal entity had its own operating unit then that one legal entity with the specific tax requirements could contain the special rules only to that operating unit – thus not affecting the others making the solution simpler and easier to maintain.

Migrated Data

When data is migrated into the newly created ERP solution, it is usually assigned to an operating unit (for Subledger data). If only one operating unit is used for multiple legal entities then at a later stage, it is far more difficult to pull that data out if it needs to be separated at a later stage, if the legal entity is sold off for example.Reporting – With multiple operating units, the reports can be run by operating unit and thus give another level to split the data out to make the reporting easier to see and also reconcile.


whether drop shipments or using AGIS, having multiple operating units makes it far easier to create intercompany transactions. If only one operating unit is used then intercompany transactions are limited using just one operating unit and the ship from and the ship to.

for a downloadable PDF copy, follow this link