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. On Tuesday, August 27, 2024 at 2:54:25 PM UTC+2 [email protected] wrote: > 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 > > On Monday, August 26, 2024 at 8:22:16 PM UTC+2 [email protected] wrote: > >> 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. >> >> On Mon, Aug 26, 2024 at 05:57 Justus Pendleton <[email protected]> wrote: >> >>> 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. >>> >>> >>> On Monday, August 26, 2024 at 1:12:27 AM UTC+7 [email protected] wrote: >>> >>>> 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. >>>> >>>> On Sunday, August 25, 2024 at 9:39:54 AM UTC+2 [email protected] wrote: >>>> >>>>> In my ledger i've let these accounts have multiple currencies and do a >>>>> conversion in one or the other when reporting / computing balances. >>>>> >>>>> On Sat, Aug 24, 2024, 23:41 Dmitry Kudryavtsev <[email protected]> >>>>> wrote: >>>>> >>>>>> 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! >>>>>> >>>>> -- >>>>>> 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 [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/beancount/CAEzdkV9ZWWVET9FgUQuHBX-%3DnoriruTi6Tu%3DKeTy_O0P1VDhYA%40mail.gmail.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/beancount/CAEzdkV9ZWWVET9FgUQuHBX-%3DnoriruTi6Tu%3DKeTy_O0P1VDhYA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>> >> 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 >>> [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/beancount/4d9cd994-928b-4007-a275-4b1d12dbc281n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/beancount/4d9cd994-928b-4007-a275-4b1d12dbc281n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/ac711b5e-44d8-40da-b541-50c64237991an%40googlegroups.com.
