Translation

 Translation

Translation in Oracle Fusion Financials

 The four-way confusion you have to clear up first

 I'm going to start the same way I start every multi-currency conversation on a project, by separating four words that

  people use interchangeably and that mean completely different things in Oracle Fusion. If you don't pin these down,

  every later sentence about translation gets muddy. The four are conversion, revaluation, translation, and reporting

  currencies. They all touch foreign currency, they all involve exchange rates, and they are not the same operation.

 

  Conversion happens at the moment you enter a single transaction in a currency that isn't your ledger's currency. You

  raise a supplier invoice in euros, your ledger is in US dollars, and the system converts that one euro amount to

  dollars using the rate on that day. Conversion is transaction-level, it happens at entry time, and it's about getting

  one foreign-currency transaction expressed in your books' currency. It's the smallest unit of the whole multi-currency

  story.

 

  Revaluation is what you do at period end to your open foreign-currency balances — your foreign-currency receivables,

  payables, and bank balances — to restate them at the current period-end rate and recognize the unrealized gain or loss

  from rate movement since they were booked. You invoiced a customer 100,000 euros when the rate was 1.10, and at month

  end the rate is 1.15; revaluation books the unrealized gain on that open euro balance. Revaluation is about monetary

  balances denominated in a foreign currency and the gain/loss from rates moving while they sit open.

 

  Translation — our actual topic — is different from both. Translation takes your entire ledger, expressed in its

  functional currency, and restates the whole thing into a different currency, typically for consolidation or group

  reporting. Your subsidiary keeps its books in dollars, but the parent reports in euros, so you translate the whole

  dollar ledger into euros at period end. Translation operates on balances, across the whole ledger, and produces a full

  set of financials in another currency. It's not about individual transactions and it's not specifically about open

  monetary items — it's about converting a complete set of books from one currency to another.

 

  Reporting currencies are the structural feature that lets you maintain a parallel version of your ledger in another

  currency on an ongoing basis, at different levels of granularity. Translation is one way to get a reporting view in

  another currency (balance-level), but reporting currencies can also work at the journal or subledger level for more

  detail.

 

  So the clean one-liners: conversion is one transaction at entry; revaluation is open foreign balances at period end;

  translation is the whole ledger restated to another currency at period end; reporting currencies are the ongoing

  parallel ledger in another currency. Keep those four straight and the rest of this falls into place. The rest of this

  piece is about the third one — translation — but I'll keep relating it back to the others because the questions

  clients ask are almost always really about which of the four they need.

 

  Why translation exists at all

 

  Step back and think about the business reality, because it explains every technical rule that follows. You're a

  multinational group. Your German subsidiary naturally keeps its books in euros — that's its functional currency, the

  currency of its primary economic environment, the currency it pays salaries and suppliers in. Your US subsidiary keeps

  its books in dollars. Your UK subsidiary in pounds. Each one is perfectly happy in its own functional currency.

 

  But the group has to publish consolidated financial statements in a single currency — say the parent reports in US

  dollars. You cannot simply add up euros, pounds, and dollars; that's adding apples to oranges. Before you can

  consolidate, every subsidiary's complete set of financials has to be expressed in the common group currency. That

  restatement of a whole set of books from its functional currency into the group's reporting currency is translation.

  It's the prerequisite step that makes consolidation arithmetically possible.

 

  And here's the wrinkle that makes translation genuinely interesting rather than just "multiply everything by a rate":

  different types of balances get translated at different rates, and that's not an Oracle quirk — it's mandated by

  accounting standards (the FASB/IFRS rules on foreign currency translation, the current-rate method). Get the rate

  types right and translation produces clean financials that balance; get them wrong and you get a meaningless

  out-of-balance mess. So most of understanding translation is understanding which rate applies to which balance, and

  what happens to the difference that inevitably arises.

 

  The rate rules — the actual substance of translation

 

  This is the core of the topic, so let me be precise. When you translate a ledger, the system applies different

  exchange rates depending on the type of account, following the current-rate (closing-rate) method:

 

  Assets and liabilities — translated at the period-end rate. Your balance sheet's monetary and non-monetary asset and

  liability balances get translated at the closing rate for the period — the spot rate as of the last day of the period.

  The logic: these balances exist as at the period-end date, so you state them at the rate prevailing on that date.

  Cash, receivables, payables, fixed assets, inventory — all at period-end rate.

 

  Revenue and expenses — translated at the period-average rate. Your income statement accounts get translated at the

  average rate for the period. The logic: revenue and expense accrued throughout the period, not all on the last day, so

  an average rate better represents the rate at which that activity actually occurred across the whole period. Using

  period-end rate for the income statement would wrongly imply all the year's sales happened at the December 31 rate.

 

  Equity / owners' equity — translated at historical rates. This is the one people forget and the one that causes the

  most grief. Equity accounts — share capital, contributed capital, and so on — should be translated at the historical

  rate, meaning the rate in effect when that equity actually arose (when the shares were issued, when the capital was

  contributed). You don't restate share capital at today's rate every period, because the capital was raised once, at

  one historical rate, and that's the dollar value it contributed to the group. So equity uses historical rates that you

  maintain specifically for those accounts.

 

  Retained earnings — a special case. Retained earnings is the accumulation of prior periods' translated net income plus

  the current period's, and Oracle handles it through the translation process so that it ties to the cumulative

  translated results rather than being translated at a single current rate.

 

  Now stop and notice what those mixed rates do to the balance sheet. Assets and liabilities went in at the closing

  rate. Equity went in at historical rates. Income statement flowed in at average rates. There is no earthly reason

  those should still balance after translation — debits translated at one set of rates and credits at another set will

  not naturally equal. Translation, by its nature, breaks the fundamental accounting equation because it deliberately

  uses different rates for different lines. So something has to absorb the difference and force the translated balance

  sheet back into balance. That something is the Cumulative Translation Adjustment.

 

  The Cumulative Translation Adjustment (CTA) — the plug that makes it all work

 

  The CTA is the single most important concept in translation, and it's the one that separates someone who's truly

  understood translation from someone who just ran the process and hoped. When the system translates a ledger using

  mixed rates, the resulting imbalance — the difference between translated assets and translated liabilities-plus-equity

  — is captured in the Cumulative Translation Adjustment account, which sits in the equity section of the balance

  sheet.

 

  The CTA is not an error. It's a real number with a real meaning: it represents the net effect of exchange-rate

  movements on the group's net investment in that foreign subsidiary. As rates move period over period, the dollar value

  of the subsidiary's net assets moves too, and the CTA accumulates that effect in equity — specifically in other

  comprehensive income, not in the income statement. That last point matters: translation adjustments go to equity

  (OCI), they do not hit profit and loss. This is deliberate, because the gain or loss from translating a

  self-sustaining foreign operation isn't realized — it's a paper effect of rate movements that only crystallizes if you

  actually dispose of the subsidiary. So it parks in equity rather than distorting reported earnings.

 

  In Oracle Fusion you designate the cumulative translation adjustment account in your ledger setup, and the Run

  Translation process posts the balancing difference there automatically every time it runs. The CTA account is what

  guarantees the translated balance sheet balances despite the mixed rates. If your translated ledger is out of balance,

  in nineteen cases out of twenty the CTA account isn't set up correctly, or a rate is missing somewhere so the system

  can't compute the adjustment properly. The CTA is both the elegant solution to the mixed-rate problem and the first

  thing I check when a translation run goes wrong.

 

  There's also a retained earnings account you designate, and the relationship between how income statement net income

  closes to retained earnings and how the CTA absorbs rate differences is the heart of why translated financials hold

  together. When I'm troubleshooting, the CTA account and the retained earnings account assignment in the ledger are the

  two settings I verify first.

 

  The rates you have to maintain

 

  Translation is only as good as the rates feeding it, so part of the work is making sure the right rates exist before

  you run anything. In Fusion you maintain rates in the currency rates setup, and for translation specifically you care

  about:

 

  Period-end rates — the closing spot rate for each currency pair as at each period end, used for assets and

  liabilities. These have to be loaded for the period before you translate, or the run fails or produces nonsense.

 

  Period-average rates — the average rate for each period, used for income statement accounts. You either load these or

  have them derived, depending on your setup.

 

  Historical rates and historical amounts — for equity accounts. This is a manual-ish, deliberate maintenance task. You

  can specify either a historical rate for an account or even a historical amount (the actual fixed translated value you

  want that equity account to carry, regardless of rate). The historical amounts/rates screen in the translation setup

  is where you control how equity translates, and neglecting it is a classic cause of equity translating "wrong" and

  throwing the CTA off.

 

  The rates live in the GL Daily Rates / currency rates structures, and there are conversion rate types (like the

  "Corporate" rate type, "Spot," "User," or custom types) that organize which set of rates is used. For translation you

  point the process at the appropriate rate types for period-end and average. Loading rates can be manual entry,

  spreadsheet upload, or — common in mature shops — an automated feed from a market-rate provider into the daily rates

  tables. The discipline of "are this period's translation rates loaded?" needs to be a line on the close checklist,

  because translation simply cannot run correctly without them, and the failure mode (missing rate) is one of the most

  common support calls.

 

  Running translation — the mechanics

 

  Operationally, translation in Fusion GL is a process you run per period, per target currency. You find it in the

  General Accounting work area / Period Close work area — the Translate action, which submits the Run Translation

  process (the Translation program). You select the ledger, the target currency you're translating into, and the period,

  and submit.

 

  A few practical realities about running it:

 

  Order in the close. Translation runs after you've completed the period's accounting in the functional currency — after

  posting, after revaluation of foreign balances, ideally after the period is substantially closed in the source

  currency. The sequence usually is: enter and post all transactions → revalue open foreign-currency balances →

  translate the whole ledger to the reporting currency → consolidate. Running translation before you've finished posting

  just means you translate incomplete numbers and have to re-run.

 

  Re-running. You can run translation multiple times for a period — if rates change or you post more entries, you

  re-translate and it recalculates. Translation is generally re-runnable, which is forgiving, but you want your final

  translation to be on final functional-currency numbers and final rates.

 

  First-time / retroactive considerations. The first time you translate a ledger, or if you've changed period-end

  balances in prior periods, the system has to handle cumulative effects. There are nuances about translating prior

  periods and ensuring continuity of the CTA across periods — translation is inherently cumulative, since the CTA

  accumulates, so you generally translate periods in sequence rather than skipping around.

 

  Output. The result is a full set of translated balances in the target currency, which you can then report on exactly

  like any ledger balances — Financial Reporting Center, OTBI, Smart View, account inspector — but now showing the books

  in the reporting currency. And those translated balances are what feed consolidation.

 

  Translation versus reporting currencies — the structural choice

 

  Now I need to connect translation to the reporting currencies feature, because they overlap and clients constantly ask

  which to use. A reporting currency in Fusion is a representation of your ledger in a different currency, and Oracle

  supports it at three levels of granularity:

 

  Balance-level reporting currency. Here you only maintain the balances in the other currency, and you populate them by

  running translation. This is, in effect, translation institutionalized as a standing reporting view. It's the lightest

  touch — you get translated balances for reporting and consolidation, but you don't get individual transactions in the

  reporting currency. For most consolidation needs, balance-level (i.e., translation) is exactly enough.

 

  Journal-level reporting currency. Here every journal posted to the primary ledger is also converted and posted to the

  reporting currency in real time, so you have journal-by-journal detail in the second currency, not just period-end

  balances. More overhead, more detail.

 

  Subledger-level reporting currency. The most granular — even subledger transactions are maintained in the reporting

  currency. Heaviest, most detailed, used when you genuinely need transaction-level books in two currencies (some

  statutory situations demand it).

 

  The way I frame the choice for clients: if you only need the consolidated/reporting view in another currency at period

  end, balance-level reporting currency populated by translation is the right, lightweight answer — and that is

  "translation" in the everyday sense. If you need transaction-level detail in the second currency — because of

  statutory requirements or because you genuinely operate the books in two currencies — you step up to journal-level or

  subledger-level reporting currencies, which carry conversion at entry rather than translation at period end. Most

  consolidation-driven requirements land on balance-level/translation. The heavier levels are for when the second

  currency isn't just for reporting but is a real operating currency for that entity.

 

  This is also where secondary ledgers enter the picture — a secondary ledger can be maintained in a different currency

  (and even a different chart of accounts or calendar) from the primary, and currency is one of the "four Cs" that can

  differ. When an entity needs a fully separate set of books in another currency for statutory reasons, a secondary

  ledger in that currency may be the answer rather than translation of the primary. Knowing when to reach for a

  reporting currency versus a secondary ledger is a genuine design decision, and it hinges on whether the differences

  are only currency (reporting currency suffices) or also chart/calendar/accounting-method (secondary ledger).

 

  Translation versus revaluation — keeping them apart

 

  I want to come back and sharpen the translation-versus-revaluation distinction specifically, because these two are the

  most-confused pair in the whole area, and they both happen at period end which makes it worse.

 

  Revaluation acts on the foreign-currency-denominated balances within your functional-currency ledger. You're a dollar

  ledger holding some euro-denominated payables. Revaluation restates those euro items at the period-end rate and books

  the unrealized gain/loss to the income statement (it's a P&L item — realized when settled, unrealized at period end).

  The scope is only the foreign-currency monetary balances, not the whole ledger, and the result hits profit and loss.

 

  Translation acts on your entire functional-currency ledger and restates all of it into a different currency. The

  balancing difference goes to the CTA in equity, not to the income statement. The scope is the whole ledger, and the

  result is parked in equity, not P&L.

 

  So three clean contrasts: revaluation touches only foreign-currency items, translation touches everything; revaluation

  produces a P&L gain/loss, translation produces an equity CTA; revaluation keeps you in your own ledger currency,

  translation moves you to a different currency. And the sequence: you revalue first (in functional currency, period

  end), then translate (to reporting currency). Revalue, then translate. If you can recite that — different scope,

  different destination (P&L vs equity), different currency, and revalue-before-translate — you've genuinely separated

  the two, and you'll dodge the single most common conceptual error in multi-currency accounting.

 

  Setup checklist — what has to be in place

 

  Pulling the configuration together, here's what must exist before translation works:

 

  The ledger's currency and the target currency. Your primary ledger has its functional currency; you're translating

  into another currency, which you set up as a balance-level reporting currency (or you translate ad hoc to a target

  currency for reporting).

 

  The Cumulative Translation Adjustment account. Designated in the ledger / reporting currency setup. This is

  non-negotiable — without it, translation cannot balance. It's an equity-section account.

 

  The Retained Earnings account. Also designated; translation relies on it for the cumulative-results handling.

 

  Currency rates. Period-end rates and period-average rates loaded for the relevant currency pairs and periods, under

  the correct rate types, before you run.

 

  Historical rates / historical amounts for equity. Maintained deliberately so equity accounts translate at their

  historical values rather than getting swept along at current rates. This is the easily-forgotten step that throws the

  CTA off when neglected.

 

  Conversion options on the ledger — the settings that govern how the reporting currency and translation behave,

  including which rate types feed which balance types.

 

  Once those are in place, the period-end routine becomes: finish posting in functional currency, run revaluation, run

  translation to the reporting currency, verify it balances (CTA absorbed the difference cleanly), and

  report/consolidate.

 

  A worked example to make it tangible

 

  Let me ground all of this. Your German subsidiary keeps books in euros (functional currency EUR). The group reports in

  US dollars (USD), so each period you translate the EUR ledger into USD.

 

  At December 31, the closing rate is 1 EUR = 1.10 USD; the period-average rate for the year was 1.08; share capital of

  1,000,000 EUR was contributed years ago at a historical rate of 1.20.

 

  - Assets total, say, 5,000,000 EUR → translated at the closing rate 1.10 → 5,500,000 USD.

  - Liabilities total 2,000,000 EUR → at closing rate 1.10 → 2,200,000 USD.

  - Share capital 1,000,000 EUR → at historical rate 1.20 → 1,200,000 USD (not 1.10 — that's the whole point of

  historical rates).

  - Revenue and expenses flowed in at the average rate 1.08, producing translated net income that closes to retained

  earnings.

 

  Now add up the translated credit side — liabilities 2,200,000 + share capital 1,200,000 + translated retained earnings

  — and compare to translated assets 5,500,000. Because assets used 1.10, equity used 1.20, and income used 1.08, the

  two sides won't naturally match. The difference — whatever it is — posts to the Cumulative Translation Adjustment in

  equity, and that is what makes the translated USD balance sheet balance. The CTA isn't fudged; it's the genuine

  cumulative effect of rate movements on the group's net investment in the German subsidiary, and it lives in equity /

  OCI, never touching the income statement.

 

  Next period, rates move again, you re-run translation, and the CTA accumulates the new effect on top of the old —

  which is exactly why it's called the cumulative translation adjustment, and why you translate periods in sequence

  rather than in isolation.

 

  That single example exercises every rate rule (closing for assets/liabilities, average for income, historical for

  equity), the CTA as the balancing plug, the equity/OCI treatment, and the cumulative nature of the adjustment. If you

  can narrate it, you understand translation.

 

  Common pitfalls I watch for

 

  A handful of things that reliably cause trouble:

 

  Missing rates. The number-one cause of failed or wrong translation. The period-end or average rate for the currency

  pair simply isn't loaded for the period. Build "rates loaded?" into the close checklist.

 

  Unset or wrong CTA account. If the cumulative translation adjustment account isn't designated, or points somewhere

  odd, the translated ledger won't balance and the whole run is suspect. First thing I verify.

 

  Neglected historical rates for equity. Let equity translate at current rates by accident and your equity section is

  wrong and your CTA is distorted. Maintain historical rates/amounts deliberately.

 

  Confusing translation with revaluation. Teams run one when they needed the other, or skip revaluation and go straight

  to translation, leaving open foreign balances unrevalued before the whole-ledger restatement. Revalue first, then

  translate.

 

  Running translation on incomplete numbers. Translate before posting is finished and you've translated a draft.

  Translation is re-runnable, but your final translation must be on final functional-currency balances.

 

  Out-of-sequence periods. Because the CTA is cumulative, translating periods out of order or skipping a period creates

  continuity problems. Translate in sequence.

 

  Expecting translation gains to hit P&L. Some users hunt for the translation gain in the income statement. It's not

  there by design — it's in equity (CTA / OCI). Only revaluation hits P&L; translation hits equity.

 

  Closing thought

 

  Translation in Oracle Fusion is, at its core, the disciplined restatement of a whole ledger from its functional

  currency into a reporting currency so that a multinational group can consolidate apples with apples. Everything

  technical about it flows from one accounting reality: different balance types get translated at different rates —

  closing rate for assets and liabilities, average rate for income and expenses, historical rates for equity — and

  because those rates differ, the balance sheet can't naturally balance, so the Cumulative Translation Adjustment in

  equity absorbs the difference. That CTA is the elegant heart of the whole mechanism, and it's the first place to look

  when something goes wrong. Keep translation firmly separate from its three cousins — conversion at the transaction,

  revaluation of open foreign balances to P&L, and reporting currencies as the standing parallel-ledger structure — and

  the period-end routine becomes a calm, repeatable sequence: post, revalue, translate, consolidate. Get the CTA and

  retained-earnings accounts set, keep the rates loaded and the equity historical rates maintained, run the periods in order, and translation quietly does exactly what the group needs it to do, month after month.