On Sat, Jul 15, 2023 at 11:19 AM Eric Altendorf <ericaltend...@gmail.com> wrote:
> I'm looking into Beancount for the specific purpose of rigorous capital > gains tracking for crypto transactions. I just read the docs, and now have > a few questions, hoping someone can help. Thanks in advance! :) > > I'd like to run my own rules for booking (mostly HIFO, except able to > select a slightly lower basis lot if it qualifies for long term instead of > short term cap gains .. maybe some other special cases). I'm guessing I > will need to implement these rules in my importer somehow, and have the > importer label each lot and sale? Or should I implement the rules in > Beancount directly? > Those are not pluggable (but it would be a good idea to restructure some of my code to make it so). You'd have to make the change to the "master" branch, if you mirror the other methods I'd welcome a PR (it should be easy I think). I'll have a few (maybe 3-6) CSVs of all-time transactions from wallet > software or downloaded from exchanges. Should I write Beancount importers, > or just scripts that generate Beancount text files? Does my need for > custom lot-selection rules affect this decision? > Not really. I think it's a matter of whether you think the identify/extract/archive functionality is useful to you. Based on all the emails that follow this one, I suspect not; a custom script is probably what you're after. Also note: if you'll invest a lot of time into this, if your only purpose is to get booking like HIFO you can probably just as well do away with Beancount and write something custom. What's a good workflow for taking the booking decisions Beancount makes for > a given tax year and "locking" them in so they can't be changed when I run > again in the next tax year -- e.g., if I tweak my booking algorithm? > You don't reimport the same material. Updating your Beancount input file should be an incremental process. Don't overwrite that you already imported. Similar to my previous comment -- if you're going to automate importing everything from scratch every time you might as well build something distinct; I did that myself with github.com/blais/johnny. I saw in the docs somewhere that transaction merging isn't well supported. > Is that still the case? This is something I'll encounter since transfers > between an exchange and a cold wallet will result in one leg being imported > from the exchange and the other from the cold wallet. > That's still the case. For context: by "merging" what is meant here is that the two halves of a two posting transaction are inserted in the input as two distinct transactions and automatically merged into one. (It just requires a feature that matches the transactions and inserts postings to transfer accounts, a bunch of design questions would come up.) > I was a little surprised that Beancount doesn't deal with times or > timezones :) Are there cases where ordering of intraday transactions can > mess things up? > That was an explicit design decision to (a) keep things simple (it can get pretty hairy), (b) because the various institutions don't usually include time and we're just trying to represent the data from the institutions. At this stage my sense is that all we need is a way to resolve ordering. Given that balance checks are done sparsely on the flow of transactions changes in ordering don't cause dramatic problems, but like the ability to resolve the mismatch in dates from two sides of a transaction, it would be nice to eventually solve this properly. > > This page discussed Beancount's incomplete handling of acquisition > costs/commissions: > https://beancount.github.io/docs/trading_with_beancount.html#commissions > Is that still an outstanding issue? > Yes. Historically the few times I needed this I wrote a script to do this at reporting time. Johnny also deals with this properly. In cases where a transaction has legs in non-USD (e.g., a USDT (Tether > stablecoin) / BTC swap), but it needs to be tracked for taxes in USD terms, > is it a good practice to split the transaction with a synthetic temporary > position in USD (i.e., one USDT-USD tx and one USD-BTC tx?) > I have no idea (I don't do crypto). It sounds to me more onerous than to just use USD right away, but I have no idea how those things get taxed. This doesn't matter yet for crypto, but are there ways to catch/prevent > wash sales using Beancount? > Oh gosh... I went down the rabbit hole of attempting to compute them some years ago, I remember I went deep on that one. After spending days building something and looking into all the minute details and examples from the IRS I came out with the conviction that it's an ill-defined problem, there are cases you can't resolve. I can't remember now. I'm scarred. But that's a separate issue. It should be easy to build something that warns you as of a particular date (say "today") and across all your accounts what you can't trade. I think I do that in Johnny, it has page in its web interface I can consult. I don't think that was done in Beancount (at least not by me). > > Thanks again! > > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beancount/CAFXPr0v18V479ZF4h8Rvz%2B_6fmAjttrkZamDpQXhE%2BHx%3DKg7sg%40mail.gmail.com > <https://groups.google.com/d/msgid/beancount/CAFXPr0v18V479ZF4h8Rvz%2B_6fmAjttrkZamDpQXhE%2BHx%3DKg7sg%40mail.gmail.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 beancount+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhOHUO8oUJ_UK3kHya0XdS85FthF6pwYuuAVBocAOFkxQw%40mail.gmail.com.
