Strategy for multi currency

[Dmitry Kudryavtsev]

Recently I made a relocation. This means I now live with two main currencies.

Before relocating, I used currency as a name for the leaf account. So if I had a bank account BankA that held both EUR and USD, I’d have two account BankA:EUR and BankA:USD.

However, since most of my expenses were made from my main currency, I usually recorded that in that currency, even when traveling, since the bank usually did the conversion of which I didn’t care. So my income/expense had one level, let’s say Expenses:Groceries.

Now I have more than 10 years worth of financial data in my main currency and I’m wondering how to move forward. I could let Groceries have expenses in two currencies, but in GnuCash I adopted the currency name as a leaf for most income/expenses as well, so I’d have Groceries:USD and Groceries:EUR.

Is this a good model for starting with beancount, or I should just let income/expenses contain multiple currencies?

Thanks!

[Martin Blais]

In my ledger i've let these accounts have multiple currencies and do a conversion in one or the other when reporting / computing balances.

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAEzdkV9ZWWVET9FgUQuHBX-%3DnoriruTi6Tu%3DKeTy_O0P1VDhYA%40mail.gmail.com.

[Dmitry Kudryavtsev]

Thanks. I slept on it and I think it makes sense to create a subcategory for expenses in each country, the same way as "Income:US:Salary" and "Income:UK:Salary" is shown as an example in the documentation. This allows to have proper separation between the two countries. On the other hand, on expenses such as travel, I think it makes sense to have on category, such as "Expenses:Travel:Flights", that can hold transactions in multiple currencies.

[Martin Blais]

+1 to that

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/ea5897f1-071a-42b4-b431-7e7a6e4b3639n%40googlegroups.com.

[Justus Pendleton]

FWIW, I have income and expenses in three countries (and three currencies) and have to file taxes in all three and I've never seen a point in having subcategories per-country for either expenses or income.

The hard part with any kind of accounting is that your account structure needs to reflect what you're actually going to do with the information. What are you going to do with knowing that some of your grocery expenses were in Country A and some in Country B? Does it affect tax reporting or your spending behaviour or...something? That's what needs to drive your account structure.

So, for instances, I pay taxes on global income. There's no point in pretending that income from Country A is somehow different from income from Country B. The distinction has never once come up -- for me! -- in almost a decade of using beancount across multiple countries.

And the great thing about plaintext accounting is that if I ever decide I'm wrong, it is pretty easy to edit all the files and change things around in the future.

[Dmitry Kudryavtsev]

It does make sense when you put it this way. 

The things is I’m new to PTA so I’m somewhat afraid to commit to a particular CoA, so I’m trying to come with the best setup right ahead. But I guess I just need to start and see how it goes throughout at least one/two tax seasons.

You received this message because you are subscribed to a topic in the Google Groups "Beancount" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beancount/gpc1G1ho63E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/4d9cd994-928b-4007-a275-4b1d12dbc281n%40googlegroups.com.

[Chary Chary]

I think the conversation now is not about Strategy for multi currency, not about  Strategy for multi location.

My approach is that I normally try to log as much information as I may need in the future and be sure, that I know how to extract it later.

If you think of it, country of expense is just one of the things you may want to track for the purposes of the future data analysis. But this is not the only information, you may want to track.

Say you track Expenses:Clothing. But you may want to track this per country and also per family member. Say you have 4 family members and you have expenses in 3 countries, In this case just for Expenses:Clothing you will have 3*4 = 12 sub-accounts

Expenses:Clothing:UK:John

Expenses:Clothing:UK:Mary

Expenses:Clothing:UK:Richard

Expenses:Clothing:UK:Anna

Expenses:Clothing:US:John

Expenses:Clothing:US:Mary

Expenses:Clothing:US:Richard

Expenses:Clothing:US:Anna

.......

If you then separate Clothing on Clothing and Footwear, you already end up with 24 accounts

This very quickly becomes not manageable. However the advantage of keeping meta information in an account is that beancount gives you a lot of  control about accounts (it checks them,  you can then close them at certain moment etc).

Another disadvantage is that it is not that easy for instance to group expenses per country, as the country is berried as the 3rd element of the account name.

Another alternative is to keep meta data in a meta field. Meta fields do not have a lot of built in checks (but you can script them), but avoids problems, mentioned above.

Example:

2024-01-01 price GBP 2 USD

2024-01-01 * "Shopping UK"

    Expenses:Clothing                    100 GBP

      country:"UK"

    Assets:Cash

2024-01-01 * "Supermarket UK"

    Expenses:Supermarket                 50 GBP

      country:"UK"

    Assets:Cash

2024-01-02 * "Shopping US"

    Expenses:Clothing                 100 USD

      country:"US"

    Assets:Cash

2024-01-02 * "Supermarket US"

    Expenses:Supermarket                 50 USD

      country:"US"

    Assets:Cash

You can then query the above like this for instance

SELECT  meta['country'] as country, account,   SUM(convert(position,"USD", date)) as USD

WHERE account ~ "Expenses"

GROUP BY country, account

You can experiment with it here:

https://colab.research.google.com/drive/1DNmh9Jlos_LHIN2joGzs3-EKcKt6qzZr?usp=sharing

[Dmitry Kudryavtsev]

This is an interesting approach. Old me would love to go to that level of details, but new me is different. I no longer care about diving that deep. I usually care about the bottom line of Income-Expenses being greater than 0. I keep an eye on this number every week, as well as comparing it to previous months, and if one category is getting bigger than it used to, then it's easy to deep dive into the list of transactions and see if it's justifiable or not.

But it is an interesting approach indeed.

[Red S]

The things is I’m new to PTA so I’m somewhat afraid to commit to a particular CoA, so I’m trying to come with the best setup right ahead. But I guess I just need to start and see how it goes throughout at least one/two tax seasons.

I had similar concerns long ago. And this seems to be a general theme that comes up over and over with setting up one's accounting system, and it makes sense that it does. The beautiful thing about PTA (or the Beancount ecosystem at least), is it's extremely easy to make changes to one's account structure and even transaction structure at any point. Changing account structure permanently is a simple sed command. Doing it temporarily on demand can be done via a plugin. More complex transformations of your ledger file can be done via autobean.

What've I've found with all of this is, I don't need to sweat out making an optimal decision upfront. Your approach about just starting and trying it out will work really well!