Oracle EBS – Secondary Ledgers and Reporting Currencies

The intent of this document is provide the reader with a fundamental understanding of Oracle’s Secondary Ledgers, enriched with lessons learned from actual implementations. Matt Makowsky is an Oracle Financial Applications Consultant with 17 years experience and a Senior Solutions Architect with Perficient. Feel free to ask him any questions in the comments section below the blog.

Oracle EBS offers two ledger types in addition to the traditional “Primary Ledger”: Secondary Ledgers and Reporting Currency Ledgers.

To determine which to use, consider these basic business objectives:

1 – Accounting Presentation – does your business (for a given country), require a chart of accounts which is different than your functional ledgers’ chart of accounts?

2 – Calendar – does your business (for a given country), require a reporting calendar which is distinct from that of your primary ledger?

If the answer to either of these two questions is “yes,” then you will find you need a full Secondary Ledger, which has all of the functionality of a primary ledger.

In a secondary ledger, you may have a different chart of accounts, a different calendar, and a different currency. In addition, you may also define a reporting currency ledger that is directly connected to your secondary ledger.  You may also use special subledger accounting rules to create journals with different rules than your primary ledger.

In a reporting currency ledger, the ledgers accounting flexfield and calendar must be the same as the primary ledger, and you cannot hook another reporting ledger to a reporting ledger. The reporting currency, must however, be different from that of the primary ledger, whereas a secondary ledger can have the same currency as the primary ledger.

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

If you’re in any doubt, a full secondary ledger will be the preferred method, as you may decide shortly down the road that you will require some of its advanced features.  There is only a little more configuration involved, and it may pay off down the road.  You cannot however change the chart, currency, or calendar.  If any of those requirements change, you will need to build a new secondary ledger.

However if you decide to use a simpler reporting ledger instead, you can always manually migrate to a full secondary ledger at a later date, by downloading data from either your primary or reporting ledger and re-uploading via ADI.

Both types of ledgers will transfer data from the subledgers and post at the same time as the primary ledger. Reporting Ledgers will never have mapping issues, however currencies with exchange rates must always be in place to avoid errors in processing.

With the use of either ledger type, subledger data may be converted to display and report in the currency and accounting presentation of the secondary ledger or reporting ledger.  The program may only be run once, so it should be tested first in a test environment and evaluated to see if it meets your business needs.

Best Practices:

1 – Use a secondary ledger if your local requirements also require that the statutory ledger is stated in another currency.

2 – Use a secondary ledger if your chart of accounts or calendar must be different than your primary ledger.

3 – Choose “Subledger Level” postings in your configuration to obtain the most information out of your secondary or reporting ledger, especially if another currency is required for reporting at detail level.

4 – If at all possible, keep the calendar and flexfield the same so the ledgers may be joined in a ledger set.  This will enable responsibilities to link to both primary and secondary ledgers at the same time, as well as enable reporting across ledgers.

5 – If balances is all that is needed for a reporting currency, consider simply using translation.  Translation is only run at month end, and typically uses different rates between balance sheet and P&L accounts.  Cumulative differences are “plugged” into a cumulative translation adjustment account.  Consider your business needs prior to activating a reporting ledger rather than using translation.  Both will give you different results on foreign exchange, as reporting currency ledgers will pull the rate from the transaction in real time, and month end translation is working off of period end and average rates against balances.

6 – Name responsibilities that closely correspond to the names of your ledgers, so users know what they are accessing when the choose a specific responsibility.

7 – Use the profile GL: Data Access Sets rather than GL Set of Books Name to determine the access of the responsibility.  This will allow you to assign multiple ledgers to one responsibility (if they share the same chart and currency).