I documented in more detail the problem that Rick brought up in a section in the cookbook document I'm building: https://docs.google.com/document/d/1WjARst_cSxNE-Lq6JnJ5CC41T3WndEsiMw4d46r2694/edit#heading=h.gy32bzj5jx1w
(Feel free to comment.) On Sat, Jun 14, 2014 at 1:50 PM, Martin Blais <[email protected]> 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, > > > > > > > > -- --- 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.
