[GH-ISSUE #1132] [Feature] Budget Currency and Category Currencies #49555

Closed
opened 2026-04-30 11:06:03 -05:00 by GiteaMirror · 57 comments
Owner

Originally created by @joel-jeremy on GitHub (Jun 14, 2023).
Original GitHub issue: https://github.com/actualbudget/actual/issues/1132

Verified feature request does not already exist?

  • I have searched and found no existing issue

💻

  • Would you like to implement this feature?

Pitch: what problem are you trying to solve?

There are many people who work abroad and send remittances back to their home countries. Having to track bills in different currencies will make it harder to do your budget especially for those who are just wanting to start on their budgeting journey. To help with this, maybe the app could introduce a concept of a budget/primary currency and allow category budgets to be defined in a different currency (by default it should use the budget/primary currency) and let the app do the conversion based on the currency conversion rates or a custom conversion rate.

Describe your ideal solution to this problem

Introduce a budget/primary currency which will be used as the default currency on budgets unless otherwise specified. We could fetch conversion rates and store it in a local database for offline functionality if necessary and allow users to define custom conversion rates in order to match the conversion rates of the remittance services they are using. This should help users do their budgeting more accurately and no more manually doing conversions or adding buffers due to possible fluctuations in conversion rates.

Teaching and learning

No response

Originally created by @joel-jeremy on GitHub (Jun 14, 2023). Original GitHub issue: https://github.com/actualbudget/actual/issues/1132 ### Verified feature request does not already exist? - [X] I have searched and found no existing issue ### 💻 - [X] Would you like to implement this feature? ### Pitch: what problem are you trying to solve? There are many people who work abroad and send remittances back to their home countries. Having to track bills in different currencies will make it harder to do your budget especially for those who are just wanting to start on their budgeting journey. To help with this, maybe the app could introduce a concept of a budget/primary currency and allow category budgets to be defined in a different currency (by default it should use the budget/primary currency) and let the app do the conversion based on the currency conversion rates or a custom conversion rate. ### Describe your ideal solution to this problem Introduce a budget/primary currency which will be used as the default currency on budgets unless otherwise specified. We could fetch conversion rates and store it in a local database for offline functionality if necessary and allow users to define custom conversion rates in order to match the conversion rates of the remittance services they are using. This should help users do their budgeting more accurately and no more manually doing conversions or adding buffers due to possible fluctuations in conversion rates. ### Teaching and learning _No response_
GiteaMirror added the needs votesfeature labels 2026-04-30 11:06:03 -05:00
Author
Owner

@github-actions[bot] commented on GitHub (Jun 14, 2023):

Thanks for sharing your idea!

This repository is now using lodash style issue management for enhancements. This means enhancement issues will now be closed instead of leaving them open. This doesn’t mean we don’t accept feature requests, though! We will consider implementing ones that receive many upvotes, and we welcome contributions for any feature requests marked as needing votes (just post a comment first so we can help you make a successful contribution).

The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+

Don’t forget to upvote the top comment with 👍!

<!-- gh-comment-id:1590444771 --> @github-actions[bot] commented on GitHub (Jun 14, 2023): :sparkles: Thanks for sharing your idea! :sparkles: This repository is now using lodash style issue management for enhancements. This means enhancement issues will now be closed instead of leaving them open. This doesn’t mean we don’t accept feature requests, though! We will consider implementing ones that receive many upvotes, and we welcome contributions for any feature requests marked as needing votes (just post a comment first so we can help you make a successful contribution). The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+ Don’t forget to upvote the top comment with 👍! <!-- feature-auto-close-comment -->
Author
Owner

@j-f1 commented on GitHub (Jun 14, 2023):

Linking to some earlier discussion of this: https://github.com/actualbudget/actual/issues/541 https://github.com/actualbudget/actual/discussions/362

This would be a very complex feature to add since the app currently assumes everything is in the same currency and just treats budget values as numbers. We’d also need to think about how this could be exposed in the UI (especially the budget) in a way that isn’t confusing, including taking into account historical budgets.

<!-- gh-comment-id:1591079439 --> @j-f1 commented on GitHub (Jun 14, 2023): Linking to some earlier discussion of this: https://github.com/actualbudget/actual/issues/541 https://github.com/actualbudget/actual/discussions/362 This would be a very complex feature to add since the app currently assumes everything is in the same currency and just treats budget values as numbers. We’d also need to think about how this could be exposed in the UI (especially the budget) in a way that isn’t confusing, including taking into account historical budgets.
Author
Owner

@carkom commented on GitHub (Jun 14, 2023):

This has been discussed a lot, have a look at the previous closed feature requests. Best I came up with was to convert any foreign currency imports to the "home" currency. Can see the PR here (#690)

<!-- gh-comment-id:1591953745 --> @carkom commented on GitHub (Jun 14, 2023): This has been discussed a lot, have a look at the previous closed feature requests. Best I came up with was to convert any foreign currency imports to the "home" currency. Can see the PR here (#690)
Author
Owner

@joel-jeremy commented on GitHub (Jul 4, 2023):

@j-f1 I just realized that we can use math expressions in the Budgeted, Payment and Deposit columns. I am thinking maybe instead of currencies, we can update these columns to save the math expression used to calculate the amount and when the columns are clicked or hovered, we show this saved math expression so the user can modify the amount or the multiplier easily.

<!-- gh-comment-id:1619483993 --> @joel-jeremy commented on GitHub (Jul 4, 2023): @j-f1 I just realized that we can use math expressions in the `Budgeted`, `Payment` and `Deposit` columns. I am thinking maybe instead of currencies, we can update these columns to save the math expression used to calculate the amount and when the columns are clicked or hovered, we show this saved math expression so the user can modify the amount or the multiplier easily.
Author
Owner

@nmathey commented on GitHub (Sep 11, 2023):

Potentially simplifying also if such transaction details is going Read-Only or replacing the math expression proposed by @joel-jeremy by the result only as soon as it is reconciliated (?)

<!-- gh-comment-id:1713072125 --> @nmathey commented on GitHub (Sep 11, 2023): Potentially simplifying also if such transaction details is going Read-Only or replacing the math expression proposed by @joel-jeremy by the result only as soon as it is reconciliated (?)
Author
Owner

@Crazypkr1099 commented on GitHub (Nov 16, 2023):

In response to
https://github.com/actualbudget/actual/discussions/362#discussioncomment-7571035

This would be an astronomical amount of work to complete unfortunately.

Your best bet as of right now is to have two budgets, one in CAD and one in USD.

I don't think it would be possible to have all the information from each corresponding budget shown in one budget due to security reasons, so there's really no great way to do this.

One thing I think might be possible is when you upload a CSV or QIF, OFX, and QFX file, you could add an option to automatically do an exchange rate and apply a memo stating "converted to USD" or something.

This would be the easiest way...

<!-- gh-comment-id:1813526299 --> @Crazypkr1099 commented on GitHub (Nov 16, 2023): In response to https://github.com/actualbudget/actual/discussions/362#discussioncomment-7571035 This would be an astronomical amount of work to complete unfortunately. Your best bet as of right now is to have two budgets, one in CAD and one in USD. I don't think it would be possible to have all the information from each corresponding budget shown in one budget due to security reasons, so there's really no great way to do this. One thing I think might be possible is when you upload a CSV or QIF, OFX, and QFX file, you could add an option to automatically do an exchange rate and apply a memo stating "converted to USD" or something. This would be the easiest way...
Author
Owner

@carkom commented on GitHub (Nov 16, 2023):

One thing I think might be possible is when you upload a CSV or QIF, OFX, and QFX file, you could add an option to automatically do an exchange rate and apply a memo stating "converted to USD" or something.

This would be the easiest way...

This already exists. See my comment (above).

<!-- gh-comment-id:1814396912 --> @carkom commented on GitHub (Nov 16, 2023): > One thing I think might be possible is when you upload a CSV or QIF, OFX, and QFX file, you could add an option to automatically do an exchange rate and apply a memo stating "converted to USD" or something. > > This would be the easiest way... This already exists. See my comment (above).
Author
Owner

@michele-perrone commented on GitHub (Feb 7, 2024):

Giving a vote for this one.

I have a multi-currency account and I mainly use CHF and EUR, exchanging them based on my needs.

I tried having two separate budgets, but that's not really an option: not having a unified net worth report is already a deal breaker for me. I can't really see how much I'm saving each month, since CHF and EUR are just summed together.

This is the only feature that I'm missing in Actual. I'm super happy with all the rest!

<!-- gh-comment-id:1931884203 --> @michele-perrone commented on GitHub (Feb 7, 2024): Giving a vote for this one. I have a multi-currency account and I mainly use CHF and EUR, exchanging them based on my needs. I tried having two separate budgets, but that's not really an option: not having a unified net worth report is already a deal breaker for me. I can't really see how much I'm saving each month, since CHF and EUR are just summed together. This is the only feature that I'm missing in Actual. I'm super happy with all the rest!
Author
Owner

@maxime1992 commented on GitHub (Feb 7, 2024):

☝️ that's the only reason I've decided not to start using Actual. If I cannot track multiple currencies it doesn't make sense for me to track accounts at all as I can swap from one account to another one it's not really an expense or anything. I'm keeping an eye on Maybe as they've announced this will be supported by default

<!-- gh-comment-id:1932526848 --> @maxime1992 commented on GitHub (Feb 7, 2024): :point_up: that's the only reason I've decided not to start using Actual. If I cannot track multiple currencies it doesn't make sense for me to track accounts at all as I can swap from one account to another one it's not really an expense or anything. I'm keeping an eye on Maybe as they've announced this will be supported by default
Author
Owner

@darianf01 commented on GitHub (Feb 16, 2024):

I'm in same situation, besides having accounts with different currencies, i'm also having a multi-currency account. I transfer from one account to another doing also an exchange. So amount in the source account should end up being different than the amount in the destination account. I'm syncing these accounts via gocardless.

One solution I could suggest, is to have the option to do "Transfer & Exchange", where one transaction is marked as transfer along with providing a custom exchange rate (and as a matter of fact, also a fee). Transferring 100EUR into 86GBP for example would keep same transaction, only "viewed" differently depending on the account. With such implementation I think there would be no need to define in Actual which account is EUR & which is GBP, for example...

<!-- gh-comment-id:1948715424 --> @darianf01 commented on GitHub (Feb 16, 2024): I'm in same situation, besides having accounts with different currencies, i'm also having a multi-currency account. I transfer from one account to another doing also an exchange. So amount in the source account should end up being different than the amount in the destination account. I'm syncing these accounts via gocardless. One solution I could suggest, is to have the option to do "Transfer & Exchange", where one transaction is marked as transfer along with providing a custom exchange rate (and as a matter of fact, also a fee). Transferring 100EUR into 86GBP for example would keep same transaction, only "viewed" differently depending on the account. With such implementation I think there would be no need to define in Actual which account is EUR & which is GBP, for example...
Author
Owner

@qmph22 commented on GitHub (Mar 2, 2024):

I'm in same situation, besides having accounts with different currencies, i'm also having a multi-currency account. I transfer from one account to another doing also an exchange. So amount in the source account should end up being different than the amount in the destination account. I'm syncing these accounts via gocardless.

One solution I could suggest, is to have the option to do "Transfer & Exchange", where one transaction is marked as transfer along with providing a custom exchange rate (and as a matter of fact, also a fee). Transferring 100EUR into 86GBP for example would keep same transaction, only "viewed" differently depending on the account. With such implementation I think there would be no need to define in Actual which account is EUR & which is GBP, for example...

It might be out of the scope of this feature request but you could take it a step further and have an option to show both currencies for a transaction side-by-side per the exchange rate set for that transaction.

<!-- gh-comment-id:1974886451 --> @qmph22 commented on GitHub (Mar 2, 2024): > I'm in same situation, besides having accounts with different currencies, i'm also having a multi-currency account. I transfer from one account to another doing also an exchange. So amount in the source account should end up being different than the amount in the destination account. I'm syncing these accounts via gocardless. > > One solution I could suggest, is to have the option to do "Transfer & Exchange", where one transaction is marked as transfer along with providing a custom exchange rate (and as a matter of fact, also a fee). Transferring 100EUR into 86GBP for example would keep same transaction, only "viewed" differently depending on the account. With such implementation I think there would be no need to define in Actual which account is EUR & which is GBP, for example... It might be out of the scope of this feature request but you could take it a step further and have an option to show both currencies for a transaction side-by-side per the exchange rate set for that transaction.
Author
Owner

@thetechnaddict commented on GitHub (Apr 8, 2024):

Same issue for me as darianf01 - I can sync both my euro and gbp accounts and all I need to do is identify the two transactions as being involved in the transfer - no need to manage exchange rates, just say 100 from this account went to 86 in this other account. They could be suasages to carrots, who cares - it gets more complex if I want to track different types of income in euros that are implicated in one transfer, since the value of the income in a base currency matters -- for this reason I am leaving the euro account out of the budget and registering the income as European Income, and tracking the sources separately

<!-- gh-comment-id:2042679465 --> @thetechnaddict commented on GitHub (Apr 8, 2024): Same issue for me as darianf01 - I can sync both my euro and gbp accounts and all I need to do is identify the two transactions as being involved in the transfer - no need to manage exchange rates, just say 100 from this account went to 86 in this other account. They could be suasages to carrots, who cares - it gets more complex if I want to track different types of income in euros that are implicated in one transfer, since the value of the income in a base currency matters -- for this reason I am leaving the euro account out of the budget and registering the income as European Income, and tracking the sources separately
Author
Owner

@patrontheo commented on GitHub (Apr 21, 2024):

Same situation for me. I have accounts in EUR and CHF. Being able to unify them is super important. Perhaps you could have a look at how other budget management apps (Firefly III ?) handle this.
I guess the user should define its 'main' currency, and be able to add accounts in other currencies.
The exchange rate would have to be updated automatically (to see the net worth of all my accounts as of today).
For transfers, it should be possible to match transactions that don't have the same amount (e.g. 100CHF -> 103EUR).
Where it could get tricky (not that the above is not tricky ;)) is how you manage budget for a given category for example. If there was an expense of 100€ in this category on a given date, should you use the exchange rate of the transaction date, or of today (I'm not sure what's best).
As of now, the lack of multi-currency support might be a deal-breaker for me, unfortunately :(. If someone has a recommendation of a great, self-hosted budgeting app that can do this, I'm all ears :). Hopefully Actual will integrate that in the future !
I know that I'm a bit of an edge-case having accounts in different currencies, but I guess everyone using apps like revolut for traveling would also be interested in being able to import their revolut accounts' statement.

<!-- gh-comment-id:2068059172 --> @patrontheo commented on GitHub (Apr 21, 2024): Same situation for me. I have accounts in EUR and CHF. Being able to unify them is super important. Perhaps you could have a look at how other budget management apps (Firefly III ?) handle this. I guess the user should define its 'main' currency, and be able to add accounts in other currencies. The exchange rate would have to be updated automatically (to see the net worth of all my accounts as of today). For transfers, it should be possible to match transactions that don't have the same amount (e.g. 100CHF -> 103EUR). Where it could get tricky (not that the above is not tricky ;)) is how you manage budget for a given category for example. If there was an expense of 100€ in this category on a given date, should you use the exchange rate of the transaction date, or of today (I'm not sure what's best). As of now, the lack of multi-currency support might be a deal-breaker for me, unfortunately :(. If someone has a recommendation of a great, self-hosted budgeting app that can do this, I'm all ears :). Hopefully Actual will integrate that in the future ! I know that I'm a bit of an edge-case having accounts in different currencies, but I guess everyone using apps like revolut for traveling would also be interested in being able to import their revolut accounts' statement.
Author
Owner

@Mart-Bogdan commented on GitHub (Jul 23, 2024):

I think having currency per account would solve this. not per category.

You basically create cash account in different currency.

In case you are using bank card -- it would be auto converted by your bank, so in your invoice it would be in native currency.

In this case app won't require to fetch exchange rates. You simply input it when you transfer from one account to another.

P.S. This was the thing that bogged me out when I was using YNAB many years ago.

<!-- gh-comment-id:2246162698 --> @Mart-Bogdan commented on GitHub (Jul 23, 2024): I think having currency per account would solve this. not per category. You basically create cash account in different currency. In case you are using bank card -- it would be auto converted by your bank, so in your invoice it would be in native currency. In this case app won't require to fetch exchange rates. You simply input it when you transfer from one account to another. **P.S.** This was the thing that bogged me out when I was using YNAB many years ago.
Author
Owner

@vinstaal0 commented on GitHub (Aug 7, 2024):

How most other programs would do this is that you would add the account and select the given currency.
The exchange rates would be pulled from a table that is either manually filled or filled by an API.

Let's say this second account is in EUR and the main budget is in USD.

You would put all the transactions in EUR in the EUR account and they would show up as EUR in that account. Actual would then convert the transactions to the last know currency exchange rate. So say I process a transaction on 2024-08-07 of 100 euro and the last know exchange rate is from 2024-08-01 it would then use that to convert to USD and post that to the budget.

Since Actual is cashflow based and not based on double entry bookkeeping we don't care about the exchange rate differences that exist.
If I say transfer 100 USD to my EUR account the EUR account would show an deposit of 91 EUR. If you match this as a transfer between the two then any given exchange rate should be ported to exchange rates.

You don't want to have currencies per category, it's a whole lot of work to make that work and it woudln't give a good example either. Just think about you putting a budget for food for your vacation in Japan. It would show a number in the tens or maybe even hundreds of thousands of yen. Would look weird against your normal budget.

The best way to currently solve this IMO is to take your .CSV export from the bank and convert all the transactions manually and then import it as if it where in your main currency.

Edit: changed comment to be more clear.

<!-- gh-comment-id:2272963938 --> @vinstaal0 commented on GitHub (Aug 7, 2024): How most other programs would do this is that you would add the account and select the given currency. The exchange rates would be pulled from a table that is either manually filled or filled by an API. Let's say this second account is in EUR and the main budget is in USD. You would put all the transactions in EUR in the EUR account and they would show up as EUR in that account. Actual would then convert the transactions to the last know currency exchange rate. So say I process a transaction on 2024-08-07 of 100 euro and the last know exchange rate is from 2024-08-01 it would then use that to convert to USD and post that to the budget. Since Actual is cashflow based and not based on double entry bookkeeping we don't care about the exchange rate differences that exist. If I say transfer 100 USD to my EUR account the EUR account would show an deposit of 91 EUR. If you match this as a transfer between the two then any given exchange rate should be ported to exchange rates. You don't want to have currencies per category, it's a whole lot of work to make that work and it woudln't give a good example either. Just think about you putting a budget for food for your vacation in Japan. It would show a number in the tens or maybe even hundreds of thousands of yen. Would look weird against your normal budget. The best way to currently solve this IMO is to take your .CSV export from the bank and convert all the transactions manually and then import it as if it where in your main currency. Edit: changed comment to be more clear.
Author
Owner

@dvcrn commented on GitHub (Aug 15, 2024):

Hi! Found this thread because I was searching on how to set a currency for an account - I guess it's not possible yet

I also think that there is no need to have currencies per category or things like that, and currency conversion is unnecessary either.

All I want is that the accounts and transactions I have, have a currency symbol and/or field, so I know the currency of each transaction.

My sidebar looks like this:

image

With JPY it's a bit more obvious that this isn't the same as the others, but with the others it's a bit more subtle.

Then in transactions, display the currency of the account, and in aggregations, list up all the currencies and their respective value. So if an aggregation has $20 USD and 10 Euro, display it as "$20, 10€".

One app that does this very well is https://moneymoney-app.com/

Screenshot 2024-08-18 at 10 16 53 AM

or with mulitiple currencies

Screenshot 2024-08-18 at 10 17 05 AM
<!-- gh-comment-id:2290824901 --> @dvcrn commented on GitHub (Aug 15, 2024): Hi! Found this thread because I was searching on how to set a currency for an account - I guess it's not possible yet I also think that there is no need to have currencies per category or things like that, and currency conversion is unnecessary either. All I want is that the accounts and transactions I have, have a currency symbol and/or field, so I know the currency of each transaction. My sidebar looks like this: <img width="336" alt="image" src="https://github.com/user-attachments/assets/9dfede1b-bbd2-4f63-8524-51f989f92f8f"> With JPY it's a bit more obvious that this isn't the same as the others, but with the others it's a bit more subtle. Then in transactions, display the currency of the account, and in aggregations, list up all the currencies and their respective value. So if an aggregation has $20 USD and 10 Euro, display it as "$20, 10€". One app that does this very well is https://moneymoney-app.com/ <img width="260" alt="Screenshot 2024-08-18 at 10 16 53 AM" src="https://github.com/user-attachments/assets/012f3a42-b537-4792-97f3-88d06ed3fac7"> or with mulitiple currencies <img width="285" alt="Screenshot 2024-08-18 at 10 17 05 AM" src="https://github.com/user-attachments/assets/7fe0c70a-0a40-4c5a-abb5-03553d3588de">
Author
Owner

@vinstaal0 commented on GitHub (Aug 19, 2024):

@dvcrn I disagree that currency conversions aren't needed. Like in your example with JPY it's gonna have huge impacts on your budget if you assign a single purchase in JPY to a category. That would need to be converted by the exchange rate set in the system.

We don't need categories to be set in different currencies though, that makes basically no sense

<!-- gh-comment-id:2295910716 --> @vinstaal0 commented on GitHub (Aug 19, 2024): @dvcrn I disagree that currency conversions aren't needed. Like in your example with JPY it's gonna have huge impacts on your budget if you assign a single purchase in JPY to a category. That would need to be converted by the exchange rate set in the system. We don't need categories to be set in different currencies though, that makes basically no sense
Author
Owner

@bandiba commented on GitHub (Aug 26, 2024):

Hi! The lack of multicurrency support is a blocker for me too. I'm back to AceMoney, which is somewhat outdated, but does have multiple currencies, they download exchange rates, daily values I believe, and do conversion when needed.
I tried Firefly III too, there you can assign a currency to each account, however exchange is not supported. Resulting in that eg in reports, you have as many lines for each item (eg category) as many currencies you used for that category. Not ideal either.
I fully understand this would be a significant change for Actual, while I'm sure it would make it even more useful, standing out of the crowd of financial apps. Lacking coding skills, I'm ready to support financially, if that helps somehow...

<!-- gh-comment-id:2309568159 --> @bandiba commented on GitHub (Aug 26, 2024): Hi! The lack of multicurrency support is a blocker for me too. I'm back to AceMoney, which is somewhat outdated, but does have multiple currencies, they download exchange rates, daily values I believe, and do conversion when needed. I tried Firefly III too, there you can assign a currency to each account, however exchange is not supported. Resulting in that eg in reports, you have as many lines for each item (eg category) as many currencies you used for that category. Not ideal either. I fully understand this would be a significant change for Actual, while I'm sure it would make it even more useful, standing out of the crowd of financial apps. Lacking coding skills, I'm ready to support financially, if that helps somehow...
Author
Owner

@emudojo commented on GitHub (Aug 28, 2024):

this would be ideal for me having USD and CRC as currencies, I had to update my import script to convert CRC to dollars before it gets ingested into actual, now transfters between accounts as I often use my bank for that then the amount gets converted to USD and then imported (or the other way around)

<!-- gh-comment-id:2315536135 --> @emudojo commented on GitHub (Aug 28, 2024): this would be ideal for me having USD and CRC as currencies, I had to update my import script to convert CRC to dollars before it gets ingested into actual, now transfters between accounts as I often use my bank for that then the amount gets converted to USD and then imported (or the other way around)
Author
Owner

@bandiba commented on GitHub (Aug 28, 2024):

Right, I think this is a problem for anyone who uses more than one currency - and that is not just a few people, I'm sure. In my case, I plan to use the online connection to download transactions - so I would need to modify the download script to convert the amounts to the base currency.

<!-- gh-comment-id:2315953821 --> @bandiba commented on GitHub (Aug 28, 2024): Right, I think this is a problem for anyone who uses more than one currency - and that is not just a few people, I'm sure. In my case, I plan to use the online connection to download transactions - so I would need to modify the download script to convert the amounts to the base currency.
Author
Owner

@StamenchoBog commented on GitHub (Aug 31, 2024):

I will also add that I am waiting for multi-currency support so I can completely transition my excel files into an application like this. Multi-currency will be a crucial feature so people can use this application since everyone in the world at the moment uses multiple currencies. Especially after the multiple fluctuations of currencies because of the economic crisis.

<!-- gh-comment-id:2323034329 --> @StamenchoBog commented on GitHub (Aug 31, 2024): I will also add that I am waiting for multi-currency support so I can completely transition my excel files into an application like this. Multi-currency will be a crucial feature so people can use this application since everyone in the world at the moment uses multiple currencies. Especially after the multiple fluctuations of currencies because of the economic crisis.
Author
Owner

@ThomasHFWright commented on GitHub (Sep 21, 2024):

Adding my vote for this feature. I'm daily managing accounts between different countries

<!-- gh-comment-id:2365140508 --> @ThomasHFWright commented on GitHub (Sep 21, 2024): Adding my vote for this feature. I'm daily managing accounts between different countries
Author
Owner

@Seovance commented on GitHub (Sep 22, 2024):

Also adding my vote ! Would be great to have multiple currencies available! One easy and quick solution would be to add a conversion rule based on account. For example, all transactions for a given account are converted with a specific factor. Of course, it would be better to have them converted on a daily basis with some open source currency exchange factor. But option 1. would help a lot of people and should not be a big deal. :)

<!-- gh-comment-id:2366953723 --> @Seovance commented on GitHub (Sep 22, 2024): Also adding my vote ! Would be great to have multiple currencies available! One easy and quick solution would be to add a conversion rule based on account. For example, all transactions for a given account are converted with a specific factor. Of course, it would be better to have them converted on a daily basis with some open source currency exchange factor. But option 1. would help a lot of people and should not be a big deal. :)
Author
Owner

