One amount, four valid answers

The universal journal stores every posting in several currency types at once, the company-code currency and the group currency among them, and across parallel ledgers, the leading ledger and one or more parallels for a second accounting principle. So a single revenue posting is already several stored amounts before anyone reports on it.

A cube built on a single-currency, single-ledger example looks clean and answers the wrong question half the time. The controller’s first question of any figure is which currency and which ledger, and a report that cannot say is not usable for the close, the consolidation, or the audit.

Four valid numbers for one revenue. The group amounts are the company-code amounts at the illustrative 1.08 rate; the parallel-ledger amounts differ from the leading by a recognition difference between accounting principles. Every one is correct, for a different question, and a figure quoted without both labels could be any of them. Sample values are illustrative, never client data.

Land the journal with ledger and currency type as explicit dimensions, exactly as they are stored, and never collapse them in the model. Every fact row is then qualified: a trend states its ledger and its currency on the face, group-currency consolidation and the parallel-ledger view are filters, and no one has to ask which number they are looking at.

-- revenue by ledger and currency type: every amount qualified
SELECT ledger, currency_type, SUM(amount) AS revenue
FROM fct_universal_journal
WHERE account_group = 'revenue' AND fiscal_period = '2026-05'
GROUP BY 1, 2 ORDER BY 1, 2

The single-currency cube is the trap this catalog documents in another shape: a model that drops a dimension the source carries. Keep the ledger and the currency, and the SAP number stops being a guess about which number it is. It pairs with the enterprise model, where these dimensions are shared across the finance stars.