Does Actual Budget Support Multiple Currencies? (2026)

If you searched for whether Actual Budget handles more than one currency, you probably already suspect the answer. Here it is plainly, and then the useful detail.

The short answer

Actual Budget does not support multiple currencies natively. This is not a gap someone forgot to document. It is a stated design position. From Actual’s own multi-currency documentation:

The Actual Budget software is currency agnostic and does not support multi-currency.

“Currency agnostic” is worth understanding, because it is not the same as “broken”. Actual stores amounts as plain numbers and does not attach a currency to them. If every account you own is in the same currency, this is invisible to you, and Actual works beautifully. The moment two currencies exist in one budget, those plain numbers get added together as if they were the same unit, and your totals stop meaning anything.

Why this matters more than it sounds

The failure is quiet, which is what makes it worth knowing about.

Nothing errors. No warning appears. A 500 EUR balance and a 500 PLN balance simply sum to 1000, and your net worth is confidently wrong. Transfers between accounts in different currencies are the sharpest version of this: you debit 11 USD and credit 10 EUR, and the two sides of a transfer that should balance do not.

If you are budgeting across currencies, the number you most need to trust is the one that breaks first.

The official workaround

Actual documents a real workaround rather than leaving you to invent one, which is to their credit. It uses Rule Action Templating, an experimental feature.

One thing to know before you build on it, because Actual’s own pages disagree with each other on this point. The multi-currency documentation still recommends rule action templating, but the templating page itself now carries a deprecation notice:

Rule action templating is deprecated and will be removed in a future release. New rules should use Rule formulae instead, which cover the same use cases with a more powerful Excel-style syntax.

No removal date is given. If you set this up today, expect to migrate your rules to Rule formulae at some point, and treat any tutorial written before mid-2026 as describing the older syntax.

The approach, in outline: for each foreign currency account you create two rules. They convert the incoming amount into your budget currency automatically, and record the exchange rate that was used in the transaction notes so the conversion stays auditable.

It genuinely works, and for some people it is enough. Two things to weigh before committing to it:

The rate lives in the rule. It is a number you typed, not a live feed. When the rate moves, you update the rules yourself. For a currency pair that drifts slowly this is a minor chore. For a volatile pair, or for someone reconciling a year of history, it is not.

Historical accuracy is up to you. A transaction from eight months ago should be valued at the rate that applied on the day it happened, not today’s rate. Rule-based conversion applies whatever rate the rule currently holds, so backfilled or re-imported history can be converted at the wrong rate without anything looking wrong.

Actual is explicit that this is temporary. Their docs frame it as what to do “until multi-currency is supported natively”.

What is actually coming

Native support is being built. The publicly documented direction is one budget currency, many account currencies, which is the right model: each transaction carries its own currency, its own native amount, the exchange rate applied, and the date of that rate, alongside the base currency equivalent.

The public tracker Actual’s docs link to shows real progress: the first step is merged, and currency support itself is in development. It also sets expectations worth carrying into your decision. The FX rate table is planned as manual entry initially, and both the budget’s base currency and an account’s currency are intended to be fixed once set.

So even after native support lands, the first version is unlikely to fetch rates for you. If what you need is automatic daily rates and correctly valued history, that is a later milestone rather than the one being built now.

That is a substantial change to a core data model, which is why Actual’s own wording is careful:

People are working on implementing currency support, but it will take time.

If you are choosing a tool for the next few months, treat multi-currency as not yet available. If you are choosing for the next few years and like everything else about Actual, it is reasonable to wait. Both are defensible, and they are genuinely different decisions.

Where Actual remains the better pick

This is not a case of one tool beating another. Actual is very good at what it set out to do.

Its local-first architecture is a real differentiator: your data lives on your machine, it works offline, it is fast, and it is fully open source and self-hostable. If you want your finances on hardware you control, few tools come close. The rule system is powerful, the community is active, and if you have one bank account in one currency, Actual is hard to beat and the currency question never touches you.

Choose based on whether you actually hold money in more than one currency. If you do not, this entire article is irrelevant to your decision, and you should evaluate Actual on its considerable merits.

If you need multi-currency today

Several personal budgeting tools have native support: Toshl, Lunch Money, PocketSmith, and Tallyroot. We build Tallyroot, so treat what follows as interested rather than neutral, and go verify it.

The specific thing worth testing in any of them, including ours, is this: does it convert at the rate from the day of the transaction, or at today’s rate? Many tools that advertise multi-currency do the second one. It looks correct in a demo with recent data and quietly misstates any history longer than a few months. Import a year of real transactions in two currencies and check whether last spring’s numbers still look right.

Tallyroot was built around this from the start. Every transaction is stored in the currency it happened in and valued in your base currency at the historical rate, which is also why it uses a double-entry ledger rather than a single-entry list: a cross-currency transfer has two legitimately different amounts on its two sides, and single-entry has nowhere to put that.

If you want the longer version, we wrote about how multi-currency budgeting actually works and compared the tools that support it.

In one line

Actual Budget is excellent single-currency software with an honest workaround and credible plans for the rest. If your money lives in one currency, use it. If it does not, use something that already does the conversion properly, and check the historical rates before you trust it.