Changing booking methods over time

[Eric Altendorf]

I'm struggling to come up with the right workflow for filing capital gains taxes each year.

I have too many lots for manual lot selection to be feasible, so I rely on automatic booking.  However, the method I picked when I started filing my taxes a few years ago may no longer be what I want to use.

One option would be to run parsing and booking for the older transactions, and somehow persist the booking decisions.  AFAIK, this isn't currently possible with Beancount but it doesn't seem too difficult in practice.

Another option would be to create sub-accounts for each account, per year (or whatever time period), since then I can assign per-account booking methods for each year.  This doesn't require any changes to Beancount, but it makes my accounts messier and requires synthetic transfers from one year's account to the next.

Finally, another option is to implement a new virtual booking method that dispatches to a particular booking method based on the date of the transaction.  This is kind of easiest but seems the ugliest.

any thoughts?

eric

[Martin Blais]

On Wed, Aug 21, 2024, 00:51 Eric Altendorf <erical...@gmail.com> wrote:

I'm struggling to come up with the right workflow for filing capital gains taxes each year.

I have too many lots for manual lot selection to be feasible, so I rely on automatic booking.  However, the method I picked when I started filing my taxes a few years ago may no longer be what I want to use.

One option would be to run parsing and booking for the older transactions, and somehow persist the booking decisions.  AFAIK, this isn't currently possible with Beancount but it doesn't seem too difficult in practice.

I think if you bake in all the cost basis numbers explicitly the booking method doesn't get invoked. It's only there you resolve closing postings with a missing cost basis. In that way if you replaced your inputs to have an explicit cost basis you can cement the old decisions (which I think you have to, because they've been declared to the irs)

Another option would be to create sub-accounts for each account, per year (or whatever time period), since then I can assign per-account booking methods for each year.  This doesn't require any changes to Beancount, but it makes my accounts messier and requires synthetic transfers from one year's account to the next.

Agreed, that's a bit ugly. Better might be too define your own booking method, that is dependent on time. That would require changing beancount to at least allow registering custom booking methods or to extend its default way to specify them by adding date ranges where they're applied. I'm not against it in principle but it's unclear if the additional complexity is worth it. 

Finally, another option is to implement a new virtual booking method that dispatches to a particular booking method based on the date of the transaction.  This is kind of easiest but seems the ugliest.

I wrote my answer above before I read this paragraph and it sounds like the same idea. I think that is the most elegant, because it reflects what were trying to do accurately: change the booking method over time. 

If it was easy to rewrite the input to insert the cost basis numbers that would be the nicest solution imho because you wouldn't have to maintain older versions of algorithms. Imagine for example a case where there was a bug in the booking method and you declared these amounts to the irs. It wouldnt be great to have to maintain the buggy code to be reapplied historically. This is why I think in a new parser we want to treat the input a little more like a database with update capability, where we can parse, make some modifications - insert the cost basis - and produce a new file with them changes but that otherwise keeps everything else the same including comments.

any thoughts?

eric

--
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/CAFXPr0u6rD3MErQGhRvhV5v9YbtrF4%2BUWa1PphECfXAtcniy-g%40mail.gmail.com.

[Eric Altendorf]

Thanks, makes sense.

Re-serializing the data structures after parsing/booking seems reasonable.  That's not something Beancount currently can do, is it?  Aside from the comments issue, it seems this shouldn't in principle be difficult to do?

Since my pipeline is mostly automated I haven't been using comments (instead putting extra info in metadata tags for the code to read) so I don't mind comments being lost.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhN94Jjp_-gjHXhOoSzGMdkeR_U8LAZFG9GpKayii-hpcw%40mail.gmail.com.

[fin]

Eric Altendorf wrote:
> --000000000000c902060620261b59
> Content-Type: text/plain; charset="UTF-8"

hmm, in my newer transactions i've been doing everything
with explicit lots no matter what because i hate having
anything left to chance (my older transactions i mention
below).

maybe this would make sense?

when you change the booking method you are in effect
really changing the account nature itself so i would explicitly
close the account and give it a new name (reflecting the
booking method too) and reopen with the new booking method:


2013-12-31 close Assets:Invest
2014-01-01 open Assets:InvestFIFO "FIFO"

now i prefer to fully specify my lots and trades so there
is no ambiguity allowed no matter what booking method might be used.

for my older data i did change my booking method part way through
and i had to have my importer code know those dates for when things
changed. i decided after running into that situation to always
fully specify the lots to avoid any future problems.

it was a bit of fun for me to write the importer code and to
figure out the different booking methods. i noticed that different
brokers offer different booking methods too so that can be a
complication (one that having complete information about the
data involved may be important to answer questions in the
future about what was actually going on and what was reported
to the tax people).


fin

[Eric Altendorf]

I have too many transactions and lots to manually book them (wonky crypto exchange execution and pooled mining rewards).  And the broker doesn't do lot tracking (crypto).  I also have a lot of headache of needing to track lots through account transfers (again, crypto).  So I'm in that tough spot of trying to integrate automated and hand-guided workflows.  I have some processes and workarounds but I'm always looking for better ideas.  Running and tuning automated booking for a while as a prep my taxes, then locking in those decisions when I file, seems useful.

Right now I'm experimenting with a tax-minimizing booking method that takes into account holding periods and short/long term rates, since I have had situations where I could sell newer lots with less gain but at the higher short-term rate, or older lots with more gain but at a lower rate ... sometimes it's better to go FIFO sometimes HIFO.

The other fun aspect with transfers is that when you are transferring out of the exchange into cold storage, you generally want to invert your booking priorities, as it's not a sale, but rather, stashing away for long term storage, so you want to book the lots that you *wouldn't* want to sell.  sigh.

--
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/3ieipk-edr.ln1%40anthive.com.

[Martin Blais]

On Wed, Aug 21, 2024, 17:34 Eric Altendorf <erical...@gmail.com> wrote:

Thanks, makes sense.

Re-serializing the data structures after parsing/booking seems reasonable.  That's not something Beancount currently can do, is it? 

Not in there nice way I envision. 

You could sort of hack by finding the locations of the cost basis inputs using the metadata stored on the parser directives (which are close to an ast) and insert they missing cost basis as strings. Ugly.

Aside from the comments issue, it seems this shouldn't in principle be difficult to do?

I wouldn't call it difficult but the parser's output has to be extended to store all of the comments and whitespace in between the stuff that matters. 

Since my pipeline is mostly automated I haven't been using comments (instead putting extra info in metadata tags for the code to read) so I don't mind comments being lost.

I suspect most people do a nontrivial amount of writing their beancount file by hand.

On Tue, Aug 20, 2024 at 11:28 PM Martin Blais <bl...@furius.ca> wrote:

On Wed, Aug 21, 2024, 00:51 Eric Altendorf <erical...@gmail.com> wrote:

I'm struggling to come up with the right workflow for filing capital gains taxes each year.

I have too many lots for manual lot selection to be feasible, so I rely on automatic booking.  However, the method I picked when I started filing my taxes a few years ago may no longer be what I want to use.

One option would be to run parsing and booking for the older transactions, and somehow persist the booking decisions.  AFAIK, this isn't currently possible with Beancount but it doesn't seem too difficult in practice.

I think if you bake in all the cost basis numbers explicitly the booking method doesn't get invoked. It's only there you resolve closing postings with a missing cost basis. In that way if you replaced your inputs to have an explicit cost basis you can cement the old decisions (which I think you have to, because they've been declared to the irs)

Another option would be to create sub-accounts for each account, per year (or whatever time period), since then I can assign per-account booking methods for each year.  This doesn't require any changes to Beancount, but it makes my accounts messier and requires synthetic transfers from one year's account to the next.

Agreed, that's a bit ugly. Better might be too define your own booking method, that is dependent on time. That would require changing beancount to at least allow registering custom booking methods or to extend its default way to specify them by adding date ranges where they're applied. I'm not against it in principle but it's unclear if the additional complexity is worth it. 

Finally, another option is to implement a new virtual booking method that dispatches to a particular booking method based on the date of the transaction.  This is kind of easiest but seems the ugliest.

I wrote my answer above before I read this paragraph and it sounds like the same idea. I think that is the most elegant, because it reflects what were trying to do accurately: change the booking method over time. 

If it was easy to rewrite the input to insert the cost basis numbers that would be the nicest solution imho because you wouldn't have to maintain older versions of algorithms. Imagine for example a case where there was a bug in the booking method and you declared these amounts to the irs. It wouldnt be great to have to maintain the buggy code to be reapplied historically. This is why I think in a new parser we want to treat the input a little more like a database with update capability, where we can parse, make some modifications - insert the cost basis - and produce a new file with them changes but that otherwise keeps everything else the same including comments.

any thoughts?

eric

--
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/CAFXPr0u6rD3MErQGhRvhV5v9YbtrF4%2BUWa1PphECfXAtcniy-g%40mail.gmail.com.

--
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/CAK21%2BhN94Jjp_-gjHXhOoSzGMdkeR_U8LAZFG9GpKayii-hpcw%40mail.gmail.com.

--
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/CAFXPr0vMbo6omq3EZu9_-v%2BN3iZ%3DAfcPvPzc9q65tyNe%2BzSaQw%40mail.gmail.com.

[Eric Altendorf]

Ok, I was just thinking there might be a spot where I could (in my own patch) inject a serialization call.  It wouldn’t be generally useful (since it wouldn’t retain comments or order etc) but it might be good enough for my immediate needs.

Thanks for the responses!

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhOJzH1kBXy%3DL6%2BVYbmg9NSyGFpimxJ7DQ7OJrEBiR_NTA%40mail.gmail.com.

[Eric Altendorf]

There's a vaguely related question around my attempt to find a good way to work automatic cost basis transfers into Beancount transfer transactions.

When you move assets from account A to B, if you want to automatically move cost basis along with, you need to automatically select which lots are moving.  This is basically the same as booking a sale, but there's no particular reason to assume that one wants to use the same method for lot selection as one uses for sales.  (In particular, the most common case for this functionality seems to be crypto users, in which case the transfer may be to cold storage, in which case one probably wants exactly the inverse lot selection one uses for booking sales.)

So at this point, what I'm looking at is making booking decisions based not just on the cost basis and cost date, but the date (to use different algos over time), as well as the accounts of the augmenting and reducing legs.

Agreed on the "unclear if it's worth it" for Beancount, although I kinda need it (and already hacked it up) for myself.