Oracle EBS – Multi Org vs. Single Org

Enterprise Design in EBS is one of the first things you tackle when beginning a new client engagement. It will likely include chart of accounts design, number of business groups, ledgers, legal entities, operating units (OU), and inventory organizations. This document will brush lightly on a few of these areas but will focus primarily on the concept of operating unit.

The operating unit sits directly below the ledger in the enterprise design. For point of reference, inventory organization is directly below the OU. A ledger may have multiple OUs, and an OU may have multiple inventory organizations.  An OU may only belong to one ledger, and an inventory organization may only belong to one OU.

Over the years, I have come across a lot of confusion at client sites as to the use and purpose of the OU.  It goes without saying, that at minimum, your enterprise will require at least one OU per ledger if that ledger has Accounts Payable and/or Accounts Receivable activity, if it is required to hold inventory, conduct sales, or write purchase orders.  Sometimes the question arises, “Do we need more than one OU for that ledger?” and the confusion arises as a result of not fully understanding the purpose of the OU and how it works in the most simplistic terms.

The OU, in laymen terms, organizes and segregates your data from other sources of operations.  This prevents you from mixing apples and oranges.  And if you have two totally different companies working out of the same home currency (one ledger), with their own bank accounts for paying bills and issuing invoices, you may very well want to create a separate OU.

Looking at the OU from a simple Payables perspective, you need only ask one basic question: Can you or Do you use one bank account to pay all your bills for a given ledger (home country).  If that answer is YES, then you need to challenge yourself pretty hard to find rationale to open up multiple OUs within a single ledger.  This is because Oracle will simply pay all bills within an OU, without regard for the bank account/legal entity arrangement.  It is designed for shared services functionality, meaning that one group within an organization, within a country, pays all the invoices for all legal entities.  If in fact this is not the case, and each legal entity has its own paying bank account, and you do not operate in a shared services model, you should consider multiple OUs, especially if there are concerns for liabilities and taxes.

Many people express concern over the ability to cross charge legal entities within a single OU.  As long as those legal entities are members of the same ledger, then yes, you can charge one invoice to multiple legal entities, and providing your intercompany accounting rules have been properly setup, then Oracle will handle the cross charges by adding in intercompany lines.  This functionality allows you then to enter invoices without concern for the legal entity relationships.  When running your payment batch, all invoices (due for payment) will be swept into the batch.

Case Study:

International Clothing Retail with 3,000+ retail locations (under different brand names), operating in North America, Latin America, and EMEA

Oracle Footprint: GL, AP, FA, PO, Inventory (for supplies only).

Initial Design Decision: One OU per brand within the North America implementation, under one USD Ledger

After several weeks on site, we found that the Payables team was struggling to understand when to enter an invoice under OU for brand A versus the OU for brand B.  Especially for invoices that are charged across all the brands, such as a utility bill.

Guide to Oracle Cloud: 5 Steps to Ensure a Successful Move to the Cloud

Explore key considerations, integrating the cloud with legacy applications and challenges of current cloud implementations.

Get the Guide

We asked one key question: “Do you care who pays the bill?”  The answer was a simple: Well, NO, because we only have one bank account anyway.

Once that simple question was asked and answered, we very quickly shut down all the other operating units.  In fact, in our next test environment, we did not even configure them.  They served absolutely no purpose.  They did not match up to the legal entity structure (which was property based, and not brand based), and did not match up to how they operated.

They were initially directed to use 8 operating units because of the legal entity on the payables account (they have one legal entity per major brand, but is not a true legal entity).  They wanted this legal entity to match the legal entities on the expense distributions (mind you, in this context, the legal entities were only representing the brand, and not the actual true legal entities).  The only purpose in this setup was to make sure a balance sheet could be produced at the brand level, with each brand holding its own liability.  Oracle has a simple setup to resolve for this functionality, without having to enable multiple operating units, and that is the “Balancing Option” in Payables Options.  With a simple flip of a flag, each invoice could have multiple liability accounts, and when paid from the single bank account, intercompany accounting would close the loop between the banks legal entity and the invoices multiple legal entities.  Once this issue was resolved, the client had no purpose for multiple OUs.

It should be noted that this client had no need for Receivables and was not issuing any customer facing documents which might require unique branding based on the store name where the purchase took place.  However, even if that were the case, similar tricks can be configured in Receivables and Order Management to utilize multiple brands within a single operating unit.

In short, within a country, within a ledger, all best efforts should be made to keep a single OU with the following litmus tests:

1 – Do you pay your bills out of one or multiple bank accounts?

2 – Does your AR and AP departments operate with the same group of people?  ie: Are your collectors the same across all of your customers, are your payables associates entering bills for all of your operations?

3 – Is there a large overlap in suppliers and customers across the operations?

4 – Are legal relationships between your company and your customers and suppliers uniform across the enterprise?

5 – Are sales tax rules the same across the enterprise within the country?

If the answers to these questions are yes, then best efforts should be made to create and live within a single OU.

Why avoid mulitple OUs?

Without a true purpose, multiple OUs can cause confusion for end users.  Even with a true purpose, it adds complexity to your system.  Each OU requires a unique set of responsibilities and security rules.  Role assignment can become more complex.  If you’re going to entertain multiple OUs within a single ledger then the following should be clear:

1 – You have distinct legal obligations that are uniquely different across each OU.

2 – You have bank accounts that, for purposes of payments and receipts, cannot be co-mingled with other bank accounts.

3 – Your operations are vastly different, and different groups of people work within them, different collectors and different payment groups, ie: your organization is not setup for shared services.

Oracle has made it easier in Release 12 to move across OUs by placing an OU field within each transaction.  And yet many clients have asked that this be turned off, creating one unique responsibility that has access to only one OU.  This is because of “user error”, and they wish to force their users to pick an absolute OU to work within, especially for large batches.  This defeats the purpose of attempting a shared services model across multiple OUs, forcing users to constantly switch responsibilities.

In conclusion, from this consultants point of view, keep your implementation simple.  If anyone thinks you need multiple OUs within a given ledger, be sure to ask some basic questions as outlined above.  In 17 years, I have had one client which actually required multiple OUs within one ledger, and they “failed” all the basic questions in that they OUs were of completely different industries, different members in ownership, different legal entity models, unique employees, vendors,  and bank accounts.