https://lazy-beancount.xyz
https://github.com/Evernight/lazy-beancount
Opinionated guide on how to start (and continue) tracking personal finances using the open-source Beancount accounting system.
It comes together with some code. Lazy Beancount is Beancount packaged in Docker with batteries included:
The primary goal of this guide is to provide you a way to start managing your own finances using plain-text accounting gradually and incrementally. Also with various useful tools already included and set up.
The key new feature is to allow to only enter totals for your accounts periodically via UI, and corresponding Beancount data will be generated for you. That takes very little time and you can import of fill in other data when you have time or whenever you want to do more detailed research on your finances.
3 Likes
Hi @simonmic, thanks for the repost!
Just a little update to mention that the project is still active and has seen some improvements during few months after first announcement.
The documentation was updated quite a bit: https://lazy-beancount.xyz/, as well as just generally more stuff included and refined.
I don't guarantee that everything's going to be updated at the same speed as the upstream libraries it depends on but I'm planning to maintain and sometimes improve at least set of tools I use myself on a regular basis.
1 Like
A big new update for Lazy Beancount: the Beantab plugin ( GitHub - Evernight/beantab: BeanTab is a spreadsheet-like interface for Fava to mangage balance assertions in your Beancount ledger ).
When I started this project as a proof of concept, the core idea has been that personal finance tracking should start with balances, not with transactions. The reason is tracking the balances is arguably the simplest and least-effort thing you can do, you just need to sit down and record numbers from the apps. Transactions, on the other hand, either need to be entered manually, or imported, and there are more of them. Former requires time and discipline, latter is still a bit of PITA to setup initially. Also even if you have transactions in good order, it's nice to have regular balance checks.
While using balance-first approach with relaxed rules was possible with pad+balance operations, the amount of boilerplate got large. That's why I made a sort of prototype to manage code generation. After running it for over a year though, I found that while it allows me to do things in a way I wanted to, the process was not optimal or straight out annoying in some places. Ultimately tracking balances in a spreadsheet was easier in a lot of ways (much less useful, however).
So I imagined this new plugin as an attempt to get the best of the two worlds. It presents a spreadsheet-like interface while keeping data in sync with plain-text transactions (because PTA is what we're here for, right?).
If you're interested in this concept, please give it a try. It's included in Lazy Beancount starting from 0.3.13 and 0.4.0. For now it's in beta and the main documentation still refers to the previous Streamlit-powered interfaces by default. Instead, refer to Beantab documentation and example_data_beantab folder.
Small bonus: a simple GitHub - Evernight/fava-git: Simple git interface inside Fava plugin so your data is safer while you try out the new functionality. All of the extensions can be used separately and without the full LB package, of course.
Quite interesting, thanks for sharing @vandereer.
I like the UI; what is the advantage over an ordinary spreadsheet ? From the readme I didn't quite grok what kinds of journal entries are generated, and when, and how this would/could/should interact with a transactions-based workflow.
@simonmic, thanks!
what is the advantage over an ordinary spreadsheet ?
What is the advantage of Beancount/hledger over an ordinary spreadsheet? 
I would look at this more than extension over PTA tools (like, a customized editor) rather than extension over a spreadsheet. It integrates fully within Beancount ecosystem, just needs balance_extended and pad_extended plugins enabled.
You can follow the full rationale of the approach here: I. Totals | Lazy Beancount . The BeanTab is a natural development of the solution described that is meant to smooth the rough edges. I will eventually rewrite that section of the documentation website almost fully (once Iām certain BeanTab is stable enough and documented well).
what kinds of journal entries are generated, and when
The balance-ext entries are generated on save (when you change existing or create new entries).
The reason it uses balance-ext and pad-ext over Beancount's vanilla balance and pad plugins is due to extensions in the API that allow to set some defaults, options and reduce repetition and boilerplate in the ledger, leaving just the semantics.
Under the hood balance-ext just resolves to balance operation and pad-ext processing works almost exactly the same as pad processing. That transpiling happens in the beancount plugin which means essentially each ledger load. Haven't measured an overhead yet but it shouldn't be significant.
how this would/could/should interact with a transactions-based workflow
Again, this is a development over Debugging errors | Lazy Beancount in this case.
Namely, once you specify the balances, accounts are padded by default and you can track discrepancy in Expenses:Unattributed accounts (I plan to rename them to Expenses:Unreconciled). Initially it would account for the full delta between balance checks. Once you enter/import actual transactions, they should resolve ideally to 0. If they don't, the discrepancy can be tracked/understood/fixed using Fava visualization capabilities.
I also mean to add more visualization to assist with that into the plugin/UI soon. For now it only shows an error badge over the cell if the account tracking is set to strict and calaulated balance doesn't match the asserted value (which is the default way Beancount treats balance operations).
Thanks for your questions, it helps to understand which parts of the description/documentation can be improved. It feels like a natural and relatively straightforward approach to me but once I try to describe details and implementation it starts to sound complicated which I don't think it actually is
Thanks for the info. Yes it's often hard to describe these things in way that's straightforward and clear for new users (or non-Beancount users), without getting into lots of technical details.
tracking the balances is arguably the simplest and least-effort thing you can do, you just need to sit down and record numbers from the apps. Transactions, on the other hand, either need to be entered manually, or imported, and there are more of them.
This bit, for example, immediately makes sense - love it. PTA should promote this approach more, perhaps.
1 Like
I've added the visualization I was thinking about.
Now the view is packed with additional information:
- Transactions in and out of each account in period classified by type
- When there's no balance explicitly shown in the cell, an estimated balance is shown (given specified balances and transactions in the ledger)
- Number of transactions for account in the given time period
This is what I always wanted to have in the reconciliation flow because:
- It allows to see missed/erroneous transactions more easily (pad is prominent and should trend towards zero)
- If the number of transactions in account is low, it probably hasn't been imported in that time period
- If one account has unexpected flows out and another ā unexpected flows in, then it's probably where a transaction was missed.
- Links to open the relevant parts of the ledger in the Fava journal are readily available
etc, etc
