Multi-currency configuration

What it does

Every Dataverse environment has one base currency, fixed when the environment is created. Additional transaction currencies are added as records, each holding a conversion rate to the base. Records carry a currency lookup and store money values twice: the amount in the transaction currency and the converted base value, which the platform calculates and users cannot edit.

Key facts

Currencies are managed in the Power Platform admin centre under the environment's Settings, Business, Currencies. It needs System Administrator or equivalent.
A currency record is either System — chosen from the predefined list, which fills in name and symbol — or Custom, where you type everything. Custom currency codes must be alphabetic.
The currency code is three characters. Currency precision is 0 to 4 decimal places.
The conversion rate is a static number on the currency record. Nothing updates it for you: no feed, no schedule, no warning when it goes stale.
Each record stores its own copy of the exchange rate at the point the record was created or last saved with a currency change. Editing a currency's rate does not retrospectively restate existing opportunities, quotes or orders.
Base-value fields are system-calculated and read-only. Reporting across currencies is done on the base fields, which is why the base currency choice matters far beyond cosmetics.
A currency in use by existing records cannot be deleted. Deactivate it instead — history stays intact, and it disappears from new transactions.
Base currency is no longer permanently fixed. A Base Currency Conversion app is available from the Marketplace, generally available, and documented at https://learn.microsoft.com/en-us/power-platform/admin/change-base-currency-environment.
That conversion is a project, not a setting: back up the environment first, create a single BaseCurrencyConversion record, supply historical exchange rates covering the entire date range of existing data, and run the job. Rollup column jobs are disabled while it runs.
Price lists are currency-specific, so multi-currency selling means one price list per currency, not one list with several prices.

When to use / skip

If the client trades in more than one currency, you have no choice — but the scope of "multi-currency" is worth pinning down. Selling in three currencies and reporting in one is what this handles well. What it handles poorly is anything that needs rate history, revaluation, or accounting-grade FX treatment. Those belong in the ERP, and the sensible position is that Dynamics holds the deal value in the customer's currency and an indicative base value for pipeline reporting, while finance owns the real numbers.

Single-currency clients should still take the base currency decision seriously at environment creation. It is the one moment where getting it right costs nothing and getting it wrong costs a migration project later.

Configuration decisions

The base currency, chosen at environment creation and matched to how the business reports group revenue — not to where the project team happens to sit.
Which transaction currencies are actually needed. Adding all of them "just in case" gives sellers a long picker and you a maintenance list.
Currency precision per currency, and whether money columns use currency precision or a fixed decimal setting — check this against how finance rounds.
Who owns exchange rates, how often they're updated, and whether that's manual admin work or an automated flow writing to the currency records.
One price list per currency, and what determines which one lands on an opportunity.
Whether pipeline reporting uses base values with historical rates baked in, or is restated at a current rate through the reporting layer.

Gotchas

Rates are static and silently stale. A rate left untouched for a year quietly distorts every base-currency report, and there is no alert.
Changing a rate does not restate open opportunities. Sellers see one number, finance sees another, and both are technically correct.
Adding a currency without adding a matching price list means sellers can select the currency and then get no prices on their lines.
Currency on a record is effectively fixed once lines exist — changing it forces a rework of the line items rather than a clean reconversion.
The base currency change tooling exists, but it wants a full history of exchange rates for the whole data range. Clients who never kept those rates cannot supply them, and the project stalls there.
Deactivating a currency doesn't stop it appearing on historical records, which is correct behaviour but confuses users who expected it to disappear.
Money column precision is a schema decision. Changing it later on a table with data is not a casual edit.

Consultant notes

Ask the base currency question in the first workshop, before anyone provisions an environment. It is the cheapest good decision on the project.
If the client trades in more than a couple of currencies, build a scheduled flow that writes rates into the currency records from whatever source finance already trusts, and let finance own the source.
Set expectations in writing that pipeline in base currency is indicative, not accounting. Get finance to agree it, and the month-end argument never happens.
Demo the same opportunity in two currencies during UAT so the client sees where base values appear and where they don't.
Before go-live, check that each active currency has a complete price list and that a test opportunity in each currency produces sensible line totals.

Worth another look if the client opens a new market, or if anyone starts talking about changing the reporting currency.