by thcipriani on 11/13/24, 2:17 AM with 28 comments
by teo_zero on 11/13/24, 7:03 AM
1. Entries in one month's CSV file may be repeated in the previous or following month's CSV file, typically movements at the beginning or end of the month that the bank takes some time to record, or adjusts later. Is this familiar with you and how do you address it? Is your system robust against it?
2. Credit card: the total amount for a month is one single entry in the bank's CSV file, while a separate CSV file contains all the details. Do you rely on accounts to handle this indirect flow, e.g. one transaction of 1000$ from checking to cc, based on the single entry of the bank's CSV, then several transactions from cc to the various expense categories, based on the details CSV, and checking that the cc account has a zero balance?
3. Some utility companies bill every 2 or 3 months. This makes monthly stats meaningless (why is September so high compared to August? did I spent too much or is it the effect of the phone bill of the previous quarter?). Do you make any effort at trying to allocate such expenses to the month(s) when the cost originated, rather when it's billed?
by ashish01 on 11/13/24, 5:57 AM
by davidhunter on 11/13/24, 11:17 AM
1. Use excel
2. See ledger/hledger. Think this must be 'the way'. Go all in.
3. Constantly wrestle with ledger/hledger because you only do your accounting once per month/quarter which is not enough frequency to really grok it.
4. Use excel with a new sense of calm that you're not missing out on something better
by s0fasurfa on 11/13/24, 4:25 PM
a) defining the regexes/categories) for dozens to hundreds of expense descriptions (e.g. walmart, gas station xyz)
b) "recompiling" your hledger journals after every rule change
c) checking for negative and positive errors (expense description was not matched OR too many different expenses were matched)
This process is much faster in a spreadsheet application. IMHO the journal format of hledger and other plaintext accounts apps is too verbose.
it would be a great relief if someone started a Github repository with expense texts used when you e.g. pay at Carrefour in Italy or Walmart in the USA with your debit card. People could submit those descriptions from the CSV exports of their bank accounts.
Another annoyance in Europe is that there is no API connection for open source apps to bank account statements, you always rely on manual CSV exports.
by simonmic on 11/14/24, 12:01 AM
Eventual consistency is a nice phrase to highlight. I feel (https://fosstodon.org/@simonmic/113444957161144239) the same way. For me it's about not feeling you're on a time-sensitive treadmill, where if (when) you fall behind, you might risk losing data or never catching up. (Though book-keeping regularly is still advantageous because it's less work.) I believe the "pure function" style of many PTA tools, where all inputs are known and the output is deterministic, combined with version control, are a big part of this.
For newcomers, I like to make clear there's multiple styles of doing plain text accounting, including:
1. Entering all your own data by hand (optionally assisted by data entry tools).
2. Downloading data periodically from banks (as CSV, OFX, PDF, or whatever you can get) and importing it once to your journal file.
3. Downloading data periodically from banks, keeping that as your master data, and frequently regenerating journal files from it.
Each of these has its pros and cons, and there are people successfully using each of them. hledger's own docs focus on methods 1 and 2. Several third-party workflows using method 3 have been built on top of hledger; Full-Fledged Hledger that OP is using is the best known.
1 requires nothing but hledger.
2 adds: either manual bank downloading, or setting up one or more bank download tools/APIs; plus maintenance of conversion rules/scripts.
The workflows implementing 3 add: a recommended file layout, a recommended process, and tools/scripts which depend on these. They bring some benefits (a well documented featureful workflow) and some costs (added complexity). This isn't justified for all users, so don't think you're required to use these workflows.
More details: https://hledger.org/workflows.html
by kreyenborgi on 11/13/24, 11:32 AM