#93 Decision: where the consolidation/presentation currency lives (EPM Settings default vs Consolidation Group node vs reporting basis)

[Anonymous]

Originally created by: grynn-in

Summary

We need a clear, single place to configure the consolidation currency (the currency the group reports in). This issue defines how to do that — and, just as importantly, what not to build yet.

In one line: add a single group consolidation currency to EPM Settings now (Phase 1). Defer per-region currencies (Europe in EUR, Asia in INR) to a later feature (Phase 2), because they need a new translation engine, not just a setting.

How it works today

• Each legal entity already has its own functional currency (from D365 — e.g. CHF, GBP, JPY).
• The group consolidation translates every entity directly into one reporting currency (e.g. USD) in a single step, then rolls up ownership across the group tree.
• The reporting currency is currently stored as free text on every Consolidation Group row (default USD), with nothing enforcing that all members of a group agree. There is no single "this is the group's consolidation currency" setting.

The key insight (why single-step is fine)

There are two accepted methods under IAS 21:

Method	What it does
Direct (what we do)	Translate each entity straight into the final group currency (USD)
Step-by-step	Translate up through each tier: CHF/GBP → Europe (EUR) → Global (USD)

For the global USD numbers, both methods give the same total net assets — translating CHF→EUR→USD lands on the same place as CHF→USD, as long as rates are consistent. So doing the global consolidation in one step is not a shortcut or a bug; it's a valid method.

The only number that differs between the two methods is the split of equity between retained earnings and the translation reserve (CTA) — and that difference only has a real effect when a foreign sub-group is sold (the amount of translation reserve recycled to P&L depends on the method).

What single-step genuinely cannot do is produce regional statutory statements — e.g. "Europe consolidated in EUR" for a German/EU filing. That is a separate legal deliverable, not a correction to the USD number.

Decision — phase it

Phase 1 — Consolidation currency in EPM Settings (this issue, small)

• [ ] Add a Consolidation Currency field to EPM Settings (single value, e.g. USD), as a Link to the Currency master (ties to [#91] — ISO 4217 list), not free text.
• [ ] Use it as the default/source of truth for the global consolidation reporting currency.
• [ ] Add validation: all members of a consolidation group must resolve to this one currency (flag mismatches instead of silently translating wrong).
• [ ] Keep the existing direct method translation — no engine change.

Phase 2 — Step-by-step (multi-tier) sub-consolidation (future PRD, large — not in this issue)

• Per-tier currency on each Consolidation Group node (Europe = EUR, Asia = INR, Global = USD).
• New engine: translate → sub-consolidate in the tier currency → compute CTA per tier → retranslate up.
• Regional statutory outputs (e.g. Europe-in-EUR consolidated statements with their own IC eliminations and CTA).
• Justified by statutory regional reporting, not by the global USD number being wrong.

What NOT to do

Do not add a per-group currency field now. Until the Phase 2 engine exists, setting "Europe = EUR" would do nothing — the engine still translates every entity straight to USD. Shipping that field early makes the system look configurable when it isn't (the same silent no-op trap flagged on the Historical Equity Rate keys, [#92]).

Related

• [#91] — ISO 4217 currency master + Exchange Rate table (Phase 1 depends on the Currency link).
• [#92] — Historical Equity Rate bugs (referenced for the silent-no-op anti-pattern).

[Anonymous]

Originally posted by: grynn-in

Decision (next round, phased). Biggest consolidation feature gap. Recommend: Phase 1 first — EPM-Settings-driven single reporting currency (direct method); it's self-contained and the near-term win. Defer Phase 2 (step-by-step sub-consolidation) until [#130] is resolved — sub-consolidation depends on a real intermediate-group hierarchy (the GROUP_EMEA-vs-seed divergence), so building it before reconciling doctype↔seed would bake in the wrong structure. Keeping open; P1 is the next big feature to pick up.

[Anonymous]

Originally posted by: grynn-in

📋 Decision brief (options + trade-offs + recommendation): docs/developer-guide/decisions/konsolidat-93-consolidation-currency.md — merged in [#133].

[Anonymous]

Originally posted by: grynn-in

Rescoped on 12 Sep 2026 after an issue review against main.

Phase 1's EPM Settings field consolidation_currency exists in konsol (get_consolidation_currency), but nothing reads it. dbt takes the currency from the Consolidation Group's reporting_currency, which konsol now describes as the group's presentation currency. The reporting-bases proposal gives each basis its own presentation currency.

Decide where the currency lives, then wire the setting in or drop it. Phase 2 (step-by-step) is untouched.

[Anonymous]

Originally posted by: grynn-in

Decided by the user on 13 Sep 2026 (recorded in HANDOFF with the group-2 work). The presentation currency lives on each Consolidation Group node, which is what the translation already reads: reporting_currency becomes a Link to Currency and is validated, and the unused EPM Settings consolidation_currency is removed. The direct translation method stays; step-by-step sub-consolidation stays deferred. A reporting basis may override the currency later. Rates: grynn-in/konsol#103.

[Anonymous]

Ticket changed by: grynn-in

• status: open --> closed