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.

Attachment: commissions.beancount
Description: Binary data

Reply via email to