Grouping Income accounts

90 views
Skip to first unread message

mikv...@gmail.com

unread,
Apr 14, 2017, 4:28:07 PM4/14/17
to Beancount
I started to use Beancount some time ago without reading entire documentation. Thus, I have Income accounts grouped by income type. E.g.

Income:Interest:MyBank:Savings
Income:Interest:AnotherBank:Savings

But I have found that Beancount doc recommends grouping Income accounts by institution.

What advantages does this approach have?

Thanks.

Oon-Ee Ng

unread,
Apr 14, 2017, 7:51:30 PM4/14/17
to bean...@googlegroups.com
First thing to note is that it's fairly trivial to convert account names (assuming you're handy with your editor, regex, sed, or any other string processing method).

That being said, the main difference between Income:Type:Institution and Income:Institution:Type is what the main group is.

Using 'Institution' as the main group means you have an overview amount/transaction list per institution. So you know how much 'business' you do with a particular BankA, and how much of your net worth currently resides in that bank. In my country, for example, automatic government insurance on deposited amount is per-institution, so I can immediately see if my total deposits in various types of accounts is close to that limit (at which point moving some funds to another institution makes sense).

Using 'Interest' as a main group has a different utility, as it allows easy viewing of how much interest you actually made, across all institutions.

Of course, a quick query can 'solve' both of the above, whatever your structure. So no, it doesn't really matter much at the end of the day. I prefer the recommended way because I use fava exclusively and it displays nicely there without me having to write a query.


--
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+unsubscribe@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/96a2303f-c5ef-44bc-bbd3-77d3cfc255cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

mikv...@gmail.com

unread,
Apr 15, 2017, 12:12:27 AM4/15/17
to Beancount
Thanks for the prompt reply.


On Saturday, April 15, 2017 at 9:51:30 AM UTC+10, Oon-Ee Ng wrote:
First thing to note is that it's fairly trivial to convert account names (assuming you're handy with your editor, regex, sed, or any other string processing method).
This brings another interesting question. Are there any tools available that can manipulate ledger files on a higher level?
Regex search and replace is sufficient in this case, but I would like to perform more complex file transformations in the future.


Using 'Institution' as the main group means you have an overview amount/transaction list per institution. So you know how much 'business' you do with a particular BankA, and how much of your net worth currently resides in that bank. In my country, for example, automatic government insurance on deposited amount is per-institution, so I can immediately see if my total deposits in various types of accounts is close to that limit (at which point moving some funds to another institution makes sense).
We also have limited government insurance. This is why I choose Institution grouping for Asset accounts but I wasn't able to find strong reasons to use the same grouping for Income accounts. It looks like it is a matter of personal preference.
 
Of course, a quick query can 'solve' both of the above, whatever your structure. So no, it doesn't really matter much at the end of the day. I prefer the recommended way because I use fava exclusively and it displays nicely there without me having to write a query.
I tried fava and it looks great. Now I am wondering how one can switch between rendering income by institution (banks) and by type (i.e. interest) writing queries in fava.

It is easy to do with bean-web since I can select components (either institution name or income type) on the main page and then navigate to Income Statement page.
 
On Sat, Apr 15, 2017 at 4:28 AM, <mikv...@gmail.com> wrote:
I started to use Beancount some time ago without reading entire documentation. Thus, I have Income accounts grouped by income type. E.g.

Income:Interest:MyBank:Savings
Income:Interest:AnotherBank:Savings

But I have found that Beancount doc recommends grouping Income accounts by institution.

What advantages does this approach have?

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 beancount+...@googlegroups.com.

Martin Blais

unread,
Apr 15, 2017, 3:54:11 PM4/15/17
to Beancount
One the one hand, it doesn't matter. On the other, it does. 
In any case, the concern is that of automatically creating aggregation groups.

For the former, these account names can be viewed like columns in a data table, e.g. in your case

category  type      institution  account
Income    Interest  MyBank       Savings
Income    Interest  AnotherBank  Savings

So as long as there's a way to match from the right component in those account names (typically by regexp using the SQL query tool), you should be able to aggregate any which way. So it doesn't matter much.


On the other hand, it implies a hierarchy, and the web interfaces render only that hierarchy.
Collapsing parent nodes is an easy way to aggregate all the nodes under them, for instance.
So by choosing to do it this way, you're making it easy to render all the subaccounts of "Income:Interest", but not "Income:*:Savings" in the web interface.


I think it should be possible to make a web UI that automatically renders different hierarchies of accounts based on criteria.
Currently, bean-web just uses the hierarchy implied in the account name, + it has these "component" filters, as you mention.

Anyhow, it could be fun to somehow specify criteria for inferring a custom hierarchy beyond that which is implied by the account names and render that with a collapsible and aggregating UI like Fava has. I think the Fava folks will probably chip in at this moment, they're the one who've been actively innovating the web UI.



 
Reply all
Reply to author
Forward
0 new messages