General Ledger & Intercompany

Get Involved. Join the Conversation.

Topic

    Sudhir K
    Loading Historical GL Balances for Reporting Ledgers in...
    Topic posted April 24, 2017 by Sudhir KRed Ribbon: 250+ Points, last edited January 30, 2019, tagged Financials, General Ledger, Period Close / Reconciliation, Reports 
    571 Views, 3 Comments
    Title:
    Loading Historical GL Balances for Reporting Ledgers in Fusion
    Summary:
    Loading Historical GL Balances for Reporting Ledgers in Fusion
    Content:

    Can you please let me know how to load historical GL balances for primary and reporting ledgers, when the translation between ledgers is set to convert on balances.

    we were asked us to use ‘forced’ or calculated currency rates, and load primary ledgers only and then copy the data to the reporting ledger using the rate.  However, this poses several big accounting / records (system of record) issues:

    1) Inevitably there are rounding issues that will cause discrepancies in calculated data (reporting ledger balances) – given that this would be a huge issue for publicly held companies, there must be an alternative approach
    2) Historical rates in Oracle will misrepresent the real historical rates in the prior system – again, false data
    3) The UK Primary ledger has 2 reporting ledgers:  one for USD and one for EUR for local statutory reporting.  There isn’t a clear way to input multiple F/X rates for each balance in the primary ledger, so how would the EUR balances be calculated?
    4) Certain accounts used for F/X gains/losses/translation would not have a balance in the primary ledger, but would have a balance in the reporting ledger

    Comment

     

    • Ba Kwon

      You will need to separately convert balances into the primary ledger and the reporting currency (or secondary) ledgers. You can define a journal source for the conversion journals to be excluded from the conversion of primary to RC (or secondary) ledgers.

      • Sudhir K

        Thank you Ba!

         

        Our partner is suggesting that we utilize the FX revaluation functionality on journal level detail to perform our FX translation in our reporting ledgers.   Are you aware of this being an acceptable way to configure Oracle cloud to address FX translation accounting?

    • Ba Kwon

      I think I understand the question, but somewhat puzzled by the statement FX revaluation functionality on "journal level detail".

      Revaluation is at GL balances, although the process takes into account the "Entered Balances" in the original currency for revaluation to produce the FX effect on "Accounted Balance" of the ledger currency. To use your example, let's say primary ledger currency is GBP and there is a USD RC ledger at sub-ledger level. If you have a bank account denominated in EUR, you would normally run Revaluation of the account in the primary ledger at end of month to GBP accounted balance, therefore creating an unrealized FX gain/loss effect. The Revaluation journal is replicated in the USD RC Ledger, hitting the CTA account. For Translation, you would normally use Balance Level Translation of the primary ledger -- taking the accounted GBP balance  and translate into USD for reporting. The Translation process creates a difference in CTA. For many customers, Balance Level Translation would meet their requirement. In this case, you report USD based on the translated balances in the primary ledger.

      When you have an RC ledger at sub-ledger level, everything is being replicated so there's no CTA (except where you run Revaluation in the primary ledger). However, you could run Revaluation in the USD RC Ledger, doing a "true up" of the USD balances and charging the difference to CTA -- this would be the account to use in defining the Revaluation, instead of unrealized gain/loss accounts. In this case, you would not use Balance Level Translation. We have customers that use this approach and it's perfectly acceptable.

      Which method to use depends on your requirements.

      Hope that answers your question.