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.
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).
why we use reporting currency why not secondary ledger in GL
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.
what is the exact use of secondary ledger ? with example plz.
what is the exact use of secondary ledger? with example plz..
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.
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.
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.
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?
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?
Thanks
Durga