Hacker News new | past | comments | ask | show | jobs | submit login
GnuCash 5.9 (gnucash.org)
281 points by moasda 72 days ago | hide | past | favorite | 173 comments



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


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/


sqlite is stable for GnuCash, I moved from xml to sqlite a few years ago. No issues.


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?

[0] https://www.codat.io/wp-content/uploads/2021/02/Codat_Global...


Come on, of course Hacker News is a local Bay Area forum, nothing happens beyond Bay Area ever. /s

And even this post only lists English-speaking countries, as the Babylonian barrier is impenetrable. Who knows what happens in these strange places where people communicate in unknowable sigils?


Ah, I live in one of those impenetrable realms, and have made some progress deciphering their arcane glyphs. I can tell you that here in Viet Nam, accounting is almost entirely done in spreadsheets. I've mostly seen similar in nearby countries.

Also your accountant will universally have a bizarre custom font for Vietnamese characters, that they downloaded ten years ago from a now-defunct forum. It will never correctly transcribe into any other font, and they don't know how to change it. If I switch accountants, it's always a different cursed font. This is a great and enduring mystery.

So I keep a second set of books -- GnuCash is fantastic for this, but I've also used QuickBooks sometimes. Then I use that to make sure the accountant is producing something that at is at least adjacent to reality. I'm audited by law every year (at my own expense), and they only support spreadsheets.

Surely one day soon this will change (except the font thing I bet), but for now I thought you might get a laugh out of this little slice of my life :)


India had / has a bunch of indie vendors of small financial accounting packages (that's what it is called here), some years back and for quite a while before that. When a new Indian software product company starts up, this is often the field they enter first, partly because the domain knowledge is widely available via chartered accountants and is fairly standardized, I think. Not an expert in the field myself.

I don't know how many there are nowadays, but my guess is that they must be at least a few of them, still, if not many.

Tally was one of the more successful ones and is still around. I heard someone talk about it the other day.

I am talking about the small businesses sector.

Larger companies tend to use ERPs, either commercial or home-grown. There are even some indie vendors in this sector.


> When a new Indian software product company starts up, this is often the field they enter first

This doesn't ring true to me. It's almost impossible for a new accounting suite to find traction because Tally is the defacto standard. The only successful newcomer I can think of is Zoho.


Maybe I was thinking about the situation of some years ago.

I've heard Zoho is successful, though.


> Your bank will hate you

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.


> US banking is a shitshow which is decades European banking, addressing that would benefit everyone.

The problem that I (and many business owners) are solving for right now is not one of federal policy, but rather an economic one: I like to have food on the table to eat. I care very little about whether or not I'm doing that in a way that satisfies open source zealots.

If there's an open source option that lets me do what I need to do in an equal or better way, then sure: happy to go that route. But I'm not doing something in a clunky, nonstandard way just for the lulz.


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.


> ERPNext is not perfect, but works quite well

This. ERPNext can be quirky and annoying at times. But it is still better than dealing with the ever-changing quriks and annoyances of an online suite that you have not control over.


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 would like to learn more about this. Why is it that those things won't work with GnuCash?

A lot of other people seem interested, if you have a blog this would be a great post.


The situation seems quite dire.


>The world has chosen QuickBooks. This choice was made under duress and with corrupt power brokering.

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.


We're aligned, you didn't get the sarcasm. :)


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?


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.


You can do a lot with specific and very little with generic entries.

In NL we got the banks to allow exporting [YOUR] data kicking and screaming. Nothing real time sadly but at least it's a thing now.

I would like to force merchants to do the same.

Enforce some protocol that doesn't suck and it should take 0 seconds.

Imagine the things we could build and how many people we could fire.


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.


You don’t need that level of accuracy, you just need “close enough”. Split things out that are important, but if you’re trying to get the sales tax calculated to the cent you’re going way past a level of utility that matters. Eyeball it and move on.


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 agree. I've also been tracking my family's personal finances for about that long.

You have to ask yourself what you're going to do with the data. Don't just collect data for data's sake.

The most granular I've ever needed is things like: "wow, I've spent way too much on hobbies in the past 3 months" or "we've spent way too much eating out this month" or "the kid's sports are getting out of hand". Or even "we can afford to spend a lot more on vacations over the rest of the year".

Those are all very top level categories. I can't imagine a world where I'd ever make a lifestyle change based on how I spend on meat over the past six months.

And if you're not actually making a change then the data is just data hoarding.


Yup. Although even if you’re not making any changes based on your habits, it’s still helpful to track money spent to know where your money actually is, especially the liabilities. Except you don’t even need to track expenses at all, outside of the generic “Expenses” category.


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.


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.


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'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.


This is true but unless you have a motivation, i.e. somewhere else that money could rather be going that's somewhat immediate, you're kind of wasting your time (IMO).

If you want a vacation and couldn't afford it or you wanted some cool home gadget and couldn't afford it then sure, delve into your finances. But if that money you're saving is just going to sit around then what's the point? If you already have a rainy day and a 401K or equivalent, then you're good. Ultimately money is worthless if you don't use it.

The reason I say this is because tracking money is not free. It's a mental burden. Do you really want that to be your business? How much mental energy are you willing to give it?

Because it sounds simple until you really want a coffee after work, but it turns out you don't have the budget and then you sit and cry in your car because that hypothetical coffee was the one thing tying you to reality.


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.


> 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.


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.


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.


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 haven't gotten a single bill over SMS, is this an US thing?


They don't send a bill over sms, but a transaction acknowledgement indicating total amount over sms.


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.

Make it work well and then stop fiddling with it.


There is a middleground. Of course, change for the sake of change sucks, you just have to relearn for no benefit.

But change for the sake of implementing m New features and having a well thought out redesign after collecting issues over a decade or so makes software more accessible and allows you to streamline workflows where new features just got tacked on over time.


> 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.


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 was going to say what GP said, but, yeah, XSLT is just no fun to write by comparison to SQL.


Hardly anybody was using XSLT even when XML was all the rage. Python scripts work just fine.


XSLT 1 was very limited. XSLT 2 was too late. That's my take. I actually like XSLT 2, but it's so verbose... -- it's horrible.

Once in a while I dream of adding proper XML support to jq just to be able to use jq as a pithy alternative to XSLT.


XQuery is easier and can be fun to use!


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.



The other person said GnuCash has a scripting engine. These are just scripts. Not the same thing.


These are examine scripts for a REST API that gives access to internals of GnuCash.


Oh ok. I will have a look, thank you!

Does it allow setting values, or just reading?



It's one piece in one of the puzzles, but it's not really what I'm looking for.


Internally, it uses Guile. I'm afraid there might not be a good user interface to edit the Guile source files, but at least Guile is much more pleasant to work with than C and offers way less paper cuts. I think it's mostly used for reports. You might have to create a plugin to expose your own scripts in the UI.


I feel like it could do with some tutorials and guides on Guile. I would have liked to be able to do reporting and invoicing with more control through scripts, but last time I looked at it I just gave up due to lack of docs.


Yeah, at some point I got the impression that I could use Guile to extend it, but then couldn't find any way to do it as an end user. Not sure if I was just wrong, or out of date.


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.


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.)

[0] based on https://gist.github.com/nonducor/ddc97e787810d52d067206a592a...


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.


I like that I can version control the GNUCash XML file, and edit it by hand when needed while still having a GUI for entry.


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.


Cool, thanks for sharing, but is there no better way to automate GnuCash, eg with a Bash or Python script?


Interesting, can you share the code?


Sure: https://github.com/blackle/GnuCashAutoInvoice/tree/main

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.


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.


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.


Beancount + Fava looks like a pretty slick combo. Can anyone describe experience with it ?


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.


>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.


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.


Double entry bookkeeping is the gold standard in finance bookkeeping since the romans. It is not overkill, because once mastered it is very easy to handle especially with a program that implements the logic like GnuCash. The problem for novices is usually to understand the logic: https://gnucash-docs-rst.readthedocs.io/en/latest/guide/C/ch...


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.


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. :)


It might be easier to use, but it's not a simpler technology.


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.


Arguably, XML’s schemas are better than SQLite’s constraints, especially in this domain.


Yeah I get that SQLite technically has weak schema constraints, but it's rarely a problem in practice. I'm far more concerned about messing up with the filesystem and losing data.


[flagged]


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.


I bed that's true. And that's nothing to do with which is more complex. I'm not saying SQLite is more difficult to use, I'm saying it's more complex. You're confusing the two.


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.


I agree, I think this is what people miss when it comes to machine processing versus human processing.

