I've tried to track personal finances several times, but it only started to work when I've discovered the idea (from https://github.com/adept/full-fledged-hledger) that you need to treat the whole PTA story more like a project compilation:
- Everything is managed by build system that is able to track dependencies
- Inputs from financial institutions are kept in the repo as is
- Those inputs are converted by your scripts to .csv files that are readable by PTA import engine
- There are rules files that describe how to convert .csv lines to PTA entries
- Generated files are included from per-year PTA journals (and you can put any manual transactions in here also)
The benefit is that you can change any part of this pipeline, and just re-generate the changed parts:
- improve the program that converts to .csv - raw data immediately gets better across the whole repo
- add/customize import rules - better classification is immediately applied to all of the past data
And with this approach you can start small (like, a single month of data from your primary bank), and refine the thing in steps, like adding more historical data or adding more data sources (examples being not only bank statements, but even things like itemized Amazon orders and Paypal slips).
Thank you! I’ve always procrastinated tracking finances, but as a programmer who believes in reproducible builds, this just clicked.
I just downloaded a bunch of qfx and csv files, and got Claude Code to do this. Took an hour to create the whole system from nothing. Then of course I stayed up until 2am getting CC to create Python rules to categorize things better, and trying to figure out what BEENVERI on my bank statement means
(If you do this, make Claude generate fingerprints for each transaction so it’s easy to add individual overrides…)
Getting Claude to write a FastAPI backend to serve up a “Subscriptions” dashboard took about 3 minutes, plus another minute or two to add an svg bar graph and change ordering.
The mortgage payments always confused me and that link has a good explanation of how it works. Have you used that code base in your own system or just the principles? I don’t know Haskell so not sure how much I can/need to modify.
Do you want to share what's confusing about mortgage payments?
You have a balance that accrues a monthly interest. Separately, you're told that you're owed a monthly payment. If monthly payment > interest, then the difference is subtracted from the balance. No need for haskell.
Loans can be confusing in double entry accounting for the uninitiated.
On the accounting side you have liabilities:mortgage which would only include the principal. Then for an individual bill you have to debit liabilities:mortgage the principal portion and debit expenses:interest the interest portion.
I’m not sure how mortgage bills usually come but for my auto loan the principal vs interest were not noted on the bill, so i had to calculate via apr myself for each payment for which the interest accrued daily. If i imported those payments from my bank statement or the bill i would not be able to enter the transaction correctly without doing the math.
For calculating interest automatically upon entry based on the rate and payment amount and date I used python iirc as i used beancount, but that was a while ago.
Yes, I'm using parts of this codebase. But Haskell is only being used as a build tool, so you can replace it with anything that you're comfortable with, like make, bazel, ...
There is at least one area where both macos and windows suck - handling window focus. MacOS is regularly having trouble with tracking focus across multiple monitors and multi-window apps, making it unusable with keyboard only. And Windows just loves to steal focus in the most inappropriate moments.
claude-code rendering pipeline often goes awry, and start scrolling back and forward very fast, causing insane flickering. They have some explanation in https://github.com/anthropics/claude-code/issues/769#issueco... describing that they've made that tradeoff in the name of native terminal experience (instead of learning per-program shortcuts/etc).
Funnily enough, before reading their reasoning, I thought that the whole rendering pipeline was badly vibe-coded.
For my personal computers I was actually buying Windows licenses up to and including Windows 10, but now I switched to alternative acquisition methods again, and mostly run Windows in VMs with GPU pass-through and disabled networking. Just an honest relationship - they don't respect me, I don't respect them.
The Wheel of Time by Robert Jordan - spent the most time reading it and got the most value from it. This book series is my device for the language learning. It was translated into Russian so painfully slow I've just forced myself to read it in English, learning the vocabulary and grammar on the way. Later I did it intentionally with Dutch, and now I'm going to do the same with Spanish.
It's so big you can reread it as many times as you want and still be surprised by the details you no longer remember. In the end I've read it 2 times in Russian, 3 times in English and 1 time in Dutch - and I'm not going to stop.
CAD is exactly what I'm using VMs with GPU passthrough for, and it's working briliantly there. The advantage is that most of these VMs have no internet access at all (they only see a single SMB share on the host) - so most of the security and privacy issues are just non-existent.
- Everything is managed by build system that is able to track dependencies
- Inputs from financial institutions are kept in the repo as is
- Those inputs are converted by your scripts to .csv files that are readable by PTA import engine
- There are rules files that describe how to convert .csv lines to PTA entries
- Generated files are included from per-year PTA journals (and you can put any manual transactions in here also)
The benefit is that you can change any part of this pipeline, and just re-generate the changed parts:
- improve the program that converts to .csv - raw data immediately gets better across the whole repo
- add/customize import rules - better classification is immediately applied to all of the past data
And with this approach you can start small (like, a single month of data from your primary bank), and refine the thing in steps, like adding more historical data or adding more data sources (examples being not only bank statements, but even things like itemized Amazon orders and Paypal slips).