Good for tracking investments?

749 views
Skip to first unread message

Avinash C

unread,
Jul 22, 2019, 12:20:08 PM7/22/19
to Ledger
I'm trying to decide whether I can use ledger well for tracking investments.

Looking at many of the messages to this board, and discussions on the --exchange related issues, it seems that it is very hard to use and understand ledger for investments tracking.
Are there people using ledger to track extensive investments, and if so, are there any collected tips?
Some docs suggest using trading accounts, but that seems to involve yet another complication.

Things that would make investment tracking good:
- easily enter purchases, sales, splits, return on capital, etc stock/mutual fund transactions
- compute capital gains (I understand this part is not there - so have to enter specific lot sales and capital gains at each sale transaction? LIFO or such default would be useful)
- reports that show amount of commodity, total cost basis, and current market value, and gain. Is this something doable using a custom report (I don't think there is any default report for this).
- A discussion a few days ago mentions some confusion about --unrealized for  a scenario that would be quite common

Pranesh Prakash

unread,
Jul 25, 2019, 1:36:05 PM7/25/19
to Ledger
<not-flame>
Having used ledger-likes (mostly hledger) for the past 2.5 years, I've come to the conclusion that they are great for bookkeeping, and the format they use is great and allows all the necessary information to be captured (especially, since they have a tagging mechanism that allows you to extend the syntax provided by the format).  

However, the existing in-built tools have a lot of limitations for more complex analysis, as is the case with lots, automated capital gains analysis, differentiated costs bases (ACB for some, FIFO for others), etc.  I'm convinced all the necessary information for good handling of investments can be eked out of the existing data with hand-coded tools and tags (which are needed to say what lots should be treated as FIFO (most, since most tax authorities seem to use this), as LIFO (if your business uses this for inventory management), and what as ACB (non-speculative currency exchange transactions, and in some jurisdictions like Canada), and what should be strictly cost-basis (lot-designated transaction costs associated with purchase/sale of lots)).  

As things stand, given my lack of programming skills, I'm doing a lot of my investment analysis (calculating capital gains, e.g.) by hand, using data I enter using hledger-iadd (which makes data entry a breeze!), and the first-level analysis (unrealized gains, which I calculate using trading accounts) being spit out by {h}ledger.  So I do find that useful.  YMMV.

(And FWIW, I believe trading accounts are a very powerful idea that unfortunately don't have enough integration into the ledger-likes.  They, used judiciously with sub-accounts, can even mimic lots accurately.)
</not-flame>

John Wiegley

unread,
Jul 26, 2019, 1:32:45 PM7/26/19
to Pranesh Prakash, Ledger
>>>>> "PP" == Pranesh Prakash <the.so...@gmail.com> writes:

PP> (And FWIW, I believe trading accounts are a very powerful idea that
PP> unfortunately don't have enough integration into the ledger-likes.  They,
PP> used judiciously with sub-accounts, can even mimic lots accurately.)

Hi Pranesh,

I do quite a lot of investment tracking with Ledger these days. It's a bit
more manual than I would like, but I haven't run into any blocking
limitations.

Here's a typical transaction from my Ledger:

2019/07/23 * (46958) SOLD -W NFLX @311.1325
; Time: 06:50:43
(Expenses:BR:Fees) $X
Expenses:Capital:Short:Wash $Y
Assets:BR:Brokerage:Equities -1 NFLX {$307.74667} [2019/07/22] @ $311.1325
Assets:BR:Brokerage:Cash $U = $Z

2019/07/23 * (50177) BOT +W NFLX @311.649
; Time: 06:51:15
Assets:BR:Brokerage:Equities 1 NFLX @ $329.58215
Assets:BR:Brokerage:Cash $-V = $Z
Expenses:Capital:Short:Wash $-Y

This is selling a set of lots under the wash sale rule, and accumulating the
wash to an account so I can reprice the cost basis of the next purchase of the
same commodity (if it happens within 30 days). Had it been a profitable
transaction, I would have registered that in Income:Capital:Short instead.

NOTE: The purpose of the above sale was an attempt to adjust the cost basis
using the falling price of the commodity, but it ended up moving against me
and I re-entered the position and unfortunately increased the cost basis. I
was experimenting using a different study for buy/sell triggers based on a
trend analysis, which didn't work out as well as I was hoped. :)

Things that are still manual in the above:

- Entering the lot details
- Calculating the wash amount
- Calculating the adjusted cost basis on the next purchase (or of
other shares currently held)
- Withdrawing from the wash account on the next purchase

John

d10

unread,
Nov 2, 2019, 3:36:32 PM11/2/19
to Ledger

On Friday, July 26, 2019 at 1:32:45 PM UTC-4, John Wiegley wrote:
>>>>> "PP" == Pranesh Prakash <the.so...@gmail.com> writes:

PP> (And FWIW, I believe trading accounts are a very powerful idea that
PP> unfortunately don't have enough integration into the ledger-likes.  They,
PP> used judiciously with sub-accounts, can even mimic lots accurately.)

Hi Pranesh,

I do quite a lot of investment tracking with Ledger these days. It's a bit
more manual than I would like, but I haven't run into any blocking
limitations.

[snip]  
Things that are still manual in the above:

 - Entering the lot details
 - Calculating the wash amount
 - Calculating the adjusted cost basis on the next purchase (or of
   other shares currently held)
 - Withdrawing from the wash account on the next purchase

John

I struggled to calculate gains for a bunch of trades recently.  Long story short, I was able to automate a lot of the calculation, and ledger was a huge help.

In order to address some of the complexity mentioned by Pranesh, I added splits to call out inventory and cost basis explicitly.  I think the inventory and gains splits mske it easier to see and understand when trades create or consume inventory.  Once the splits are there, ledger calculates gains like a champ.

I wrote up some notes, and made the tool available.  


See https://src.d10.dev/lotter for the open source tool.

the.so...@gmail.com

unread,
Dec 28, 2020, 9:17:58 AM12/28/20
to Ledger
Dear John,
> (Expenses:BR:Fees) $X
> Expenses:Capital:Short:Wash $Y

I hadn't thought of using (Expenses:BR:Fees) as a virtual posting.  So far, I haven't used virtual postings at all over the past three years of using plain text accounting.  But I think transaction costs that should also be counted as part of the currency exchange cost is the perfect use case for virtual postings.  I think I will adopt this convention from here on.

Dear David,
Thanks for that excellent blog post (and for recommending the Github Wiki post that I'd contributed to!).

Sadly, I'm still trying to figure out how Lotter works before using it with my files.  (I currently use real currency trading accounts ("Equity:Trading:XXX:YYY") for commodity interchanges, as described in the Github Wiki,[1] rather than the virtual postings that Lotter seems to generate.  And given the format I currently use, I don't capture lot-related information, which I ideally should.)

What kind output would Lotter have if I accumulated currency from two distinct purchases and sold them at once?  What would the "[Lot:Income:long term gain]" be in such a case, and on what basis would it be calculated (FIFO? LIFO? ACB?)  Would Lotter allow me to tell it what time period should be counted as "short term gain" and what is "long term gain"?  I imagine the rules for determining this in the US aren't the same as in India.

One reason why Lotter seems attractive to me over my current system is that it would enable me to leverage improvements in the ledger ecosystem using its native syntax (XX @ YY / XX @@ YY), while also using currency trading accounts for "proper" (Selinger-style) double-entry accounting.

Thanks,
Pranesh

d10

unread,
Dec 30, 2020, 5:12:36 PM12/30/20
to Ledger

Pranesh,

On Monday, December 28, 2020 at 9:17:58 AM UTC-5 wrote:

Sadly, I'm still trying to figure out how Lotter works before using it with my files.  (I currently use real currency trading accounts ("Equity:Trading:XXX:YYY") for commodity interchanges, as described in the Github Wiki,[1] rather than the virtual postings that Lotter seems to generate.  And given the format I currently use, I don't capture lot-related information, which I ideally should.)

The idea behind lotter is that you capture the actual trades in your ledger file, then lotter adds additional splits that don't change anything, but add information about inventory, cost basis, and gains/losses.  It is supposed to save you the trouble of capturing lot-related information.

You can try lotter without fear.  It doesn't change your original file.  Use it to make a new file with the lot splits added, then run ledger-cli on that file to see the effects of the additional splits.
 

What kind output would Lotter have if I accumulated currency from two distinct purchases and sold them at once?

It will create two lots of inventory, one for each purchase.  Then, show both lots consumed when sold, as several splits added to the sell transaction.
 
  What would the "[Lot:Income:long term gain]" be in such a case, and on what basis would it be calculated (FIFO? LIFO? ACB?)

It might show long term gain, short term gain, or both, depending on the dates of the events.

It supports LIFO or FIFO only.  I don't have plans to add others, but I'm happy to review patches.
 
  Would Lotter allow me to tell it what time period should be counted as "short term gain" and what is "long term gain"?  I imagine the rules for determining this in the US aren't the same as in India.

It is hard-coded to one year.  What is the policy in india?
 

One reason why Lotter seems attractive to me over my current system is that it would enable me to leverage improvements in the ledger ecosystem using its native syntax (XX @ YY / XX @@ YY), while also using currency trading accounts for "proper" (Selinger-style) double-entry accounting.

Yes, that's the idea.  Lotter requires the "@" or "@@" syntax to infer whether a transaction is a trade. 

-David

Reply all
Reply to author
Forward
0 new messages