search

simonmichael / hledger

Robust, fast, intuitive plain text accounting tool with CLI, TUI and web interfaces.
https://hledger.org
GNU General Public License v3.0
3.06k stars 320 forks source link

[Overview issue] Make hledger good for investment tracking #1015

Open simonmichael opened 5 years ago

simonmichael commented 5 years ago

This is an overview/starting point for the project of making hledger good (best-in-class, effective, pleasant) for tracking investments. I'll keep this summary updated.

Related docs

Ledger

Ledger Tutorial:

Principles of Accounting with Ledger:

Transactions:

Beancount

beans

Elsewhere

Related issues

Things we need

docs/examples for common investment-related tasks, using existing features [20%]

market price fetching (latest prices, prices over a period) [10%]

show value at different dates (period end, custom date, maybe transaction date) [50%]

show value in specified commodity [10%]

show revaluations/unrealized capital gains [10%]

clear price inference & propagation behaviour [40%]

track & show lot deposits [10%]

check, execute valid lot movements (FIFO etc.) [0%]

show realized capital gains [0%]

compatibility with ledger/beancount where reasonable, better compatibility docs [40%]

other ?

the-solipsist commented 2 years ago

Hi. I'd like to underscore the significant number of important insights contained in this doc (from 2014): https://beancount.github.io/docs/a_proposal_for_an_improvement_on_inventory_booking.html

I think the discussion on the shortcomings with Ledger, the shortcomings with Beancount (up until 2016), and the requirements section are well worth considering. I think the requirements for hledger are largely the same.

This document (from 2016) provides details of the revised inventory system that beancount adopted, which reveals both a few trade-offs, as well as one or two simplifications adopted. But I think the requirements section of the 2014 document is crucial to understand both the mistakes to avoid and what needs to be done to provide the best support for investment tracking.

the-solipsist commented 2 years ago

As an update, here is Beancount's proposed redesign of its inventory (lots) booking system, which involves some simplification of the syntax as well: https://docs.google.com/document/d/1H0UDD1cKenraIMe40PbdMgnqJdeqI6yKv0og51mXk-0/edit#

This 2021 document should ideally be read after the documents from 2014 and 2016 that are linked here: https://github.com/simonmichael/hledger/issues/1015#issuecomment-988118311

I think it would be useful for the hledger, beancount, and ledger devs to discuss this and seek to converge on similar syntax to ensure greater interoperability in the PTA ecosystem.

jkyiv commented 2 years ago

It would be great if lot tracking syntax could converge for greater interoperability.

However, at least in 2017 when I last looked at Beancount in any depth, it didn't support situations where a lot basis for an asset or commodity purchased with one currency and sold for another could be tracked in either of the two currencies---at least not situations where the cost basis must be tracked (which is unfortunately the case with bitcoin and sometimes with physical commodities)[1]---as Martin correctly says that most people don't think about currency lots when they're spending between currencies.

I need to look at the Selinger multicurrency trading accounts essay again [2]. I think that could work, but if it looses the lot data, it fails to serve the needs of people who need to report gains/losses on bitcoin and other cryptocurrencies. And in that​ space, people will trivially move between far more than just two currencies. I don't remember if or how Selinger tracks lot data, or if that's simply opaque in his method.

I think Plain Text Accounting (PTA) needs a syntax for tracking lots that can be toggled on or off (as Ledger does) but combined with the ability to programmatically add to and reduce lots according to the user's choice of FIFO, LIFO, average cost, or arbitrary matching. (At least in the USA, my understanding is that if you have the records, specific lot matching is allowed; I think that would allow writing algorithms to minimize tax liability).

What kind of writing and/or examples would be helpful to more experienced programmers than myself to clearly lay out the use cases that would be helpful in PTA regarding lots and cost basis?

jkepler

[1] https://groups.google.com/g/beancount/c/5lLY4nzSNtA/m/6AiU2Z0TCQAJ

[2] https://www.mscs.dal.ca/~selinger/accounting/tutorial.html ------- Original Message ------- On Wednesday, August 17th, 2022 at 9:08 PM, Pranesh Prakash @.***> wrote:

As an update, here is Beancount's proposed redesign of its inventory (lots) booking system, which involves some simplification of the syntax as well: https://docs.google.com/document/d/1H0UDD1cKenraIMe40PbdMgnqJdeqI6yKv0og51mXk-0/edit#

This 2021 document should ideally be read after the documents from 2014 and 2016 that are linked here: #1015 (comment)

I think it would be useful for the hledger, beancount, and ledger devs to discuss this and seek to converge on similar syntax to ensure greater interoperability in the PTA ecosystem.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

simonmichael commented 2 years ago

