How Does the Revaluation Process Work

Revaluation is the process of revaluing accounts that have transactions denominated in foreign currency. This is done for the account balance, not individual transactions. Revaluation can be done on any account, but typically, this is done for balance sheet accounts, whose balance is made up of open transactions (ie. Accounts Payable, Accounts Receivable).  Revaluation reflects the change in conversion rates between the date of the transaction and the date of the balance sheet.

On the Revalue Balances form (Currency>Revaluation), either specify the rate or let it default to the Revaluation rate calculated on the Period Rates form (Setup>Currencies>Rates>Period). Also, it is possible to revalue all accounts or to revalue only specific accounts by defining the accounting flexfield ranges on this form.

Note: This has changed with effect from 11i.FP.D/standalone patch 2532538. Please refer to Note 216504.1 About Oracle General Ledger in Financials Family Pack D

When revaluation is run, a journal entry is created that either increases or decreases the functional currency amount for that account, based on the fluctuation of the exchange rate.  The offset for this journal is a predefined Unrealized Gain/Loss Account.

The revaluation adjustment is created in the functional currency; this is where the fluctuation exists. Remember, the foreign currency of the transaction will stay the same; it is the functional currency equivalent that fluctuates.

When looking at the revaluation entry on the Enter Journals form, Entered Debits/Credits should be equal to zero. The Converted Debits/Credits should be the revaluation adjustment - there should be an amount here!

The AutoReversal program may be set to automatically create the reversing entry for the next period (see Note 120019.1 Currencies, Translations, Revaluation, Conversion FAQ:).
This is because revaluation is a temporary adjustment to the accounts, made in order to capture the effects of exchange rate fluctuation.
The realized exchange gain or loss is recognized at the time transactions are actually settled (i.e., When the receipt/payment of the foreign currency amount  takes place.)
If the system generated reversal entries are not posted, the beq fields in the  gl_balances table will not be cleared out.  Not clearing out the beq fields will cause subsequent periods revaluation results to be skewed as new balances will be co-mingled with the previously revalued amounts stored in the beq fields.
The system uses amounts stored in the beq fields in the calculation formula to determine the revalued amounts.

When entering a foreign currency journal, the system will prompt a required entry of a conversion rate that will convert the foreign currency amount to the functional currency. These are usually Corporate, Spot or User conversion rates.
Corporate and Spot rates are defined on the Daily Rates form setup>Currencies>Rates>Daily).
User rates are defined on the journal entry itself.
For any account that has foreign currency journals in it, there should be a row in gl_balances that represents the foreign currency balance for a given account,with the translated_flag set to "R". This flag indicates that the balance is a candidate for revaluation.  Also, as noted above, the converted functional currency amounts are stored in the gl_balances table in the columns ending with beq.

When running revaluation, the process goes out and picks up the balances that are stored for the foreign currency, where the translated_flag = "R", applies the revaluation rate that has been chosen, and calculates a new functional currency amount. It then calculates what is already existing in the table for the functional currency amount. It compares the two figures: What  is wanted for the new functional currency balance to be vs. what the current functional currency balance is. The difference between these numbers is then the revaluation adjustment.

Discrepancies with the revaluation adjustment amount can arise if functional currency adjustments are made to the account that is being revalued. This is because the foreign currency rows with translated_flag set to "R" are still in the gl_balances table. Remember that revaluation looks at these foreign currency rows with translated_flag set to "R", not the functional currency rows with no translated_flag. So if adjustments are made in functional currency, revaluation will not recognize this, and the revaluation adjustment will appear to be incorrect.

Questions have arisen regarding whether or not revaluation can be run twice in the same period. The answer is yes. For example, if revaluation has already been run and posted, then it is discovered that additional adjusting journal entries need to be made in that same period. Based on the Revaluation calculation, any additional journal entries posted after the initial Revaluation journal has been posted, will be picked up in the balances that are subsequently  revalued in that same period. The subsequent Revaluation journal entry will then represent the incremental change in the revalued balance, due to the additional  journal entries posted after the initial Revaluation.