Allow me to gush about ledger for a moment -- I've been using it exclusively for my small business accounting for the past 3 years and it's absolutely spectacular and has been life-changing.
For many years I suffered through QuickBooks because I just assumed that was the Only Way. The single biggest pain point (and it's hard to pick just one) is that QuickBooks makes it absolutely mind-numbingly difficult to bulk-change any entries in your ledger -- if you categorize 1000 items one way and your accountant later tells you to recategorize them, there is NO WAY (or at least there was no way when I did this in the early 2000s) to bulk recategorize items. So I remember the pain of having to manually change thousands of entries or, worse, doing indecipherable things like making single journal entries like "moving from X category to Y category".
Discovering ledger was a breath of fresh air because the source data is just text! If you need to change data or recategorize or make any tweaks whatsoever you have the entire world of text manipulation tools at hand. You can write shell scripts and use IDEs (and believe it or not Github Copilot works REALLY well).
It's just amazing to realize that the perfect accounting solution has been there the whole time and is vastly vastly SIMPLER than I ever imagined. I went through all the SaaS tools (Xero, etc.) and nothing felt right. Ledger just works and feels right.
> I suffered through Quickbooks because I just assumed that was the Only Way
Suffering through QuickBooks is literally a product feature. Like, when they were porting it to the online version, bookkeepers got upset that the web version didn’t have many of the frustrating quirks of the desktop version that they’d spent decades learning to deal with. They see their having learned the bizarre ins and outs of the software as a moat that keeps their clients from doing their books themselves, so many/most require their clients to use it. And Intuit is far more responsive to the interests of CPAs/bookkeepers than it is to the end users who pay for it.
Source: I worked in Intuit’s SBG and was really surprised when I heard that from some of the product people. I’m so used to being user-focused and searching out ways to be more user friendly that it never occurred to me that, in a 3-sided market, making the software hostile to the user could be a selling point.
I generally despise having to do double entry bookkeeping in the first place, but when I do (in some situations you have to), I use ledger (or hledger). Way less painful than QuickBooks if you're also a programmer or adjacent.
> and believe it or not Github Copilot works REALLY well).
And yes, this is one area where LLM can help. That valley between "manually duplicating these near identical entries is painful" and "but it's not painful enough to warrant a custom generator". LLM is often great for that kind of boilerplate. Gotta doublecheck the bejesus out of it though.
What's your plan if you need to share the books with someone else (tax authority, accounting firm, etc)? Can ledger export it some industry-standard format that will let you share this information?
Or, at the end of the day is the default interchange format in this space just CSV?
I love how this thread immediately filled up with all the accounting nerds on the site. Good to see you all again!
I’ll do my part and throw in what I believe is the most popular modern take on this, beancount. I ended up going back to ledger but if the super old school interface and stack bother you, beancount might be nicer. Plus the beancount docs are just out-of-this-world good for learning double-entry accounting in general.
I’ve been using beancount for almost 1.5 years now, and other than having to explicitly open accounts I love it! I use the fava UI to have all the nice modern visuals: https://beancount.github.io/fava/
beancount user here, I remember starting with ledger/hledger and then switching to beancount because of its nicer handling of investments (as in nicer towards the user); the "Philosophical Differences" highlighted in the docs reminded me of why I switched — and then there is fava which is cool to start with
I recently started using Ledger this year, and I've been really impressed with its utility for me. I think, for my personal needs, https://pypi.org/project/ledger-autosync/ is a must-have. I don't want create my own transactions, and with the autosync extension, I can simply export my bank transactions as QFX files and then import them into my ledger file. In the past, I struggled to accurately track my spending, and typical banking apps were either slow or lacked good querying capabilities. Now, I can easily budget, track purchases, calculate my worth across multiple accounts, and more.
I guess similar results might be possible with other accounting tool but Ledger perfectly meets my requirements. Also, it integrates pretty well with Emacs and I get to check my reports from there.
It looks like ledger-autosync isn't very good at guessing what accounts to use. I wrote my own machine learning thing to do that. However my scripts are a hodgepodge with manual work required. I wonder if I could integrate the machine learning aspect into autosync...
Lmao I wrote my own csv translator using regex, because I thought this was a paid feature of stuff like Plaid only. You’re a lifesaver! How do you download your statements though? That’s still a small sticking point for me, and it sounds like you still need to individually go to each bank and pull each statement. Maybe I just have too many credit cards lol
I think all these tutorials and showcases showing CLI usage for plaintext accounting kinda miss the mark and ultimately hinders adoption. 99% of the times I interact with ledger is with the same 4 commands. The fact I have the ledger file open in emacs and use these commands from a keybind is what makes the experience great. Trust me, if you need to run some complicated analysis, (h)ledger has your back and you can find how to do it in the docs. Most of the time you don't so just go and start bookkeeping. You need your file populated to see any benefit, and they'll become obvious when you get there.
My brain quickly gets bored with any attempt to "track" myself, even if it's finance. If you're like that, I'd advise you to first make concrete how you're gonna use the result -- which report-commands you'll bind to keys, and how the reports are gonna influence your decisions. Only then start tracking.
I use hledger only for the things I want reports of (taxes, utilities etc split with spouse, money spent on specific hobbies, etc; not restaurants etc). Entering everything into ledger is mind-numbingly boring.
Outside of automatic git hooks for validation, I really only run hledger when reconciling balance with spouse or when reporting taxes.
Do you have a good guide to start that you could recommend? It sounds quite simple when you mention it, but every time I tried to get started with Ledger with or without emacs, it always seemed too much of an undertaking and stalled pretty early... if you have a good workflow to recommend, that would be very helpful.
A key advantage of hledger, and why I migrated from ledger, is that hledger internally orders transactions chronologically, whereas ledger inexplicably orders them in the order they appear int he file, irrespective of the date attached to them.
This [ledger's approach] totally breaks the ability to break different transaction types into different files and then import all files into a master file.
My ledger file works in both ledger and hledger, I tend to mostly use ledger as it's worked better within emacs for me. It's very rare that I even have to use the CLI. Ledger's docs are great.
Can hledger be run in a Haskell repl? That sounds way more useful than a command line terminal. (Otherwise I'm not sure why it matters whether it was written in Haskell?)
ledger has a few powerful features that hledger lacks, for example in ledger you can create an "assert" statement that checks all your journal entries fall in the correct time period (easy to mess up if you copy/paste journal entries). But it's pretty easy to move between the two.
Hledger has a more sane query language, but its not as powerful as ledger's. Also probably less bugs than ledger. Ledger, however, lets you do pretty much anything you want and thats why i prefer it. of course its easier to make mistakes with it, but i prefer the freedom it offers.
Double entry accounting is the original immutable event architecture.
They call out that it is hard to learn, but most of that in my experience is because people don't realize that credit cards and debit cards.
Just remember the formula:
Assets= liabilities + capital
It may be counterintuitive at first, but keeping that formula true is the requirement.
Debits on the left and are positive
Credits on the right and are negative.
Using Excel and a cash basis has killed lots of companies where customers pay for services and products, which looks like income, while the related expenses haven't been paid for.
Accounting for computer scientists is a good read. it presents double entry accounting in a way that should be more familiar to us, as a graph theory problem.
Sometimes non-accounting people get hung-up on the words "debit" and "credit" and think they have to do with "owing" or "being owed" money, being "positive" or "negative", etc.
The effect of a debit or credit on the business depends on the accounts in the transaction and debit and credit don't have anything to do with the "direction" of a flow of money.
My 100-level accounting instructor summarized it as: "A debit is the entry in the left column, and a credit is an entry in the right column." Without the context of the specific accounts being debited or credited the terms themselves don't confer significant meaning.
A basic knowledge of bookkeeping and accounting terminology can confer near "super powers" when it comes to dealing with finance people. It's easy to learn and worth the time.
Double-entry bookkeeping is one of the oldest and longest-practiced "IT" disciplines. Your work probably touches revenue / expenses for your employer and someday you'll need to interface with accounting or finance people. Being able to speak the language, even poorly, has helped me gain trust and credibility that I don't believe speaking only in IT terms would have.
I've been using hledger[1] - similar tool but has more features like balance sheet, income statement generation with a plain text file for the last 3 years and it's been working out great. Before that I used iBank (rebranded as Banktivity) and don't miss it at all.
I've been using Ledger for years now and with thousands of entries a year. I track investments, income, expenses, and budgeting. For mobile entry, I keep my ledger file on Dropbox and use the Drafts app and TextExpander on my iPhone to quickly append properly formatted ledger entries to the file from my phone, the moment the expense occurs. Every two to four weeks, I spend 10 minutes and use ledger-mode in Emacs to reconcile accounts with online bank / credit card transactions. It works really well and I love the flexibility and long-term portability of keeping my ledger in plain-text.
In my country, the numbered chart of accounts [1] is considered standard. A question to other (possibly European) Ledger users: have you ever considered this a hindrance or inconsistency regarding your use of the software?
I've been using Ledger for almost a decade (tiny single-person "company"). At one point, though, I started migrating my stuff to PTA by OpenBSD dev Ingo Schwarze [2]. It is a small Perl utility and relies on the numbered accounts system in a separate file, so I do feel more on the same page with general accounting-related discussions and corner-case howtos in my country.
I also like how PTA's reliance on account numbers also allows for a single-line oriented, very compact journal format [3]. This is great for further parsing with Unix tools. There was interesting discussion on PTA vs Ledger etc involving the author [4].FWIW, PTA is also linked on the plaintextaccounting.org website
To be fair, because of little prior experience with accounting in general, I did somewhat mess up my initial system of accounts in Ledger. So the migration to PTA is also in a standstill at this point. But it is a nice system for people in countries where the numbered chart of accounts might be preferred.
My only complaint is, the author might have written it in something as tiny and easily portable like Awk instead (for us occasional Windows users). But Perl, despite being "huge" in this comparison, is included in the OpenBSD base, and it is praised for text parsing, so the preference is understandable.
PTA's journal syntax looks very not-human-friendly, who wants to memorize those category numbers.
I'm sure you can create ledger accounts that match your required chart of accounts.
The example account tree you linked to seems very business oriented, and driven by interests of stakeholders & tax authorities. Ledger gets used by private individuals too, and not everything is tracked for the goal of standard business report.
Personally for me, if I had to use such a standard account tree, then I'd need to use a second system of classification for the things I am interested in.
Example 1: I have 3 heating and 2 cooling mechanisms in this house, with very different costs to operate. Each device gets a separate account. For the pellet stove, I also need to keep track of consumption to buy the right amount of fuel before the next winter, so there's even non-currency items tracked in my accounting. That doesn't sound like it'll fit in a standard scheme.
Example 2: We own a van built as a recreational vehicle. I want to track the expenses related to that (potentially expensive) hobby, whether trips, consumables, equipment or repairs. But at the same time, it's just a vehicle, and has "normal vehicle" costs just like the regular car.
My country also has a standard format (several actually). Ledger allows you to basically name any account anything you want, so you can follow that naming convention.
The standard alphabetic ordering of `ledger balance` isn't very useful. I created a small script to sort the output into a format where the entries are listed in a more sensible order. One solution could be (I haven't done this yet) is prefixing each account name with the number from the standard format, that should result in the ledger balance being more useful.
The main problem is that I don't want to give a third party access to my bank accounts, so importing into gnucash is (1) download pdf statements from bank (2) use python scripts I wrote to convert to csv (3) use gnucash importer to import.
This is fairly painful stuff, more so because my bank statements are all generated on different days of the month. So I can't form a habit of doing this regularly enough to make the data useful.
Just started using it last month. Used Mint until a year or two after Intuit bought it, then basically did no real budgeting until my recent GnuCash use.
A few YouTube vids made the interface less daunting and I read a few Reddit comments on how people use it themselves, and I'm applying what I can to my own setup.
If there's anything a new GnuCash user should read or learn, please let me know!
A while back I switched over to using SQLite, a bunch of Python functions for munging and dBeaver as a makeshift GUI. My main focus is tax reporting rather than budgeting.
The best my (awful) banks seem to be able to manage is old-fashioned CSV exports, so there’s little benefit from having something with the ability to call out to an API or import (US) standardised file formats.
Anyone else doing it this way? Seems to be going pretty well so far and of course doesn’t require learning a new query language. I’m sure there’s a lot more to (h)Ledger than that, though.
I've been using ledger for years, quite happily. My setup includes a whole lot of custom code for downloading transactions from my banks, PayPal etc and classifying them automatically. I use Ledger as the storage format and to generate reports. I find it simple, pretty easy to learn and powerful.
The only thing I'm really missing are custom fields, I slam a lot of information about transactions into comments.
I've just done the same thing. My inputs are CSV files from all over the place, and the output is a ledger file. Driven by make, of course. :)
Processing the CSVs takes about one second per year of my data, so what I think I'll probably do is summarize it out to ledger format each year.
I was using awk to do the CSV parsing, and it's blazing fast. But it gets a little bit unwieldy if you have to do multiple passes through a file or if a single CSV file has multiple sections. So I moved them to Python which is far more capable, but slower.
Shameless plug – last year I published a short ebook teaching the principles of personal accounting using Ledger: https://leanpub.com/personal-accounting-in-ledger. In fact, I've been using Ledger for about 10 years now (earlier GnuCash), and I like it a lot.
Been using ledger and hledger for about four years, love them dearly. I find ledger + Emacs ledger-mode the most convenient for daily use. Hledger has a somewhat nicer way of formatting reports on the CLI, making it useful for creating ad-hoc reports and digging into your data.
I like the idea of plaintext accounting and have tried a few of these options a number of times, sometimes pretty earnestly, but have never landed on a satisfactory flow. I've always ended up spending quite a lot of time building out the tooling around trying to fetch from now more than a dozen accounts and then munge/categorize things acceptably. In the end, I just fall back to pressing "Download All Accounts" in the clunky-but-serviceable Moneydance (local data FTW).
I have the same issue, but in Europe. Most bank don't offert a data export, so it's fun an games to try to get YOUR data. In Belgium we have CODA for companies... but they're slightly different for each bank. I've worked on this for a middleman and it's hell, between the source data sucking and the destination being cryptic.
I don't understand this: why would anyone want to block this? There are no advantages. None. For either party.
[+] [-] nlh|2 years ago|reply
For many years I suffered through QuickBooks because I just assumed that was the Only Way. The single biggest pain point (and it's hard to pick just one) is that QuickBooks makes it absolutely mind-numbingly difficult to bulk-change any entries in your ledger -- if you categorize 1000 items one way and your accountant later tells you to recategorize them, there is NO WAY (or at least there was no way when I did this in the early 2000s) to bulk recategorize items. So I remember the pain of having to manually change thousands of entries or, worse, doing indecipherable things like making single journal entries like "moving from X category to Y category".
Discovering ledger was a breath of fresh air because the source data is just text! If you need to change data or recategorize or make any tweaks whatsoever you have the entire world of text manipulation tools at hand. You can write shell scripts and use IDEs (and believe it or not Github Copilot works REALLY well).
It's just amazing to realize that the perfect accounting solution has been there the whole time and is vastly vastly SIMPLER than I ever imagined. I went through all the SaaS tools (Xero, etc.) and nothing felt right. Ledger just works and feels right.
[+] [-] curun1r|2 years ago|reply
Suffering through QuickBooks is literally a product feature. Like, when they were porting it to the online version, bookkeepers got upset that the web version didn’t have many of the frustrating quirks of the desktop version that they’d spent decades learning to deal with. They see their having learned the bizarre ins and outs of the software as a moat that keeps their clients from doing their books themselves, so many/most require their clients to use it. And Intuit is far more responsive to the interests of CPAs/bookkeepers than it is to the end users who pay for it.
Source: I worked in Intuit’s SBG and was really surprised when I heard that from some of the product people. I’m so used to being user-focused and searching out ways to be more user friendly that it never occurred to me that, in a 3-sided market, making the software hostile to the user could be a selling point.
[+] [-] dmoy|2 years ago|reply
> and believe it or not Github Copilot works REALLY well).
And yes, this is one area where LLM can help. That valley between "manually duplicating these near identical entries is painful" and "but it's not painful enough to warrant a custom generator". LLM is often great for that kind of boilerplate. Gotta doublecheck the bejesus out of it though.
[+] [-] EE84M3i|2 years ago|reply
Or, at the end of the day is the default interchange format in this space just CSV?
[+] [-] bbor|2 years ago|reply
I’ll do my part and throw in what I believe is the most popular modern take on this, beancount. I ended up going back to ledger but if the super old school interface and stack bother you, beancount might be nicer. Plus the beancount docs are just out-of-this-world good for learning double-entry accounting in general.
Docs: https://beancount.github.io/docs/the_double_entry_counting_m...
Comparison: https://beancount.github.io/docs/a_comparison_of_beancount_a...
[+] [-] cipehr|2 years ago|reply
[+] [-] visika|2 years ago|reply
[+] [-] thisisthenewme|2 years ago|reply
I guess similar results might be possible with other accounting tool but Ledger perfectly meets my requirements. Also, it integrates pretty well with Emacs and I get to check my reports from there.
[+] [-] globular-toast|2 years ago|reply
[+] [-] bbor|2 years ago|reply
[+] [-] Jtsummers|2 years ago|reply
Includes a list of similar software and ports and their current status (active/inactive).
[+] [-] lvass|2 years ago|reply
[+] [-] medstrom|2 years ago|reply
[+] [-] yencabulator|2 years ago|reply
Outside of automatic git hooks for validation, I really only run hledger when reconciling balance with spouse or when reporting taxes.
[+] [-] margarina72|2 years ago|reply
[+] [-] skulk|2 years ago|reply
Comparison of the two: https://hledger.org/ledger.html
I'm trying to start using hledger.
[+] [-] chromatin|2 years ago|reply
This [ledger's approach] totally breaks the ability to break different transaction types into different files and then import all files into a master file.
[+] [-] lvass|2 years ago|reply
[+] [-] notfed|2 years ago|reply
[+] [-] speleding|2 years ago|reply
[+] [-] peterhajas|2 years ago|reply
[+] [-] faustlast|2 years ago|reply
[+] [-] jesusofnazarath|2 years ago|reply
[+] [-] nyrikki|2 years ago|reply
They call out that it is hard to learn, but most of that in my experience is because people don't realize that credit cards and debit cards.
Just remember the formula:
Assets= liabilities + capital
It may be counterintuitive at first, but keeping that formula true is the requirement.
Debits on the left and are positive Credits on the right and are negative.
Using Excel and a cash basis has killed lots of companies where customers pay for services and products, which looks like income, while the related expenses haven't been paid for.
[+] [-] fragmede|2 years ago|reply
Accounting for computer scientists is a good read. it presents double entry accounting in a way that should be more familiar to us, as a graph theory problem.
[+] [-] EvanAnderson|2 years ago|reply
Sometimes non-accounting people get hung-up on the words "debit" and "credit" and think they have to do with "owing" or "being owed" money, being "positive" or "negative", etc.
The effect of a debit or credit on the business depends on the accounts in the transaction and debit and credit don't have anything to do with the "direction" of a flow of money.
My 100-level accounting instructor summarized it as: "A debit is the entry in the left column, and a credit is an entry in the right column." Without the context of the specific accounts being debited or credited the terms themselves don't confer significant meaning.
A basic knowledge of bookkeeping and accounting terminology can confer near "super powers" when it comes to dealing with finance people. It's easy to learn and worth the time.
Double-entry bookkeeping is one of the oldest and longest-practiced "IT" disciplines. Your work probably touches revenue / expenses for your employer and someday you'll need to interface with accounting or finance people. Being able to speak the language, even poorly, has helped me gain trust and credibility that I don't believe speaking only in IT terms would have.
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] notfed|2 years ago|reply
Lol, that'd be nice! I think you'll want to edit that.
[+] [-] rwbt|2 years ago|reply
[1] - https://hledger.org
[+] [-] raamdev|2 years ago|reply
[+] [-] jimmcslim|2 years ago|reply
[+] [-] marttt|2 years ago|reply
I've been using Ledger for almost a decade (tiny single-person "company"). At one point, though, I started migrating my stuff to PTA by OpenBSD dev Ingo Schwarze [2]. It is a small Perl utility and relies on the numbered accounts system in a separate file, so I do feel more on the same page with general accounting-related discussions and corner-case howtos in my country.
I also like how PTA's reliance on account numbers also allows for a single-line oriented, very compact journal format [3]. This is great for further parsing with Unix tools. There was interesting discussion on PTA vs Ledger etc involving the author [4].FWIW, PTA is also linked on the plaintextaccounting.org website
To be fair, because of little prior experience with accounting in general, I did somewhat mess up my initial system of accounts in Ledger. So the migration to PTA is also in a standstill at this point. But it is a nice system for people in countries where the numbered chart of accounts might be preferred.
My only complaint is, the author might have written it in something as tiny and easily portable like Awk instead (for us occasional Windows users). But Perl, despite being "huge" in this comparison, is included in the OpenBSD base, and it is praised for text parsing, so the preference is understandable.
1: https://en.wikipedia.org/wiki/Chart_of_accounts
2: https://mandoc.bsd.lv/pta/
3: https://cvsweb.bsd.lv/~checkout~/pta/journal.example.en
4: https://undeadly.org/cgi?action=article;sid=20200928123430
[+] [-] yencabulator|2 years ago|reply
I'm sure you can create ledger accounts that match your required chart of accounts.
The example account tree you linked to seems very business oriented, and driven by interests of stakeholders & tax authorities. Ledger gets used by private individuals too, and not everything is tracked for the goal of standard business report.
Personally for me, if I had to use such a standard account tree, then I'd need to use a second system of classification for the things I am interested in.
Example 1: I have 3 heating and 2 cooling mechanisms in this house, with very different costs to operate. Each device gets a separate account. For the pellet stove, I also need to keep track of consumption to buy the right amount of fuel before the next winter, so there's even non-currency items tracked in my accounting. That doesn't sound like it'll fit in a standard scheme.
Example 2: We own a van built as a recreational vehicle. I want to track the expenses related to that (potentially expensive) hobby, whether trips, consumables, equipment or repairs. But at the same time, it's just a vehicle, and has "normal vehicle" costs just like the regular car.
[+] [-] speleding|2 years ago|reply
The standard alphabetic ordering of `ledger balance` isn't very useful. I created a small script to sort the output into a format where the entries are listed in a more sensible order. One solution could be (I haven't done this yet) is prefixing each account name with the number from the standard format, that should result in the ledger balance being more useful.
[+] [-] zie|2 years ago|reply
`2008-01-01 Opening Balance`
hledger-flow is my BFF for managing this: https://github.com/apauley/hledger-flow
Like others have mentioned plaintextaccounting.org is a great resource into the larger community.
[+] [-] gadiyar|2 years ago|reply
[+] [-] somat|2 years ago|reply
[+] [-] abdullahkhalids|2 years ago|reply
The main problem is that I don't want to give a third party access to my bank accounts, so importing into gnucash is (1) download pdf statements from bank (2) use python scripts I wrote to convert to csv (3) use gnucash importer to import.
This is fairly painful stuff, more so because my bank statements are all generated on different days of the month. So I can't form a habit of doing this regularly enough to make the data useful.
[+] [-] Andrex|2 years ago|reply
A few YouTube vids made the interface less daunting and I read a few Reddit comments on how people use it themselves, and I'm applying what I can to my own setup.
If there's anything a new GnuCash user should read or learn, please let me know!
[+] [-] bostik|2 years ago|reply
For the past decade or so I record the transactions on the mobile version, and use desktop software to dissect the data in more effective ways.
[+] [-] darkteflon|2 years ago|reply
The best my (awful) banks seem to be able to manage is old-fashioned CSV exports, so there’s little benefit from having something with the ability to call out to an API or import (US) standardised file formats.
Anyone else doing it this way? Seems to be going pretty well so far and of course doesn’t require learning a new query language. I’m sure there’s a lot more to (h)Ledger than that, though.
[+] [-] fhd2|2 years ago|reply
The only thing I'm really missing are custom fields, I slam a lot of information about transactions into comments.
[+] [-] beej71|2 years ago|reply
Processing the CSVs takes about one second per year of my data, so what I think I'll probably do is summarize it out to ledger format each year.
I was using awk to do the CSV parsing, and it's blazing fast. But it gets a little bit unwieldy if you have to do multiple passes through a file or if a single CSV file has multiple sections. So I moved them to Python which is far more capable, but slower.
[+] [-] mbork_pl|2 years ago|reply
[+] [-] koeng|2 years ago|reply
[+] [-] compns8-ng|2 years ago|reply
[+] [-] ligurio|2 years ago|reply
https://github.com/kedder/ofxstatement
[+] [-] LVB|2 years ago|reply
[+] [-] Arcanum-XIII|2 years ago|reply
[+] [-] FerretFred|2 years ago|reply