On Aug 25, 2022, at 20:20, Joel @.***> wrote: It would be great if lot tracking syntax could converge for greater interoperability.

However, at least in 2017 when I last looked at Beancount in any depth, it didn't support situations where a lot basis for an asset or commodity purchased with one currency and sold for another could be tracked in either of the two currencies---at least not situations where the cost basis must be tracked (which is unfortunately the case with bitcoin and sometimes with physical commodities)[1]---as Martin correctly says that most people don't think about currency lots when they're spending between currencies.

I need to look at the Selinger multicurrency trading accounts essay again [2]. I think that could work, but if it looses the lot data, it fails to serve the needs of people who need to report gains/losses on bitcoin and other cryptocurrencies. And in that​ space, people will trivially move between far more than just two currencies. I don't remember if or how Selinger tracks lot data, or if that's simply opaque in his method.

I think Plain Text Accounting (PTA) needs a syntax for tracking lots that can be toggled on or off (as Ledger does) but combined with the ability to programmatically add to and reduce lots according to the user's choice of FIFO, LIFO, average cost, or arbitrary matching. (At least in the USA, my understanding is that if you have the records, specific lot matching is allowed; I think that would allow writing algorithms to minimize tax liability).

What kind of writing and/or examples would be helpful to more experienced programmers than myself to clearly lay out the use cases that would be helpful in PTA regarding lots and cost basis?

Hi Joel,

thanks for this, it's useful. I don't follow exactly, could you give a minimal example or two of those situations not supported by Beancount ?

danielschonfeld commented 4 months ago

Is this still on the roadmap?

simonmichael commented 4 months ago

Yes, certainly; though no-one has been working on it or expressing strong needs in this area for a while.

jkyiv commented 2 months ago

Hi Simon,

2017 was a long time ago, so perhaps Beancount has updated their syntax (I haven't looked). But, at the time, here is a short imaginary example of the sort commodity postings that were not possible---I'll use gretchka (Ukrainian for buckwheat) as my example commodity:

2024-04-01 buy some gretchka to import from Ukraine to USA

buying at 8.25 /lb in UAH, selling at 0.27/lbd in USD

Assets:Grains:Gretchka 500 lbs @@ 4,125 UAH # buy gretchka at 8.25 UAH / lb Expenses:PrivatBank

2024-06-01 sell the gretchka in the USA Assets:Grains:Gretchka 500 lbs @@ 135.00 USD # sell gretchka at 0.27 USD / lb Income:Imports -135.00 USD

One can't do that kind of thing with traditional securities like APPL, since stocks are sold in single-currency markets, but if one buys apples in one currency and sells in another, it would be good to be able to track the actual transactions, rather than being forced to declare a currency of reference. Declaring a currency or reference for recording the primary transactions in a journal introduces discrepancies when the exchange rate between the actual currency used and the reference currency changes.

For anyone living in a place that uses two currencies---like most of the world where people do business in their local currency and dollars, or the growing bitcoin space where people spend a local currency but save in bitcoin---having accurate accounting that reflect the real transactions they do would be helpful. Then, when its time to run reports on their journals, they can pick a reporting currency. But the primary data in the ledger should match reality.

Does that example help?

simonmichael commented 2 months ago

Thanks for the example @jkyiv. It's clear but I don't quite understand your point. Is there a problem with the example you showed ? Or is it demonstrating something you'd like to do with AAPL, but can't for some reason ? What sort of entries would you like to write, but can't ?

Generally speaking of course, we should first find the correct entries using standard DEB, and then think about more efficient representations/workflows.

jkyiv commented 1 month ago

Hi @simonmichael , I picked a commodity (gretchka) to illustrate the need to be able to handle cost-basis in a currency-neutral manner. I only mentioned APPL because typically if one buys a security with a given currency, its in that market, and will only be sold for the same currency.

Part of what originally drew me to ledger-cli for my accounting needs was that it doesn't force one to use a currency of reference the way GNU Cash did.

Last time I looked, Beancount's ways of tracking cost basis assumed that sale of a commodity would be in the same commodity it was purchased in. But in the case of commodities bought in one country, and sold in another market---or in the case of expats perhaps buying bitcoin in one currency but selling in another, the how ought one to record such a transaction if the accounting software assumes the sale currency will match the currency of the cost basis?

Does that clarify what I was trying to do?

PS - I haven't had a chance to look at their source code yet, but I wonder if a project like https://github.com/eprbell/rp2/ might have some indications how to track cost basis?

simonmichael commented 1 month ago

Hi @jkyiv. My best understanding so far is that you would like full flexibility in which currencies you use for purchase and sale, without being forced to pick one as a reference currency. And that's what hledger provides, as far as I know. It doesn't have any concept of a reference currency. Am I still missing your point ?