Multi-Currency in Oracle ERP Cloud

By Peter Care posted 7 days ago


Oracle Financials Cloud is part of Oracle Fusion ERP Cloud and has extensive multi-currency functionality. Let’s take a look at the details of how this works, for transactions, balances, revaluations and translations.

Ledger Configuration

Balances for all accounts are held within a ledger, and are updated by financial transactions from all parts of Fusion Cloud.

Each Ledger has a single ‘Ledger Currency’, generally the prime reporting currency for the group of organizations represented within the Ledger. Oracle also has the ability to set up additional reporting currencies, more on those later.

 Multi-currency is relevant at two levels:

  • Multiple Ledgers in different currencies, that you may need to consolidate.
  • Transactions and balances in multiple currencies within a Ledger.

Foreign Currency Transactions

All financial transactions are in the context of a Ledger. Examples include Payables Invoices and Payments, Receivables Invoices and Receipts and GL Journals. The transaction currency defaults to its Ledger Currency, but you can change it to any enabled currency. If you do change it, the transaction is defined as a Foreign Currency transaction.  For these transactions, Oracle records the amount in Entered Currency (currency of the transaction) and Ledger Currency (the converted equivalent in the Ledger Currency). The conversion is done by looking up the current rate from a central Daily Rates table in the GL, using the:

  • Exchange Rate Type – type against which rates are stored, often defaulted from the business unit and module of the transaction
  • Exchange Rate Date – date to find relevant rate, set to the accounting date by default

If rates are not stored centrally, the special User rate type allows you to enter a rate on each transaction. Hence an invoice for 100.00 GBP for a purchase in your US entity, whose Ledger is in US dollars, would have 100 GBP converted to USD. If the rate stored in GL for GBP>USD, rate type ‘Corporate’, for the accounting date is 1.22, the invoice amount would be stored in two fields:

  • 100.00 GBP (Entered Currency field)
  • 122.00 USD (Ledger Currency field)

GL Journals

GL journals are created from accounted sub-ledger transactions. For Foreign Currency transactions, these journals are in the Entered Currency, with the Ledger Currency equivalent stored on each line.

A Receivables example looks like this:

The header of the journal shows Conversion Rate Type User and a Rate of 1, so clearly this is not used. A single journal from the sub-ledger could include multiple transactions using different rates, so instead the Ledger amount is stored on each line.

 If you create a journal directly in the GL, Oracle does use the header Rate Type and Conversion Date to convert all lines at the same rate.

 GL Balances

 Account balances are updated when journals are posted in GL. These balances are maintained in Foreign Currencies and Ledger Currency. Foreign Currency balances represent ONLY the journals in that Entered Currency. Ledger Currency balances are the sum of journals in ALL currencies, converted to the Ledger Currency, and so represent the total balance of an account. This means posting a Foreign Currency journal updates two balances. The 100.00 GBP invoice above would credit supplier liability balances:

  • GBP Balance: +100.00
  • USD Balance: +122.00

 Viewing the Ledger Currency balance is done by selecting Currency Type ‘Total’:


Foreign Currency balances are viewed using Currency Type ‘Entered’ and selecting a Currency:


Note that this second one shows both the Entered Currency (GBP) balance and the Ledger Currency (USD) balance resulting from the GBP journals.


 Revaluation is run in the GL to revalue Foreign Currency balances at latest Period End exchange rates. The process examines balances for each Foreign Currency and calculates difference between Ledger Currency equivalent amounts stored versus a conversion using the latest FX rate. It then posts this difference, in Ledger Currency only, with other side of the transaction using the unrealized gain/loss account.

 The revaluation journal is usually reversed in the next period, so it can be calculated again at the end of that period.

Translation and Reporting Currencies

 If you have multiple Ledgers in different currencies, you may need to restate each Ledger Currency balances in a global reporting currency, often as a first step to consolidation.

 The GL translation process typically uses Period End rates for Balance Sheet accounts and Period Average rates for P&L account. You can also use Historical Rates to override the rates with a fixed rate for certain accounts.

 Reporting Currencies are similar to translation in that the purpose is to translate all balances in the Ledger Currency to another currency. They can be configured at three levels:

  • Balance: this is actually the same as translation
  • Journal: journals are converted to the Reporting Currency during posting
  • Subledger: subledger accounting creates subledger Reporting Currency journals along with Ledger Currency journals

Journal or Subledger levels are generally only used when need more frequent reporting in another currency is needed, for example when the Ledger Currency is ‘unstable’.

Currency Rates and Sources

The Daily Rates stored centrally can be loaded via a spreadsheet or some fully automated background process like FXLoader.

Rates can be sourced from services such as OANDA, Refinitiv, Bloomberg, Xignite and XE, or various government/central banks around the world. They key is to use a source that matches the accounting principles and rules in each country. In the US, this is a source that reflects market rates accurately. In other locations, there is a statutory requirement to use rates published by the central bank. We see this a lot for Mexico, Brazil and other countries in Latin America, plus parts of Europe. A useful reference of central bank sources is here.