On Tue, Jun 17, 2014 at 4:00 AM, Jostein Berntsen <[email protected]> wrote:
> > > On Saturday, June 14, 2014 7:50:32 PM UTC+2, Martin Blais wrote: >> >> On Fri, Jun 13, 2014 at 9:57 AM, Martin Blais <[email protected]> wrote: >> >> On Fri, Jun 13, 2014 at 9:01 AM, Rick F <[email protected]> wrote: >>> >>>> The method used in the cookbook, is not correct. >>>> >>> >>> That's not exactly true: it's correct if your definition of capital gain >>> does not take into account commissions. I used the definition that excludes >>> capital gains in order to keep things simple (the level of discussion I >>> chose in that doc is that congruent with trying to explain P/L clearly, >>> intro level). Whether you should be able to exclude commissions or not from >>> your gains is a matter tax law, and it depends on your own situation. >>> >>> Thanks for bringing up the topic, though, I admit I did forget to >>> explain it. I'll add a separate section about commissions. I'm well aware >>> of this. >>> >>> At the moment, I simply subtract the commissions from the gains for >>> reporting. The gains and commissions get counted in separate accounts >>> (which is mostly fine, except for the prorating detail you bring up below). >>> You can subtract the total commissions from total gain for a good >>> approximation of gains-without-commissions. Most of my trading accounts >>> already provide a suitable 1099 so I use my own accounting on these >>> accounts for tax planning and cross-checking against their calculations, >>> and I use the 1099 forms for tax reporting. >>> >>> >>> >>> The cookbook uses the example of buying 10 shares of IBM at $160 and >>>> then selling those shares at $170. Without commissions, that would amount >>>> to a realized gain of $100, $1700 (the sales price) - $1600 (the cost >>>> basis). With commissions, however, the reportable gain is really $1700 >>>> (the sales price) - $9.95 (commission on the sale) - $1600 (basis) - >>>> $9.95 (commission on purchase) = $80.10. The method in the cookbook >>>> only accounts for the sale commission when figuring the capital gain. >>>> >>> >>> Actually, that's incorrect, the method I described does exclude the >>> commission from the gain on BOTH sides and will thus calculate a gain of >>> 100$ (no commissions at all). >>> >>> >>> So what's the right way to do this, accounting for commission on >>>> purchase. Note that if only part of the purchased shares are sold the >>>> commission is prorated, so the actual basis is $1609.95 or $160.995 per >>>> share. >>>> >>> >>> That's a great question. >>> >>> Again, how it should be done is a matter of tax law, it's a choice, but >>> this is indeed a sensible one in many cases. Simply subtracting the sum of >>> the commissions - you could easily track them per account, e.g. using >>> Expenses:US:ETrade:Commissions instead of Expenses:Financial:Commissions - >>> from the capital gains provides a good approximation of the gains as you >>> describe it, but as you point out, not a perfectly accurate one, especially >>> if you hold positions across reporting periods (taxation years). It is >>> appropriate to note that folding in the purchase commission on the cost >>> basis is but one method to automatically pro-rate that commission into the >>> gain - we could track it separately, per-lot - but it is one that is >>> elegant and leads to an unambiguous implementation. I would like to be able >>> to support it. >>> >>> I don't have a good solution for doing this at the moment, but I want to >>> think of one. >>> In particular, we should design a method that leads to easy entry by a >>> user, with a correspondingly nice syntax. >>> >>> I'll be thinking about this; any ideas welcome. >>> >> >> >> Some more thinking about this: one possible method would be to allow the >> user to >> indicate that a particular leg of the transaction is meant to be folded into >> the >> cost of another leg's, something I would implement like the following. >> >> First let's make up an example of a transaction the way they're currently >> done, >> with the full capital gain, that is, one that unfairly (to you) includes >> commissions: >> >> 2014-06-13 * "Transactions with Commissions" >> Assets:US:Invest:Cash -5009.95 USD ; 5009.95 >> USD >> Expenses:US:Invest:Commissions 9.95 USD ; 9.95 >> USD >> Assets:US:Invest:GOOG 10.00 GOOG {500.00 USD} ; 5000.00 >> USD >> >> 2014-06-20 * "Transactions with Commissions" >> Assets:US:Invest:GOOG -10.00 GOOG {500.00 USD} ; -5000.00 >> USD >> Expenses:US:Invest:Commissions 9.95 USD ; 9.95 >> USD >> Assets:US:Invest:Cash 5090.05 USD ; 5090.05 >> USD >> Income:US:Invest:PnL -100.00 USD ; -100.00 >> USD >> >> This is what we need to fix, we want the gain to become 100 USD - 2 x 9.95 >> USD. >> >> So now let's introduce a flag into the cost syntax (there's already a flag >> available on each posting): >> >> 2014-06-13 * "Transactions with Commissions" >> Assets:US:Invest:Cash -5009.95 USD ; >> 5009.95 USD >> + Expenses:US:Invest:Commissions 9.95 USD ; >> 0.00 USD (+) >> Assets:US:Invest:GOOG 10.00 GOOG {500.00 USD +} ; >> 5009.95 USD = 10.00 GOOG {500.995 USD} >> >> 2014-06-20 * "Transactions with Commissions" >> Assets:US:Invest:GOOG -10.00 GOOG {2014-06-13 -} ; >> -5009.95 USD = -10.00 GOOG {500.995 USD} >> - Expenses:US:Invest:Commissions 9.95 USD ; >> 0.00 USD (-) >> Assets:US:Invest:Cash 5090.05 USD ; >> 5090.05 USD >> Income:US:Invest:PnL -80.10 USD ; >> -80.10 USD >> >> When a flag is encountered in the cost, this says, add to the total cost the >> amount from postings marked with that flag. In the case of the buy, this >> means (500.00 x 10 + 9.95) is the new total cost and the cost per unit is now >> 500.995 USD. This works to give you a capital gain as you desired. >> >> However, here are some drawbacks: >> >> - You cannot use the cost basis of the lot to identify it anymore (the lot is >> now at a different cost basis, 500.995 USD instead of 500.00 USD, and that >> amounts shows up nowhere, we cannot realistically expect the user to know >> it). >> >> That may not be a bad thing though, I never liked identifying lots by their >> cost in the first place, I prefer a method that uses a label or the date to >> disambiguate. When reducing a position, the purpose of that cost really is >> just to identify which lot we should be using to reduce the position. I >> already have a proposal to make this better, by using labels or dates >> instead >> of cost (see sale transaction). >> >> - A bigger problem, however, and one that is preventing me from fully going >> ahead with this idea just yet, is that the expenses are gone. The expenses >> leg >> just cannot post to the commissions account, because its amount has been >> incorporated into the cost of the position. Allowing the cost to show up in >> both places would break the accounting equation; this transaction must >> balance. >> >> Maybe we should add an Income leg to absord the Expenses amount and post it >> anyhow? >> >> 2014-06-13 * "Transactions with Commissions" >> Assets:US:Invest:Cash -5009.95 USD ; >> 5009.95 USD >> + Expenses:US:Invest:Commissions 9.95 USD ; >> 0.00 USD (+) >> + Income:US:Invest:Commissions-Rebate >> Assets:US:Invest:GOOG 10.00 GOOG {500.00 USD +} ; >> 5009.95 USD = 10.00 GOOG {500.995 USD} >> >> I'm not quite sure how to solve this yet. >> >> Ideas welcome, >> >> >> >> >> >> >> >> > Would it be useful with a python function here, something like this? > > https://gist.github.com/kevin3/5119111 > Jostein, The challenge is not calculating the commission; the challenge is designing a scheme, a recipe for how to enter this as a DE transaction, for putting down the various legs of the transaction in a way that automatically accumulates the correct capital gain - in this case, the capital gain without commissions and other costs, with the acquisition commissions pro-rated to the number of shares sold. Requirements of the design are: - The user should not have to calculate anything manually, all numbers needed to book the transaction should be readily available from a typical confirmation statement - The transaction's postings have to balance according to some set of universal rules for balancing postings; right now Beancount uses this rule: https://hg.furius.ca/public/beancount/file/181d0d299c87/src/python/beancount/core/complete.py#l20 The code you quoted is something that in Beancount you would have you put into a plugin for yourself, to make your own data entry easier. That is, your plugin would go through all the transactions after the parsing stage, detecting those that match your criteria for trades on these platforms (e.g. "one leg is in account Asssets:SG:StandardChartered"), and transforming them by generating new ones that have the commissions leg added in. This would make your data entry easier. Ledger has such a transformation mechanism in its expression language; Beancount takes the route of allowing you to process all your entries in Python instead of providing a custom expression parser. But for both systems, the problem that remains is in how to book the gains right in the most elegant way. I'll make the unfortunate observation here that if you relax the requirement that a transaction balance by allowing, for example, virtual transactions, you can solve the problem, but then you can't draw a balance sheet anymore (you break the accounting equation). This is not a solution IMO: you can "solve" any problem by allowing any arbitrary counting, which is what virtual transactions are, but you lose what I think of as an essential property of the counting method). -- --- You received this message because you are subscribed to the Google Groups "Ledger" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
