Payees, Subaccounts, Channels

[Martin Blais]

I was revisiting some of my accounts hierarchy as part of doing some cleanup and
had some thoughts I thought I'd share here about it for discussion.

One of the topics we've discussed in the past is regarding the use of
subaccounts over payees. For example, consider this transaction imported from a
credit card:

    2018-05-01 * "VISIT PATREON.COM/INSAN FRANCISCO       CA" "OPSNT_CMEVT 1234567890"
      Liabilities:US:Amex                        -10.00 USD
      Expenses:Online:Media

The problem is that there is no breakdown of the bill into its individual
component parts, which in this case are donations to multiple content creators.
You also can't easily override the payee field for it: the payee for the whole
transaction (Patreon) should be preserved as well, we might want that
information (e.g., the same "channel" might change which service it uses to
receive a donation, thus changing payee for the same channel).

One way I've been getting around this is by using dedicated subaccounts for each
part of the breakdown (in this example they are content creators):

    2018-05-01 * "VISIT PATREON.COM/INSAN FRANCISCO       CA" "OPSNT_CMEVT 1234567890"
      Liabilities:US:Amex                        -10.00 USD
      Expenses:Online:Media:Safecast               3.00 USD
      Expenses:Online:Media:AbroadInJapan          3.00 USD
      Expenses:Online:Media:OnlyInJapan            2.00 USD

Some people have in the past expressed disapproval of this method because it
pollutes the expense report with a potentially large number of unnecessary
subaccounts. It was also perceived as unnecessary because the context of our
discussion was limited to that of a single transaction, e.g.,

    2018-05-01 * "VISIT PATREON.COM/INSAN FRANCISCO       CA" "OPSNT_CMEVT 1234567890"
      Liabilities:US:Amex                         -3.00 USD
      Expenses:Online:Media:AbroadInJapan          3.00 USD

which could be trivial translated to:

    2018-05-01 * "AbroadInJapan" "VISIT PATREON.COM/INSAN FRANCISCO       CA - OPSNT_CMEVT 1234567890"
      Liabilities:US:Amex                         -3.00 USD
      Expenses:Online:Media                        3.00 USD

At the time, we discussed ideas around identifying the parent account as such
(perhaps with metadata on the Open directive) and having the various reporting
codes honor this and aggregate at that level. This was never implemented: it's
unclear how it would generalize to both the SQL tools and all custom scripts,
not elegant.

Another idea is to use metadata to breakdown the parts into what I'll call here
"channels":

    2018-05-01 * "VISIT PATREON.COM/INSAN FRANCISCO       CA" "OPSNT_CMEVT 1234567890"
      Liabilities:US:Amex                        -10.00 USD
      Expenses:Online:Media           3.00 USD
        channel: "Safecast"
      Expenses:Online:Media           3.00 USD
        channel: "AbroadInJapan"
      Expenses:Online:Media            2.00 USD
        channel: "OnlyInJapan"

The bean-query/SQL tool has the ability to pull and insert per-posting metadata,
so this fulfills the purpose. Note that this transformation could be done
elegantly entirely by a plugin filtering and transforming select postings.

Another idea, one that we never discussed, is the idea to have a special marker
as part of the account name, marker which would automatically identify a portion
of an account name as being a leaf, e.g.,

    2018-05-01 * "VISIT PATREON.COM/INSAN FRANCISCO       CA" "OPSNT_CMEVT 1234567890"
      Liabilities:US:Amex                        -10.00 USD
      Expenses:Online:Media/Safecast               3.00 USD
      Expenses:Online:Media/AbroadInJapan          3.00 USD
      Expenses:Online:Media/OnlyInJapan            2.00 USD

This would probably also be best translated to metadata as in the above. I'm not
sure I like this design because this would require core modifications and
creating a new concept (thus adding complexity to the core); though I have mixed
feelings about not doing something to handle this, because I suspect this use
case is pretty common, e.g., donations, online content, apps from app stores,
etc.

Any further thoughts and discussion appreciated,

[Stefano Zacchiroli]

