[Overview issue] Make hledger good for investment tracking #1015
Comments
|
Hi. I'd like to underscore the significant number of important insights contained in this doc (from 2014): 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. |
|
As an update, here is Beancount's proposed redesign of its inventory (lots) booking system, which involves some simplification of the syntax as well: 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. |
|
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)](#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](#1015 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ABOFZ5FFOWZC3QZVFYVBMT3VZU2ETANCNFSM4HMLTXZQ).
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
|
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 ?
|
|
Is this still on the roadmap? |
|
Yes, certainly; though no-one has been working on it or expressing strong needs in this area for a while. |
|
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?
|
|
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. |
|
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? |
|
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 ? |
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
Converts to a desired commodity:
"derives arbitrary commodity conversions between all commodities, as long as there is at least one path (possibly over several links) from one commodity to another. For example, conversion from SomeStock in CHF is possible when prices of SomeStock in USD and CHF in USD is available. Inverted rates are derived automatically."
Generates revaluation transactions (calculates unrealized gains) when reporting in a different commodity:
"The journal now not only shows explicit inflows and outflows, but also valuation corrections due to price changes at the specific date they occurred."
"When valuating the balance in a certain reference commodity, beans accounts for changes in valuation using the Equity:Valuation account. It reflects gains and losses over time with respect to the reference currency."
"applies valuation directly at the transaction level. For example, if you choose to display a balance at market prices, beans will transparently insert valuation transactions to reflect gains and losses due to price changes"
"Depending on whether one wants to convert commodities at cost or at market value, beans will add balancing accounts automatically."
"offers either no valuation or valuation at market prices. Valuation at cost is yet to be implemented."
"applies valuation at the level of transactions, which seems unique amongst plain-text accounting tools" --Transaction-level valuation.
1 Converts all postings to the target commodity using market prices at target valuation date (there are no explicit transaction prices)
2 At each market price change, for each asset/liability account, calculates the balance and adds a revaluation transaction (transfer to/from Equity:Valuation).
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 text was updated successfully, but these errors were encountered: