The Currency dimension, where translation happens
A group with entities in twelve currencies reads its result in one, or two, or three. This dimension holds each reading side by side, the local books and every reporting currency, and translation is the walk between them.
Every cell in a consolidation cube answers several questions at once, and each dimension carries one of them. This page is the question of which money a number is expressed in. Which rate applies is decided per account on the Account page, the computed FX lands in members owned by Movement, and the whole reference is mapped on the FCCS index.
◆ How translation runs— the members, the three rates, and where the FX difference goes.
| Piece | What it does |
|---|---|
| Entity Currency | The number as the entity's own books hold it, the starting point every translation reads from. Loads land here, and here is where a local controller recognizes their trial balance. |
| The reporting members | One member per reporting currency the group reads in, USD_Reporting and its siblings. Each is a complete, separate translation of the whole application, which is both the power and the trap of the design. |
| The three rates | Income statement accounts translate at the period's average rate, balance sheet accounts at the closing rate, and designated accounts, equity above all, at their historical rates. Which rate an account gets is its rate type, set on the Account dimension, and the classic CTA failure is a wrong rate type there, not a wrong rate here. |
| Where the difference lands | Translating a balance sheet at three different rates cannot balance by itself; the difference is real and has a home. The computed FX lands in the Movement dimension's system-owned FX members, and the cumulative translation adjustment builds from the FX on historical accounts, into equity, where the balance sheet balances again. |
◆ The traps, from live cases— the ways translation goes quietly wrong, each seen in the field this year.
| Trap | The pattern |
|---|---|
| Translates to one currency, not another | A calculated amount reached the first reporting currency and stopped, because the second currency's rate was missing for that account's rate type. Nothing errored; that currency simply stayed empty. The check is the rates table per reporting currency, before anything else. |
| CTA stops calculating | Almost always an account problem wearing a currency costume: an equity or historical account carrying the wrong rate type falls out of the CTA sum. The walkthrough lives on known issues. |
| Intercompany pairs that will not match | Two entities booking the same trade at different rates create a difference that is real, needs tracking, and is not a bug. Its cousin, FX on an intercompany loan in a third currency, stays in income even when the loan eliminates. |
| Layered structures | A euro holding company consolidating three currencies before rolling to a dollar parent translates at each level, and the CTA accumulates level by level. More levels, more places a rate can be missing, same single check repeated. |
In the owned warehouse, the star schema we recommend building beside FCCS on your own cloud, mapped here, currency is a first-class key on the consolidated fact, entity currency and each reporting currency landing as separate rows, never mixed and never summed across, the same overlap discipline as the consolidation belt. Member behavior and cases verified against Oracle's documentation and Customer Connect, July 2026.
- Entity Currency
- The number in the entity's own books. Every translation starts here.
- reporting member
- One per currency the group reads in. Each a complete separate translation.
- rate type
- Average, closing, or historical. Decided per account, not per currency.
- CTA
- The cumulative translation adjustment. Where the balance sheet balances again.