There are two approaches to this, each of which carries a different advantage.

Original Database #

The first solution is very simple, you work within your existing database. Here you create a new reporting group in the currency you want the group to be reporting in. This new company is then placed at the top of the group reporting structure. Group consolidation then calculates all translations according to the currency definition listed within the company structure.

In other words, having a different currency nominated at the top of the tree will generate a new currency translated number, in addition to retaining the existing (or outgoing) group currency translation. The advantage of this approach is speed or ease of system update. It does though come at the likely cost of data reconciliation issues, particularly regarding investment elimination.

It is common to automate this calculation using the investment elimination template that is embedded within the Controller application, which may have carried translated and reconciled positions in the outgoing group reporting currency. These reconciled positions may become lost from reporting against a different currency, as may also be case for other accounts that have been defined to use historic rate translation. No strict rule applies here, the data reconciliation experience in new group currency will be dictated by the settings specific to your database design. This may or may not work with the new reporting currency.

Critically, currency entries will need to continue to be input against the original group currency. The group or base currency must never be changed after it has been defined and used.

New Database #

The second solution carries more work, but you can achieve this relatively quickly. Importantly, this approach addresses the data reconciliation issues noted above.

In brief, you will create a new database, move the existing structure and local data across to it then set the group or base currency to the new currency wanted. New rates will be imported that match the new reporting currency and have been triangulated from the source asset.  Reconciliation work is then applied, particularly to areas impacted by historic or fixed translation, such as investment eliminations.  This work may require you to update the general configuration settings, say switch from group to local currency for investment eliminations.  The net outcome is a new database that presents reconciled numbers in the new group reporting currency.  This approach should retain the original consolidated numbers, in the outgoing reporting currency. These numbers are stored in an adjacent legacy database that you can easily access for historic data reference.

Lastly, this second approach presents opportunity for some structural tidy up, helping to ease application maintenance. For example, removal of dimensional elements that are no longer used, say defunct account codes, or disposed companies