Feature Request: Add multi-currency support

[Sleapy31]

Hi, It could be nice if we could have the following changes, they are not breaking changes I guess:

1. Having all currencies in the world as a choice of default currency.
In settings we set the actual currency as the default one.

2. Having the choice of the currency when adding an expense, if none is specified it default to the default currency.
I guess this one is important for people who travels a lot or may have expenses in a different currency (like online shopping for example).

3. Having a conversion in the default currency for an expense with another currency.
When an expense is added with a different currency than the default currency, an http call is made to fetch the correct conversion rate. If an error is returned then no converted amount is shown.
The Json payload will change because we have to add a "currency" field and a "convertedAmount" field but both could be instantiate as a default object and shown as is. (default currency for the "currency" field and 0 for "convertedAmount" which means that we don't show any conversion in the UI.

I have no bagage in Go or javascript but I can try to generate something.

[Tanq16]

hello! thanks for the request @Sleapy31

conversion requires an active internet connection, so it will fail in case of local-only network access.

i'm not sure what's the best way to add this as a feature .. i have a refactor in progress right now in #62 , so i don't mind changes to the backend structs, since that will be a breaking release.

but tbh, i'm not too convinced this would be desirable. it also serves to complicate the add expense form (the complexity is set to increase with the refactor)

i've seen some apps handle this with different accounts (like a $ account and another yen account, etc.) but i have not seen apps that convert rate for you; especially since converted amounts will lead to varying balances

let's discuss the feasibility if you're up for it. if it looks like an addition worth it, i'll add a dummy field in the refactor for a later implementation

[Sleapy31]

Hi! Actually since my post I forked your refactored-backend branch and started it implement it lol. I am almost finished but I went into several issues.
I'll post the branches here and explain it better when I am finished and maybe we can pick whatever is good and let whatever is not really desirable.

But in short there is a local .json file now to fetch all the currency and their behavior for string representation, the ability to specify another currency for an expense and a simple api to fetch current rate of the day (with little memory caching).
This works well but if an user want to change again the default currency in the settings all the conversions will break so I went further but I guess it'll not be so simple anymore so we'll see when I'm finished.

[ericjack371]

add BDT - ৳ currency

[Tanq16]

just for completeness, i will be adding some skeleton to support this feature, so we don't need a breaking change in the future. i have a theoretical way of dealing with this. but it won't be part of the refactor. feel free to work on it in the meantime, but be sure to pull the refactor once the new release hits. i'll be changing a couple things

[Sleapy31]

Hi, I haven't got much time to continue this week but I guess I am at the end of the tunnel lol. I think I'll write here what I did before cleaning up the branches and push them on github.
I already picked the actual refactored-backend branch as a source, there is no breaking changes yet to my knowledge. There is new changes of course but old requests should work as usual. We'll see if we can merge the changes with the new release

[Sleapy31]

Ok so I basically finished what I wanted to add. There is still some cleaning to do but you can can start to review it if you want.
I am not used to Go, Javascript and Html so I had help from AI and it maybe can shows in the code. It was maybe the first time coding in these langage too lol.

https://github.com/Sleapy31/ExpenseOwl/tree/multiple-currencies-fx-support

I'll explain a little bit how I decided to implement theses changes.

1. Having all currencies in the world as a choice of default currency.
Since you hardcoded a list of currency in storage.go file. I first decided to generate another currencies.go file to hardcode currencies too.
I generated a worldCurrencies.json file and a script to do it.
Later I needed to handle formatting behavior for each currency in javascript code so I directly imported the .json file in it.
I think the best thing would be to get rid of the hard coded part and just let the backend import the .json and manage the api requests from the frontend.

2. Having the choice of the currency when adding an expense, if none is specified it default to the default currency.
So basically every time we add an expense the currency is set to default currency but you can change it if you want.

3. Having a conversion in the default currency for an expense with another currency.
I initially added a "convertedAmount" variable in Expense struct but I finally reverted it. The reason is that if the user change the default currency in the settings another time, that convertedAmount stays in the old value. I realized that the convertedAmount should be only for UI purpose.
At first I had a helper to get rates from internet (I found this repo to help me with that: https://github.com/fawazahmed0/exchange-api).

Finally since I wanted the user the possibility to change back and forth the default currency I added a storage of those conversions rates. For each day/currency pair we can have in our expense list, we store around 160 rates. I quickly benchmarked it in another project to evaluate disk space and even with 10k unique pair (different days or currency) we only store a few megabytes. The reality will be much less since we usually have fewer foreign currency expenses.

UI Changes
No breaking changes but I adapted some things. index.html now shows amounts converted to default currency. So if my default currency is USD and I add few expenses in EUR, they are all shown in USD. There is a line under Total who shows the percentage of other currencies in that total.
In table.html we have another table column who show the amount in the default currency if there is any.
Since all rates are fetched and stored, it could be useful to add a button to select a kind of "show in that currency" button without change settings but It would only serve curiosity I guess lol.

ToDo
Some cleaning, I realized after pushing the branch that I forgot to delete useless functions or some work I've done before reverting it.
I'll wait for your release to adapt the code to your likeing and see if we can merge it.

TLDR; I added support to all currencies, we can add expenses with other currencies, rates are fetched then stored and conversions shown in UI

[Tanq16]

hello @Sleapy31 , sorry - i meant, i'm about to change the signage as a fundamental thing in the refactor.

but your explanation looks good to me. i have thoughts though. i almost want to avoid storing an exchanged amount, to me that goes against maintaining a base currency.

i know you've spent effort making this - are you open to working with some suggestions on this?

i'd love to have this work be done by you and get it merged. i'd like to do this piece only after the refactor hits, so that we have a working base. so as to not make a breaking change in the future, i will add a currency field for expenses for when we implement this

here's the difference i'm thinking of about for implementing this

• we don't convert the amount to store in the backend
• since i specifically do all the analysis and charting in the frontend, we should treat backend as source of truth
• i.e., currency and exact amount will always be consistent in the backend
• for exchange rates, we can fetch from a decent api (i'd prefer not using a lib for this if it is a simple api op)
• exchange rates can be maintained in a db/json file with simple methods on the storage interface: GetExchangeRates(), PutExchangeRates()
• we can have a go routine fetch the exchange values periodically and maintain that in the backend

the improvements with this:

• backend data is now static and source of truth
• exchange rate fetch can be throttled/fail due to networks so putting in a separate go routine allows app to function without depending on it
• we can maintain a sensible average as default exchange rate too

the only con is we need to do more testing on the import/export pieces because currency is included per expense. i will think a bit more on this con today/tom and may add a solution to the refactor to avoid a future breaking change too

how does that sound?

also, may be evident lol - i don't have a fait idea of designing a full fledged expense app, so all of the above is just design thoughts. though i would love to review other open source projects to see how they handle the logic. do you have a target app you had in mind when you suggested the feature?

[Sleapy31]

Hi, no problem I'll wait for your new release to refactor it.
All the points you mentionned are almost already implemented.

we don't convert the amount to store in the backend
No converted amount is stored in the end. There is only an added Currency field in the expense and recurring expense struct. The amount is the same as the user send.

since i specifically do all the analysis and charting in the frontend, we should treat backend as source of truth
I agree with that. For now the frontend fetch rates from db/json and do the conversion itself but I was already thinking of adding another api to get only convertedAmount (the backend still fetch rates but add a 'amount * rate' operation). I personally prefer if the worldCurrencies.json file is only accessed by backend and whenever frontend need to get currency list and his behavior (like if there is a comma or a point or where to place the symbol) it fetch it from backend.
If the user wants to add a fantasy currency for fun purpose he can still modify that .json file.

i.e., currency and exact amount will always be consistent in the backend
As I said earlier, it will be. When an expense is saved its currency and amount is stored with it, I can of course edit or delete it like before.

for exchange rates, we can fetch from a decent api (i'd prefer not using a lib for this if it is a simple api op)
the repo I use just host rates on a cdn. No library is used, just simple http call : https://cdn.jsdelivr.net/npm/@fawazahmed0/currency-api@2025-07-19/v1/currencies/eur.json

exchange rates can be maintained in a db/json file with simple methods on the storage interface: GetExchangeRates(), PutExchangeRates()
I have two functions to fetch rates. GetRate() who take a REST approach but only query single rate (I think I will refactor this one to match the second one) and a GetRates() who take a json body and a POST method and will return a map of dates, base, quote.

we can have a go routine fetch the exchange values periodically and maintain that in the backend
It is already implemented. Whenever we add an expense with another currency, it launch a goroutine to fetch rate. The UI does not show converted amounts until there is one to show.
Same thing, if during the GetRates() function there is unfound rates, it launches a goroutine to fetch them and be available on next calls.

The only drawback I can see is that the backend will store rates for all currencies for a specific date/currency pair and the disk storage would be higher than expenses if there is a lot of different pairs. I'll post a summary of my benchmarks at the end of the post for informations

About the export/import thing. after the refactor all new expenses will have the currency set based on the settings. I did not code a migration for old expenses yet because I was thinking you maybe was doing it already lol. But we can simply do the same and add the currency field with the currency set in the settings.

Sorry the post is really long I should try to short it a bit next time lol.

For informations for the benchmark. I did it in C# because I am more familiar with it but I wanted to see the impact of .json storage files on disk.

For 100k Txs including 4 other currencies during 10 years:
rates.json: 18.68mb
expenses.json: 17.87mb

For 10k Txs including 4 other currencies during 10 years (basically 1 rate per tx):
rates.json: 18.87mb
expenses.json: 1.79mb

For 1k Txs including 4 other currencies during 10 years:
rates.json: 2.6mb
expenses.json: 0.18mb

--

For 100k Txs including 4 other currencies during 1 year:
rates.json: 18.68mb
expenses.json: 4.12mb

For 10k Txs including 4 other currencies during 1 year::
rates.json: 3.17mb
expenses.json: 1.79mb

For 1k Txs including 4 other currencies during 1 year:
rates.json: 1.23mb
expenses.json: 0.18mb

But the reasonable numbers would be no more than 200 rates per year which would decrease even more the disk footprint (around 0.5mb).

[Tanq16]

@Sleapy31 , thanks - this is in pretty nice shape then

we can optimize for disk space for rates later.

pulling that from cdn sounds good to me.

i just pushed an update to include currency for expenses and recurring expenses. added it to import also

did not code a migration for old expenses yet because I was thinking you maybe was doing it already

yep, np. the refactor release is a breaking release anyway because of signage and a bunch of things. i just wanted to put the currency pieces in place so when we merge your update, it doesn't end up breaking.

i will change signage tomorrow, test the app with the new currency piece in the struct.

do you mind looking at the refactored branch and confirm those currency additions are good?

im almost done with the refactor, so will be releasing this weekend. we can then do testing and smaller release for your PR on multi-currency (and i might club that with some ui updates)

[Sleapy31]

@Tanq16 I reviewed it and I did almost the same thing for adding Currency field in databaseStore and jsonStore.
I just modified the Currency name in settings from Currency to DefaultCurrency (and requests linked to it too) to avoid any confusion when switching between files. If that is an issue I can revert back to previous name.

You can try my branch and see if the changes in UI are ok with your plan and what I could change.