Thanks for your thorough and helpful response. I think I'd seen Selinger's currency trading accounts post referenced before, but hadn't taken time to read and understand it. Wow. His method does resolve the problem "elegantly," as you say.
Unfortunately for me, I believe that the IRS requires using FIFO to calculate capital gains and losses with bitcoin. So as much as I would like to simply treat it like another currency and use Selinger's "trading account(s)" method, I don't think I'm free to do that. So, I'm currently trying (A.) to wrap my mind around how to write a plugin as you suggested or (B.) to re-work my source data converting the EUR amounts to USD equivalents, thereby avoiding the problem of trying to reduce lots in a different currency from that which I used to purchase them. Le samedi 19 août 2017 23:52:55 UTC+2, Martin Blais a écrit : > > On Sat, Aug 19, 2017 at 7:54 AM, <jke...@gmail.com <javascript:>> wrote: > >> One clarification: over lunch I was thinking about this, and realized >> that beancount does FIFO booking reductions correctly for securities like >> stocks under the usually valid assumption a security is sold/ reduced in >> the same currency it was purchased in, since each security is denominated >> in the currency of its exchange. >> > > That is correct. > The main issue is that there are two processes going on, and it's not > clear which one could come first: > - Interpolation of missing values > - Booking against existing inventories of lots > Resolving this is hard - one can come up with useful cases where one would > be preferred to run before the other - and part of it involves inferring > the currency of a lot. > Once the currencies are resolved, then the booking takes place. > So the currency is fixed. > > > >> This is reasonable: if one buys shares in Nokia (NOK) listed on the New >> York Stock Exchange, they're always listed in USD. Shares listed in EUR are >> available on the Helsinki Stock Exchange, but their symbol is NOKIA, hence >> a different security. >> >> Where thinks currently seem not to work is if one is tracking a real >> commodity -- apples, bitcoin, or coffee -- anything that doesn't have an >> intrinsic currency for valuing it. >> > > What you call a "real commodity" here is generally a currency. Beancount > differs from Ledger in this regard, you can treat currency as they are. > > >> >> Does that make sense, or have I misunderstood something? >> > > No, I think you get it. > > However, I think there may be a better resolution here. > I think you may be able to treat Bitcoin as a currency, disregard its cost > basis, yet still be able to account for gain/loss for it. > Let me explain. > > When a currency conversion is accepted by Beancount, no cost basis is > stored. > However, if the exchange rate takes place, a gain or loss will be incurred. > In other words, the sum of all postings will not be an empty inventory. > In order to deal with this, Beancount inserts an ugly conversion > transaction which makes us for exactly this. > This transaction is inserted by this code: > http://www.mscs.dal.ca/~selinger/accounting/tutorial.html > Its purpose is to exactly counterbalance this difference, across all > currencies. > One problem is that its contents must depend on the set of transactions > being summarized. > That's why it's inserted when you open or close on the set of directives, > e.g.., before producing a report. > > Now, please take a few minutes to dive in and go read this: > http://www.mscs.dal.ca/~selinger/accounting/tutorial.html > > This method resolves the problem elegantly. > Each of the transactions posts the currency differences to a dedicated set > of currency accounts. > Unfortunately, it would be a pain to enter your transactions in this way. > > However, it would be simple to do this automatically with Beancount, even > as a plugin. > I plan to do this eventually. > (You're welcome to get ahead about that, I'm working on other things these > days.) > > Now, how does this relate to your question? > Well, with this "trading accounts" method, you could later (in time) > unwind some of these currency account at their current rate, and post the > difference as a gain/loss. > > I know I've said previously it would be easier to use the cost basis. > What you get from that is specific lot reduction methods, e.g. FIFO, LIFO. > On the other hand, if you'd like not to have a particular cost currency, > really you are dealing with currencies. > In this case, you won't have any booking, but you could still have total > gain/loss. > > (I hope this makes sense.) > > > >> >> Thanks for all you work on beancount. It's a great tool! >> > > Thanks, and please keep on finding problems, that's the way software gets > stronger. > > > >> >> Joel >> >> Le samedi 19 août 2017 11:38:11 UTC+2, Joel a écrit : >>> >>> Thanks for your response. >>> >>> >>>>> 2. If I explicitly put "USD" in all my empty {}, how does will FIFO >>>>> booking option handle the occasional cases where I've purchased bitcoin >>>>> with euros? >>>>> >>>> >>>> I don't understand the question. If you try to reduce and provide USD >>>> in the description, it will only match against lots in USD. Can you >>>> provide >>>> an example pair of transactions? >>>> >>>> >>>> >>>> >>>>> Will it always reduce the oldest bitcoin lots first, regardless of the >>>>> currency I'm reducing with, or will explicitly specifying the reducing >>>>> currency mean I have to manually check the order lots are cleared to make >>>>> sure that the total of the two currencies reduces correctly per FIFO? >>>>> >>>> >>>> I'm still not sure I understand, it will never convert currencies when >>>> reducing. >>>> >>>> >>> Here's an example, from a fictitious episode in which I rode Amtrak >>> back and forth a few times between New York City and Montreal to sell >>> apples: >>> >>> >>> option "title" "My Personal Ledger" >>> option "operating_currency" "USD" >>> option "operating_currency" "CAD" >>> option "booking_method" "FIFO" >>> >>> 2016-01-01 open Equity:Opening-Balances >>> 2016-01-01 open Assets:US:Cash USD >>> >>> 2016-01-01 open Assets:CA:Cash CAD >>> 2016-01-01 open Assets:MyBackpack:Stuff APPLES >>> 2016-01-01 open Income:CapitalGains >>> >>> 2016-05-26 price CAD 0.77046 USD >>> 2016-05-28 price CAD 0.76761 USD >>> >>> 2016-05-24 * "Opening Balances" >>> Assets:US:Cash 40.00 USD >>> Assets:CA:Cash 0.00 CAD >>> Equity:Opening-Balances >>> >>> 2016-05-25 * "Bought some apples in New York" >>> Assets:MyBackpack:Stuff 10 APPLES {1.00 USD} >>> Assets:US:Cash >>> >>> 2016-05-26 * "Convert USD to CAD" >>> Assets:CA:Cash >>> Assets:US:Cash -15.03 USD @ 1.29792 CAD >>> >>> 2016-05-26 * "Bought some more apples in Montreal" >>> Assets:MyBackpack:Stuff 13 APPLES {1.50 CAD} >>> Assets:CA:Cash >>> >>> 2016-05-27 * "Bought some apples in New York" >>> Assets:MyBackpack:Stuff 11 APPLES {1.20 USD} >>> Assets:US:Cash >>> >>> 2016-05-28 * "Sold some more apples in Montreal" >>> Assets:MyBackpack:Stuff -14 APPLES {USD} @ 1.70 CAD ; should sell >>> 10 APPLES {1.00 USD} & 4 APPLES {1.50 CAD}, a cost basis of 14.605 USD >>> Assets:CA:Cash 23.80 CAD ; converts to >>> 18.269 USD >>> Income:CapitalGains ; revenue ( >>> 18.269 USD) - cost basis (14.605 USD) = 3.665 USD >>> >>> ; CapitalGains = 3.47 USD per beancount when the {1.50 CAD} lot doesn't >>> get reduced. >>> >>> I don't think beancount is reducing my apples by FIFO correctly, because >>> when I run the *bean-report *sample *holdings* when selling 14 apples, >>> its reducing from my {1.00 USD, 2016-05-25} and {1.20 USD, 2016-05-27} >>> lots, but not reducing any apples from my {1.50 CAD, 2016-05-26} lot. Since >>> apples are apples, shouldn't it reduce the lots by date order? >>> >>> If I replace the {USD} with an empty {} beancount tries to reduce all 14 >>> sold apples form the {1.50 CAD, 2016-05-26} lot, but fails because there's >>> only 13 apples in that lot. The only was I can find to have beancount >>> reduce my apple inventory selling the oldest lots first is manually, like >>> this: >>> 2016-05-28 * "Sold some more apples in Montreal" >>> Assets:MyBackpack:Stuff -10 APPLES {USD} @ 1.70 CAD >>> Assets:MyBackpack:Stuff -4 APPLES {CAD} @ 1.70 CAD >>> Assets:CA:Cash 23.80 CAD >>> Income:CapitalGains >>> >>> So, I'm not sure FIFO is reducing the oldest lots first. It depends on >>> the lot currency. >>> >>> >>> -- >> 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 <javascript:>. >> To post to this group, send email to bean...@googlegroups.com >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/beancount/dc892eed-3ce2-4372-92c3-6decc85ccab0%40googlegroups.com >> >> <https://groups.google.com/d/msgid/beancount/dc892eed-3ce2-4372-92c3-6decc85ccab0%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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/cc5be9b5-56e7-48d2-812e-955332677d3e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
