Revaluation

 Revaluation

Revaluation in Oracle Fusion Financials

 What problem revaluation actually solves

 Let me start with the situation that creates the need, because revaluation makes no sense until you feel the problem

  it fixes. Your ledger runs in US dollars. Back in October you booked a supplier invoice for 100,000 euros, and on that

  day the rate was 1 EUR = 1.10 USD, so the invoice sat in your books at 110,000 dollars. Fast forward to the end of

  December. You still haven't paid that euro supplier — the payable is open — and now the rate has moved to 1 EUR = 1.20

  USD. That same 100,000-euro obligation is, in dollar terms, now worth 120,000 dollars. You owe 10,000 dollars more

  than your books currently say, purely because the exchange rate moved.

 

  Your December 31 balance sheet still shows that payable at the old 110,000. That's wrong. As at the reporting date,

  the dollar value of a 100,000-euro liability is 120,000, and accounting standards (both IFRS and US GAAP) require you

  to restate open foreign-currency monetary balances at the period-end rate so the financials reflect their true value

  as of that date. The 10,000 difference is an unrealized loss — unrealized because you haven't actually paid yet; the

  loss only becomes real when you settle. Revaluation is the period-end process that performs exactly this restatement

  and books that unrealized gain or loss.

 

  So in one sentence: revaluation restates your open foreign-currency-denominated balances to the period-end exchange

  rate and recognizes the resulting unrealized gain or loss. Everything in the rest of this piece is detail hanging off

  that single idea.

 

  The word "monetary" is doing a lot of work

 

  Before going further I have to stress one qualifier, because it's the thing people get wrong: revaluation applies to

  monetary balances denominated in a foreign currency. Monetary items are things that will settle in a fixed number of

  currency units — receivables, payables, foreign-currency bank accounts, foreign-currency loans. They have a

  contractual cash amount in a foreign currency, and that's exactly why rate movement changes their home-currency value

  and why they need revaluing.

 

  Non-monetary items — fixed assets, inventory, prepayments — generally are not revalued, because they don't represent a

  fixed claim to foreign currency that fluctuates with the rate. A building doesn't owe you euros. So when you scope a

  revaluation, you're targeting the accounts that hold open foreign-currency monetary balances: your foreign AP, foreign

  AR, foreign cash, foreign loans. Scoping revaluation across accounts that shouldn't be revalued is a classic setup

  error that produces meaningless gains and losses, so the account selection in the revaluation definition matters a

  great deal, and I'll come back to it.

 

  There's also the matter of open versus settled. Revaluation cares about balances still outstanding at period end — the

  invoice you haven't paid, the receivable you haven't collected. Once an item is settled, the gain or loss on it is

  realized at the point of settlement (handled by the subledger or at conversion), and it's no longer revaluation's

  concern. Revaluation is specifically about the unrealized effect on what's still open.

 

  Unrealized versus realized — the distinction that defines everything

 

  This pairing is the conceptual spine of the whole topic, so let me be precise.

 

  An unrealized gain or loss is a paper effect. The rate moved, so the home-currency value of your open foreign balance

  changed, but nothing has actually happened in cash terms — you haven't paid or collected. It's a "what would this be

  worth today" adjustment. Revaluation books unrealized gains and losses, and crucially it books them to the income

  statement (a P&L gain/loss account), because under the standards the change in value of monetary items goes through

  profit and loss.

 

  A realized gain or loss happens when you actually settle the transaction at a rate different from the one it was

  booked at. You finally pay that 100,000-euro invoice, and the rate that day is 1.18 rather than the 1.10 you booked it

  at, so the cash you part with differs from the recorded liability, and the difference is a realized loss — it's real,

  it's in cash, it's locked in. Realized gains and losses are handled at the point of payment/settlement in the

  subledgers, not by the GL revaluation process.

 

  Here's the elegant part that ties them together, and it's the reason for a feature I'll detail shortly. Because the

  unrealized gain or loss you book at period end is just a snapshot estimate that will be superseded by the real outcome

  when the item eventually settles, the standard practice is to reverse the revaluation entry at the start of the next

  period. You revalue at December 31 to make the year-end balance sheet correct, then on January 1 you reverse that

  entry, putting the balance back to its original booked value, so that when the item actually settles you compute the

  true realized gain/loss cleanly without double-counting the estimate. Revalue, then auto-reverse — that pattern is

  fundamental to how revaluation is meant to operate, and I'll explain the mechanics when I get to running it.

 

  Setting up a revaluation — the revaluation definition

 

  In Oracle Fusion GL, revaluation is driven by a revaluation definition — a saved, reusable specification of what to

  revalue and how. You create and manage these in the General Accounting / Period Close work area (the "Manage

  Revaluations" or "Create Revaluation" task launches the definition). Building one well is most of the skill, so let me

  walk the key parts:

 

  The currency or currencies to revalue. You tell the definition which foreign currency (or currencies) it covers. You

  might have one revaluation for your euro exposure, another for sterling, or a single definition spanning all your

  foreign currencies — design choice. The definition needs to know which currency's open balances it's restating.

 

  The rate type and the period-end rate. Revaluation uses the period-end (closing) rate for the currency, and you

  specify which conversion rate type supplies it — commonly your designated period-end or "Spot" rate type, or a custom

  one. The whole calculation hinges on this rate, so it must be loaded in the currency rates tables for the period

  before you run, or the process fails or produces nothing. The system takes each open foreign-currency balance,

  recomputes its home-currency value at this period-end rate, and the difference versus the currently-recorded

  home-currency value is the gain or loss.

 

  The unrealized gain and loss accounts. You designate the account(s) where the unrealized gain and the unrealized loss

  get posted. These are income-statement accounts (often a foreign-exchange gain/loss line). You can specify a single

  account used for both gains and losses, or separate accounts for gain and for loss — many organizations split them so

  the P&L shows gross FX gains and gross FX losses rather than a net figure. This is part of the definition, and it's

  worth confirming with the client's accounting policy whether they want net or gross presentation.

 

  The accounts to revalue — the account ranges / filters. This is the scoping piece I flagged earlier. You specify which

  accounts the revaluation should examine — your foreign AP control account, foreign AR, foreign bank accounts, foreign

  loans. You define this as account ranges or with the account filter, and getting it right is critical: include

  accounts that hold open foreign-currency monetary balances, exclude the ones that don't. Over-scope it and you revalue

  things that shouldn't move; under-scope and you miss real exposure. I always tie this scope back to the chart of

  accounts and confirm exactly which natural accounts carry foreign-currency monetary balances.

 

  The balancing and tracking options. Revaluation has to balance — the gain/loss is one side, and the other side adjusts

  the revalued account's balance. There are also options around how the revaluation is tracked, including by currency,

  so you can see the effect per currency. Some setups track the unrealized gain/loss with a counterpart so the balance

  sheet account reflects the restated value.

 

  Days-to-run / date considerations. You run a revaluation as of a date (the period-end date), and that date determines

  which balances are "open" and which rate applies. The definition plus the run parameters pin down the as-of date.

 

  Once the definition is built and saved, it's reusable every period — you don't rebuild it each month; you just run it

  for the new period with the new period-end rate. That reusability is the point of having a definition rather than an

  ad-hoc process.

 

  Running revaluation — the mechanics and the auto-reverse

 

  Operationally, you run a saved revaluation definition for a period from the Period Close / General Accounting work

  area — the Run Revaluation process. You pick the definition, the period (and as-of date), confirm the rate is in

  place, and submit. The process:

 

  1. Reads each open foreign-currency balance in the scoped accounts.

  2. Recomputes its home-currency value at the period-end rate.

  3. Compares to the currently-recorded home-currency value.

  4. Generates a revaluation journal posting the difference to the unrealized gain or loss account, with the offset

  adjusting the revalued balance.

 

  The result is a journal (typically in your manual or a dedicated revaluation source) that you can review before or

  after posting depending on your setup. As with most period-end processes, my advice is to review the first runs rather

  than blindly auto-post, and tie the gain/loss back to a couple of balances by hand to confirm the rate and scope are

  right.

 

  Now the auto-reverse, which is the operational embodiment of the unrealized/realized logic. Because the revaluation

  entry is a period-end estimate that must not contaminate the real settlement outcome, you configure the revaluation

  journals to automatically reverse in the next period. Fusion's automatic reversal capability (journal reversal

  criteria / auto-reverse setup) lets you flag the revaluation journal category so that the reversal is generated and

  posted at the start of the following period — either automatically or by running the reversal process. So the rhythm

  each month is: run revaluation at period end → it books the unrealized gain/loss → the balance sheet is correct at the

  reporting date → at the start of next period the entry reverses → the balance returns to its booked value → and

  either it settles (realized gain/loss computed cleanly) or it's still open and gets revalued again at the new period

  end.

 

  Setting up the automatic reversal criteria for the revaluation journal category is therefore part of a proper

  revaluation implementation, not an afterthought. If you revalue but don't reverse, you double up — the next period's

  revaluation stacks on top of an estimate that was never backed out, and the gain/loss balances drift into nonsense.

  "Revalue and reverse" is the rule; forgetting the reverse half is a common and damaging mistake.

 

  Where the period-end sequence puts revaluation

 

  Revaluation has a specific slot in the close, and getting the order right matters. The functional-currency-side

  sequence is roughly:

 

  1. Enter and post all transactions for the period (including foreign-currency transactions, which get converted at

  entry).

  2. Reconcile subledgers to GL.

  3. Run revaluation of open foreign-currency monetary balances — this is now, near the end, once posting is complete,

  because revaluation must act on the final open balances.

  4. Then, if you're a multinational consolidating into another currency, run translation of the whole ledger to the

  reporting currency.

  5. Consolidate.

 

  The "revalue before translate" ordering I mentioned in the translation discussion is important: you first restate your

  open foreign balances at period-end rate within your functional-currency ledger (revaluation), and only then

  translate the entire functional-currency ledger into the reporting currency. Doing it the other way around —

  translating before revaluing — leaves your open foreign monetary items unrestated when you move to the reporting

  currency, which misstates the result. So in the close checklist, revaluation comes after posting is done and before

  translation.

 

  Revaluation versus its three cousins — drawing clean lines

 

  Because this is the single most-confused cluster in multi-currency accounting, let me draw the boundaries explicitly,

  even at the risk of repeating myself, because the clarity is worth it.

 

  Conversion is transaction-level, at entry. You book one foreign-currency invoice and the system expresses it in your

  ledger currency using that day's rate. One transaction, one moment, done at entry. Revaluation is not this —

  revaluation acts at period end on the accumulated open balances, not on individual transactions at entry.

 

  Revaluation acts on open foreign-currency monetary balances within your own ledger currency, restates them to the

  period-end rate, books the unrealized gain/loss to the income statement, and auto-reverses next period. Scope: foreign

  monetary items only. Destination: P&L. Currency: stays in your ledger currency. Timing: period end, reversed next

  period.

 

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

  balancing difference goes to the Cumulative Translation Adjustment in equity, not the income statement, and it does

  not auto-reverse — it's cumulative. Scope: the whole ledger. Destination: equity (CTA/OCI). Currency: a different

  currency. So the three sharpest contrasts between revaluation and translation: revaluation touches only foreign

  monetary items while translation touches everything; revaluation hits P&L while translation hits equity; revaluation

  keeps you in your own currency while translation moves you to another currency.

 

  Reporting currencies / secondary ledgers are the structural feature for maintaining a parallel set of books in another

  currency — that's about where the books live, not the period-end gain/loss recognition that revaluation handles.

 

  If a client says "we need to handle exchange rates at month-end," your job is to figure out which of these they

  actually mean. Open euro payables that need restating with a P&L gain/loss? That's revaluation. The whole subsidiary

  ledger restated into the parent's currency? That's translation. They are different processes with different setups,

  different destinations for the difference, and different positions in the close.

 

  Realized gain/loss and the subledger angle

 

  One nuance worth covering because it rounds out the picture: revaluation in the GL deals with the unrealized

  period-end restatement, but the subledgers — Payables and Receivables — are also part of the foreign-currency

  gain/loss story, specifically for realized gains and losses at settlement.

 

  When you pay that euro invoice in Payables at a rate different from the booking rate, AP computes and records the

  realized exchange gain or loss at the moment of payment — the difference between what you booked and what you actually

  paid in home-currency terms. Similarly, Receivables records realized gain/loss when a foreign-currency invoice is

  collected. These realized amounts are handled by the subledger accounting at settlement, separate from the GL

  revaluation that handles the unrealized period-end snapshot on what's still open.

 

  So the complete foreign-currency gain/loss picture is: conversion sets the initial home-currency value at entry;

  revaluation in GL handles the unrealized effect on open balances at period end (and reverses); and the subledgers

  handle the realized effect at settlement. They interlock — the auto-reverse of the GL revaluation is precisely what

  prevents the unrealized estimate from colliding with the realized figure the subledger computes when the item finally

  settles. Understanding that the GL revaluation and the subledger settlement gain/loss are two halves of the same coin,

  kept clean by the reversal, is the mark of someone who really understands the area.

 

  A worked example, end to end

 

  Let me run the opening scenario all the way through so every concept lands in sequence.

 

  Your ledger is in USD. On October 15 you book a supplier invoice for 100,000 EUR; the rate is 1.10, so AP records a

  payable of 110,000 USD. You don't pay it before year end.

 

  December 31 — revaluation. The period-end rate is 1.20. Your revaluation definition is scoped to the foreign AP

  account, uses the period-end rate type, and posts to your FX unrealized gain/loss accounts. You run revaluation. The

  system recomputes: 100,000 EUR at 1.20 = 120,000 USD. The recorded value is 110,000. The difference is 10,000 — and

  because this is a liability that's now worth more in dollars, it's an unrealized loss of 10,000. The revaluation

  journal debits unrealized FX loss (P&L) 10,000 and credits the AP balance 10,000, so the December 31 balance sheet now

  shows the payable at its true 120,000 value. Your year-end financials are correct.

 

  January 1 — auto-reverse. Because the revaluation journal is configured to auto-reverse, the reversal posts: it backs

  out the 10,000, returning the payable to its booked 110,000 and reversing the P&L loss. Why? Because the 120,000 was

  only an estimate as of December 31; the real outcome depends on the rate when you actually pay.

 

  February 10 — settlement (realized). You finally pay the 100,000 EUR. The rate that day is 1.18. AP computes the

  realized loss: you booked the liability at 110,000 (1.10) and you're settling 100,000 EUR which costs 118,000 USD, so

  the realized loss is 8,000 USD — handled by the subledger at payment. Notice how clean this is: because the December

  31 unrealized estimate (a 10,000 loss) was reversed on January 1, it didn't contaminate this realized 8,000 figure.

  The year-end balance sheet got its correct snapshot, and the eventual P&L reflects the true realized loss of 8,000 —

  no double counting. That interplay — revalue at period end, reverse next period, realize at settlement — is the whole

  machine working as designed.

 

  If the example had been a foreign-currency receivable and the euro had strengthened, you'd have booked an unrealized

  gain instead, to the gain account, with the same reverse-and-realize rhythm. Same machine, opposite direction.

 

  Common pitfalls I watch for

 

  The recurring traps, from real projects:

 

  Forgetting the auto-reverse. The single most damaging mistake. Revalue without reversing and the estimates pile up

  period over period, the FX gain/loss balances drift into nonsense, and the balance sheet carries stale restatements.

  Set up the automatic reversal criteria for the revaluation journal category as part of the implementation, and confirm

  the reversals actually post each period.

 

  Missing the period-end rate. Revaluation can't run correctly without the period-end rate loaded for the currency pair

  and period under the right rate type. The failure mode is a failed run or a zero/wrong result. "Period-end rates

  loaded?" belongs on the close checklist right next to the revaluation step.

 

  Wrong account scope. Including non-monetary accounts (fixed assets, inventory) or accounts that don't hold

  foreign-currency balances produces meaningless gains and losses; missing genuine foreign monetary accounts leaves real

  exposure unrevalued. Validate the account ranges in the definition against exactly which natural accounts carry open

  foreign-currency monetary balances.

 

  Confusing revaluation with translation. Running translation when they needed revaluation, or vice versa — or running

  them out of order. Revalue first (open foreign balances, to P&L, in your own currency), then translate (whole ledger,

  to equity CTA, in another currency).

 

  Net versus gross gain/loss presentation. Using a single account for both gain and loss when the client's policy wants

  gross FX gains and gross FX losses shown separately. Confirm presentation policy and set the gain and loss accounts

  accordingly.

 

  Revaluing before posting is complete. Run revaluation on draft balances and you've restated incomplete numbers. It

  acts on final open balances, so finish posting and subledger reconciliation first.

 

  Assuming revaluation handles realized settlement. It doesn't — the subledgers do that at payment/collection. GL

  revaluation is purely the unrealized period-end snapshot on open items.

 

  Closing thought

 

  Revaluation in Oracle Fusion is, at heart, an honesty adjustment: at period end it makes your open foreign-currency

  monetary balances tell the truth about what they're worth as of the reporting date, by restating them at the closing

  rate and booking the unrealized gain or loss to the income statement. The qualifier "open foreign-currency monetary"

  is the whole scoping discipline — receivables, payables, foreign cash and loans, not fixed assets or inventory. The

  unrealized-versus-realized distinction is the conceptual spine, and the reverse-next-period rhythm is its operational

  expression: you revalue to make the balance sheet correct today, reverse tomorrow so the estimate never collides with

  the real settlement, and let the subledgers compute the realized gain or loss when the item finally pays or collects.

  Keep revaluation cleanly separated from its three cousins — conversion at the transaction, translation of the whole

  ledger to equity, and reporting currencies as the parallel-books structure — and slot it correctly in the close (after

  posting, before translation). Build the revaluation definition with the right currency, rate type, gain/loss

  accounts, and account scope; wire up the auto-reverse; keep the period-end rates loaded; and revaluation becomes a quiet, dependable month-end step that keeps your foreign-currency exposure honestly stated, period after period.