Human processing benefits from pretty colors and organization. Machine processing is almost the exact opposite, it benefits from data definition and strong guarantees around invariants.

A graph is often the best way for a human to process something. But it's awful for a computer - computers can't see! At least not easily.

A nice in-between is something like XML. But if it's primarily gonna be interacted with by a computer, might as well make it a database.


Being familiar != simple.

Sure, more people have used SQL, but it’s definitely not impossible to just query XMLs. Hell, if someone has written JS they are likely familiar with DOM manipulations, which are more or less the same.


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.


Yes, I know what to do. Doesn't change the fact it's more complex.

In fact, any database is more complex than a text file.

You sound like the kind of person to push at work for a database when a file would suffice, introducing needless complexity.


> You sound like the kind of person to push at work for a database when a file would suffice, introducing needless complexity

Simplicity versus complexity is not a linear scale like you describe.

Complex tools can lead to simpler implementations. This is the key people are missing.

For example, C++ is much more complex than C. Okay, now build a generic sequential data structure. It's a quarter the LOC in C++ versus C, and it's a much simpler implementation. Because C lacks the tools, so we have to use macros or maybe void pointers.

In this case, imagine you need to aggregate lots of data from different places, eliminate some of it, collapse some of it etc. For a reporting type thing.

Well, SQLite is more complex than XML. But doing this in SQL is much less complex, because XML lacks the tools. SQL is built for this, so you can do it in a quarter the amount of code, or maybe even less.


> In fact, any database is more complex than a text file.

This statement is true, at a very superficial level. But it is missing all the nunace that goes into why would someone be using this file.

Are you comparing opening a text file in a text editor vs. opening the db.sqlite file in a text editor? Yes, of course the text file is more usable.

But what is the use case of just staring at the file? I can't imagine any.

If you are someone who wants to programmatically use the contents of that file (outside gnucash application), surely you are writing code to process the data. And thus, being able to use SQL is massively more convenient.


GnuCash is really nice, and eventually it would have been my end game, but at some point numbers didn’t end up.

Everything was recorded correctly, but reports would show wrong numbers.

After migrating from GnuCash to beancount, I realized that some transactions where recorded with invalid currency conversion rates.

As someone who relocated recently, manage money in at least 3 currencies, and have an online business, I can’t handle it. I need everything to be explicit in order to avoid mistakes.


plaintextaccounting to the rescue


I kind of surprised to see lots of hatered to GnuCash. What are your usecases? I run cafe business in Japan, but it does everything I need.


Don't you have to buy some Japan specific software like Freee for the e-Tax integration?

I like GnuCash, but for a business, it doesn't automatically handle sales/consumption tax, or employee payroll withholdings, you'd have to manually make splits in every transaction for that.

(Actually I think you all don't have to keep your consumption tax received in a separate account bc you net it out against purchases, but in the US we have to journal the tax into sales tax payable liabilities account, not revenue).


Can't speak of Japan, but where I've lived the percentage of tax is calculated against total sales, you don't need it separated beforehand

I believe there are some exceptions, with regulated or specially taxed goods like cigarettes, but there was none of those where I worked so it's mostly speculation


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.


Right! And this isnt a difficult feature to implement either. You just need that A) every transaction, or better every leg of a transaction, supports tag, and B) the reports break down by tag.


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


Do you have any tips on where to start?


It was several years ago I’ve read it, but GNUCash’s documentation does actually start with some generic accounting knowledge, which I have found quite useful at the time.


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.


I’ve still yet to find anything that matched the usefulness and straightforwardness of Microsoft Money.


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.


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.


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 concur, KDE applications tend to be more traditional. I don't mean necessarily in style, I think they can look quite good, but rather in form. Personally, I think Desktop software UX peaked maybe 10 years ago so to me this is a good thing. Assuming a typical experience of mouse, full-size keyboard, and monitor. Things do change UX wise when you switch to a laptop IMO.


How come no one mentioned ERPNext. It's open source, can be self hosted, free and biggest growing software in the market. It also scores high on user recommendations. I switched from GnuCash to ERPNext and it has been a blessing.


Can confirm. It's excellent software, though getting going on your own server is not as smooth as, say, gitlab-ce.


ERPNext is whole different project and its accountability functionality aren't even comparable to GnuCash.


