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, ...
- 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).