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.
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.
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.
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.
There are many levels in between tracking at the "Amazon" level vs the "Meat:Pork" level. For example I currently track all unprepared food shopping as "Groceries", and would break down "Amazon" shopping into categories such as "Electronics" or "Books".
Ultimately it comes down to how much effort you want to spend categorising spending, but there are many levels of granularity and orthogonal dimensions to slice against
Sure, and my Amazon example wasn't very illustrative of the kind of information that could be gleamed from tracking this at a more granular level. A more concrete example is that my wife and I were flirting with the idea of reducing our meat consumption (for non-financial reasons) and wanted to see what the financial implications would be. Another example is to try to accurately price out past trips we went on: some things normally get filtered under other categories, such as clothes or other products purchased specifically for the trip.
This level of granularity probably isn't worth it to most people, but I found it useful as an exercise to do once because it opened my eyes to insights about my expenses I never would have thought about otherwise. And if there were software that made this super easy to do (<1 minute per entry), I might still be doing it.
Some stores are modern-day general stores (Costco, Walmart) so you will end up purchasing from several categories on one trip (gift, groceries, home maintenance). YNAB, for example, allows for splitting a single transaction across several categories but you have to figure out what the cost of that individual item was.
It’s annoying to do in Canada where sales tax is not included. The fly in the ointment is that certain categories are tax-exempt (essential foods, kids’ clothing) but not others (prepackaged foods, adult clothing).
If your shopping trip is across three or more categories (gifts, clothing, food), you’ll have to figure out which items were tax-exempt before you can do any subdivision.
1. Amazon shopping. You can buy anything for your life in one place, and the credit card receipt just says, Amazon. Thats too broad a bucket to really track where your money is going. I like to understand, for example, what I am spending on consumables for house upkeep, like light bulbs and air filters, separately from things like bike accessories.
2. Splitting out alcohol and other highly discretionary purchases from grocery shopping. Lets say I want to budget for alcohol spend as a way of gently trimming back my consumption. Or chocolate, candy, etc. Would be nice to be able to do this quickly. The ideal would be to simply scan the supermarket receipt and let OCR figure it out for the majority case (aka the 2 or 3 stores I shop at every week).
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.
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.
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.
Not normally, no. But we track things like cleaners vs food.
I budget very high level but when my wife did her own before we were married she prefered fine grain control. I think it's more of a personality thing.
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."
In the early period after moving to the USA, for a few years I was tracking money in and out in great detail. Including splitting checks from stores. And while I did not set explicit budget, I believe it allowed me to keep our finances healthy. And it certainly decreased money-related anxieties, giving me sense of control.
I stopped doing it after a few years, after I felt pretty secure financially. And that certainly coincided with more spending on things that I would otherwise not spend on...
Your grandparents tracked money because they were also verifying the math, which could have done by hand. Now, we assume the math is right, and we're checking for fraud.
Oh come on... there's lots of reasons. Understanding where the money goes. How much are you spending on dining out each month? How much does your car cost when you add it all up at the end of the year? It's easy to fool ourselves when it goes out $10 - $20 at a time.
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 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.
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.
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.
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.
Can you share a link to the docs for the scripting engine? I've seen conflicting information over the years and I'm not sure what the latest really is.
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.
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 :)
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.
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.
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...
I used GnuCash for a while, but I ended up spending too much time making the online sync settings work. For accounts where I had to manually download and import, I would end up putting off importing them due to the friction. I now pay for Quicken Classic and it's some of the best money I spend each year. The online account connections consistently work as expected, and it gets the job done for much less of a headache overall.
I have to care about accounts in the US, Canada (likely soon to vanish from my list), EU (two countries), and Mexico. I would love to have an option to pay for like Quicken Classic with all the banking connections reliably working, but I don’t think there is a single one that even covers the US and any of the major EU economies, let alone everywhere I care about. Quicken Classic is US and Canada only.
Do you know of such an option, or even multiple options that can be sensibly used together to achieve this?
At this point, given how many “access your transaction data” companies choose not to cross the US-EU bridge in a way that’s viable for direct personal use, I have to think there’s some reason around incompatible bureaucracy or similar. Or maybe not enough people have international enough lives to want it.
Ran a business with it, payroll, administered the 401k accounts, etc. Solid. Expense tracking good enough for a business with limited expenses, or background as a bookkeeper (my teenage job). But being able to generate balance sheet and profit&loss reports for my accountant, golden.
Love Gnucash... allows me to look at my expense history for more than a decade.
I think it would benefit from some changes in the next major version though - the GL of account is good but requires a lot of work for example to track vendors. If I want to track where I'm buying my groceries I have to create separate account for those, rather than being able to optionally specify vendor.
I tried to get into it several times but eventually came to the conclusion that it is, despite the unassuming name and the advertisement as a tool for personal finances probably more targeted at professional accountants or people who have some training in accounting, rather than just being a tool for tracking private finances in an intuitive way.
I don’t disagree with you, but I’d suggest that the accounting knowledge is pretty easy to pick up, and getting that under your belt will actually be incredibly valuable
Getting OT here, but I've tended to prefer Gnome apps with a KDE desktop. The latest UI pessimizations in Gnome may having me switch completely away from Gnome, with the "You must click on sub menus to open them" being the final straw.
GnuCash is solid. One thing that I love: I have full control over my data, and its stored as a simple xml (also supports SQLite, but why use more complex when simpler works just as well?)
I have a few (comparatively minor) complaints about GnuCash, but they're around UI. Things like: it would be nice to assign all matching (eg Regen) transactions to a selected account, and stuff like that.
But overall, having something that is A) simple and B) I control fully, beats everything else.
I agree with bdjsiqoocwk that XML is way simpler than SQLite. In the case where I'm making changes by hand, it's much easier to open an XML file in a text editor and edit it, than it is to figure out an SQL query to do the same thing. In the case where I'm making changes programmatically, libraries will handle the complexity of XML for me, but I will still have to struggle through figuring out an SQL query if I'm trying to connect to SQLite.
SQLite is easier if you're comfortable with SQL to the extent that it's little to no effort for you to write queries. But most people aren't that comfortable, and XML offers them significant advantages. I certainly prefer XML at any rate.
I bet if we do a random poll of the people here, more people would be comfortable writing a SQL query then doing xpath processing to query the same data.
Far too often I've ended up with corrupt SQLite db files. At times it wasn't discovered until much later (i.e. most queries would still work). Very hard to fix (in fact, I never did fix any).
With XML, under version control, you can identify easily what went wrong.
It is not weird at all if you think of it from an implementation perspective: it is much easier and simpler to write an XML parser than it is to write a loader for SQLite databases, even if you do not write an SQL parser for it.
After all there are way more independent XML parsers implemented in a variety of programming languages than there are SQLite implementations :-P.
If you intend to read it by human eyes, you're right.
That seems like a rare edge case though. If you want to interact with the data outside of the software, the common case is you're writing some script for that, in which case being able to use SQL is much easier.
Suppose you don't have SQLite, how do you open a SQLite database? The only way is you have to re-implement SQLite from scratch. Good luck with that.
Now imagine you don't have vim, how do you open an XML file? You can use any of other thousands of text editors out there, or any of tens of libs in tens of different languages.
I think your take that sqlite is simpler than a text file is the weird one.
> Suppose you don't have SQLite, how do you open a SQLite database? The only way is you have to re-implement SQLite from scratch. Good luck with that.
Or, you know, install SQLite. Although it is so ubiquitous that it is almost certainly installed already. Even on a mac it's there already. Or if you are on some system where it is not, a single package install away.
XML is human readable, but barely. I do not trust any executable other than SQLite, postgres and a few others to correctly manage state on disk without corrupting it.
Second that. Microsoft Money was _amazingly_ practical and useful - head and shoulders above Quicken. It is a real shame, Microsoft didn't find a better solution than to sunset it.
This is the only reason I have any experience with these apps. When MS sunset Money and compatibility started to get wonky, my in-laws were at a loss at what to do. We never did find an alternative. They do however have a seperate Win 7 PC just for Money, which at there age isnt a huge problem but for others that is not viable long term.
I know the aesthetic is part of the “simple” appeal, but it’s just inexcusable to not have a responsive (aka “mobile friendly”) site in 2024. It’s also a great example of why I don’t trust hand-rolled guis like this, if I can avoid it: the standards are standard for a reason.
Well, the applicable standard in this case would be “Web Development” writ large. Responsiveness is a start, but consistency is one of the most important design principles, and this site seems to disrespect user expectations about layout, menus, and interactable elements, from a glance.
Responsiveness in particular is “inexcusable” to miss because it’s so easy that it’s practically boilerplate these days, and the lack makes it impossible to read on mobile. Will I be convinced by this update to try GnuCash? We’ll never know, because I can’t read the changelog!
I know I’m a zoomer, but zoomers have money too! A little. Sometimes. And for what it’s worth: I’m pretty sure this is an accounting app, not a finance app ;)
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.
Cheers
Yet another instance of free software succeding for its free as in free beer qualities
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.
Maybe, I don't find it yet? Any suggestions?
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.
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.
There are many levels in between tracking at the "Amazon" level vs the "Meat:Pork" level. For example I currently track all unprepared food shopping as "Groceries", and would break down "Amazon" shopping into categories such as "Electronics" or "Books".
Ultimately it comes down to how much effort you want to spend categorising spending, but there are many levels of granularity and orthogonal dimensions to slice against
Sure, and my Amazon example wasn't very illustrative of the kind of information that could be gleamed from tracking this at a more granular level. A more concrete example is that my wife and I were flirting with the idea of reducing our meat consumption (for non-financial reasons) and wanted to see what the financial implications would be. Another example is to try to accurately price out past trips we went on: some things normally get filtered under other categories, such as clothes or other products purchased specifically for the trip.
This level of granularity probably isn't worth it to most people, but I found it useful as an exercise to do once because it opened my eyes to insights about my expenses I never would have thought about otherwise. And if there were software that made this super easy to do (<1 minute per entry), I might still be doing it.
Some stores are modern-day general stores (Costco, Walmart) so you will end up purchasing from several categories on one trip (gift, groceries, home maintenance). YNAB, for example, allows for splitting a single transaction across several categories but you have to figure out what the cost of that individual item was.
It’s annoying to do in Canada where sales tax is not included. The fly in the ointment is that certain categories are tax-exempt (essential foods, kids’ clothing) but not others (prepackaged foods, adult clothing).
If your shopping trip is across three or more categories (gifts, clothing, food), you’ll have to figure out which items were tax-exempt before you can do any subdivision.
The sweetspot is to group by providers. Unless you have a huge all in one provider, you'll have enough granularity.
Here are two examples:
1. Amazon shopping. You can buy anything for your life in one place, and the credit card receipt just says, Amazon. Thats too broad a bucket to really track where your money is going. I like to understand, for example, what I am spending on consumables for house upkeep, like light bulbs and air filters, separately from things like bike accessories.
2. Splitting out alcohol and other highly discretionary purchases from grocery shopping. Lets say I want to budget for alcohol spend as a way of gently trimming back my consumption. Or chocolate, candy, etc. Would be nice to be able to do this quickly. The ideal would be to simply scan the supermarket receipt and let OCR figure it out for the majority case (aka the 2 or 3 stores I shop at every week).
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.
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.
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.
Just tracking no but allocating yes.
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.
A proper budget does not require you to drill down to the level of tracking specific food groups.
Not normally, no. But we track things like cleaners vs food.
I budget very high level but when my wife did her own before we were married she prefered fine grain control. I think it's more of a personality thing.
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."
In the early period after moving to the USA, for a few years I was tracking money in and out in great detail. Including splitting checks from stores. And while I did not set explicit budget, I believe it allowed me to keep our finances healthy. And it certainly decreased money-related anxieties, giving me sense of control.
I stopped doing it after a few years, after I felt pretty secure financially. And that certainly coincided with more spending on things that I would otherwise not spend on...
Your grandparents tracked money because they were also verifying the math, which could have done by hand. Now, we assume the math is right, and we're checking for fraud.
That, and we like to watch a number go up.
Oh come on... there's lots of reasons. Understanding where the money goes. How much are you spending on dining out each month? How much does your car cost when you add it all up at the end of the year? It's easy to fool ourselves when it goes out $10 - $20 at a time.
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 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.
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.
For this I recommend https://actualbudget.com/ . It is in many ways like You Need A Budget but you can host it yourself for free.
https://actualbudget.org/ is the open source site.
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.
> Maybe, I don't find it yet? Any suggestions?
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...
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.
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.
> I don't think any other package really matches the endurance.
This is hugely valuable. I've been using gnucash since the late 90s, and have the all data files going back to 2000.
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.
Make it work well and then stop fiddling with it.
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.
This is absolutely a valid reason to not use GnuCash.
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.
You can write scripts to transform XML documents as well.
True, but I don't want to. And that is the biggest barrier of all.
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.
Can you share a link to the docs for the scripting engine? I've seen conflicting information over the years and I'm not sure what the latest really is.
Does this help? https://github.com/Gnucash/gnucash/tree/stable/bindings/pyth...
And since the CSV importer is terrible there are always a lot of edits to do unfortunately.
Exactly. I can try out stupid stuff, but because it's all text files and no magic, reverting back is as easy as it gets.
It's xml right.
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.
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 :)
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.
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.
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...
I build my transaction list in Excel and then export that to .beancount with a very simple script. You could do the same with sql except even easier.
That gives me the benefits of Fava and all the other PTA tools as well.
>The deal breaker for me was the underlying XML or SQLite formats of GnuCash
... if SQLite isn't sufficient it also supports SQL backends? I've been running it that way for like a decade.
I used GnuCash for a while, but I ended up spending too much time making the online sync settings work. For accounts where I had to manually download and import, I would end up putting off importing them due to the friction. I now pay for Quicken Classic and it's some of the best money I spend each year. The online account connections consistently work as expected, and it gets the job done for much less of a headache overall.
I have to care about accounts in the US, Canada (likely soon to vanish from my list), EU (two countries), and Mexico. I would love to have an option to pay for like Quicken Classic with all the banking connections reliably working, but I don’t think there is a single one that even covers the US and any of the major EU economies, let alone everywhere I care about. Quicken Classic is US and Canada only.
Do you know of such an option, or even multiple options that can be sensibly used together to achieve this?
At this point, given how many “access your transaction data” companies choose not to cross the US-EU bridge in a way that’s viable for direct personal use, I have to think there’s some reason around incompatible bureaucracy or similar. Or maybe not enough people have international enough lives to want it.
Ran a business with it, payroll, administered the 401k accounts, etc. Solid. Expense tracking good enough for a business with limited expenses, or background as a bookkeeper (my teenage job). But being able to generate balance sheet and profit&loss reports for my accountant, golden.
Love Gnucash... allows me to look at my expense history for more than a decade.
I think it would benefit from some changes in the next major version though - the GL of account is good but requires a lot of work for example to track vendors. If I want to track where I'm buying my groceries I have to create separate account for those, rather than being able to optionally specify vendor.
I tried to get into it several times but eventually came to the conclusion that it is, despite the unassuming name and the advertisement as a tool for personal finances probably more targeted at professional accountants or people who have some training in accounting, rather than just being a tool for tracking private finances in an intuitive way.
I don’t disagree with you, but I’d suggest that the accounting knowledge is pretty easy to pick up, and getting that under your belt will actually be incredibly valuable
GnuCash and KDE Money always seemed very similar to me. Why should I use GnuCash over KDE money?
First thing to come to mind is if Gnome's your DE and you prefer more-native-feeling apps.
Vice-versa if you're using KDE instead.
Getting OT here, but I've tended to prefer Gnome apps with a KDE desktop. The latest UI pessimizations in Gnome may having me switch completely away from Gnome, with the "You must click on sub menus to open them" being the final straw.
I tried some time ago GnuCash after getting tired of plain text accounting.
I’m not sure what it was but I couldn’t get it working for me. Tried HomeBank afterwards and was blown away by how accessible it is in comparison.
I might give another try at GnuCash to track something like business/project expenses but it was rather hard to use for my personal finances.
Time to read the release notes and see if it fixes the stock price fetching at all.
How is gnucash?
I've been looking for a less data intrusive budgeting app. The other I saw was Firefly III.
GnuCash is solid. One thing that I love: I have full control over my data, and its stored as a simple xml (also supports SQLite, but why use more complex when simpler works just as well?)
I have a few (comparatively minor) complaints about GnuCash, but they're around UI. Things like: it would be nice to assign all matching (eg Regen) transactions to a selected account, and stuff like that.
But overall, having something that is A) simple and B) I control fully, beats everything else.
The principles of free software show, I guess.
I would argue xml is more complex, but to each his own. :)
XML is not simpler. You can just query a SQLite db with SQL.
What a weird take.
I agree with bdjsiqoocwk that XML is way simpler than SQLite. In the case where I'm making changes by hand, it's much easier to open an XML file in a text editor and edit it, than it is to figure out an SQL query to do the same thing. In the case where I'm making changes programmatically, libraries will handle the complexity of XML for me, but I will still have to struggle through figuring out an SQL query if I'm trying to connect to SQLite.
SQLite is easier if you're comfortable with SQL to the extent that it's little to no effort for you to write queries. But most people aren't that comfortable, and XML offers them significant advantages. I certainly prefer XML at any rate.
Disclaimer: no stats
I bet if we do a random poll of the people here, more people would be comfortable writing a SQL query then doing xpath processing to query the same data.
Far too often I've ended up with corrupt SQLite db files. At times it wasn't discovered until much later (i.e. most queries would still work). Very hard to fix (in fact, I never did fix any).
With XML, under version control, you can identify easily what went wrong.
It is not weird at all if you think of it from an implementation perspective: it is much easier and simpler to write an XML parser than it is to write a loader for SQLite databases, even if you do not write an SQL parser for it.
After all there are way more independent XML parsers implemented in a variety of programming languages than there are SQLite implementations :-P.
How is SQLite DB simpler than a human readable markup language?!
If you intend to read it by human eyes, you're right.
That seems like a rare edge case though. If you want to interact with the data outside of the software, the common case is you're writing some script for that, in which case being able to use SQL is much easier.
Suppose you don't have SQLite, how do you open a SQLite database? The only way is you have to re-implement SQLite from scratch. Good luck with that.
Now imagine you don't have vim, how do you open an XML file? You can use any of other thousands of text editors out there, or any of tens of libs in tens of different languages.
I think your take that sqlite is simpler than a text file is the weird one.
Hard mode: balance your register in XML, using ed
> Suppose you don't have SQLite, how do you open a SQLite database? The only way is you have to re-implement SQLite from scratch. Good luck with that.
Or, you know, install SQLite. Although it is so ubiquitous that it is almost certainly installed already. Even on a mac it's there already. Or if you are on some system where it is not, a single package install away.
XML is human readable, but barely. I do not trust any executable other than SQLite, postgres and a few others to correctly manage state on disk without corrupting it.
For personal accounting, MoneyManagerEx has a much simpler UI than GnuCash.
No double-book accounting thus toy and not worth consideration.
I’ve still yet to find anything that matched the usefulness and straightforwardness of Microsoft Money.
Second that. Microsoft Money was _amazingly_ practical and useful - head and shoulders above Quicken. It is a real shame, Microsoft didn't find a better solution than to sunset it.
This is the only reason I have any experience with these apps. When MS sunset Money and compatibility started to get wonky, my in-laws were at a loss at what to do. We never did find an alternative. They do however have a seperate Win 7 PC just for Money, which at there age isnt a huge problem but for others that is not viable long term.
Why not just setup a VM for Money specifically?
Because they had a spare M.
I know the aesthetic is part of the “simple” appeal, but it’s just inexcusable to not have a responsive (aka “mobile friendly”) site in 2024. It’s also a great example of why I don’t trust hand-rolled guis like this, if I can avoid it: the standards are standard for a reason.
Why is it inexcusable? And what standards?
This is for serious finance, not for swiping yolo stonks on Robin Hood.
Well, the applicable standard in this case would be “Web Development” writ large. Responsiveness is a start, but consistency is one of the most important design principles, and this site seems to disrespect user expectations about layout, menus, and interactable elements, from a glance.
Responsiveness in particular is “inexcusable” to miss because it’s so easy that it’s practically boilerplate these days, and the lack makes it impossible to read on mobile. Will I be convinced by this update to try GnuCash? We’ll never know, because I can’t read the changelog!
I know I’m a zoomer, but zoomers have money too! A little. Sometimes. And for what it’s worth: I’m pretty sure this is an accounting app, not a finance app ;)