Live data from Hacker News

10 years of personal finances in plain text files

sgoel.dev

161–170 of 199 posts

Re: 10 years of personal finances in plain text files

#161
post #72

Earlier quoted context omitted.

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.

Re: 10 years of personal finances in plain text files

#162
post #123

Earlier quoted context omitted.

Yes, very true. It might be useful to start with overtracking to see where the money actually goes. I didn't track anything until about 5 years ago as my mental model was "track all purchases", and I wasn't willing to do that. Someone had to point out that higher level tracking can be quite useful too, and this is what I found to work well for me. That's why I bring this up in related topics: it's not an all-or-nothi…

I don't track purchases at all, I track savings. I find that much more sustainable. I have a savings rate goal (50%), and automatic withdrawals to make that goal. If I can't pay my bills without dipping into the savings then I'll have to reevaluate my spending only then. As long as my savings rate is what it needs to be I don't worry about spending money.

This sounds like a good way to do it.

I'm a freelancer with variable income so I can't do a fixed investment rate. For me it's useful to see what was the actual rate vs. what I'd like it to be, and the high level view is quite enough to track that.

Re: 10 years of personal finances in plain text files

#163
post #38

+1 to OP's book, which is the best beginner guide I've found for understanding Beancount / plaintext accounting. I was also confused about double-entry accounting for most of my life until I read the article, "Accounting for Computer Scientists"[0] by Martin Kleppman (author of Designing Data-Intensive Applications ). It explains double entry accounting in a surprisingly accessible way by putting it in terms of graph…

What did you find hard to understand about double entry accounting? Seems pretty straightforward. Every transaction affects at least two accounts, and the total debits must equal the total credits. I can't imagine how introducing graph theory simplifies it, although I trust there are interesting insights none-the-less.

I think it explains the "why" of double entry accounting. Since it is used to track flows of money, a graph representation is a natural representation (just not the only one and not necessarily the most useful for day to day operations).

Re: 10 years of personal finances in plain text files

#164
post #154

Earlier quoted context omitted.

If ROI has diminished (maybe dopamine diminished?) then what keeps you motivated?

These days, I find it is doable 2-3 times a year. Its a lot of work at one shot but somehow able to catch up so as to review the main spending accounts. The zeroing is what attract me still. I get to see some patterns in my overall spending/categories. And it is side project where there is perceivable concrete progress, so still somewhat easier dopamine. Simplifying/automating the workflow is a pull. As I type this,…

Interesting! In a different comment, I took the other side: maybe it’s only worth tracking NW in hledger? Itemizing transactions is heavy duty bookkeeping effort, and I didn’t feel any directional value.

Re: 10 years of personal finances in plain text files

#165

Earlier quoted context omitted.

I think Accounting needs automation. Because manual tasks are error prone & Accuracy is a P0 requirement for finance.

Two points here. First, automation is a new orthogonal dimension. You can have automation with or without plain text. Second, your emphasis on "automation" leads me to believe that perhaps you misunderstand what accounting is. Accounting is not just taking a list of transactions and recording them (database, file etc). That is called bookkeeping . Yes, accounting is also amenable to automation, but much less so than…

> This understanding in turn isn't stored anywhere other than the accountant's mental model of the entity he's doing the accounting for.

It doesn’t have to be this way, though. It isn’t impossible (for most use cases) to embed that mental model into your automation tools.

You the correct that it means you can’t have purely general purpose automation that will do all accounting work for every entity, but you could certainly create automation rules that cover everything (or nearly everything) for some particular entity.

Re: 10 years of personal finances in plain text files

#166
post #38

+1 to OP's book, which is the best beginner guide I've found for understanding Beancount / plaintext accounting. I was also confused about double-entry accounting for most of my life until I read the article, "Accounting for Computer Scientists"[0] by Martin Kleppman (author of Designing Data-Intensive Applications ). It explains double entry accounting in a surprisingly accessible way by putting it in terms of graph…

What did you find hard to understand about double entry accounting? Seems pretty straightforward. Every transaction affects at least two accounts, and the total debits must equal the total credits. I can't imagine how introducing graph theory simplifies it, although I trust there are interesting insights none-the-less.

That core idea is simple. But the details, such as credit and debit having the opposite meaning to casual bank account accounting, and the use of a variety of accounts makes things not intuitive.

Re: 10 years of personal finances in plain text files

#168
Related question. When I look at finance software and accounting software I’m often looking to gain a bank feed that helps with reducing data entry workload.

Is there a way to get bank data feeds through an API? I’m not wanting to download monthly CSV or PDF files for that matter.

Any ideas?

Re: 10 years of personal finances in plain text files

#169

Related question. When I look at finance software and accounting software I’m often looking to gain a bank feed that helps with reducing data entry workload. Is there a way to get bank data feeds through an API? I’m not wanting to download monthly CSV or PDF files for that matter. Any ideas?

All the money managements apps (Monarch etc) use one of the big three bank gateways, Plaid, MX or Fincity.

They all have issues mainly the banks want constant reauth two factor rather than just trusting forever.

Mint was better they had their own connection supposedly and now that’s gone but wasn’t an open api.

I get the feeling banks don’t want this sort of thing and are fine making it annoying to use

Re: 10 years of personal finances in plain text files

#170
post #38

+1 to OP's book, which is the best beginner guide I've found for understanding Beancount / plaintext accounting. I was also confused about double-entry accounting for most of my life until I read the article, "Accounting for Computer Scientists"[0] by Martin Kleppman (author of Designing Data-Intensive Applications ). It explains double entry accounting in a surprisingly accessible way by putting it in terms of graph…

What did you find hard to understand about double entry accounting? Seems pretty straightforward. Every transaction affects at least two accounts, and the total debits must equal the total credits. I can't imagine how introducing graph theory simplifies it, although I trust there are interesting insights none-the-less.

>What did you find hard to understand about double entry accounting?

I didn't understand the point of the two entries.

My prior experience with bookkeeping was that I imported my bank statements into some tool and categorized each transaction. So, if I bought a cookie for $5, I'd mark that transaction as "food," and that felt intuitive to me. I didn't understand why it would become two transactions where one is food and the other is my cash. It just felt like, why split it into two? What does that do for me?

The "ah-ha" moment from Kleppman's post was seeing how it's not just about creating two entries but about defining flows between accounts. The graphs helped because they show how balances increase or decrease as you traverse the nodes.

To be clear, it wasn't like I spent hours banging my head against the wall trying to understand double-entry accounting and failed until Kleppman's post. It was just that I'd encountered the idea a few times, and it never clicked until Klepmman.

Post reply on HN