Skip to main content


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.

Oracle - Guide to Oracle Cloud: 5 Steps to Ensure a Successful Move to the Cloud
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).

Thoughts on “Oracle EBS – Secondary Ledgers and Reporting Currencies”

  1. Matt Makowsky Post author

    Use of reporting currencies is far easier than Secondary Ledger if you use the same chart of accounts and SLA rules.
    Secondary Ledger has more flexibility. You have to evaluate your own requirements against the functionality.

  2. Matt Makowsky Post author

    If you need a different chart of accounts, or different SLA rules, or anything just more complicated than currency. Secondary Ledgers are designed to give you a totally different accounting representation. A Reporting Ledger is designed just to give you a currency difference.

  3. If there is a legal requirement for countries to report local Forex rates and Fixed Assets depreciation and asset useful etc., applicable for the local government reporting purposes. Would it be possible to update these specific requirement in Secondary ledger? Please advise with some examples.

  4. Am not sure about the fact of using a reporting currency. I already have a secondary ledger because the natural accounts are different. If i need just to have a reporting monthly in both currencies. It might just be done by using translation? Thank you in advance for your explanation.

  5. We have created a new secondary ledger mid-year. Payments made for existing invoices are not getting accounted as the invoice does not exist in SL. How do we handle this scenario?

  6. Hi Matt,
    We have a requirement for having a Reporting Ledger. The COA, currency and Calendar will remain same as the Primary but our requirement is to report some special transactions (coming from one of our custom application) to a new ledger (only for reporting). Do you think , its better to define a secondary ledger in this situation?
    Or is there any better way of doing it?


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Matt Makowsky

Matthew is the managing director of Perficient's Oracle ERP practice. He has 19 years of experience in Oracle Financial Applications which include 5 large-scale, global, full cycle implementations across multiple industries and multiple countries across Europe and Latin America, plus upgrades across many release of Oracle EBS.  Matthew has extensive application experience in General Ledger, Accounts Payable, Accounts Receivable, and Fixed Assets.  In addition he has managed implementations ranging from 2-3 people to as many as 100 people.  Matthew is personable, and has both excellent written and verbal communication skills.  Matthew has experience conducting workshops– both formal and informal and is charged with driving design sessions.   Matthew’s application experience extends into supply chain modules including purchasing, order management, and inventory, and with that he is able to guide our clients through month end and financial reporting, seamlessly, end to end.

More from this Author

Follow Us