On Sun, Jul 24, 2022 at 12:25:45PM -0400, Martin Blais wrote:
> One of the topics we've discussed in the past is regarding the use of
> subaccounts over payees.

As a general comment: +1 on the fact that this divide between payees
(or, more generally, per-posting metadata) and sub-accounts is a
problem. I consider sub-accounts to be better in general (they are more
controlled and easier to query), but they come with additional burden
(e.g., you need to declare them, open/close them, etc.) Having to
constantly decide "is this worth a sub-account" is for me recurringly
annoying.

> Another idea, one that we never discussed, is the idea to have a
> special marker as part of the account name, marker which would
> automatically identify a portion of an account name as being a leaf,
> e.g.,
>
> 2018-05-01 * "VISIT PATREON.COM/INSAN FRANCISCO CA" "OPSNT_CMEVT
> 1234567890"
> Liabilities:US:Amex -10.00 USD
> Expenses:Online:Media/Safecast 3.00 USD
> Expenses:Online:Media/AbroadInJapan 3.00 USD
> Expenses:Online:Media/OnlyInJapan 2.00 USD

I like the idea of having a given prefix of an account marked as
something under which you can freely create new leaf sub-accounts. But
why does it need an additional core concept and syntax? There might be
advantages, which I'm not seeing yet, but the cost of doing so seems to
be pretty high --- both in terms of code for the codebase and cognitive
overhead for users.

It seems to me that the same idea can be implemented, as you suggested
earlier on, with a directive associate to the, in the example above,
"Expenses:Online:Media" account, which says "this account can contain
any number of leaf sub-accounts".

Anyway, this is totally worth exploring, as it's an annoying problem in
the current state of affairs. Thanks for raising this.

Cheers
--
Stefano Zacchiroli . za...@upsilon.cc . upsilon.cc/zack _. ^ ._
Full professor of Computer Science o o o \/|V|\/
Télécom Paris, Polytechnic Institute of Paris o o o </> <\>
Co-founder & CTO Software Heritage o o o o /\|^|/\
Former Debian Project Leader & OSI Board Director '" V "'

[Ben Blount]

+1 to this idea and Stefano's well reasoned response, leaf accounts are an annoying trade-off I often make too. I agree that the metadata approach seems best and totally backwards compatible to older parsers.

It would be nice to have the open and closing plugins respect these leaf accounts and not complain if a channel subaccount isn't opened for each payee.

As for bql you could potentially use an option that let's the user decide whether channel subaccounts should be folded or not. If you want to get really fancy could let them specify a default leaf folding optionally in the query and then add case by case exceptions in the query also. Probably not worth the effort to give that level of control.

--
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/20220727081845.bh7uwx7yyi5xgiea%40upsilon.cc.

[Archimedes Smith]

I had similar issue maintaining my multi-party (e.g. family) ledger:

• I want to conveniently note down the category information but opening sub-accounts is too much toil / mess.
  • I put them in posting metadata.
• Sometimes, I want to view each category separately.
  • I created this plugin to automatically redirect postings to sub-accounts.
• Sometimes, I want to view everything as a whole / sub-accounts are annoying.
  • I have a separate main file that does not enable that plugin. I load both on fava which allows me to switch on the UI.

I guess I'm essentially using plugin as "advanced bql" here, which comes from my general philosophy to focus on collecting information in the recording phase while pushing viewing issues to processing / querying / displaying phases. 

Below are some concrete examples in my multi-party ledger workflow. You can find more in test data.

What I wrote:

Fava selection:

The overall view (as if the plugin is not enabled):

The everyone view (everything goes into sub-accounts):

The Alice view (Alice's stuff remains but everything else goes to Receivables):

[Red S]

Interesting and cool solution, thanks for sharing this plugin! Nice to see what others are doing with plugins, beancount, and fava. One thing to consider is including a README.md with your screenshots below, and an example.beancount to your plugin directory to make it easier to see what your plugin does for folks who are new to it.

my general philosophy to focus on collecting information in the recording phase while pushing viewing issues to processing / querying / displaying phases. 

Helpful way to put it.