OK. I have more to think about. Making lots identifiable would mean you could have splits from multiple accounts assigned to one lot. I noticed too that in the current scrub implementation, say you buy 100 and then sell 50, you end up with two lots (lot 0: 50 closed, lot 1: 50 open) instead of one lot (lot 0: 100 start/50 left open). When originally developed, was it important to have a lot have one input and one output split? This creates extra splits in the account which may be confusing.
Regards, Emily On Wed, Dec 30, 2015 at 9:20 PM John Ralls <jra...@ceridwen.us> wrote: > > > On Dec 30, 2015, at 1:55 AM, Emily Zora <milliehandshr...@gmail.com> > wrote: > > > > Hi all. I've been working a lot with bitcoin lately and I've noticed some > > deficiencies in the way lots and capital gains are handled, particularly > > when multiple wallets (accounts) are involved. From my googling, this > > appears to be an acknowledged problem. Before taking a stab at trying to > > fix, I wanted to get some input from y'all. > > > > Using a FIFO policy, say I bought 1 btc in wallet #1 two years ago, 1 btc > > in wallet #2 one year ago, and today I sell the 1 btc from wallet #2, if > > I'm not mistaken, the cost basis and acquisition date for the sale should > > be the purchase in wallet #1 two years ago, not the purchase in wallet #2 > > last year. However, with current implementation, the purchase from the > same > > wallet as the sale would be used. > > > > Options to fix it: 1) track lots by commodity rather than account. 2) > allow > > lot tracking at a common parent account. 3) Keep the current > implementation > > and search for other accounts in the same commodity and kinda hack it to > > work. > > > > Another issue: Wash Sales, transfers and acquisition date > > > > When there is a wash sale according to US tax law, no capital loss is > > allowed for the recent sale, instead the loss is added to the cost basis > of > > the new purchase and the acquisition date is adjusted by the days > > previously held. > > > > With current implementation, a lot does not track its acquisition date. > > Instead, you use the earliest split. This is also a problem with > transfers > > between accounts, as the earliest split will be later than the > acquisition. > > Propose adding an acquisition date field to lot. > > > > Let me know your thoughts. > > If we're going to offer the option to consider lots across accounts for > basis policy it should be up to the user but that in most cases it should > be per-account. I'm not an accountant or enrolled agent, but my > understanding is that the IRS expects you to apply your selected basis > policy (FIFO, LIFO, average cost, or designated lot) per account, not per > asset. > > Consider the analogous case where you own shares of XYZ in two accounts: > If you sell the shares from one of the accounts the broker will report on > your 1099-B the basis and period for the shares in that account without > reference to the other account, even if it does happen to be at the same > broker. > > We need to ask our European colleagues about the wash sale rule — which > says that if you buy a like asset (most commonly means shares of the same > stock) within 30 days of selling at a loss you don't get to book the loss > but instead increase your basis in the new shares — do your tax laws have > such a provision? > > I'm pretty sure that that *is* a case where the IRS would expect you to > consider multiple accounts: If you sell XYZ at a loss from broker A's > account and buy it a few days later in broker B's account, neither will > know that you've got a wash sale and it won't show on your 1099-B, but the > IRS will object if they catch you. > > It might anyway be venturing too much into tax accounting for GnuCash to > implement that. > > Rather than simply adding a date field to the Lot class I think we need a > way to maintain lot identity through a transfer. That would require a more > fundamental change in the way lots are handled within GnuCash so that a lot > is always created when buying an asset that should be managed with lots > (lot-able for brevity) and explicitly linking lots and splits. What's > lot-able may depend on its intended use as well as what it is: For example, > currency wouldn't normally be lot-able, but if one does forex trading where > the sole reason for holding the currency is to make capital gains then it > might become lot-able. That would be a question for one's tax accountant. > > Regards, > John Ralls > > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
