Multi – Currency Overview

iWare Logic > Blog  > Multi – Currency Overview

Multi – Currency Overview

(Oracle General Ledger R12.1 Feature)

Currency which is one of the four ‘C’ of a Ledger and ledger being a shared entity in Oracle Applications, leverages its multi-currency benefits in multi ferrous way viz., entering a transaction in foreign currency and reporting in your functional and reporting currency.
Basically, multi-currency refers to the ability of transactions being entered and reported in multiple currencies. It comprises of three main concepts:

  • Conversion
  • Revaluation
  • Translation

The above concepts are explained briefly as below:

  1. Conversion: Refers to a foreign currency transaction immediately converted in functional currency (i.e. the ledger currency).
  2. Revaluation: Adjusting the assets and liabilities that may be materially understated or overstated at the end of the period due to significant fluctuations in the exchange rates between the time the transaction was entered and at the end of period.
  3. Translation: Refers to the restatement of an entire ledger or balances for a company from functional currency to foreign currency.

Having understood of the above concept let us understand how does the multi-currency feature works in the above scenarios:


Consider the example as below:

A`Ltd.’ company registered and operating in India, sells goods on credit worth USD 1,000 to its customer located in US. A`Ltd`s functional currency is INR. The transaction happens on 01-APR-2014.

So, in the above example the company would be billing to its customer in USD however the US dollar denominated transactions (i.e. the foreign currency transaction) needs to be CONVERTED in INR while booking/recording an accounting entry in A`ltd’s ledger or the books.

…So there is a conversion happening

So in the above example following would be the components of a foreign currency journal:

foreign currency journal

From the above entry it would be clear that currency needs to be enabled and the daily rates for any given date of transaction needs to be uploaded in the Rate Type that you define. Following would be the three key setups need to be configured in a sequential manner depicted below:


So, in the above ex., rates can come as shown below:

Rate Type

*If we want the user to enter the rates as per the user discretion then at the transaction level
we must select User


Rate Type: Here we can setup different rate types depending upon the requirement and rates need to be uploaded or entered in the defined rate types. So at the transaction level the rates will default from the daily rates entered in the rate types.

Following are the rate types that can be defined

  • Spot
  • Corporate
  • User (Note it is one of the rate type)
  • EMU Fixed
  • User Defined

Consider the above example of A`ltd. supposingly, the balance of USD 1,000 remains unpaid as on 30-APR-2014 and books need to be closed as on that date for the month reporting purposes. But when the transaction was entered it was at Rs. 50 a dollar and now the rate has increased say for example to Rs. 52 a dollar. So, it would not be appropriate to report the receivables still at INR 50,000. It needs to be reported at INR 52,000 (52 x USD1000). Thus there is a difference of INR 2,000/- which is referred to as ‘Unrealized Gain’ arising due significant changes in the exchange rate between 01-APR-14 and 30-APR-14.

This is only one transaction but in actual business scenarios there might be hundreds of transactions entered not only in USD but in different currencies, dates and rates. All these foreign currency denominated transactions remained unsettled at the period end must be REVALUED.

…So there is a Revaluation happening

In order to perform revaluation, the following steps need to be followed:



After submitting the program named Program – Revalue balances, wait until the program is completed normally. Once it is completed you can enquire the Revaluation batch. You will find an unposted journal entry if you have unchecked the ‘AutoPost Revaluation’ while performing revaluation.

Even after generating an unpost revaluation journal, if at all the user thinks that the journal entry is not correct, one has an option to query the revaluation earlier submitted, change the parameters and resubmit the revaluation program.
Once the revaluation entry is generated the user can either set the journal for reversal or reverse it upfront.
Note : You must update the ‘Cumulative Translation Adjustment Account’ in your accounting setup manager, if you have reporting currency enabled. If you don`t update it, it will generate the revaluation journal in your functional currency, but while posting it will through an error as ‘CTA account failed validation.’ And only functional currency revaluation journal will be generated, its reporting currency representation journal will not be generated.

Following is a demonstrated example of revaluation:

In order to perform revaluation the user needs to follow the below steps:

Step-1: Navigate to Revaluation window

step 1 Navigate to Revaluation

Step-2: A Revaluation window opens wherein you need to enter the revaluation parameters as below:

step 2 revaluation parameters

Step-3: Click on the Revalue button above – a Program – Revalue Balances will open then in the parameters enter information as below:

step 3 Revalue Balances

Note: After submitting the program ensure that it completes with the status as normal.

Step-4: Query your journal batch in Journal window. The following journal would appear:

step 4 journal

Note the date and rate at which revaluation journal was created. The journal entry is created in your functional currency.
You can now select the journal for posting.

So, these are the steps that you need to follow while performing the revaluation.

Note: Sample examples are taken for performing the revaluation.

Translation refers to restatement of your Balance Sheet and Income & Expenditure statement accounts from functional to foreign currency.


General Ledger selects the translation rates based on the GL Account type and Translation rate type. The following table will summarize the rates and account balance type used for translation:

1 Assets Cumulative Balance Period-end rate
2 Liabilities Cumulative Balance Period-end rate
4 Revenue Periodic Balance Period average rate
5 Expense Periodic Balance Period average rate
6 Owner’s Equity Cumulative Balance Period-end rate unless historical rates are defined for these accounts.

As it can be evident from the above table that all of the Balance Sheet and Income Statement Accounts are translated at different rates there is a difference which is bound to occur. So the difference is accounted for in the ‘Cumulative Translation Adjustment’ Account (CTA). So this account must be specified in the Accounting Setup Manager.

Translation with Historical Rates and Amounts:

  • Historical Rates are the weighted average rates for transactions that occur at different times.
  • Historical rates are used to report journal entry line amounts in the units of money that were current when the transaction took place.
  • Historical balances are opposite of inflation adjusted balances

It is not usual that you use the same translation rate for all accounts. As you can see from the above table that different rates are used for different account types. For many assets typically the non-monetary items are to be carried at historical rates. Thus you need to set up historical rates before you run translation.

If you have defined historical rates or amounts, oracle GL selects one of the two amounts those are used to arrive at a translated balance for your account:

  • Account balance
  • Net Activity

However, the amount would differ depending on the type of account to which the historical rate or amount applies:

  • Revenue/Expense
  • Asset/Liability
  • Owner’s Equity

The translation has to be done using period to date (PTD) and year to date (YTD) rules:

  • Typically the Revenue/Expense accounts are translated using the PTD rules
  • Asset/Liability accounts are translated using YTD rules
  • Owner’s Equity is translated using the historical rate

Some useful reports are provided by Oracle GL are shown below:

Report - foriegn currency listing

Purpose of Reports:
Daily Conversion Rates Listing: Lists the conversion rates defined for a specific foreign currency and accounting period.
Historical Rates Listing: Lists defined historical translation rates and amounts.
Period Rates Listing: Lists defined exchange rates for any accounting period, including the period average and period end translation rates and revaluation rates.

– Harshad N Godbole
Oracle Apps – Functional Finance Consultant