Multiple currencies are handled natively without workarounds or consulting solutions

Description

In the context of corporate performance management (CPM) software the software should seamlessly convert, calculate, and report financial data in different currencies thus streamlining financial management in multinational corporations. This should not require a custom-built currency conversion process, or odd workarounds such as adding more members to a dimension.

Example Use Case

Scenario: An enterprise operating in multiple countries uses CPM software for planning and budgeting. The enterprise deals with multiple currencies in its operations, making it complex to aggregate, convert, and analyze financial data.

Solution: The CPM software should natively handle these multiple currencies, automatically calculating conversions according to exchange rates that are entered or automatically updated in the system, allowing the enterprise to generate accurate, relevant financial reports and models without having to resort to complex workarounds or external consulting solutions.

Considerations

Many products on the market struggle with currencies due to the manner in which they've been architected. For example, there are systems on the market that just don't handle currencies at all. That's great if you never plan to leave your home country, or only plan and report in your home currency. However, if the company has any aspirations for growth, expanding outside the home country is likely at some point.

To handle currencies, many products will assign a dimension called Currency. That adds significant flexibility. It allows the user to view any combination of dimensions in any currency in the system. Using this method, a US-based company can view their Canadian subsidiaries in CAD, or USD, simply by selecting the currency from a drop-down.

Others will add layers to a hierarchy where currency matters. This is less flexible, but also less taxing on system resources. For example, a Mexican subsidiary may have a Product dimension. It could look like this:

• All Products
• Anvil - USD Reporting
• Anvil - USD
• Anvil - CAD
• Anvil - MXN
• Dynamite - USD Reporting
• Dynamite - USD
• Dynamite - CAD
• Dynamite - MXN

This simple example shows currency not as a dimension, but assigned to a product. Looking at “Anvil - USD Reporting” will show the US, Canadian, and Mexican markets rolled up to USD. It does not allow the Canadian market to be viewed in USD alone. It could though, by adding yet another layer to the hierarchy. For some organizations this is fine when it is not important to report in more than one currency, but the planners in Canada or Mexico need to plan in their local currency.

Questions to Ask a Vendor

• Native Currency Handling: How does your system handle multiple currencies natively? Can it automatically update exchange rates and perform relevant conversions?
• Multi-Currency Reporting: Can the software create financial reports and models across multiple currencies without the need for external solutions or manual workarounds?
• Scalability: How many currencies can your system handle? Can new ones be easily added as the company expands?
• Reporting Views: Can I view any combination of dimensions using any currency, not matter if it is the original or planning currency for the specific dimension?