Sub-accounts for Stocks

[Paul Walker]

Do you use sub-accounts for individual stocks? Why?

I do because I found it more deterministic to balance and close accounts, but I've always thought the explicit open/close directives were redundant with lot tracking. Else why not go all out with `Broker:GOOG-2024-03-02`?

Now I'm starting to use more queries and metadata (coming from basic fava usage), and am not looking forward to finding and maintaining the meta on each individual open directive. I'm considering opening a parent account and filtering using coalesce:

    2024-01-01 open Assets:IRA
        tax-status: "Deferred"
    2024-01-01 close Assets:IRA ; Or maybe use for USD/fiat
    2024-01-01 open Assets:IRA:GOOG  GOOG

Then I think I could get the meta like so:

    coalesce(getitem(open_meta(account), 'tax-status'), getitem(open_meta(parent(account)), 'tax-status'))

... But this seems like a hack, so I'm wondering if it really makes sense to keep the sub-accounts. Alternatively, this complete balance assertion proposal looks perfect for my concerns about balance tracking.

What else would I miss by simplifying to multi-currency accounts?

[fin]

Paul Walker wrote:
> ------=_Part_2358_1111469923.1716422812306
> Content-Type: multipart/alternative;
> boundary="----=_Part_2359_567520660.1716422812306"
>
> ------=_Part_2359_567520660.1716422812306
> Content-Type: text/plain; charset="UTF-8"

>
> Do you use sub-accounts for individual stocks? Why?

no, i specify the full purchase price, the date and a text tag
lot number or other identifier that is unique. this way when
selling i specify all of that and it gets used to match and
adjust the position. since i also keep a separate spreadsheet
of lots i generally know which lots i'm likely to be selling
or about what prices i might buy at next.

i also include in the meta data a text entry that gives
the basis of the purchase as a reminder to myself so i
don't have to do the math again.

with the full specification if i examine my holdings each
lot is there.

> I do because I found it more deterministic to balance and close accounts,
> but I've always thought the explicit open/close directives were redundant
> with lot tracking. Else why not go all out with `Broker:GOOG-2024-03-02`?

i use the auto account plugin and i think in my entire
ledger i only have one open statement. i consider it
rather silly to do something manually if a computer can
figure it out and do it instead.

> Now I'm starting to use more queries and metadata (coming from basic fava
> usage), and am not looking forward to finding and maintaining the meta on
> each individual open directive. I'm considering opening a parent account
> and filtering using coalesce:
>
> 2024-01-01 open Assets:IRA
> tax-status: "Deferred"
> 2024-01-01 close Assets:IRA ; Or maybe use for USD/fiat
> 2024-01-01 open Assets:IRA:GOOG GOOG
>
> Then I think I could get the meta like so:
>
> coalesce(getitem(open_meta(account), 'tax-status'),
> getitem(open_meta(parent(account)), 'tax-status'))
>
> ... But this seems like a hack, so I'm wondering if it really makes sense
> to keep the sub-accounts. Alternatively, this complete balance assertion

><https://beancount.github.io/docs/balance_assertions_in_beancount.html#partial-vs.-complete-assertions>

> proposal looks perfect for my concerns about balance tracking.
>
> What else would I miss by simplifying to multi-currency accounts?

i don't do anything with multiple currencies yet and as of
now have no plans on that either.

at the moment i only have overall brokerage accounts
and then sub accounts for a Roth and a Regular stock account.
the tax treatments for each are different. each account is
broken into the individual securities and then also whatever
other funds might be in them, including money market accounts
or other commodities/funds/stocks/etc.


fin

[Red S]

I didn’t maintain sub-accounts (I call them “commodity leaf” accounts) for a long time, but beangrow made me switch, as it makes it possible to drill down into performance. If you use Fava, it also makes dividends/gains income tracking easier, as account hierarchies are readily represented by standard UI elements, but query results aren’t (and can't easily be).

I use my opengroup plugin to make open directives easier. Beancount now supports closing an entire tree.

I use my setup for taxes regularly but haven’t found the need to propagate metadata down the tree of open directives. Curious, what is causing that need for you?

You could write a trivial plugin to dynamically coalesce commodity-leaf accounts to their parent, and use that to evaluate if that works for you before committing to it.

​

[Paul Walker]

Good reminder about auto-open, fin! I could see this being good for the leaf accounts, maybe paired with some "auto close after inactivity". For parent accounts I'll probably need the opens anyway for my meta categories. And I tend to agree with letting the computer compute. Or specifically, I dislike redundancy. The computer can link these things, so it should and I shouldn't have to worry or trip over things being out of sync.

Red, I'll have to bookmark beangrow! My current query > csv > gsheets > xirr workflow leaves a lot to be desired. So far I'd been happy using filters like any(units:SPY), but I do like the symmetry of having dividends be security-specific as in this beangulp example. I was tentatively thinking I could filter by SPY in description, but also hacky. The one that gets me most with fava is paychecks: I'll contribute to hsa, roth, and traditional 401k all in the same transaction, which is not easy to pick apart with fava's txn-level filtering.

I'm thinking to use meta for extra/arbitrary account categories. Tax-status would be free/deferred/taxable to help with retirement planning. I'm also considering a literal category of investments/liquid/savings where savings might include some short term bonds as a mid-term/extended emergency fund. I've currently baked this into my account hierarchy:

    Assets:Liquid:Bank
    Assets:Investments:Tax-Free:Vanguard:Roth-IRA
    Assets:Investments:Tax-Free:Fidelity:HSA
    Assets:Investments:Tax-Deferred:Fidelity:IRA

But as you might imagine this gets confusing/disconnected when I have both deferred and untaxed accounts at a broker. Fundamentally, tax status seems more appropriate as an attribute. Even so, my query results look promising:

    SELECT
      getitem(open_meta(account), 'tax-status') as tax,
      root(account, 2) as category,
      sum(convert(position, 'USD')) as balance
    WHERE account ~ 'Assets'
    GROUP BY tax, category

Produces

After flattening the accounts I get... something not nearly as pretty as Fava's drill-down tree interface. I'll have to play with this report.