Re: Correctly calculate PnL when transferring between accounts
Martin, On Mon, Apr 30, 2018 at 12:26 AM, Martin Blaiswrote: > On Tue, Apr 24, 2018 at 4:11 AM, Martin Blais wrote: >> >>> The idea is supporting a transfer like this, simply moving the Position >>> objects from one account to another while taking advantage of the booking >>> mechanism for a reduction is a good one. I can see it being useful. It's >>> not supported right now. I think this type of thing would require some sort >>> of syntax. >>> >> >> Great! Would this require modifications to the core, or can it be >> implemented through a plugin? >> > > I'm not sure, but I think it may require inserting code in the booking > algorithms. > Best is to try it out. > So I'm reading up on your documentation to further my understanding and prepare for import script development, and I came across the idea of supporting stock splits in the booking proposal doc ( http://furius.ca/beancount/doc/proposal-booking); "Stock splits need to be able to maintain some of the original attributes of the position, specifically, the original trade date and the user-specified label, if one has been provided. This should allow a common syntax to specify an original trading lot when reducing a position after a split." If I understood this correctly, then this functionality would also cover the case of moving a position from one account to another while maintaining trading lot information for performing correct reductions, as requested above? If so, do you have any idea if and when the stock split proposal may be implemented? Cheers, Einar -- 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 post to this group, send email to beancount@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAKXDhcUm5zwu9US9gE8i5W2U%3DoDVEBpPaPve_pY-7YqjkodpqQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Correctly calculate PnL when transferring between accounts
On Mon, Apr 23, 2018 at 4:02 AM, Einar Idsøwrote: > Hi, > > I am a very happy user of Beancount for the past six or so months. I > currently use it for tracking vacation hours, shares, and crypto. Since tax > reporting is almost due, I need to properly calculate PnL for my shares and > crypto. This becomes extremely difficult when purchasing many lots, when > transferring lots from one broker to another and when exchanging between > multiple currencies. > Crypto presents somewhat of a challenge for all these accounting systems, because it is to be treated like an investment, tracking all the lots and cost basis, but at the same time, users also expect to be able to spend those instruments as if they were money with the expectations of simplicity that counting units of a currency implies. So basically it's forcing investment tracking to be fully automaitc, and most of these systems aren't designed with that in mind-- tracking investments usually requires a bit of user involvement on sales (though it's almost there). > > Some further elaboration: > > 1. I recently had to transfer some shares from one broker account to > another in order to perform a sale. Since I have purchased shares at > BrokerOne many times through my employer's share savings plan, I'd prefer > to not manually enter each lot to be transferred (in my example I had > almost 60 lots to be transferred which would create 120 painstakingly > manually entered lines of transaction). Instead I'd like to do something > like the following and have the transfer use FIFO to identify the lots > transferred from BrokerOne to BrokerTwo and maintaing the cost basis *and* > date stamp: > > 2000-01-01 * "Transfer shares from BrokerOne to BrokerTwo to sell at > BrokerTwo" > Assets:BrokerOne -10 HOOL {} > Assets:BrokerTwo 10 HOOL > This transaction would not balance, because balancing a transaction is done at cost, that is, the second posting would have to be in units of whatever you bought HOOL with, e.g. USD. The idea is supporting a transfer like this, simply moving the Position objects from one account to another while taking advantage of the booking mechanism for a reduction is a good one. I can see it being useful. It's not supported right now. I think this type of thing would require some sort of syntax. If you just wrote this: 2000-01-01 * "Transfer shares from BrokerOne to BrokerTwo to sell at > BrokerTwo" > Assets:BrokerOne -10 HOOL {} > Assets:BrokerTwo > would be to insert the cost of the reduced 10 HOOL. Some sort of new syntax would be needed to let it know that it needs to move the positions (as well as they dates) to the interpolated account. 2000-01-02 * "Sell shares from BrokerTwo" > Assets:BrokerTwo-10 HOOL {} @ 12.00 USD > Assets:Bank 120.00 USD > Income:PnL > > The reason the date stamp would need to be maintained is so that if I had > some shares at BrokerTwo already that were purchased after I purchased the > shares at BrokerOne, the older shares transferred from BrokerOne would be > the ones that were sold. > > 2. During crypto trading this becomes even more difficult to handle > manually since each coin can be exchanged back and forth with a number of > base coins such as BTC, ETH and LTC. Here we have to assign a cost basis > and price in the local FIAT currency to each and every transaction in order > to correctly calculate PnL. This is ok and can probably be automated from > input scripts (I'm currently looking into that). However, there are two > more issues for crypto trading: > a) It is very common to transfer coins between crypto exchanges (as for my > share example above), but due to the nature of crypto trading where trades > happen much more frequently for different base coins, it becomes impossible > to stay on top of which lot to transfer. One way of solving this is by > using FIAT cost basis and price to calculate a PnL for the transfer itself > and establish a new cost basis for the lot after the transfer. But this is > both odd and formally wrong. > I agree, you should be able to just move the Position objects across accounts. Apart from a convenient syntax to do it, there's nothing else in Beancount's schema that should prevent making that possible and easy. > b) If on day one I buy ETH for BTC at Binance, on day two I buy ETH for > BTC at Poloniex, and on day three I sell ETH at Poloniex, the cost basis to > be used for PnL calculations should really be the cost basis for the first > ETH lot I bought, i.e. the one at Binance, and /not/ the cost basis for the > lot at Poloniex. > These are in different accounts? That one is difficult. If I understand correctly what you want to do here is treat the booking algorithm across multiple accounts. Beancount doesn't currently support that. One thing you could try is to write a plugin that identifies those cross-accounts occurrences and inserts transfers automatically, I'm not sure if that would
Correctly calculate PnL when transferring between accounts
Hi, I am a very happy user of Beancount for the past six or so months. I currently use it for tracking vacation hours, shares, and crypto. Since tax reporting is almost due, I need to properly calculate PnL for my shares and crypto. This becomes extremely difficult when purchasing many lots, when transferring lots from one broker to another and when exchanging between multiple currencies. Some further elaboration: 1. I recently had to transfer some shares from one broker account to another in order to perform a sale. Since I have purchased shares at BrokerOne many times through my employer's share savings plan, I'd prefer to not manually enter each lot to be transferred (in my example I had almost 60 lots to be transferred which would create 120 painstakingly manually entered lines of transaction). Instead I'd like to do something like the following and have the transfer use FIFO to identify the lots transferred from BrokerOne to BrokerTwo and maintaing the cost basis *and* date stamp: 2000-01-01 * "Transfer shares from BrokerOne to BrokerTwo to sell at BrokerTwo" Assets:BrokerOne -10 HOOL {} Assets:BrokerTwo 10 HOOL 2000-01-02 * "Sell shares from BrokerTwo" Assets:BrokerTwo-10 HOOL {} @ 12.00 USD Assets:Bank 120.00 USD Income:PnL The reason the date stamp would need to be maintained is so that if I had some shares at BrokerTwo already that were purchased after I purchased the shares at BrokerOne, the older shares transferred from BrokerOne would be the ones that were sold. 2. During crypto trading this becomes even more difficult to handle manually since each coin can be exchanged back and forth with a number of base coins such as BTC, ETH and LTC. Here we have to assign a cost basis and price in the local FIAT currency to each and every transaction in order to correctly calculate PnL. This is ok and can probably be automated from input scripts (I'm currently looking into that). However, there are two more issues for crypto trading: a) It is very common to transfer coins between crypto exchanges (as for my share example above), but due to the nature of crypto trading where trades happen much more frequently for different base coins, it becomes impossible to stay on top of which lot to transfer. One way of solving this is by using FIAT cost basis and price to calculate a PnL for the transfer itself and establish a new cost basis for the lot after the transfer. But this is both odd and formally wrong. b) If on day one I buy ETH for BTC at Binance, on day two I buy ETH for BTC at Poloniex, and on day three I sell ETH at Poloniex, the cost basis to be used for PnL calculations should really be the cost basis for the first ETH lot I bought, i.e. the one at Binance, and /not/ the cost basis for the lot at Poloniex. These two issues can be solved by lumping the accounts together as one. I.e. instead of having both Assets:Crypto:Binance and Assets:Crypto:Poloniex, I have just Assets:Crypto. Any transfer can be ignored (except for transfer fees), and FIFO is properly maintained. The problem with this is that I lose track of how much I have at each exchange. My current approach to solving these problems is to have two separate Beancount files. One contains each exchange account and includes transfers between them in order to give me an overview of where my coins are located. I can choose whether to use FIAT cost basis or not, depending on how I want to represent the values. The other file lumps all the brokers together into one so that I can calculate PnL correctly. This two-file solution is less than ideal, and I am looking for alternatives. Does anyone have any suggestions? If I may pose a suggestion myself for a modification (perhaps a plugin?) that may solve all these problems: What if it were possible to link/group exchange accounts in such a way that their holdings/values are reported per account, but their lots are considered lumped together? When transferring from one account to another in the same group, the lots don't change at all (except for the transfer fee), but when selling lots (i.e. any transaction that transfer from the group to outside the group), the default or account-specific booking method is used. This would probably require a new keyword to link accounts together, something like: 2017-01-01 open Assets:Crypto:Binance:BTCBTC 2017-01-01 open Assets:Crypto:Binance:ETHETH 2017-01-01 open Assets:Crypto:Poloniex:BTCBTC 2017-01-01 open Assets:Crypto:Poloniex:ETHETH ; List all accounts to be linked on one line: 2017-01-01 link Assets:Crypto:Binance:BTC Assets:Crypto:Poloniex:BTC 2017-01-01 link Assets:Crypto:Binance:ETH Assets:Crypto:Poloniex:ETH Alternatively link on higher account levels: 2017-01-01 open Assets:Crypto:BTC:BinanceBTC 2017-01-01 open Assets:Crypto:ETH:BinanceETH 2017-01-01 open Assets:Crypto:BTC:PoloniexBTC 2017-01-01 open Assets:Crypto:ETH:PoloniexETH