Currently using CryptoTaxCalculator, Sharesight, Gnucash, Excel (depreciation tables & minimising CGT) and Obsidian to keep it all organised
...
I wish to simplify to just PTA + Obsidian, but crypto is by far the main pain point I have to sort. I have thousands of daily staking rewards
...
I only do 3 or 4 trades a year now because of accounting overhead for crypto, and to a lesser degree, shares with all the splits, liquidations, franking rule exceptions, demergers,...
I can imagine how complex the bookkeeping gets in your situation.
Your existing system represents a lot of work and a valuable historical reference -
in your shoes I would keep it going while experimenting with new systems in parallel.
Though it sounds like parts of it have already become unworkable.
Three knotty problems are
- importing data to your accounting system (eg from banks, brokers, exchanges, wallets)
- exporting data from your accounting system (eg to performance analysing apps, capital gains calculators, tax software)
- tracking lots and capital gains in your accounting system (if you do)
For 1, a PTA-based system is probably about as capable as your existing system, but you may have to roll your own API clients / import scripts.
hledger's import command is the easiest importing workflow out there.
For 2, a PTA-based system is probably at least as good at exporting CSV. hledger aregister ACCT -O csv is one example.
If you can achieve 3, it could simplify your setup a lot - no need for a separate gains calculating app.
But it's not a small task:
- Ledger has support for assisted lot/gains tracking - it's fairly limited, but worth a try.
- Beancount has more robust support, it is the best at this. But you may find it still limiting,
eg I believe it supports acquisitions and disposals but not cost-basis-preserving transfers between accounts. - hledger does not yet have support for this; hledger users use subaccounts and manual entries to track lots and gains explicitly.
You can do this with any PTA app, though hledger has a couple of addons to help with this workflow.
This has the advantage of being able to express any transaction, in an intuitive way.
But it is tedious and noisy and beyond a certain point, becomes too hard to manage.
https://gitea.com/EvergreenCrypto/docker-finance is a hledger-based system with a cryptocurrency focus.
I don't know how exactly it tackles 1, 2, or 3.
https://joyful.com/PTA+lot+tracking has some more discussion of this general topic.
Note most current PTA workflows assume that acquisition costs are recorded explicitly in the journal entries.
I think we also need a more scalable approach that determines those automatically (at least as a fallback) from daily market prices.
Gathering market prices is not a big problem - it's fairly easy to do this for most stocks and cryptocurrencies.
https://pypi.org/project/pricehist is one tool that can help.
I'm not sure which exactly are your goals in moving to PTA, which would guide the direction.
But generally I would try to break up the migration into smaller tasks.
For example, try to handle just the cryptocurrency activity in PTA, or maybe just one or two cc assets.
And maybe just track amounts, in enough detail to export the data to an external gains calculator;
don't try to do that in PTA yet.
I would gather a small set of representative transaction types, and
use them as test data to evaluate various PTA setups. You want to find
out early if they will handle your needs or not.
In Obsidian-land, there are two PTA plugins we know of, both linked at https://hledger.org/obsidian.html.
Exploring an example from the reddit thread, in hledger:
Here's a typical transaction buying and selling crypto coin XXX - having to use USD as an intermediary as XXX might not be sold in AUD:
AUD10000 → USD7000 (Record AUD10000 as the CGT cost base for the USD7000 purchase)
USD3500 → 1000XXX (CGT event #1 because I sold the USD, meaning I invested in it. Value of USD3500 in AUD needed. Also record it as the cost base for when I sell XXX.)
500XXX → USD2000 (CGT event #2 as I've bought and sold XXX. Record USD2000 in AUD for the event, plus the cost base for the USD I've just bought)
500XXX → USD2100 (As above, CGT event #3, new AUD valuations though)
USD2500 → AUD4500 (CGT event #4 using the chosen cost base combo of the two USD purchases above).
USD1600 → AUD2700 (CGT event #5 using the remaining cost base of the two transactions above).Further complicated when exchanges do transaction fees in their own token - which has its own USD and thus AUD valuation.
That's for assets. Balance sheet isn't a huge issue as it's just a valuation on the day.But now consider income and the P&L: if I stake that XXX and it gives daily rewards, I have to
- record that reward as income in AUD by using the XXX-USD and USD-AUD values, and
- record that AUD value as the cost base for CGT when I sell that XXX.
I've got around 7000 CGT events and I was only .So summarizing, it's really valuations on the day of the transaction which is key - which might require both XXX↔USD and USD↔AUD lookups.
And some mechanism of tracking which cost-base(s) are for CGT used upon selling. Currently I track that in Excel.
Sharesight and CryptoTaxCalculator that do respectively for stocks and crypto, but tax minimisation requires the overall picture before choosing cost bases.
That would include gains from all sources, net income and even predicted future net income,.
comment
A (incomplete) mockup of the above.
Commodity types, noted as tag values for clarity:
Cash - fiat money, cost basis not tracked; eg base currency
Capital - capital assets, with cost basis/value/lots/capital gains tracked
Investment events, noted as tags for clarity:
acquire - creates a lot; sets cost basis
transfer - preserves lots, maybe splitting one; preserves cost bases
dispose - destroys lots, maybe splittine one; records capital gain/loss
hledger infers the first posting's cost in the second posting's commodity (see hledger print --infer-costs),
so the acquired/disposed commodity's posting must be written first.
Some market prices have been added for clarity/experiments.
end comment
commodity 1.00 AUD ; type:Cash
commodity 1.00 USD ; type:Capital
commodity 1. XXX ; type:Capital
account assets:aud
account assets:usd
account assets:xxx
;include usd.prices
P 2025-10-01 USD 1.428571 AUD
P 2025-10-02 USD 1.50 AUD
P 2025-10-03 USD 1.60 AUD
P 2025-10-04 USD 1.70 AUD
P 2025-10-05 USD 1.80 AUD
P 2025-10-06 USD 1.6875 AUD
;include xxx.prices
P 2025-10-01 XXX 3.50 USD
P 2025-10-02 XXX 3.70 USD
P 2025-10-03 XXX 4.00 USD
P 2025-10-04 XXX 4.20 USD
P 2025-10-05 XXX 4.00 USD
P 2025-10-06 XXX 3.80 USD
2025-10-01 ; Record AUD10000 as the CGT cost base for the USD7000 purchase
; acquire:USD
assets:usd 7000 USD @ 1.428571 AUD
assets:aud -10000 AUD
2025-10-02 ; CGT event #1 because I sold the USD, meaning I invested in it. Value of USD3500 in AUD needed. Also record it as the cost base for when I sell XXX.
; dispose:USD
; acquire:XXX
assets:xxx 1000 XXX @ 3.50 USD
assets:usd -3500 USD
2025-10-03 ; CGT event #2 as I've bought and sold XXX. Record USD2000 in AUD for the event, plus the cost base for the USD I've just bought.
; dispose:XXX
; acquire:USD
assets:xxx -500 XXX @ 4.00 USD
assets:usd 2000 USD
2025-10-04 ; As above, CGT event #3, new AUD valuations though.
; dispose:XXX
; acquire:USD
assets:xxx -500 XXX @ 4.20 USD
assets:usd 2100 USD
2025-10-05 ; CGT event #4 using the chosen cost base combo of the two USD purchases above.
; dispose:USD
assets:usd -2500 USD @ 1.80 AUD
assets:aud 4500 AUD
2025-10-06 ; CGT event #5 using the remaining cost base of the two transactions above.
; dispose:USD
assets:usd -1600 USD @ 1.6875 AUD
assets:aud 2700 AUD
I see that having to pay for assets with a foreign currency adds another layer of complication.
With all trades completed, if we sum their imbalances (equity), I think it can show the total average capital gain per commodity:
$ hledger -f examples/cc-jontycl.j bse --infer-equity
Balance Sheet With Equity 2025-10-06
|| 2025-10-06
===============================++===========================
Assets ||
-------------------------------++---------------------------
assets:aud || -2800.00 AUD
assets:usd || 3500.00 USD
-------------------------------++---------------------------
|| -2800.00 AUD, 3500.00 USD
===============================++===========================
Liabilities ||
-------------------------------++---------------------------
-------------------------------++---------------------------
|| 0
===============================++===========================
Equity ||
-------------------------------++---------------------------
equity:conversion:AUD-USD:AUD || -2800.00 AUD
equity:conversion:AUD-USD:USD || 2900.00 USD
equity:conversion:USD-XXX:USD || 600.00 USD
-------------------------------++---------------------------
|| -2800.00 AUD, 3500.00 USD
===============================++===========================
Net: || 0
But of course, something other than average gains is often what's needed.