@ycsh-w commented on GitHub (Oct 10, 2024):

I am voting on this too. I am okay with the solution to have different budgets for different currencies, but it would be awesome if we can somehow have multi-currency support

<!-- gh-comment-id:2404135413 --> @ycsh-w commented on GitHub (Oct 10, 2024): I am voting on this too. I am okay with the solution to have different budgets for different currencies, but it would be awesome if we can somehow have multi-currency support
Author
Owner

@patrontheo commented on GitHub (Oct 10, 2024):

For those willing to not use a self-hosted solution, LunchMoney is a very nice one. I've been using it for the past month and it's really cool, the multi-currency support is well-implemented.
Actual could take inspiration from them by the way.

<!-- gh-comment-id:2404531655 --> @patrontheo commented on GitHub (Oct 10, 2024): For those willing to not use a self-hosted solution, [LunchMoney](https://lunchmoney.app/?refer=qmc6v9b9) is a very nice one. I've been using it for the past month and it's really cool, the multi-currency support is well-implemented. Actual could take inspiration from them by the way.
Author
Owner

@anatolybobunov commented on GitHub (Oct 15, 2024):

I manually convert my transactions from currencies into dollars every time. That's why I'm so interested in this feature.

I open the Actual Budget app, my bank's account with transactions on the google tab, and Google online currency converter on another tab.

I look at the bank transaction and check what the currency of this transaction is. If the transaction isn't a dollar, I go to the converter page and convert my currency into dollar. After that, I go to Actual Budget and enter the new dollar amount of the transaction.

Therefore, transferring all my transactions into Actual Budget takes approximately 50-80 minutes once per week or 30-40 minutes twice per week.

<!-- gh-comment-id:2413320411 --> @anatolybobunov commented on GitHub (Oct 15, 2024): I manually convert my transactions from currencies into dollars every time. That's why I'm so interested in this feature. I open the Actual Budget app, my bank's account with transactions on the google tab, and Google online currency converter on another tab. I look at the bank transaction and check what the currency of this transaction is. If the transaction isn't a dollar, I go to the converter page and convert my currency into dollar. After that, I go to Actual Budget and enter the new dollar amount of the transaction. Therefore, transferring all my transactions into Actual Budget takes approximately 50-80 minutes once per week or 30-40 minutes twice per week.
Author
Owner

@franco-ruggeri commented on GitHub (Nov 3, 2024):

+1

This is a show-stopper for me to start using Actual.

<!-- gh-comment-id:2453596244 --> @franco-ruggeri commented on GitHub (Nov 3, 2024): +1 This is a show-stopper for me to start using Actual.
Author
Owner

@Mart-Bogdan commented on GitHub (Nov 4, 2024):

@patrontheo: For those willing to not use a self-hosted solution, LunchMoney is a very nice one. I've been using it for the past month and it's really cool, the multi-currency support is well-implemented. Actual could take inspiration from them by the way.

As I can tell from their website, they don't offer e2e encrytion. Only some vague guarantees.

Actual on contrary has e2e option for self hosted set up.

I can't imagine why people store their financial data inside this centralized "cloud" apps, that don't have proper encryption.

<!-- gh-comment-id:2455541118 --> @Mart-Bogdan commented on GitHub (Nov 4, 2024): > @patrontheo: For those willing to not use a self-hosted solution, [LunchMoney](https://lunchmoney.app/?refer=qmc6v9b9) is a very nice one. I've been using it for the past month and it's really cool, the multi-currency support is well-implemented. Actual could take inspiration from them by the way. As I can tell from their website, they don't offer e2e encrytion. Only some vague guarantees. Actual on contrary has e2e option for self hosted set up. I can't imagine why people store their financial data inside this centralized "cloud" apps, that don't have proper encryption.
Author
Owner

@franco-ruggeri commented on GitHub (Nov 5, 2024):

I manually convert my transactions from currencies into dollars every time. That's why I'm so interested in this feature.

I open the Actual Budget app, my bank's account with transactions on the google tab, and Google online currency converter on another tab.

I look at the bank transaction and check what the currency of this transaction is. If the transaction isn't a dollar, I go to the converter page and convert my currency into dollar. After that, I go to Actual Budget and enter the new dollar amount of the transaction.

Therefore, transferring all my transactions into Actual Budget takes approximately 50-80 minutes once per week or 30-40 minutes twice per week.

In addition to taking long, that approach is inevitably imprecise. The currency exchange rates keep changing.

Each account and transaction should have and be stored with their original currency, unless it is an exchange transaction in reality (see Firefly III). The conversion should be done only for analysis purposes in the reports, using the up to date exchange rates (e.g. convert everything to one currency to see my net worth).

<!-- gh-comment-id:2456637647 --> @franco-ruggeri commented on GitHub (Nov 5, 2024): > I manually convert my transactions from currencies into dollars every time. That's why I'm so interested in this feature. > > > > I open the Actual Budget app, my bank's account with transactions on the google tab, and Google online currency converter on another tab. > > > > I look at the bank transaction and check what the currency of this transaction is. If the transaction isn't a dollar, I go to the converter page and convert my currency into dollar. After that, I go to Actual Budget and enter the new dollar amount of the transaction. > > > > Therefore, transferring all my transactions into Actual Budget takes approximately 50-80 minutes once per week or 30-40 minutes twice per week. In addition to taking long, that approach is inevitably imprecise. The currency exchange rates keep changing. Each account and transaction should have and be stored with their original currency, unless it is an exchange transaction in reality (see Firefly III). The conversion should be done only for analysis purposes in the reports, using the up to date exchange rates (e.g. convert everything to one currency to see my net worth).
Author
Owner

@bandiba commented on GitHub (Nov 5, 2024):

Each account and transaction should have and be stored with their original currency, unless it is an exchange transaction in reality (see Firefly III). The conversion should be done only for analysis purposes in the reports, using the up to date exchange rates (e.g. convert everything to one currency to see my net worth).

Exactly! BTW this is where Firefly III also missing functionality: in reports it displays a separate entry for each currency. E.g., if you bought stuff from US, UK and German Amazon, you will have 3 entries in the "stuff" category, and no total. This makes the reports somewhat difficult to read, and process. Other tools define a base/reference currency, so that in reports only one entry is shown for each category in reference currency, which is the sum of entries of various currencies, converted to the reference currency (using some spot rate or latest available rate).

<!-- gh-comment-id:2456713911 --> @bandiba commented on GitHub (Nov 5, 2024): > Each account and transaction should have and be stored with their original currency, unless it is an exchange transaction in reality (see Firefly III). The conversion should be done only for analysis purposes in the reports, using the up to date exchange rates (e.g. convert everything to one currency to see my net worth). Exactly! BTW this is where Firefly III also missing functionality: in reports it displays a separate entry for each currency. E.g., if you bought stuff from US, UK and German Amazon, you will have 3 entries in the "stuff" category, and no total. This makes the reports somewhat difficult to read, and process. Other tools define a base/reference currency, so that in reports only one entry is shown for each category in reference currency, which is the sum of entries of various currencies, converted to the reference currency (using some spot rate or latest available rate).
Author
Owner

@patrontheo commented on GitHub (Nov 5, 2024):

@patrontheo: For those willing to not use a self-hosted solution, LunchMoney is a very nice one. I've been using it for the past month and it's really cool, the multi-currency support is well-implemented. Actual could take inspiration from them by the way.

@Mart-Bogdan: As I can tell from their website, they don't offer e2e encrytion. Only some vague guarantees.
Actual on contrary has e2e option for self hosted set up.
I can't imagine why people store their financial data inside this centralized "cloud" apps, that don't have proper encryption.

If you are aware about a self hosted e2ee solution that supports fluently multiple currencies, I'm all ears ! :)

<!-- gh-comment-id:2456756919 --> @patrontheo commented on GitHub (Nov 5, 2024): > > @patrontheo: For those willing to not use a self-hosted solution, [LunchMoney](https://lunchmoney.app/?refer=qmc6v9b9) is a very nice one. I've been using it for the past month and it's really cool, the multi-currency support is well-implemented. Actual could take inspiration from them by the way. > @Mart-Bogdan: As I can tell from their website, they don't offer e2e encrytion. Only some vague guarantees. > Actual on contrary has e2e option for self hosted set up. > I can't imagine why people store their financial data inside this centralized "cloud" apps, that don't have proper encryption. If you are aware about a self hosted e2ee solution that supports fluently multiple currencies, I'm all ears ! :)
Author
Owner

@bandiba commented on GitHub (Nov 5, 2024):

I'm in search for a personal finance software, now for a year or more, that meets the following four criteria:

  • self-hosted
  • has multicurrency support, with reference currency based reports and summaries
  • supports automatic transaction download from my banks
  • can assign transaction categories automatically (rule based)

No success. The closest is Firefly III, the only thing missing there is the reference currency based reports.

<!-- gh-comment-id:2457680672 --> @bandiba commented on GitHub (Nov 5, 2024): I'm in search for a personal finance software, now for a year or more, that meets the following four criteria: - self-hosted - has multicurrency support, with reference currency based reports and summaries - supports automatic transaction download from my banks - can assign transaction categories automatically (rule based) No success. The closest is Firefly III, the only thing missing there is the reference currency based reports.
Author
Owner

@alejoar commented on GitHub (Nov 19, 2024):

Looking forward to this feature too!

This is a must for entrepreneurs working with clients in multiple countries.

<!-- gh-comment-id:2486245127 --> @alejoar commented on GitHub (Nov 19, 2024): Looking forward to this feature too! This is a must for entrepreneurs working with clients in multiple countries.
Author
Owner

@bandiba commented on GitHub (Nov 19, 2024):

All, do not forget to upvote this issue, so it gets visibility!

<!-- gh-comment-id:2486559837 --> @bandiba commented on GitHub (Nov 19, 2024): All, do not forget to upvote this issue, so it gets visibility!
Author
Owner

@rbjansen commented on GitHub (Nov 27, 2024):

I've been able to extend the Docker-based setup with a script that converts transactions in a specified account, using exchange rates by transaction date. Have a look at the example here

<!-- gh-comment-id:2503556609 --> @rbjansen commented on GitHub (Nov 27, 2024): I've been able to extend the Docker-based setup with a script that converts transactions in a specified account, using exchange rates by transaction date. Have a look at the example [here](https://github.com/rbjansen/dual-actual)
Author
Owner

@bandiba commented on GitHub (Dec 1, 2024):

I've been able to extend the Docker-based setup with a script that converts transactions in a specified account, using exchange rates by transaction date. Have a look at the example here

Sounds very promising! Can your script handle multiple accounts, if each one is in a different currency? If I list each account in .env, how can the script assign the account-currency pairs?

<!-- gh-comment-id:2510233710 --> @bandiba commented on GitHub (Dec 1, 2024): > I've been able to extend the Docker-based setup with a script that converts transactions in a specified account, using exchange rates by transaction date. Have a look at the example [here](https://github.com/rbjansen/dual-actual) Sounds very promising! Can your script handle multiple accounts, if each one is in a different currency? If I list each account in .env, how can the script assign the account-currency pairs?
Author
Owner

@rbjansen commented on GitHub (Dec 1, 2024):

@bandiba Not currently, the code in the example assumes that there's just one account to convert. It also uses the ECB's exchange rates which have EUR as the base currency.

Happy to rewrite it a bit to handle multiple accounts with different currencies. Is there any exchange rate API you would suggest? (Edit: went ahead and updated, have a look)

<!-- gh-comment-id:2510253464 --> @rbjansen commented on GitHub (Dec 1, 2024): @bandiba Not currently, the code in the example assumes that there's just one account to convert. It also uses the ECB's exchange rates which have EUR as the base currency. Happy to rewrite it a bit to handle multiple accounts with different currencies. Is there any exchange rate API you would suggest? (Edit: went ahead and updated, have a look)
Author
Owner

@Ggpsv commented on GitHub (Dec 2, 2024):

Adding my 👍 to this one. I've tried to use Actual over the years but I have accounts and transactions in two different currencies. Using different budget files for each is too cumbersome.

<!-- gh-comment-id:2510474411 --> @Ggpsv commented on GitHub (Dec 2, 2024): Adding my :+1: to this one. I've tried to use Actual over the years but I have accounts and transactions in two different currencies. Using different budget files for each is too cumbersome.
Author
Owner

@bandiba commented on GitHub (Dec 2, 2024):

@rbjansen: I suspected so, smartly deducing from the name "dual" ;).

I checked how my favorite Portfolio Performance provides the USD/HUF rate for me. By default they also use ECB for Euro-sg else pairs, for other crossrates it seems I can select the rate provider from a long list, currently set to Yahoo Finance. Works pretty well.

Synth is not an option in Portfolio Performance, but looks like a great alternative! What I'm not getting reading the readme is where exactly do I define the currency of the account and the target currency...? Maybe I'm missing something obvious, now I have no time to try, hopefully later I can experiment with it.

But hey, big thanks to you for looking into this!

<!-- gh-comment-id:2510775921 --> @bandiba commented on GitHub (Dec 2, 2024): @rbjansen: I suspected so, smartly deducing from the name "dual" ;). I checked how my favorite Portfolio Performance provides the USD/HUF rate for me. By default they also use ECB for Euro-sg else pairs, for other crossrates it seems I can select the rate provider from a long list, currently set to Yahoo Finance. Works pretty well. Synth is not an option in Portfolio Performance, but looks like a great alternative! What I'm not getting reading the readme is where exactly do I define the currency of the account and the target currency...? Maybe I'm missing something obvious, now I have no time to try, hopefully later I can experiment with it. But hey, big thanks to you for looking into this!
Author
Owner

@rbjansen commented on GitHub (Dec 4, 2024):

What I'm not getting reading the readme is where exactly do I define the currency of the account and the target currency...? Maybe I'm missing something obvious, now I have no time to try, hopefully later I can experiment with it.

You can add this to the config.js. Replace (my) placeholders EUR and SEK :)

<!-- gh-comment-id:2517018082 --> @rbjansen commented on GitHub (Dec 4, 2024): > What I'm not getting reading the readme is where exactly do I define the currency of the account and the target currency...? Maybe I'm missing something obvious, now I have no time to try, hopefully later I can experiment with it. You can add this to the [`config.js`](https://github.com/rbjansen/dual-actual/blob/main/config.js). Replace (my) placeholders EUR and SEK :)
Author
Owner

@tlesicka commented on GitHub (Dec 4, 2024):

@rbjansen Would you be able to help make multi-currency a built-in feature? I've been working a little on it and could use some help.

Here's a link to a draft proposal:
[https://github.com/tlesicka/actual-budget-multicurrency-todo]

Here's the Discord discussion:
[https://discord.com/channels/937901803608096828/1224674202083393597]

<!-- gh-comment-id:2517215075 --> @tlesicka commented on GitHub (Dec 4, 2024): @rbjansen Would you be able to help make multi-currency a built-in feature? I've been working a little on it and could use some help. Here's a link to a draft proposal: [https://github.com/tlesicka/actual-budget-multicurrency-todo] Here's the Discord discussion: [https://discord.com/channels/937901803608096828/1224674202083393597]
Author
Owner

@bandiba commented on GitHub (Dec 5, 2024):

@rbjansen Thanks, I missed this, sorry.

I gave it a try yesterday, I'm stuck at an error message at the account listing step. I tried to use in config.js budgetId both the Budget ID and the Sync ID from the advanced settings page, same result.

What am I doing wrong? Do I need to define the sync ID somewhere else than config.js?

Thanks in advance.

$ docker exec -it dual-actual node lib/listAccounts
/app/node_modules/@actual-app/api/dist/app/bundle.api.js:37329
                        throw new Error(`Budget “${syncId}” not found. Check the sync id of your budget in the Advanced section of the settings page.`);
                              ^

Error: Budget “undefined” not found. Check the sync id of your budget in the Advanced section of the settings page.
    at handlers.api/download-budget (/app/node_modules/@actual-app/api/dist/app/bundle.api.js:37329:31)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

Node.js v18.20.4
<!-- gh-comment-id:2519449928 --> @bandiba commented on GitHub (Dec 5, 2024): @rbjansen Thanks, I missed this, sorry. I gave it a try yesterday, I'm stuck at an error message at the account listing step. I tried to use in config.js budgetId both the Budget ID and the Sync ID from the advanced settings page, same result. What am I doing wrong? Do I need to define the sync ID somewhere else than config.js? Thanks in advance. ```shell $ docker exec -it dual-actual node lib/listAccounts /app/node_modules/@actual-app/api/dist/app/bundle.api.js:37329 throw new Error(`Budget “${syncId}” not found. Check the sync id of your budget in the Advanced section of the settings page.`); ^ Error: Budget “undefined” not found. Check the sync id of your budget in the Advanced section of the settings page. at handlers.api/download-budget (/app/node_modules/@actual-app/api/dist/app/bundle.api.js:37329:31) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) Node.js v18.20.4 ```
Author
Owner

@rbjansen commented on GitHub (Dec 5, 2024):

@bandiba I missed a spot, sorry about that! Try again after a pull

<!-- gh-comment-id:2521374825 --> @rbjansen commented on GitHub (Dec 5, 2024): @bandiba I missed a spot, sorry about that! Try again after a pull
Author
Owner

@bandiba commented on GitHub (Dec 6, 2024):

@rbjansen No worries! This works now, it is great! Thanks a lot!!

May make sense to add to the Notes the original amount and currency of the transaction. Would help to identify the transaction in case of doubts.

Of course would be great to add a button to Actual UI to start the conversion, so no need to log in to server. Maybe this is what @tlesicka meant?

Edit: no, I just had a look at the proposal, it is more than that...

All in all, great job, finally I can switch to Actual for 2025 and enjoy the automatic bank sync!

<!-- gh-comment-id:2522490408 --> @bandiba commented on GitHub (Dec 6, 2024): @rbjansen No worries! This works now, it is great! Thanks a lot!! May make sense to add to the Notes the original amount and currency of the transaction. Would help to identify the transaction in case of doubts. Of course would be great to add a button to Actual UI to start the conversion, so no need to log in to server. Maybe this is what @tlesicka meant? Edit: no, I just had a look at the proposal, it is more than that... All in all, great job, finally I can switch to Actual for 2025 and enjoy the automatic bank sync!
Author
Owner

@ElDubsNZ commented on GitHub (Dec 30, 2024):

I think this could be done with a few rules.

  1. Lock down accounts and categories to allow one currency each.
  2. Allow users to create currencies and maintain these in a list (like payees).
  3. A transfer between accounts with different currencies must have an exchange rate entered on the transaction.
  4. Payments to payees can have a currency and exchange rate set for where you're buying something in a different currency to what the account has.

That's it really. Actual would use the user-provided information to disambiguate the budget page. The user would enter the currency details, for example full name "New Zealand Dollar", the short name (ISO 4217) "NZD", and the currency symbol "$".

Actual can then use the appropriate symbol "$5.00" or "€5.00" and where needed, and disambiguate with the short name "NZD$5.00". Or just the short code for symbolless currencies "NZD5.00".

With the budget page, you have a tab per currency that shows the categories in that currency. It's essentially a glorified filter feature in a spreadsheet.

This would still be a fair amount of work to implement, but with those basic principles, I think it's doable.

Down the line, you could let the user set up APIs to pull daily exchange rates, something managed in the currency menu. This would power the reports so they could show total assets. And it could pre-fill the exchange rate on new transactions.

This would allow people to not just have traditional currencies, but they could also put all their assets in. They could track their gold, or their crypto, or their stocks. A "currency" in this way is a very fluid concept. It's basically marking a currency as an asset with a value. Hell, technically I could create a milk budget and say I have "MLK4000" (4 litres) in my "fridge" account, and spend MLK300 in my breakfast category. There's really no limit to how flexible this makes the concept.

This is another feature that double-entry bookkeeping allows, and something I'd like to see implemented in Actual to align the two systems for future compatibility.

<!-- gh-comment-id:2565907220 --> @ElDubsNZ commented on GitHub (Dec 30, 2024): I think this could be done with a few rules. 1. Lock down accounts and categories to allow one currency each. 2. Allow users to create currencies and maintain these in a list (like payees). 3. A transfer between accounts with different currencies must have an exchange rate entered on the transaction. 4. Payments to payees can have a currency and exchange rate set for where you're buying something in a different currency to what the account has. That's it really. Actual would use the user-provided information to disambiguate the budget page. The user would enter the currency details, for example full name "New Zealand Dollar", the short name (ISO 4217) "NZD", and the currency symbol "$". Actual can then use the appropriate symbol "$5.00" or "€5.00" and where needed, and disambiguate with the short name "NZD$5.00". Or just the short code for symbolless currencies "NZD5.00". With the budget page, you have a tab per currency that shows the categories in that currency. It's essentially a glorified filter feature in a spreadsheet. This would still be a fair amount of work to implement, but with those basic principles, I think it's doable. Down the line, you could let the user set up APIs to pull daily exchange rates, something managed in the currency menu. This would power the reports so they could show total assets. And it could pre-fill the exchange rate on new transactions. This would allow people to not just have traditional currencies, but they could also put all their assets in. They could track their gold, or their crypto, or their stocks. A "currency" in this way is a very fluid concept. It's basically marking a currency as an asset with a value. Hell, technically I could create a milk budget and say I have "MLK4000" (4 litres) in my "fridge" account, and spend MLK300 in my breakfast category. There's really no limit to how flexible this makes the concept. This is another feature that double-entry bookkeeping allows, and something I'd like to see implemented in Actual to align the two systems for future compatibility.
Author
Owner

@bandiba commented on GitHub (Dec 31, 2024):

@rbjansen: I see that actual v24.12.0 is out. Can I update dual-actual to include the new version? What is the recommended way?

Thanks!

<!-- gh-comment-id:2566434971 --> @bandiba commented on GitHub (Dec 31, 2024): @rbjansen: I see that actual v24.12.0 is out. Can I update dual-actual to include the new version? What is the recommended way? Thanks!
Author
Owner

@rbjansen commented on GitHub (Dec 31, 2024):

@rbjansen: I see that actual v24.12.0 is out. Can I update dual-actual to include the new version? What is the recommended way?

Thanks!

Rebuilding should do it, docker compose up -d --build. However the latest image tag used does not point to v24.12.0 yet I believe, see here. Maybe check back again later.

Happy new year!

<!-- gh-comment-id:2566483587 --> @rbjansen commented on GitHub (Dec 31, 2024): > @rbjansen: I see that actual v24.12.0 is out. Can I update dual-actual to include the new version? What is the recommended way? > > Thanks! Rebuilding should do it, `docker compose up -d --build`. However the `latest` image tag used does not point to v24.12.0 yet I believe, see [here](https://hub.docker.com/r/actualbudget/actual-server/tags). Maybe check back again later. Happy new year!
Author
Owner

@andymarden commented on GitHub (Jan 8, 2025):

Thinking there could be a few options to handle this relatively simply (and I agree on the idea since YNAB is woefully short in this and I have to have two separate budget files to handles this - now same on Actual as well):

  1. Add fx rate or "base ccy equiv" per transaction - laborious but useful to some.
  2. Have the server go somewhere like xe.com and use the fx rate on the transaction date - much easier but more approximate - find for many use cases.
  3. Keep ccy's separate - an account only has one ccy.

All you need to handle this is one extra field on a txn - fx rate and/or base ccy amt (as well as ccy if not there) and a base ccy set at the budget level which is the ccy that everything is aggregated to.

When looking at budgets and aggregation you can do one of:

  1. Always use base ccy amt (same as txn ccy amt when ccy's are the same) - actually this says it is easier to add txn ccy amt and leave the current as base ccy to minimise change)
  2. Require budgets to have a ccy and links to accounts with that ccy.

A useful subset of these should not be that big a change in the code I reckon and you would be one step ahead of YNAB.

<!-- gh-comment-id:2578008530 --> @andymarden commented on GitHub (Jan 8, 2025): Thinking there could be a few options to handle this relatively simply (and I agree on the idea since YNAB is woefully short in this and I have to have two separate budget files to handles this - now same on Actual as well): 1. Add fx rate or "base ccy equiv" per transaction - laborious but useful to some. 2. Have the server go somewhere like xe.com and use the fx rate on the transaction date - much easier but more approximate - find for many use cases. 3. Keep ccy's separate - an account only has one ccy. All you need to handle this is one extra field on a txn - fx rate and/or base ccy amt (as well as ccy if not there) and a base ccy set at the budget level which is the ccy that everything is aggregated to. When looking at budgets and aggregation you can do one of: 1. Always use base ccy amt (same as txn ccy amt when ccy's are the same) - actually this says it is easier to add txn ccy amt and leave the current as base ccy to minimise change) 2. Require budgets to have a ccy and links to accounts with that ccy. A useful subset of these should not be that big a change in the code I reckon and you would be one step ahead of YNAB.
Author
Owner

@vinstaal0 commented on GitHub (Jan 8, 2025):

From what I have seen from bookkeeping software is that the transactions should always be stored in the currency that the transaction is in.

Then for the reports (in this case the budget and the reports) it will convert it using an exchange rate. Often an exchange rate is set once a year, but others might do it every month.
Updating the exchange rate every day is only done for medium or bigger companies.

You will always end up with exchange rate differences and there is no way around that. Plus a lot will get additional bankcosts which aren't always fully transparent so those will create differences as well.

<!-- gh-comment-id:2578252004 --> @vinstaal0 commented on GitHub (Jan 8, 2025): From what I have seen from bookkeeping software is that the transactions should always be stored in the currency that the transaction is in. Then for the reports (in this case the budget and the reports) it will convert it using an exchange rate. Often an exchange rate is set once a year, but others might do it every month. Updating the exchange rate every day is only done for medium or bigger companies. You will always end up with exchange rate differences and there is no way around that. Plus a lot will get additional bankcosts which aren't always fully transparent so those will create differences as well.
Author
Owner

@anatolybobunov commented on GitHub (Jan 17, 2025):

I’m waiting to add plugin functionality in the AB. Then I can write a specific plugin to automatically exchange currencies.

<!-- gh-comment-id:2597631564 --> @anatolybobunov commented on GitHub (Jan 17, 2025): I’m waiting to add plugin functionality in the AB. Then I can write a specific plugin to automatically exchange currencies.
Author
Owner

@bandiba commented on GitHub (Feb 19, 2025):

@rbjansen: After some time of happy use of dual-actual, I ran into some weird errors yesterday. Opened an issue in github, could you pls have a look when you get a chance...?

<!-- gh-comment-id:2667792782 --> @bandiba commented on GitHub (Feb 19, 2025): @rbjansen: After some time of happy use of dual-actual, I ran into some weird errors yesterday. Opened an issue in github, could you pls have a look when you get a chance...?
Author
Owner

@alshdavid commented on GitHub (Jan 21, 2026):

Messing with the experimental currencies feature. The current behaviour is a little confusing and impractical for real world use.

My 5c - In line with other bookkeeping software;

  • Have a default "base" currency for the user (e.g. AUD)
  • Each account is opened with the currency specified (defaults to base currency)
  • All transactions in that account are in the currency of that account
    • e.g. If you have a USD account and an AUD account, the balances of both accounts are in their respective currencies

When reports are generated, those reports estimate your net worth in your base currency by converting the account currency to the base currency (there are many free APIs that offer daily updates to currency conversions, for example this one and an example query)

Code
async function convertCurrency(value: number, base: string, target: string): Promise<number> {
  const from = base.toLowerCase();
  const to = target.toLowerCase();

  const url = `https://cdn.jsdelivr.net/npm/@fawazahmed0/currency-api@latest/v1/currencies/${from}.json`;

  const response = await fetch(url);
  const data = await response.json();
  const rate = data[from][to];

  return value * rate;
}

console.log(await convertCurrency(100, "AUD", "USD"))

Technically, the user should be able to switch the base currency and have their net worth represented in a different currency if they wanted to (e.g. they moved countries)

The same logic extends to accounts holding things like equities or other assets.

<!-- gh-comment-id:3776389387 --> @alshdavid commented on GitHub (Jan 21, 2026): Messing with the experimental currencies feature. The current behaviour is a little confusing and impractical for real world use. My 5c - In line with other bookkeeping software; - Have a default "base" currency for the user (e.g. AUD) - Each account is opened with the currency specified (defaults to base currency) - All transactions in that account are in the currency of that account - e.g. If you have a USD account and an AUD account, the balances of both accounts are in their respective currencies When reports are generated, those reports estimate your net worth in your base currency by converting the account currency to the base currency (there are many free APIs that offer daily updates to currency conversions, for example [this one](https://github.com/fawazahmed0/exchange-api) and an [example query](https://cdn.jsdelivr.net/npm/@fawazahmed0/currency-api@latest/v1/currencies/aud.json)) <details> <summary>Code</summary> ```typescript async function convertCurrency(value: number, base: string, target: string): Promise<number> { const from = base.toLowerCase(); const to = target.toLowerCase(); const url = `https://cdn.jsdelivr.net/npm/@fawazahmed0/currency-api@latest/v1/currencies/${from}.json`; const response = await fetch(url); const data = await response.json(); const rate = data[from][to]; return value * rate; } console.log(await convertCurrency(100, "AUD", "USD")) ``` </details> Technically, the user should be able to switch the base currency and have their net worth represented in a different currency if they wanted to (e.g. they moved countries) The same logic extends to accounts holding things like equities or other assets.
Author
Owner

@alshdavid commented on GitHub (Apr 21, 2026):

Trying to implement this myself I realised there are a few challenges;

  • historical reporting (charts)
  • adding/importing historical records/transactions
  • changing the base currency

To support these, we would need to locally store & maintain a lookup table indexed against the USD for each day.

This limits the currencies supported, adds an extra data-sync step where missing rates must be routinely fetched and only offers an approximate transaction value as defined by the FX rate at the end of each day (which may differ from the time the transaction was made).

This free API https://frankfurter.dev/currencies/ which covers over 30 years+ of data currency data and can be self hosted (or scraped to create a static lookup table). This local table would only be a few megabytes (likely no more than 1mb) so it's not that bad.

<!-- gh-comment-id:4285670695 --> @alshdavid commented on GitHub (Apr 21, 2026): Trying to implement this myself I realised there are a few challenges; - historical reporting (charts) - adding/importing historical records/transactions - changing the base currency To support these, we would need to locally store & maintain a lookup table indexed against the USD for each day. This limits the currencies supported, adds an extra data-sync step where missing rates must be routinely fetched and only offers an approximate transaction value as defined by the FX rate at the end of each day (which may differ from the time the transaction was made). This free API [ https://frankfurter.dev/currencies/ ]( https://frankfurter.dev/currencies/) which covers over 30 years+ of data currency data and can be self hosted (or scraped to create a static lookup table). This local table would only be a few megabytes (likely no more than 1mb) so it's not that bad.
Author
Owner

@jamezpolley commented on GitHub (Apr 23, 2026):

To support these, we would need to locally store & maintain a lookup table

Just for clarity - I think that what you're talking about here are cases where I might use AUD as my default currency, but have a USD account as well. If I have a transaction in USD coming out of that USD account, and three years later I want to know how many AUD that was on that day - that's when the lookup table comes in handy.

The more common occurrence for me though is that I pay for something in USD and it comes out of one of my AUD accounts. For those transactions, I want to track:

  • Which foreign currency
  • The foreign currency amount
  • The amount of AUD that left my account

There's no lookup table needed there (except for the "changing the base currency" scenario, but that's always a pain).

Am I right in thinking that's what you're thinking about?

indexed against the USD for each day.

I'm assuming you mean "against the user's default currency" rather than against the USD)

<!-- gh-comment-id:4302150586 --> @jamezpolley commented on GitHub (Apr 23, 2026): > To support these, we would need to locally store & maintain a lookup table Just for clarity - I think that what you're talking about here are cases where I might use AUD as my default currency, but have a USD account as well. If I have a transaction in USD coming out of that USD account, and three years later I want to know how many AUD that was on that day - that's when the lookup table comes in handy. The more common occurrence for me though is that I pay for something in USD and it comes out of one of my AUD accounts. For those transactions, I want to track: - Which foreign currency - The foreign currency amount - The amount of AUD that left my account There's no lookup table needed there (except for the "changing the base currency" scenario, but that's always a pain). Am I right in thinking that's what you're thinking about? > indexed against the USD for each day. I'm assuming you mean "against the user's default currency" rather than against the USD)
Author
Owner

@alshdavid commented on GitHub (Apr 23, 2026):

Just for clarity - I think that what you're talking about here are cases where I might use AUD as my default currency, but have a USD account as well. If I have a transaction in USD coming out of that USD account, and three years later I want to know how many AUD that was on that day - that's when the lookup table comes in handy.

Yep! That's right

I'm assuming you mean "against the user's default currency" rather than against the USD)

This is more of a technical blah than something that would affect users. The lookup table would need to have some generic "base" to act as an index for all conversions. For example AUD -> NZD would step through;

AUD -> USD
USD -> NZD

Otherwise you'd need to have the lookup table contain every currency against every currency for every day in the index - it'll become very bloated 😆

The more common occurrence for me though is that I pay for something in USD and it comes out of one of my AUD accounts.

Please correct me if I am wrong, but I think Actual does this already and is how we track online purchases?

For example I have this entry;

Image

The bill from Amazon is in USD, but I was charged in AUD

<!-- gh-comment-id:4302608616 --> @alshdavid commented on GitHub (Apr 23, 2026): > Just for clarity - I think that what you're talking about here are cases where I might use AUD as my default currency, but have a USD account as well. If I have a transaction in USD coming out of that USD account, and three years later I want to know how many AUD that was on that day - that's when the lookup table comes in handy. Yep! That's right > I'm assuming you mean "against the user's default currency" rather than against the USD) This is more of a technical blah than something that would affect users. The lookup table would need to have some generic "base" to act as an index for all conversions. For example `AUD -> NZD` would step through; ``` AUD -> USD USD -> NZD ``` Otherwise you'd need to have the lookup table contain every currency against every currency for every day in the index - it'll become very bloated 😆 > The more common occurrence for me though is that I pay for something in USD and it comes out of one of my AUD accounts. Please correct me if I am wrong, but I think Actual does this already and is how we track online purchases? For example I have this entry; <img width="961" height="49" alt="Image" src="https://github.com/user-attachments/assets/8f22050c-e65a-40ac-a69b-9006180952df" /> The bill from Amazon is in USD, but I was charged in AUD
Author
Owner

@StephenBrown2 commented on GitHub (Apr 23, 2026):

I think the better solution is to simply store the converted amount (to the user's selected base currency) in the transaction table (in the database) itself, rather than adding a whole new exchange rates table. That value could be exposed via hover on the foreign amount of each transaction.

<!-- gh-comment-id:4306567273 --> @StephenBrown2 commented on GitHub (Apr 23, 2026): I think the better solution is to simply store the converted amount (to the user's selected base currency) in the transaction table (in the database) itself, rather than adding a whole new exchange rates table. That value could be exposed via hover on the foreign amount of each transaction.
Author
Owner

@alshdavid commented on GitHub (Apr 24, 2026):

I think the better solution is to simply store the converted amount (to the user's selected base currency) in the transaction table (in the database) itself, rather than adding a whole new exchange rates table. That value could be exposed via hover on the foreign amount of each transaction.

Ok, say I import a CSV with my last month's worth of transactions in USD to my USD account, while my base currency is AUD.

  1. When the import happens, the USD -> AUD conversion needs to be historically accurate (necessitating a lookup table)
  2. If the entiries are in AUD despite originally being USD, reconciliation of records would become a nightmare, as I would need to compare my USD statement against AUD values that are different on each day.

I think it makes sense that the "All Accounts" is displayed in the base currency, while the account specific page is in the account's currency.

Like this;

Image

Open questions;

  • What happens if you want to change the value from the "all accounts" page
    • It might be better to have the value in the account currency though that's annoying to look at
  • How would "transfers" between currencies work?
    • If I transfer 10 USD to AUD between my Wise accounts, they will have different values due to conversion losses and inaccuracy in the conversion rate.
<!-- gh-comment-id:4309831973 --> @alshdavid commented on GitHub (Apr 24, 2026): > I think the better solution is to simply store the converted amount (to the user's selected base currency) in the transaction table (in the database) itself, rather than adding a whole new exchange rates table. That value could be exposed via hover on the foreign amount of each transaction. Ok, say I import a CSV with my last month's worth of transactions in USD to my USD account, while my base currency is AUD. 1) When the import happens, the USD -> AUD conversion needs to be historically accurate (necessitating a lookup table) 2) If the entiries are in AUD despite originally being USD, reconciliation of records would become a nightmare, as I would need to compare my USD statement against AUD values that are different on each day. I think it makes sense that the "All Accounts" is displayed in the base currency, while the account specific page is in the account's currency. Like this; <img width="1258" height="788" alt="Image" src="https://github.com/user-attachments/assets/e77472f9-a12f-473c-b404-5678830a9779" /> Open questions; - What happens if you want to change the value from the "all accounts" page - It might be better to have the value in the account currency though that's annoying to look at - How would "transfers" between currencies work? - If I transfer 10 USD to AUD between my Wise accounts, they will have different values due to conversion losses and inaccuracy in the conversion rate.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#49555