I use GnuCash for business accounting and it does what I need. I don't use QuickBooks as VC's recommend in blog posts. QB has some convenient features, but that is not enough for me to pay the price QB is asking. I don't need VC money or a CPA.
I haven't tried using GnuCash with Sqlite, but I would like to experiment when I get the time. Is it reliable?
I used to be a technical/functional engineer for Oracle EBS, so I dealt with very complex schemas that interlinked with each other especially in the sub-ledgers.
I've always toyed with the idea of adding Revenue Recognition functionality to GnuCash but am too busy to do so. Perhaps after seeing the schema in Sqlite I can take a shot at it.
In case anyone is migrating from QB and wants to help others, the qb-escape quickbooks to gnucash converter could use some help: https://github.com/erikmack/qb-escape/
It's great for personal or very small businesses but god help you if you are building a real startup with GNUCash. I am speaking from experience here, GNUCash zealotry is a plague. I honestly wish this project basically did not exist, because the business world despises GNUCash, ONLY cares about QuickBooks, and using anything else is a giant waste of everyone's time. Believe me, I have been fighting this fight in non-profits and startups since the early 2000's. It's not a fight ANYONE should ever have. I USED TO BE THE "WE MUST USE GNUCASH" GUY!
Now, in a perfect world, yes, GNUCash and literally ANYTHING other than Quickbooks would be an option for small business accounting. But we do not live in a perfect world. We live in a world where Intuit has fought VERY hard to make damn sure no one can use anything but Quickbooks, and their iron fist is clad in very specific APIs and file formats.
If you do not use Quickbooks:
* Your bank will hate you.
* Your investors will hate you.
* Your payroll system won't work.
* Your tax systems won't work.
* Your accountant won't work.
* Grants are even off the table in some cases.
* Some places won't audit without Quickbooks.
I constantly run into well intentioned open source zealots who demand the use of GNUCash. This is terrible. Don't be that person.
The world has chosen QuickBooks. This choice was made under duress and with corrupt power brokering. But the decision has been made. Maybe there are some OK SaaS options, but they only exist as long as Intuit allows them to exist. Anything competing with Quickbooks is going to be bought and killed by Intuit, so you're going into a dead-end alley. I know that leaves GNUCash on the table, but...
Please, do not make the mistake my many non-profits and businesses have repeatedly made when I was not paying enough attention to scream bloody murder about it. I turn my back for one minute, and engineers are installing GNUCash on the accountant's Mac Laptop.
It's 100% always come back to bite us in the ass, as we've had to change platforms on-demand in order to meet a funding deadline, a bank requirement, a loan ask, or a grant application. And it's ALWAYS the accountant in the org that gets saddled with the 60+ hour work weeks it takes to redo everything. If I was an acocuntant, I'd quit if told to use GNUCash, but most of them kinda don't know any better because, hey, why not try some thing the techies are all excited about!
GNUCash is a wonderful project. I wish we could all use it. But we cannot. Not for real business. And honestly, this is only for contrived, arbitrary reasons. But these reasons exist. The world is 100% built to prevent people from not using Quickbooks at every turn, and you only harm yourself by demanding open source software for accounting. As I said to the director of my most recent non-profit: "You would not tolerate the accountant coming in here and demanding you use NetBeans. Please, give them the same courtesy you'd expect them to give you on tool choice."
> We live in a world where Intuit has fought VERY hard to make damn sure no one can use anything but Quickbooks
It depends on geography. According to Codat's 2021 report [0] on SME accounting market share:
- In the US, QuickBooks is the clear market leader, with 75.7% combined market share across their three main offerings (QB Online, QB SE and QB Desktop). FreshBooks is in second place at 4.5%, and Wave and Xero equal third at 3.5% each
- In the UK, Sage is the market leader, with a combined market share of 28.8% across their three main UK products (Sage 50/50 Cloud, Sage Accounting, and Sage 200cloud); QuickBooks combined market share (Online+Desktop+SE) is closely behind, in second place at 26.2%; and Xero is in third place at 24%
- In Australia + New Zealand, Xero is in first place at 49.4% market share, MYOB in second place at 33.8%, QuickBooks comes third at 11.2%
- In Canada, QuickBooks is the clear market leader with a combined market share of 68.2%; FreshBooks is in second place at 6.9%; while Sage at 6.4% is in third place. Kashoo comes fourth at 4.3%, and Wave, Xero and Logiciel Actiff are equal fifth at 3.8% each.
So, it is really only in North America that "no one can use anything but Quickbooks" is remotely true – and even there, close to 25% of US SMEs and over 30% of Canadian SMEs are successfully using "something other than Quickbooks".
But I agree it is likely true, that for the vast majority of US small-to-medium businesses, GNUCash is not a realistic alternative to Quickbooks. But what about FreshBooks or Wave or Xero? Or the dozen other commercial accounting software vendors with some presence in the US market?
Why? Surely all US banks use open, standardized data formats to export financial statements and to execute transactions in bulk? Or are you thinking of another reason?
US banking is a shitshow which is decades European banking, addressing that would benefit everyone.
> Your investors will hate you
Why? Surely your investors are interested in accurate accounting? Can gnucash not generate some kind of report they need? If so, that should be a trivial fix.
I actually have had an accountant come into engineering and tell me I had to use netbeans!
Just kidding of course. Thank you for your post. I had considered using gnu cash many times in this situation and I'm likely to have done it. Luckily someone else handled the accounting portion for the last gig.
I badly want gnu cash to be a thing. I really hate into it. And I want them to fail. I would love if gnu cash is what made them fail. But it sounds like it's going to take a whole lot more than just a few sacrifices like us. We'll just go through misery, and nothing will be affected cuz we'll end up stuck on QuickBooks anyway.
We used GNUCash for a few years for small business accounting. After a while we migrated to Quickbooks Online as it has some features that GNUCash was missing, e.g., automatically pulling in PayPal and bank transactions and inventory management. This turned out to be a very frustrating experience. Due to the following:
- The price increased every year. We started at about $60/month and after a few years it $80/month. Today the same plan is $99/month.
- The PayPal integration randomly stopped working and was missing transactions. QB customer support was completely useless and we spent hours searching and manually adding transactions. The bank integration (via Plaid) was also not reliable.
- The inventory management is very limited. E.g. you can't repack/combine items without using weird hacks.
So, after a few years I got very frustrated and ended up moving to ERPNext. Migrating all the data was quite a bit of work and involved a number of Python scripts to pull out the data from QB and re-create it in ERPNext, but after about a week we had 5 years of data migrated.
ERPNext is not perfect, but works quite well for us. A big difference to QB is that it supports inventory and manufacturing operations. It also has an API that is fairly easy to use and we use it to get transaction data from PayPal and Stripe.
I’m pretty sure it is 100% gonna bite you, yes. (In a large part of ex-USSR countries, we had the same problem with 1C – it’s less of a pain to use other options now, I think, but it’s still bad.)
But the only way to hopefully get to a world where you don’t need Quickbooks anymore is to fight back, not for them. And like you said, Intuit can buy off startups, so this leaves us with free open source systems... like GnuCash.
Serious question: is it not possible to export/import into Quickbooks for example? I agree with the principle of letting the accountant choose, just wondering if there's any way at all to "fight back", for lack of a better word.
I've tried many personal accounting software and all of them (but old Pcoket Money for PalmOS!) are very unhelpful in filling in expenses.
If you need to record whole shop visit as one transaction (like "Food at Lidl") it is tolerable, but as soon as you want to enter each line in your receipt as separate part of split transaction (like, food:milk = 2 euro, food:bread = 1 euro, food:eggs = 3 euro, food:meat:pork = 8 euro, etc) you need to type everything again and again without good suggestions, based on your previous history. Such suggestions could be very sophisticated, taking counterpart and other parameters and suggest "food:bread" and price by letters "br" if counterpart is "Lidl" or "clothing:bra" and other price if counterpart is "Victoria Secret", for example, but, alas, nothing I've tried, support this.
Really, old (PalmOS 3.0!) Pocket Money was a breeze, and everything else, Desktop or Mobile, is much, much worse in this aspect.
Also, I think, that when you have all you transactions vrty detailed, it is better to have nested "categories" and not nested "accounts". It is almost cosmetic difference, but it is strange for me to have "cache" and "food:meat:pork" as same type of objects. I don't transfer money to "food:meat:pork", I spend money for it. I transfer money to the shop, not to the product! As far as I know, professional accounting systems doesn't have account for each asset of the firm, like different accounts for monitors, laptops, computers and (computer) mices.
Is it actually all that useful to you to track each receipt line-item? For a few specific types of purchases, maybe, but I'm going to go out on a limb here and suggest you might be taking on needless work that doesn't create value for you anywhere near that level of effort.
I did this exercise for a little over a year to understand my expenses in detail. Like the OP, I found it really frustrating to do with any bookkeeping software I tried, to the point where I eventually gave up as I didn't think it was worth the effort. I started writing a web app to make this easier but just didn't have the motivation to finish.
With that said, I learned quite a bit as a result of that level of granularity. When all expenses at Amazon, Walmart, etc go into the same bucket, it's really difficult to truly understand what you're spending your money on and if you have a problem you need to curb. Seeing "$X in spending at Amazon" isn't really that useful without knowing how important or frivolous any of those expenses were.
I’m with you on that one. Been tracking my personal finances since 2011 and I have yet found a need to go deeper with analysis.
Although I can imagine it could be interesting to go extra deep, e.g. to observe changes in my nutritional habits based on my grocery receipts juxtaposed with, say, my bloodwork. But even then it’d be a gimmick as I could not potentially rely on any correlation noticed. I’m sure someone could come up with a better example.
In any case, unless tracking gets super easy, with digital receipts saved directly onto our mobile devices and standardized for processing, I just couldn’t be bothered to break down paper receipts.
That BTW makes me wonder why have we not seen e-receipts standardized yet. We can pay wirelessly with devices, so why not save some more meta data about the transaction, including the receipt itself? Seems like a low hanging fruit, also saving tons of paper.
At the grocery store it would be extremely useful to understand where money is going related to other food groups (diary is 10% more). At the garage or clothing store not very useful because the entire purchase is a good group but how much you are paying for meat could help you decide to buy it elsewhere but allow you to keep buying bread.
I feel like it isn't for the vast majority of people. I did a bit of tracking on my spending but it just ends up showing that the vast majority of my spending was on rent and fixed bills which are very easy to track in just a spreadsheet. The amount I'm spending on biscuits and milk week to week doesn't matter at all in the grand scheme.
A lot of banking apps these days will automatically categorize your spending as well which eliminated much of the need to manually enter it in to a different app.
I've tried a lot in the past as well, and after getting annoyed with proprietary OS X software (iBank in particular) back in 2009 or so, and not really liking GNUCash and KDEMoney (at least back in 2009) ended up writing my own open source simple app (native Cocoa, with a more recent Qt port for Linux) that I've been using every since on a daily basis.
In terms of the detail, I used to do very detailed breakdowns of categories, but now I don't really see the point: my app supports 'split transactions' (one of the reasons I actually made it, as existing solutions had poor support for them back in 2009), and I generally just use things like 'Food', 'Drinks', 'Essentials' as categories, as it never really made sense (at least for me) to detail them with such accuracy.
But for things like 'coffee', I do 'Drinks:Coffee', so I can see how much I am spending on fairly specific things, but I guess it's a balance in terms of whether it's worth the effort to record them so accurately compared to making use of the details.
Similarly, things like 'Car:Fuel', 'Car:Service', etc...
At some point I really should do a first principles analysis of why I track money... as far as I know, it mostly comes down to: 1. is fraud happening? and 2. Am I saving enough for retirement? Oh, and I guess 3. taxes
For fraud, I think it's basically a matter of whether we can recognize each transaction. You don't actually need to download transactions for that; you can just skim your monthly statements.
For saving, that's tricky because there needs to be that recognition of what categories are likely to increase during retirement versus decrease. I gave that a single pass a while back, and now I have a count each month of those expense categories that will continue into retirement, along with a 12-month average, so I can get a sense of what my portfolio needs to be able to fund after I retire. For that, even though I have Banktivity, I also have to use a spreadsheet.
For taxes, I don't know if anything really makes that easy. It's hard to know what category breakdown you really need to know whether you're capturing all your tax benefit, and my financial software doesn't tell me "oh, by the way, you'll want to split that transaction since some of it has a tax benefit."
When I started to track my finances I quickly ran into limitations with just a spreadsheet, and also didn't feel like any of the existing options fit my need. I agree that for most (all?) people this level of detailed tracking is probably too much, but it doesn't take that much time for me.
I ended up making my own app https://github.com/VMelnalksnis/Gnomeshade. I also felt similarly regarding accounts, so I split transactions into two parts - transfers and purchases. That allows to handle multiple currencies, and handle categorization separately from accounts. I haven't looked into suggestions like you mentioned, I went with trying to parse receipts for my most common purchases.
As others have said, you're likely too granular. I just separate into "Groceries", "Supplies", "Clothes", etc.
I couldn't quite understand what you need, but I use KMyMoney (migrated from GnuCash over a decade ago). If you've gone to Walmart and itemized in the past, then the next time you go to Walmart and import your CC statement, it will pick the last Walmart transaction with a similar total charge as your starting point. It's mildly helpful.
And yes, it does do Categories instead of Accounts. The latter, however, is more in line with accounting principles.
It would be nice if there was a QRcode format on receipts for this. Off the top of my head, the encoded format would have:
* store name/location
* total amount
* field for tax(es) broken out
* a general category of the purchase if it's simple ("fuel", "food" for receipt from McDonald's)
* groupings of items for certain types/categories: at (e.g.) Costco you can buy groceries and clothing, so have a grouping for all your food with the total for that categorized as "food", clothes grouped together with its category; you can also get gas and tire/oil changes ("transportation")
The major categories could be what a lot of countries use for CPI categories:
May I ask why you want this? Does it have an actual purpose or do you just enjoy processing data? If the purpose is "check what % I'm spending in each category", you don't need account software for this. You just need a table with 2 columns, price and category and group by and sum. How you get that table has nothing to do with accounting.
Would only work for Lidl, but I wonder if there's anyway of pulling the data using the APIs that they use for the Lidl Plus app. The Lidl Plus app contains a digital receipt of every shop you've done with them.
Not something I've looked at and specific to Lidl but if you shop there regularly it might be worth trying.
It would be better if the software could just scan the receipt. And if you live in the country with electronic receipts (like Russia) then you can get them to your email in electronic form or find online by identifiers on a paper receipt.
I’d expect something like claude 3.5 or chatgpt 4 to do OK at this. (Maybe ocr the receipt, or just send a copy to a multimodal model).
You might be able to use one of the open weight models instead. (Maybe one of the apache 2.0 qwen’s?) Scan a batch, then hand check the results in fifo order. That way you can probably get away with a local gpu.
The hard part will be getting structured output that gnucash likes. I’d try a simple json schema (stick the schema and some example input/output in the context), and then write some code to convert it to a format gnu cash can import.
You're basically describing envelope budgeting, I think, where the money is (like checking) or isn't (like credit cards) doesn't matter. You have money inside of physical or virtual "envelopes" that represent what money you really have available for X or Y. It's kind of like an abstraction on top of all your money sources.
Envelope budgeting works really well, tbh. Especially for saving.
Due to a colossal screw up my bank had after I moved back to my home country, it took me several months to get a new debit card. So I got used to just taking out X cash per month, and dividing it.
I’ve tried a few financial tracking things since getting back on the card wagon, and found none of them actually have the same result (spending less) as just dividing cash into physical buckets.
I think the only thing that will ever really make sense is flat horizontal property lists.
A given item and a given transaction could have any number of different properties, and no single heirachical category can express the reality.
Is it a work expense or is paid through paypal or is it a subscription or is it from amazon or is it food? A single item could be all of those at once, and sometimes when you want to know "all food" you want to include that regardless what it's other properties are.
IE, pork doesn't really have to be under some heirarchy like meat. It is both pork and meat, and it also may be art supplies or photographic subject etc.
Frankly the easiest way seems to be apps that parse your sms messages in your phone and build up an expense report out of that. Many people here will balk at this, but it takes a lot of effort out of keeping expense reports.
I don't like the GNUcash model very much, it is a bit fiddly to use, and is pretty hard to get the right stats I want out of it. I've used and settled on several other packages in the past.
But GNUCash existed when I first got a job decades ago.
GNUCash exists today.
I don't think any other package really matches the endurance.
It is charming in that it has that mid 90s utility design.
It is absolutely frustrating because it has that mid 90s utility design.
I don't think I have seen any other utility hasnt really progressed on interface design like GNUcash. Like they built a prototype went "Nailed it!" And then moved onto back end stuff while ignoring all input from users.
That's a big win! There are very few things more frustrating than software that keeps changing the UI just because some designed somewhere wants to feel busy.
I tried it years ago but finally settled on HLedger. Like GnuCash, I own and control my data, but with HLedger I have an ability to go in and correct or change something (and not in a "accounting-appropriate" way) in bulk just by editing it in Sublime Text. Then again, my use case is pretty basic and not mission critical so YMMV.
I use Firefly III (https://firefly-iii.org). It's a self-hosted web app which is nice for me because I tend to use it from my phone most of the time. It does have a pretty extensive API, perhaps not as easy to do bulk edits as a text file, but should be fairly straightforward. It also has a rule system that could be used to do bulk edits too.
I'm using GnuCash and not being able to easily do bulk changes or easily script it is quite annoying, for example after a slight mistake in a CSV import.
GnuCash has a scripting engine. If you have to do a specific correction very often, it might be worth it to implement something. If possible, the CSV should be preprocessed of course.
If nothing else works, a Gnucash file is XML. A bit annoying to work with, but quite possible.
I have also used hledger and ledger (specifically the lots feature) for many years. One nice feature of hledger is its csv rules system, which is very flexible. I extended it with simple python scripts to add extra information for registering capital gains. So, end of the day the raw input data is just some csv files with records and the output is financial reports with various levels of detail.
I actually run a little script that converts the gnucash xml to ledger[0] and keep that (and the original xml) tracked in git. Run that fairly regularly while entering into gnucash ui and I have an easily readable git log/diff of my changes. But it's missing the "bulk change" ability, yes. (The gnucash is just xml so one could edit that, I haven't dared to yet.)
Whenever I have to edit an xml file I tend to just go ham with python's xml library. the scripts are never pretty, mainly because they are whatever addhoc editing I wanted in written form. The hardest part is figuring out the xpath syntax.
A slight lie, I use lxml, mainly because it can select siblings which the built in xml lib is unable to do. but I still use the internal libs documentation, mainly because it is easier to read.
Yeah, I've never found XML to be easy to edit/bulk edit/edit by hand. I suppose there are tools that would allow me to do that but since I would use them sporadically, I'd need to re-learn them every use. At the same ^D/^KD in Sublime works just fine.
I use GnuCash for the accounting of my hackerspace. It was either this or a site called "wave" which the treasurer of a nearby makerspace recommended. After signing up for wave and playing around, I still wasn't sure. A few weeks later I decided I would use wave, but then I found they had locked my account for no reason. GnuCash it is!
It's good software! I eventually wrote code that dynamically links with the libgnucash library so I can auto-generate monthly invoices for the member's dues.
It's kinda a mess tbh, and it actually also requires some non-exposed symbols to work properly, so it needs access to the GnuCash source code. I wouldn't recommend doing this unless you're ok with maintaining your own unsupported GnuCash feature.
I looked carefully at GnuCash before settling on Beancount (or plain-text accounting in general) for personal finance software.
The deal breaker for me was the underlying XML or SQLite formats of GnuCash. These are not terribly amenable to scripting, either for ingesting raw data or reporting. Whereas this is basically the point of plain-text tools like Beancount or HLedger. GnuCash feels too much like a walled-garden compared to plain-text tools.
The plain-text format requires more work at first, but after you get the hang of it (and provided you have some background in scripting software) it is awesome.
To each their own I guess: my experience is the exact opposite. Plain text looks simple to human eyes but parsing it in a structured way is a nightmare and scripting edits to plain text is a mess.
Databases on the other hand are built for this. After years of dissatisfaction with plain text accounting and many hours spent trying to improve it, I now use SQLite and it has been an enormous improvement.
I agree with using the tool that works best for your purpose.
For me, I found that the SQLite models of GnuCash aren't straightforward to query. That's why Beancount created its own query language. Martin Blais has a good discussion of why a traditional database doesn't quite fit for many accounting purposes https://beancount.github.io/docs/beancount_query_language.ht...
Part of the reason I settled on beancount over h/ledger was the ease of writing python plugins to handle mutations and rules, and reuse the official parse/output as a library.
Plaintext is nice for git but I only feel that when fixup-ing a single or small number of transactions. It does feel nice to be have all the details of a transaction in one place in a visually useful way. For one-off hacking and such it definitely feels easier to write O(n^4) python looping over trying to describe things with SQL and working at a scale where it doesn’t matter.
Plaintext as a UI into a SQL store seems an interesting project. I would love a git integration for committing changes after diff review and being able to stage individual txns or parts. Many years ago I was frustrated with ledger’s more loosey goosey syntax and trying these things and eventually gave up whatever the idea was at the time. I like the idea of a constant bidrectional sql<->plaintext that provides a requirement for reproducible parsing and serializing
Not to go off topic - this story did inspire me to install gnucash again and enjoy the GUI -
> parsing it in a structured way is a nightmare
Ah, well that’s the job of the PTA app - converting “just text” to something very structured and validated. Which can then be moved into SQLite, if one likes.
> and scripting edits to plain text is a mess.
I suppose it depends. There are a lot of very powerful and quick tools and techniques for automated or assisted text munging.
As long as the XML/DB schema is documented (no idea if it is), it's actually better and more robust than Beancount/Ledger's plain text format. In fact, I use KMyMoney (XML backend), and have a script to convert the data to Ledger format. The script was easy to write precisely because it's not free flowing text.
It's a decent experience for personal accounting if you follow the advice from the beancount cookbook/manual for organizing things. I wish there was a bit more integration between the experience of editing and reviewing accounts, and started https://github.com/seltzered/beancolage as an initial attempt.
GnuCash holds a special place in my heart. My first couple years out of college, running a very tight budget on a lean income. Every time I shopped I'd bring my receipt home and enter it diligently on the ledger. Everything reconciled always. It was a ton of work :)
As a freelance consultant from Sweden I looked at GnuCash several times over the past 10+ years but it was always the same issue.
It's not tailored for our economy and our revenue services.
Here in Sweden if your revenue is below 3 million SEK/year, then you can use "simplified bookkeeping" (rough translation of "förenklat årsbokslut").
In practice it means I could write a very basic program to manage my expenses and income and just have it generate all the necessary numbers that I then enter manually into our revenue service's online app every year.
I am also a solo freelancer with simplified bookkeeping.
I experienced that Double-entry bookkeeping is - beyond the initial learning curve - not more effort than simple book keeping. That is because it automatically avoids common errors. GnuCash works fine for me since 20 years. Never looking back to fragile spreadsheets and half-baken Access DB's.
How is the GnuCash DB any different from using an Access DB?
For simplified bookkeeping GnuCash, and most generalized bookkeeping programs, is overkill.
I accomplish the same thing with 250 lines of Python, and the result is that I get exactly the numbers I need to enter into Skatteverkets e-tjänst, and nothing else. And each transaction is one yaml file, and stored off-site with git.
Readit News
I haven't tried using GnuCash with Sqlite, but I would like to experiment when I get the time. Is it reliable?
I used to be a technical/functional engineer for Oracle EBS, so I dealt with very complex schemas that interlinked with each other especially in the sub-ledgers.
I've always toyed with the idea of adding Revenue Recognition functionality to GnuCash but am too busy to do so. Perhaps after seeing the schema in Sqlite I can take a shot at it.
Cheers
Now, in a perfect world, yes, GNUCash and literally ANYTHING other than Quickbooks would be an option for small business accounting. But we do not live in a perfect world. We live in a world where Intuit has fought VERY hard to make damn sure no one can use anything but Quickbooks, and their iron fist is clad in very specific APIs and file formats.
If you do not use Quickbooks:
* Your bank will hate you.
* Your investors will hate you.
* Your payroll system won't work.
* Your tax systems won't work.
* Your accountant won't work.
* Grants are even off the table in some cases.
* Some places won't audit without Quickbooks.
I constantly run into well intentioned open source zealots who demand the use of GNUCash. This is terrible. Don't be that person.
The world has chosen QuickBooks. This choice was made under duress and with corrupt power brokering. But the decision has been made. Maybe there are some OK SaaS options, but they only exist as long as Intuit allows them to exist. Anything competing with Quickbooks is going to be bought and killed by Intuit, so you're going into a dead-end alley. I know that leaves GNUCash on the table, but...
Please, do not make the mistake my many non-profits and businesses have repeatedly made when I was not paying enough attention to scream bloody murder about it. I turn my back for one minute, and engineers are installing GNUCash on the accountant's Mac Laptop.
It's 100% always come back to bite us in the ass, as we've had to change platforms on-demand in order to meet a funding deadline, a bank requirement, a loan ask, or a grant application. And it's ALWAYS the accountant in the org that gets saddled with the 60+ hour work weeks it takes to redo everything. If I was an acocuntant, I'd quit if told to use GNUCash, but most of them kinda don't know any better because, hey, why not try some thing the techies are all excited about!
GNUCash is a wonderful project. I wish we could all use it. But we cannot. Not for real business. And honestly, this is only for contrived, arbitrary reasons. But these reasons exist. The world is 100% built to prevent people from not using Quickbooks at every turn, and you only harm yourself by demanding open source software for accounting. As I said to the director of my most recent non-profit: "You would not tolerate the accountant coming in here and demanding you use NetBeans. Please, give them the same courtesy you'd expect them to give you on tool choice."
It depends on geography. According to Codat's 2021 report [0] on SME accounting market share:
- In the US, QuickBooks is the clear market leader, with 75.7% combined market share across their three main offerings (QB Online, QB SE and QB Desktop). FreshBooks is in second place at 4.5%, and Wave and Xero equal third at 3.5% each
- In the UK, Sage is the market leader, with a combined market share of 28.8% across their three main UK products (Sage 50/50 Cloud, Sage Accounting, and Sage 200cloud); QuickBooks combined market share (Online+Desktop+SE) is closely behind, in second place at 26.2%; and Xero is in third place at 24%
- In Australia + New Zealand, Xero is in first place at 49.4% market share, MYOB in second place at 33.8%, QuickBooks comes third at 11.2%
- In Canada, QuickBooks is the clear market leader with a combined market share of 68.2%; FreshBooks is in second place at 6.9%; while Sage at 6.4% is in third place. Kashoo comes fourth at 4.3%, and Wave, Xero and Logiciel Actiff are equal fifth at 3.8% each.
So, it is really only in North America that "no one can use anything but Quickbooks" is remotely true – and even there, close to 25% of US SMEs and over 30% of Canadian SMEs are successfully using "something other than Quickbooks".
But I agree it is likely true, that for the vast majority of US small-to-medium businesses, GNUCash is not a realistic alternative to Quickbooks. But what about FreshBooks or Wave or Xero? Or the dozen other commercial accounting software vendors with some presence in the US market?
[0] https://www.codat.io/wp-content/uploads/2021/02/Codat_Global...
Why? Surely all US banks use open, standardized data formats to export financial statements and to execute transactions in bulk? Or are you thinking of another reason?
US banking is a shitshow which is decades European banking, addressing that would benefit everyone.
> Your investors will hate you
Why? Surely your investors are interested in accurate accounting? Can gnucash not generate some kind of report they need? If so, that should be a trivial fix.
> Some places won't audit without Quickbook
That is an impressive shitshow of a situation.
Just kidding of course. Thank you for your post. I had considered using gnu cash many times in this situation and I'm likely to have done it. Luckily someone else handled the accounting portion for the last gig.
I badly want gnu cash to be a thing. I really hate into it. And I want them to fail. I would love if gnu cash is what made them fail. But it sounds like it's going to take a whole lot more than just a few sacrifices like us. We'll just go through misery, and nothing will be affected cuz we'll end up stuck on QuickBooks anyway.
- The price increased every year. We started at about $60/month and after a few years it $80/month. Today the same plan is $99/month.
- The PayPal integration randomly stopped working and was missing transactions. QB customer support was completely useless and we spent hours searching and manually adding transactions. The bank integration (via Plaid) was also not reliable.
- The inventory management is very limited. E.g. you can't repack/combine items without using weird hacks.
So, after a few years I got very frustrated and ended up moving to ERPNext. Migrating all the data was quite a bit of work and involved a number of Python scripts to pull out the data from QB and re-create it in ERPNext, but after about a week we had 5 years of data migrated.
ERPNext is not perfect, but works quite well for us. A big difference to QB is that it supports inventory and manufacturing operations. It also has an API that is fairly easy to use and we use it to get transaction data from PayPal and Stripe.
But the only way to hopefully get to a world where you don’t need Quickbooks anymore is to fight back, not for them. And like you said, Intuit can buy off startups, so this leaves us with free open source systems... like GnuCash.
A lot of other people seem interested, if you have a blog this would be a great post.
And yet knowing this has gone on, you refuse to continue to fight the good fight even still? Sounds like you're part of the problem my man.
I'm so fucking tired of corporate apologists/appeasers.
If you need to record whole shop visit as one transaction (like "Food at Lidl") it is tolerable, but as soon as you want to enter each line in your receipt as separate part of split transaction (like, food:milk = 2 euro, food:bread = 1 euro, food:eggs = 3 euro, food:meat:pork = 8 euro, etc) you need to type everything again and again without good suggestions, based on your previous history. Such suggestions could be very sophisticated, taking counterpart and other parameters and suggest "food:bread" and price by letters "br" if counterpart is "Lidl" or "clothing:bra" and other price if counterpart is "Victoria Secret", for example, but, alas, nothing I've tried, support this.
Really, old (PalmOS 3.0!) Pocket Money was a breeze, and everything else, Desktop or Mobile, is much, much worse in this aspect.
Also, I think, that when you have all you transactions vrty detailed, it is better to have nested "categories" and not nested "accounts". It is almost cosmetic difference, but it is strange for me to have "cache" and "food:meat:pork" as same type of objects. I don't transfer money to "food:meat:pork", I spend money for it. I transfer money to the shop, not to the product! As far as I know, professional accounting systems doesn't have account for each asset of the firm, like different accounts for monitors, laptops, computers and (computer) mices.
Maybe, I don't find it yet? Any suggestions?
With that said, I learned quite a bit as a result of that level of granularity. When all expenses at Amazon, Walmart, etc go into the same bucket, it's really difficult to truly understand what you're spending your money on and if you have a problem you need to curb. Seeing "$X in spending at Amazon" isn't really that useful without knowing how important or frivolous any of those expenses were.
In any case, unless tracking gets super easy, with digital receipts saved directly onto our mobile devices and standardized for processing, I just couldn’t be bothered to break down paper receipts.
That BTW makes me wonder why have we not seen e-receipts standardized yet. We can pay wirelessly with devices, so why not save some more meta data about the transaction, including the receipt itself? Seems like a low hanging fruit, also saving tons of paper.
A lot of banking apps these days will automatically categorize your spending as well which eliminated much of the need to manually enter it in to a different app.
Deleted Comment
If you plan ahead you know how much money you actually have and can plan better.
I find I save way more with a proper budget in place.
In terms of the detail, I used to do very detailed breakdowns of categories, but now I don't really see the point: my app supports 'split transactions' (one of the reasons I actually made it, as existing solutions had poor support for them back in 2009), and I generally just use things like 'Food', 'Drinks', 'Essentials' as categories, as it never really made sense (at least for me) to detail them with such accuracy.
But for things like 'coffee', I do 'Drinks:Coffee', so I can see how much I am spending on fairly specific things, but I guess it's a balance in terms of whether it's worth the effort to record them so accurately compared to making use of the details.
Similarly, things like 'Car:Fuel', 'Car:Service', etc...
For fraud, I think it's basically a matter of whether we can recognize each transaction. You don't actually need to download transactions for that; you can just skim your monthly statements.
For saving, that's tricky because there needs to be that recognition of what categories are likely to increase during retirement versus decrease. I gave that a single pass a while back, and now I have a count each month of those expense categories that will continue into retirement, along with a 12-month average, so I can get a sense of what my portfolio needs to be able to fund after I retire. For that, even though I have Banktivity, I also have to use a spreadsheet.
For taxes, I don't know if anything really makes that easy. It's hard to know what category breakdown you really need to know whether you're capturing all your tax benefit, and my financial software doesn't tell me "oh, by the way, you'll want to split that transaction since some of it has a tax benefit."
I ended up making my own app https://github.com/VMelnalksnis/Gnomeshade. I also felt similarly regarding accounts, so I split transactions into two parts - transfers and purchases. That allows to handle multiple currencies, and handle categorization separately from accounts. I haven't looked into suggestions like you mentioned, I went with trying to parse receipts for my most common purchases.
I couldn't quite understand what you need, but I use KMyMoney (migrated from GnuCash over a decade ago). If you've gone to Walmart and itemized in the past, then the next time you go to Walmart and import your CC statement, it will pick the last Walmart transaction with a similar total charge as your starting point. It's mildly helpful.
And yes, it does do Categories instead of Accounts. The latter, however, is more in line with accounting principles.
It would be nice if there was a QRcode format on receipts for this. Off the top of my head, the encoded format would have:
* store name/location
* total amount
* field for tax(es) broken out
* a general category of the purchase if it's simple ("fuel", "food" for receipt from McDonald's)
* groupings of items for certain types/categories: at (e.g.) Costco you can buy groceries and clothing, so have a grouping for all your food with the total for that categorized as "food", clothes grouped together with its category; you can also get gas and tire/oil changes ("transportation")
The major categories could be what a lot of countries use for CPI categories:
* https://www150.statcan.gc.ca/n1/pub/71-607-x/2018016/cpi-ipc...
* https://www.bls.gov/news.release/cpi.t01.htm
* https://www.stat.go.jp/english/data/cpi/158c.html
* https://www.ecb.europa.eu/stats/macroeconomic_and_sectoral/h...
Not something I've looked at and specific to Lidl but if you shop there regularly it might be worth trying.
You might be able to use one of the open weight models instead. (Maybe one of the apache 2.0 qwen’s?) Scan a batch, then hand check the results in fifo order. That way you can probably get away with a local gpu.
The hard part will be getting structured output that gnucash likes. I’d try a simple json schema (stick the schema and some example input/output in the context), and then write some code to convert it to a format gnu cash can import.
Due to a colossal screw up my bank had after I moved back to my home country, it took me several months to get a new debit card. So I got used to just taking out X cash per month, and dividing it.
I’ve tried a few financial tracking things since getting back on the card wagon, and found none of them actually have the same result (spending less) as just dividing cash into physical buckets.
A given item and a given transaction could have any number of different properties, and no single heirachical category can express the reality.
Is it a work expense or is paid through paypal or is it a subscription or is it from amazon or is it food? A single item could be all of those at once, and sometimes when you want to know "all food" you want to include that regardless what it's other properties are.
IE, pork doesn't really have to be under some heirarchy like meat. It is both pork and meat, and it also may be art supplies or photographic subject etc.
But GNUCash existed when I first got a job decades ago.
GNUCash exists today.
I don't think any other package really matches the endurance.
It is absolutely frustrating because it has that mid 90s utility design.
I don't think I have seen any other utility hasnt really progressed on interface design like GNUcash. Like they built a prototype went "Nailed it!" And then moved onto back end stuff while ignoring all input from users.
Make it work well and then stop fiddling with it.
This is hugely valuable. I've been using gnucash since the late 90s, and have the all data files going back to 2000.
As for myself, I agree that the XML format is not great, but I use the SQLite format, which allows me to write scripts on it.
If nothing else works, a Gnucash file is XML. A bit annoying to work with, but quite possible.
[0] based on https://gist.github.com/nonducor/ddc97e787810d52d067206a592a...
Whenever I have to edit an xml file I tend to just go ham with python's xml library. the scripts are never pretty, mainly because they are whatever addhoc editing I wanted in written form. The hardest part is figuring out the xpath syntax.
A slight lie, I use lxml, mainly because it can select siblings which the built in xml lib is unable to do. but I still use the internal libs documentation, mainly because it is easier to read.
It's good software! I eventually wrote code that dynamically links with the libgnucash library so I can auto-generate monthly invoices for the member's dues.
It's kinda a mess tbh, and it actually also requires some non-exposed symbols to work properly, so it needs access to the GnuCash source code. I wouldn't recommend doing this unless you're ok with maintaining your own unsupported GnuCash feature.
The deal breaker for me was the underlying XML or SQLite formats of GnuCash. These are not terribly amenable to scripting, either for ingesting raw data or reporting. Whereas this is basically the point of plain-text tools like Beancount or HLedger. GnuCash feels too much like a walled-garden compared to plain-text tools.
The plain-text format requires more work at first, but after you get the hang of it (and provided you have some background in scripting software) it is awesome.
Databases on the other hand are built for this. After years of dissatisfaction with plain text accounting and many hours spent trying to improve it, I now use SQLite and it has been an enormous improvement.
For me, I found that the SQLite models of GnuCash aren't straightforward to query. That's why Beancount created its own query language. Martin Blais has a good discussion of why a traditional database doesn't quite fit for many accounting purposes https://beancount.github.io/docs/beancount_query_language.ht...
Plaintext is nice for git but I only feel that when fixup-ing a single or small number of transactions. It does feel nice to be have all the details of a transaction in one place in a visually useful way. For one-off hacking and such it definitely feels easier to write O(n^4) python looping over trying to describe things with SQL and working at a scale where it doesn’t matter.
Plaintext as a UI into a SQL store seems an interesting project. I would love a git integration for committing changes after diff review and being able to stage individual txns or parts. Many years ago I was frustrated with ledger’s more loosey goosey syntax and trying these things and eventually gave up whatever the idea was at the time. I like the idea of a constant bidrectional sql<->plaintext that provides a requirement for reproducible parsing and serializing
> parsing it in a structured way is a nightmare
Ah, well that’s the job of the PTA app - converting “just text” to something very structured and validated. Which can then be moved into SQLite, if one likes.
> and scripting edits to plain text is a mess.
I suppose it depends. There are a lot of very powerful and quick tools and techniques for automated or assisted text munging.
That gives me the benefits of Fava and all the other PTA tools as well.
... if SQLite isn't sufficient it also supports SQL backends? I've been running it that way for like a decade.
It's not tailored for our economy and our revenue services.
Here in Sweden if your revenue is below 3 million SEK/year, then you can use "simplified bookkeeping" (rough translation of "förenklat årsbokslut").
In practice it means I could write a very basic program to manage my expenses and income and just have it generate all the necessary numbers that I then enter manually into our revenue service's online app every year.
For simplified bookkeeping GnuCash, and most generalized bookkeeping programs, is overkill.
I accomplish the same thing with 250 lines of Python, and the result is that I get exactly the numbers I need to enter into Skatteverkets e-tjänst, and nothing else. And each transaction is one yaml file, and stored off-site with git.