I've been using GnuCash for a few years now and it's been good. I was looking at other options, but every time I try to book Cryptocurrencies I turn around to GNUCash. Is there another option? Most recently I've tried Odoo (stems out of OpenERP (prev. TinyERP)) which I like because it's python based, has a web interface and runs on docker.


I wonder does anybody use GnuCash for s.r.o. (LLC/ Ltd.) business in Czechia? How is your experience with it, e.g. do you also do DPH (VAT)?


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 ;)


To be fair it's a desktop-only application. Even if you did read it on mobile you'd have to move to a full fat computer to download it, anyway. Yeah conversions and stuff matter.


I don't know what you mean by "responsiveness". Html/Css/Javascript is dogshit when it comes to latency. I assume you're talking about fluid layouts, which can be accomplished just as well with native GUI libraries like Qt. Note that Qt runs like a champ in embedded devices; I don't think it can possibly get more responsive than that.

> and this site seems to disrespect user expectations about layout, menus, and interactable elements, from a glance.

Why does this matter? GNUCash is a desktop application. The website is not all that relevant. And I have a different opinion about expectations anyway. The website is functional and easy to navigate, unlike the column-style, white space wasteland that "mobile-friendly" websites typically are.


How is gnucash?

I've been looking for a less data intrusive budgeting app. The other I saw was Firefly III.


Time to read the release notes and see if it fixes the stock price fetching at all.


I've used Gnucash for my personal finances for 15-20 years, except for some periods (e.g. a few years where I was unemployed and depressed). It gives me great control of every cent, I know exactly what I've spent where, and I even use it to plan ahead.

I use scheduled transactions for all my fixed expenses, and Gnucash enters them 100 days in advance. I manually enter my income, usually also 3 months in advance. My income is very predictable, but can of course vary a little. I then plan out how much to transfer on payday to my debit card account, my bills account, my savings account, etc. I enter any "random" bills (variable or unexpected expenses) as they show up. This allows me to see, in Gnucash, quite exactly how much money I'll have available at any point in time the next 2-3 months.

I keep every receipt for things I buy during the week, and every Sunday I have a routine. It's become a bit overkill, but I enjoy it. First I scan the receipts with a scanner app on my phone. Then I sync the scans to my computer using Syncthing. Then I enter each transaction and link it to the scanned receipt. My hierarchy of expense accounts are reasonably detailed, I'd say.

I've gone so far as to program useful shortcuts into a numpad, to make this process even easier. So for example, instead of Ctrl-A or whatever is the default for linking a transaction to a file in Gnucash, I have one convenient button on the numpad. Other buttons select different transaction views. For a while I even had a setup where I could RDP to a docker container with Gnucash, so I could use it while at the office. For this I'd also use Syncthing to sync my gnucash data between my desktop and the container.

Is it overkill to scan every grocery receipt and whatnot? Yes. Do I need all this historical data? No, not really. But it's somewhat interesting to scroll 3 years back and look at some random dates to see what I bought and what prices were like. It's also useful for tax purposes. And I'm a bit of a data hoarder ;) (I should add that I don't always keep the receipt - I often pay with Google pay and then if it's just food or coffee or something simple like that I just keep the notification until I can enter the transaction in Gnucash.)

The biggest thing this setup gives me is great peace of mind. I've struggled with anxiety and depression, and I've lived through times where I've had credit card debt and very little income, so money has been a big stressor at times. Now I have a reasonably well paid job in IT and no debt except student loan, so I could probably live well without Gnucash, but it's still a source of mental well-being, even comfort. I enjoy my weekly routine and micro-managing my money. Sometimes I just open Gnucash to look at how well I'm doing financially (not wealthy by any means, but my net worth is at least in the positive). Gnucash was also great for planning how to pay off my credit cards.


> I enter each transaction and link it to the scanned receipt

How do you link transactions to receipts? The one that's on right-click and "Update Association"? When I tried that, I found it way too cumbersome, I feel like I should be able to just drag-and-drop a file onto a transaction. (I know I can set up keyboard shortcuts to open the dialog, but drag-drop would be so much simpler.)

In an ideal world, when drag-and-dropping a file onto a blank line, gnucash would run tesseract or something and extract the date, amount and summary ... one can dream.


For personal accounting, MoneyManagerEx has a much simpler UI than GnuCash.


No double-book accounting thus toy and not worth consideration.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: