If you have ever added a Currency column to a table in Dataverse, you probably picked a name, chose “Currency” as the data type, hit save, and moved on. It feels like one column.
It isn’t. It’s four.
The Idea, in One Picture
Dataverse is a multi-currency system. One base currency is set for the whole environment when it’s provisioned, but individual records can be entered in any active currency - EUR, GBP, INR, whatever the deal calls for.
Because of that, one number alone (like 50000) isn’t enough - Dataverse also needs to know which currency that number is in, what rate to convert it at, and what it equals in the org’s base currency. That’s why adding one Currency column brings three more columns along with it:
| Column | Example name | Created | What it’s for |
|---|---|---|---|
| The value | Estimated Budget | Once per Currency column | The number you type, in the record’s own currency |
| Currency | Currency (lookup) | Once per table | Which currency this record uses |
| Exchange Rate | Exchange Rate | Once per table | The rate locked in for this record |
| Base value | Estimated Budget (Base) | Once per Currency column | Same number, converted to the org’s base currency |
Notice “Currency” and “Exchange Rate” say once per table - they’re shared by every Currency column on that table, not created fresh each time. Keep that in mind; you’ll see exactly why it matters in Step 7 below.
Try It Yourself: A Step-by-Step Walkthrough
The best way to make this click is to do it. Grab a trial or dev environment and follow along.
Step 1 - Create the column
- Go to make.powerapps.com and open a solution (create one if you don’t have one, so your changes are easy to find).
- Create a new table called Project (or use any custom table you already have).
- Open the table’s Columns area and select + Add column.
- Set:
- Display name:
Estimated Budget - Data type:
Currency
- Display name:
- Save the column.
Step 2 - Observe the columns Dataverse just created for you
Go back to the Columns list and look closely. Alongside Estimated Budget, you’ll now also see:
- Currency (
transactioncurrencyid) - Exchange Rate (
exchangerate) - Estimated Budget (Base) (
estimatedbudget_base)
You didn’t create three of these four columns - Dataverse did, automatically, the moment you saved your first Currency column.
Step 3 - Add the fields to the form
- Open the table’s Forms area and edit the main form.
- Drag Estimated Budget and Currency onto the form (if they aren’t already there).
- Save and publish.
You don’t strictly need Exchange Rate or the Base field on the form for this exercise, but feel free to add them too - they’ll appear read-only, since Dataverse fills them in itself.
Step 4 - Check the currencies available in your environment
- In the maker portal, go to Tables and open the system table named Currency.
- Open its Data and look at the rows. Each one is an active currency with its own Exchange Rate relative to your base currency.
- If EUR isn’t listed, add a new row for it with an exchange rate - for this walkthrough, use
0.92.
Step 5 - Create a record and set its currency
- Open your Project table’s Data and add a new row.
- Set Currency to Euro (EUR).
- Type
50000into Estimated Budget. - Save the row.
Step 6 - Observe the result
Add the Exchange Rate and Estimated Budget (Base) columns to your view (or open the row) and check:
- Exchange Rate now shows
0.92- copied from the EUR currency row you checked in Step 4. - Estimated Budget (Base) now shows
54,347.83- calculated automatically as50,000 ÷ 0.92, in your org’s base currency.
You never typed either of those two numbers. Dataverse worked them out for you the moment you saved the record.
Step 7 - Add a second Currency column, and watch what’s shared
- Add another Currency column called Actual Cost.
- Go back to Columns - this time, only two new columns appear: Actual Cost and Actual Cost (Base). No second Currency lookup, no second Exchange Rate. They’re reused from Step 1.
- Add Actual Cost to the form, open your EUR project record, type a value into it, and save.
Notice that Actual Cost also gets converted using the same EUR exchange rate - because Currency and Exchange Rate belong to the record, not to the individual field. There’s no way to make Estimated Budget use EUR while Actual Cost on the same row uses GBP - both share the one Currency value the record has.
(If you genuinely need two different currencies on what feels like one record, the usual pattern is a related child table where each row carries its own currency - not two Currency columns on the same row.)
Step 8 (bonus) - See the relationship behind the lookup
Open the table’s Relationships tab and look for a 1:N relationship to the Currency table (named something like transactioncurrency_project). This is the real relationship powering that Currency field - proof that it’s an ordinary lookup, not a special formatting trick.
A Couple of Things Worth Knowing
- Exchange rates aren’t live. Nothing calls out to a currency API. An admin maintains rates on the Currency table manually, and a record’s stored rate only updates if that record’s amount or currency is changed again later.
- Precision is configurable. When you create a Currency column, you can choose the org-wide Pricing Decimal Precision, the precision from the Currency record itself, or a specific value (0-4 decimal places).
Quick Recap
| Column | Editable by user? | Purpose |
|---|---|---|
| Currency (value) | Yes | Raw amount, in the record’s own currency |
| Currency (lookup) | Yes (picks a currency) | Which currency the record uses |
| Exchange Rate | No (system-filled) | Rate locked in for this record |
| Base value | No (calculated) | Same amount, in the org’s base currency |
That’s the whole picture: one column you create, three columns Dataverse creates for you, and now you’ve seen all four of them in action.