Looks good but the real problem, as for 90% of similar programs, is the volume of necessary data-entry. Paid-for options like YNAB, nowadays, can fetch transactions from many mainstream US/EU banks and credit providers. Without that sort of feature, it's a real drudge to keep up entering every single expense.
I look at this from the opposite perspective. Seven years of YNAB4 trained me to include manual entry of every transaction, assigning categories, splitting it as necessary, etc right there at the moment I make the purchase. It's baked into my process, as that was one of the core components that the old YNAB taught. At this point I could never trust an automated system for everyday purchases, where it couldn't accurately know how to split transactions, or where to assign things (although scheduled bills I do input as recurring transactions so to an extent I do have some automation).
For example, take a trip to Walmart where you purchased things that cross like 3 or 4 categories. With a system relying on importing data from your bank, a couple days after the transaction posts you'll have this generic assignment to Walmart, and you must then try and remember how to split it (eg between Groceries, Clothes, Technology etc). Instead, I have my transaction manually sorted in my YNAB app before I've even left the store.
I thought this would be a problem for me and resisted using imports in YNAB... I changed to using it and I found I was more likely to actually keep on top of my budget knowing I didn't have to login to 2/3 different systems to start entering every transaction.
> For example, take a trip to Walmart where you purchased things that cross like 3 or 4 categories.
I'm still waiting for the next step in these apps, where I connect my account to Walmart/Amazon/Target/etc and it can do item/category breakdowns automatically based on the actual line items in the order.
Otherwise, I am with you. I use a much simpler system without categories but I manually enter every dollar I spend right when I spend it.
This depends on how you look at financing and budgeting (duh). But Firefly III was originally designed (by me) to lower your running expenses. It doesn't feature a lot cool budget automation because that leads to more charts but less money.
The original idea was to make it hard (or at least with some friction) to create transactions. This also excluded any way of importing data. That way you feel your transactions twice. Once when you spend the money, and twice when you have to enter it.
Making you finances tangible is a very good way of spending less money. Importing all your shit just gives GIGO but with nicer graphics.
To ask something that now seems obvious... in your experience, doesn't that friction just drive people away from the program? That seems to me the natural response.
Nice, came here to says thanks for the explanation! I was following Firefly III since a couple of years, already installed a test version on a local VM. I set up auto-pull for 2 of my 6 bank accounts, this did not work well (some transactions were missing, e.g. credit cards). I haven't found the time to proceed deeper.
For my partner and me, I keep an OpenOffice spreadsheet were I enter all expenses, so we know who owes whom how much. Also, I scan all my receipts and they are automatically renamed and moved based on patterns (paperless-ng).
I agree to your argument, seeing all your expenses in this way helps keeping a connection to how much is spend. I yet need to combine my two systems with firefly.
The data entry problem can be solved in some cases by fetching transaction data automatically using OFX from supporting institutions. Python’s OfxTools [1] works quite well for this. Quite a few large institutions in the USA support this (e.g. Amex, Chase) while some don’t (Bank of America). For the latter, transaction data can nevertheless be downloaded in ofx/qfx or csv format from the web interface, which can then be auto imported.
Once the transaction data is available, it is trivial to auto categorize it and create dashboards. I’ve blogged about my own process/tools for that here [2]
I've been using firefly over two years now. Data entry has not been been a problem:
* Run the data-importer as a separate container. Takes maybe 20 minutes to configure correctly if you already know docker and docker-compose.
* Download the transactions as CSVs from each of my 5 or so credit card and bank accounts that get regular use.
* Upload them through the data-importer. It lets you configure and save settings for each CSV format. I took five minutes to set that up the first time I imported CSVs and just keeping using the same settings.
I upload all of my transactions once a month and it takes about an hour to download them, import them, and categorize all of them (I also have a bunch of rules to auto-categorize, but there are inevitably a dozen or so bespoke transactions).
I've found that any of the solutions built on top of syncing backends like Plaid inevitably have issues: duplicates, missing txs, debit/credit mixed up. I even built my own custom Plaid-to-Firefly syncer at one point and found the data quality was very mixed, even when all my accounts are at major US banks. The data-importer takes some more up-front work, but it's more secure, way more predictable, and generally a solved problem.
I just never could bring myself to enter my bank password into Plaid.
Sure “everyone does it”, but most banks have disclaimers in their terms of service that if you lose money because your password was compromised through password sharing they aren’t liable for that loss.
I instead built a series of playwright scripts to automate signing into my bank accounts and downloading the CV, then importing (to lunch money, but I might take a look at this later as an option).
Chase is the only US bank I know that provides a proper API for plaid to connect to (plaid redirects you to chase.com for login, you acknowledge, and then give plaid an oauth token for read-only access). I don't have an impression that chase is particular tech-savvy comparing to other banks and I wonder why other banks cannot support this.
There's no reason (beyond the general dysfunction of our legislature) that the US couldn't pass a similar law. Failing to do so is holding back out banking industry and making us all dramatically less secure.
We desperately need to mandate banks provide this kind of access. It's absolutely ludicrous that I don't have a way to give various services READ-ONLY access to my bank account information. It seems intolerable to me that I would have to give WRITE access to Plaid for them to enable someone to categorize my transactions.
I appreciate the breakdown but I think you’re out of touch with how easy auto-import has become for most PF software users. They just see whatever new transactions have come in, as often as they care to look at their budgets. Like checking email.
Maybe out of touch. I've used them all (Mint, ynab, pocketsmith, buxfer, some google-sheets-based app, probably tried a dozen others). All of the auto-sync features had obvious bugs. It works for a few months and then you end up with junk data. But if it works for you, carry on!
Contra anecdote: been using auto import with YNAB for years with multiple accounts and never had junk data. At least, not of that means the data is wrong/corrupt.
The two issues I have had:
1. Have to reauthorize bank connection, but that's Plaid's issue I guess.
2. Payee names are all over the place because it's often the merchant name. I used to try and fix these and only have a single page payee for each entity, but gave up.
I guess it comes down to the tradeoffs you're willing to accept for privacy. I personally find it quite sketchy that Plaid takes your username and password to your literal money and then does some opaque screen-scraping just to grab your transactions. I also spent a lot of time working with their API and it did not inspire confidence.
Unfortunately neither of these work in the US. Salt Edge supposedly supports US banks but when I reached out to them a few weeks ago (specifically for the purpose of using them with Firefly III) this was their reply:
> We regret to inform you that temporarily Salt Edge does not provide its services on the USA market.
Though in this case I’d likely lay the blame entirely upon the US banks themselves. For example, to my knowledge, Bank of America has no way to retrieve any of my transactions or data without letting an app impersonate me using my login information, which I’m not about to do.
I'm a hugeeee LunchMoney fan. It's a solo dev and she does great! Hooked a few friends on it as well. This has been a lifesaver for insight into my financials and it's super flexible.
I switched from a decade old spreadsheet to YNAB. Then it went subscription and online only. It relied on the Adobe Air runtime which stopped working in macOS several years ago (32-bit only).
I haven’t looked at firefly yet, but I really want something that allows me to forecast expenses, and realize them as they occur and automatically adjust forecasts accordingly.
There is a script to patch YNAB 4 on macOS. You will need your serial number (but that should be enough, the script _should_ download the applications). After this, you can archive all the binaries for more safety (AdobeAir, patched YNAB, etc.)
That was my thought as well. I normally resist subscriptions, but given how much effort I went through each month to get my spreadsheet setup to work, it seems well worth it.
Most of these work be giving the application your bank credentials, right? This probably violates the terms and conditions of your bank and gives the application unrestricted access to your account.
Am I totally misremembering this, or is it a fairly recent change?
I could've sworn several years ago it was perfectly possible to use your sign-in credentials, then immediately change them, because it basically needed an authorization token, but then worked fine.
Now it doesn't. I work for a company with a Plaid integration and if the bank so much as requires any kind of 2FA, you just can't use it at all anymore.
I work at Plaid. It all depends on the bank. Most data provided by Plaid is sent from banks to Plaid via API, but some isn’t. And generally Plaid connections work fine with 2fa, but some don’t depending on the 2fa method and implementation details.
I don’t know, but it almost certainly violates your bank’s terms of service to share your password with Plaid.
If Plaid is every compromised in a way that leads to a loss of your funds in your account (probably unlikely), your bank likely has no legal requirement to make you whole for that, if you shared your password with Plaid.
I just don’t think you should share your bank password with any external entity.
I'm not sure. It is possible that some banks have an API that Plaid uses, but this issue has been known for several years and discussed on here quite a bit. Plaid even had a large settlement due to privacy violations.
Depends.
There's a bunch of providers (eg Yodlee) that ask for bank credentials (previously on HN https://news.ycombinator.com/item?id=18655712)
Akoya in US and most European providers use real bank APIs.
As of several years ago, banks would provide csv files of transactions to customers. That's still more work than the paid options, but much less than individual transactions.
I suppose something like Firefly could create a module (or even sell one) that is preconfigured, and updated, with the best method for each bank - download csv, api, scrape, etc. In fact, they could charge for that service and fund development.
I’ve tried the auto ones and they are _too_ easy. It feels like all it’s doing is showing my credit card bill in a different format. Plus, I don’t want some external corporation to be the source of truth for my money. Entering everything in myself makes me slow down and consider what I’m spending. And as a bonus, I spot check against what my creditors think I’m spending.
I always fail to see how that actually works (edit: I mean the auto importing of transactions). My 3 biggest non-recurring expenses are Amazon, REWE (German supermarket chain) and PayPal. While REWE is mostly groceries, it certainly isn’t all, Amazon could be almost anything and PayPal could be absolutely anything.
Do people just give up on granularity, or how does it work?
Budgeting tools work best when you're checking them regularly, so you should have a basic idea of what you bought even if you lost the physical receipt.
YNAB offers the ability to split transactions over different categories so categorizing an Amazon purchase is trivial.
In the case of physical receipts you can enter them before they are synced from your credit card and YNAB does a great job matching uncleared transactions back with the cleared ones.
Paypal purchases always have the merchant attached to them, so you should be able to differentiate them regardless of the budgeting app you use.
Oh, yeah, it is easy, that’s what I do. Sorry, I was unclear, I meant the automatic importing of transactions. If you have to go through them anyway, there does not seem to be much saved.
When I last did some bookkeeping of Amazon expenses, I fetched the detailed purchase history from Amazon (when available) as well as extracting data from the emails received by the person who purchased items. Similarly with some other suppliers. This undoubtedly saved on some manual data entry.
The workaround for data entry I have in hledger are a few csv import scripts for various sources of txn info, but I still have to manually edit the imported data sometimes. So still would prefer something that can auto-import transactions. The other thing I have done is close a few accounts to simplify this process.
(Personally, rather than fetch, I save OFX or QFX files from each US financial institution periodically. So that I can import them now into GnuCash, and also potentially import them into some other tool maybe decades into the future.)
It would have been great if banks sent webhooks to my specific endpoint upon a new transaction. Otherwise, especially in India where Open (API Banking) doesn't seem around the horizon, server-hosted personal finance applications aren't scalable.
I've been using (and manual-entering transactions in) Firefly-III for over 2 years. It's a good, old piece of software, but isn't scalable to our "high-frequency / busy / real-time" banking needs.
I've experimented with hacks like reading from bank transaction mails, using Tasker (Android) to read transaction SMSs, but alas the setup is cumbersome and not reliable.
Not to mention the companion mobile apps that companies like YNAB provide. It’d be nice to have something self-hosted and hackable, but my spouse won’t want to use it unless the mobile app is good
What about cash transactions? I'm still searching for something that can efficiently OCR my receipts and extract a total and a store name automatically. (and in Japanese)
Cash is still an unsolved problem. Because receipts are so different, nobody has a solution for the OCR task. The best I've seen are expense-tracking apps for businesses that offer such a service for a fee - because they farm out the job to low-paid offshore workers with stuff like Amazon Mechanical Turk.
I recently discovered PocketSmith[0] which is not free nor open-source, but I have found it to be the easiest to keep up to date. It automatically pulls transactions from most banks and credit providers, which I've been unable to replicate with other solutions.
Yeah I use them too. I keep meaning to set up Firefly III to try it but Pocketsmith _has_ been really good. For a period of time I had accounts in a couple of countries and it was one of the few tools which let me get a multi-currency view of all my finances across the globe. Highly recommend.
+1 on the Pocketsmith recommendation. I've tried several others (YNAB, Lunchmoney, etc.) and I've been using Pocketsmith consistently over the past three years. It has integrations with just about anything, has support for crypto, etc. and their support is top notch.
I wish this site was more clear about which banks exactly are supported by bank feeds. It seems right now like I have to buy the service before I know if I can even use the bank feeds feature.
To more accurately forecast a balance, why not just enter transactions with future dates and estimated amounts? Then a balance report with the same future date will be a good forecast.
I applaud the effort, but sometimes think apps like this when they promote self-hosting should have a mode of installation and operation that acts more or less like a desktop application.
My first thought when I saw "self-hosted" was "I wonder if I can pay a monthly fee to some other HN reader to get them to deal with the annoyance of hosting for me"
FWIW, Firefly III has an old Sandstorm package, but it isn't currently maintained so it's a fair bit out of date. We aim for "like installing an app on your phone".
The problem here is ultimately on the platform your app runs on, not the app itself. If web servers are hard to spin up, so too are web apps.
I mean, a windows installer (or RPM) that doesn't require a background process so that more people can access the value of the software. Even Flatpak or something if we are talking Linux specific.
Having Docker and other "enthusiast" methods of running software makes it less accessible. Having a web-stack as the goto method of writing software doesn't make sense if it limits the audience that would gain value from it.
I say this as someone who professionally maintains a web application that comes with a Windows installer, macOS traditional installation and a Linux RPM. All with desktop icons and it being pretty invisible to the user that it is a web application aside from the HTML-looking UI style.
The software is for personal finance, it isn't for a niche that makes the install/access method particuarly sane. If it were software for managing a cluster of X-thing or something ... maybe.
The system predates the popularity of installable PWAs. It is basically an exec spawning a Qt Web view and a server process then the Web view connects to local host. Server process shuts down when the Qt UI is closed. The server process is just Java with a webserver lib.
The binary is built for those OS and installed via installers idiomatic for those systems.
It defaults to use a local sqlite backend but could use any rdbms. Simple really.
You can have your cake and eat it here. If you're packaging a "web app" for local installation, you typically have a webserver sufficient for SoHo in your app. In our case, you have "]$ myapp" which runs a web view UI, local process and sqlite db.
But you can also launch it with "--serve" options to access it through a web browser and expose it on a network, with sqlite local disk database.
You can also launch with "--db=postgresql://postgres@dbhost:5432/postgres?sslmode=disable" to run it against a postgresdb.
A bit of work on the "how it runs" aspects can give great flexibility and usability for single-user cases.
https://moneywell.app is still my favorite: event-based budgeting, automatic transaction import, buy-once run-locally forever. It’s perfect. macOS only unfortunately but I highly recommend.
Edit: not a shill, just happy. :) The killer feature for me is the event-driven budgeting: you load in your expenses and note when they occur, and MoneyWell figures out how much to allocate to the corresponding envelope automatically. So nice. Anyone else know of another PF system that does that?
This is great! I've been using Firefly III for years. However it consumes a good chunk of time to keep up to date at a line item resolution with many cards and accounts across countries as I've not automated any of it.
The dashboard is a bit configurable, ok, so I can cut things I do not want but a default with just balance/all translations scrollable, the latest visible/stock option with mean price paid and actual value, optional widgets for other financial means (raw materials and their value, currencies etc) would be far nicer than a big load of graphs...
Ease to add transactions is not much a thing since at least personally all must come from external sources like bank exports in ofx/qif/sv etc with manually just tagging, description etc and a merging feature for upcoming transactions when the date is due to merge them with the actual new entry from the bank, so better import/export (i.e. woob integration for banks who do not offer exporting) would be very nice.
Generally graphs are nice but data in tabular form + operations on such tables are much more useful, especially if can be done with a programming language like "hey, that's the table, now you can generate new ones with some query language and lisp/python/ as you wish, just add a "programmed entry" and you get input in sv form for code, SQL-alike for query DSL, output view as a table for sv data or graph or raw at your option.
Surely the last paragraph might not appeal end users, but a user who self-host likely use/can use/dream such features...
Firefly III is excellent - there was a lot of excitement for Actual budget the other week (which is also excellent) but firefly has been a solid self hosted finance tool for years.
I found out about Firefly III a couple of weeks ago and wanted to try, but it seemed a bit more than what I needed. That's when I found out about Actual, which does seem to be an interesting solution. My issue with it is that they seem to have made the web version (intentionally?) not compatible with mobile, and their iPhone app requires a subscription of ~$10 a month. At first I thought I'd give it a try then felt sort of cheated. I don't mind paying for a solution but this seems like a shady way to charge money for me. Also I'm not a fan of subscription.
Anyway, I gave Firefly III a try and now I'm very happy that I did. I think those extra features that seemed too complicated at first are proving to be pretty useful.
Unfortunately Firefly is not really a double-entry bookkeeping system. There is a differentiation between source and destination accounts (called expense and revenue) which makes reverse transactions a pain. I pay 100€ for furniture in May and return it in July. Now I can either create the furniture store as both source and destination account or delete the first entry. Both is equally bad in my opinion.
I think a much better solution would be to differentiate between my accounts and 3rd party accounts.
Also, what I was struggeling with (and not only in Firefly, but all budgeting apps) was the sometimes significant delay between the purchase and the bank transaction. In addition there is the issue with split transactions from imported transactions. Basically manual data entry is too much work and automated data entry is too faulty. I roughly sketched a process in my head which could solve that.
It basically disinguishes between manually added information and bank information. Both is stored and then combined to one transaction. This closes the gap between the bank domain and the "user domain".
1. Let the importer bring in all the bank transactions with the date, the transaction is executed. Display on the right.
2. On the left there are manually entered transactions, possibly with split transactions.
3. Now you make matches.
4. If there is no manual entry, you can add some information like splitting the transaction, add a date you did the purchase, etc. by clicking on the bank transaction.
5. All the above could be automated by rules. Like making matches, giving it a pretty name, assigning a category, etc.
6. Last step: Manually sign off all the matches. If a time period has only signed off transactions it gets a "true" designation otherwise a "preliminary".
> There is a differentiation between source and destination accounts (called expense and revenue) which makes reverse transactions a pain
Sure, but that doesn't make it any less of a double-entry bookkeeping system.
> Now I can either create the furniture store as both source and destination account or delete the first entry. Both is equally bad in my opinion.
The first is correct bookkeeping. The second is bad.
Regarding the process you suggest, each step in your workflow is a massive undertaking to build. And it serves exactly one (1) user for whom the workflow fits: you.
It's how I started Firefly III: solving my own problem. So I guess you know what to do ;)
>> There is a differentiation between source and destination accounts (called expense and revenue) which makes reverse transactions a pain
> Sure, but that doesn't make it any less of a double-entry bookkeeping system.
Maybe let me formulate it a bit more diplomatic: It is not what I would expect from a double-entry bookkeeping system. Personally I find one account for each person more intuitive. There may be reasons for not doing this but they are not clear to me yet.
> Regarding the process you suggest, each step in your workflow is a massive undertaking to build. And it serves exactly one (1) user for whom the workflow fits: you.
> It's how I started Firefly III: solving my own problem. So I guess you know what to do ;)
I know that implementing this process is not walk in the park. Please don't see it as a request for you to implement that particular feature because I need it. But for me this would solve an issue I had with all of the personal finance tools. Therefor I wrote down my thoughts, maybe they resonate with someone and it results in a fruitful discussion. Or maybe someone had similar thoughts...
> There is a differentiation between source and destination accounts (called expense and revenue) which makes reverse transactions a pain. I pay 100€ for furniture in May and return it in July. Now I can either create the furniture store as both source and destination account or delete the first entry.
The use of expense and revenue accounts is standard, but I find it surprising that you can't enter a negative amount for a payment. There isn't even a "return" transaction type with a similar effect. That's how I would handle returns in my own accounting software (HLedger): Original payment, $100 from checking (asset) to merchant (expense). Return, $-100 from checking to merchant, with a comment identifying the original transaction. It doesn't make sense to have separate "Furniture Store" expense and "Furniture Store Return" income accounts—that does not provide accurate income & expense reporting. Logically, after the return you have no expense or income related to that purchase.
Of course HLedger, being much less opinionated, doesn't actually care about "source" and "destination" accounts—that's a matter of how you interpret them. IMHO it's far easier to just think of the accounting system as a single directed graph where nodes are accounts and edges are transactions. A "negative" edge is just a transfer in the opposite direction.
This does mean that the income/revenue accounts have negative balances, which can be counter-intuitive, but it makes sense once you learn to think of the income account balances as reflecting changes in the source of money (i.e., $-100 in an "employer" income account means your employer has $100 less because they it to paid your asset account) rather than the amount of income you've received. Likewise, a positive balance in an expense account means that the recipient of that money has more because of your payment, not that you do. Assets and liabilities are your accounts and sum to your net worth; the equity accounts, which I would define to including income and expense accounts, belong to your counterparties, and are relative rather than absolute since they only reflect the transactions which are relevant to you.
> Also, what I was struggeling with (and not only in Firefly, but all budgeting apps) was the sometimes significant delay between the purchase and the bank transaction.
HLedger addresses this by tracking two separate dates for each transaction, with options to choose which one to use for a given report. This can cause some issues with balance assertions which lie between the two dates, though, so I just use a priority system—the date my bank shows is always "right" even if the transaction occurred some days prior. It would be nice to be able to set a date for each account, which would probably fix the balance assertion issue, but then you could have transactions which didn't balance (sum to zero) for certain intervals. (Perhaps this is acceptable as long as the transaction eventually balances?) HLedger, like most other accounting software, also tracks flags for pending and cleared transaction which can be used in reports and queries.
Thanks for mentioning that. It looks like there is support in HLedger for per-posting / per-account dates via `date:` tags[0]; I'm not sure how I missed that before. For the auxiliary dates, I suppose one could just ignore balance assertions when using the `--date2` option, but IMHO it would be better to set a posting date for the bank account for when the transfer cleared rather than an auxiliary date on the transaction as a whole. The expense account would then show when the expense was incurred, and the bank account would show when it cleared. Usually only the latter would have a balance assertion.
I literally had to reinstall this to a new free instance on Saturday after getting my instance deleted accidentally.
I have been tracking and exporting backups of my finances using Firefly since 2020. I am young, my finances are nothing fancy, they are mostly credit card purchases, my salary, and my rent.
I love the flexibility of personally serving this on a dedicated server. Similar to the other commenter it consumes a lot of my time too. I tried to automate by writing small custom shortcuts in Apple Shortcuts for repeated things like posting a grocery purchase. Firefly has a comprehensive API, I have widgets on my homescreen showing my credit card balances at all times etc.
I like knowing how much I spend on grocery each month, how much I spent clothing last year vs this year, the effect of having a Costco membership. It is fun and I am sure in the next 10 years it will be so much more interesting looking at data from early years.
I guess I'm really old school but I just have a spreadsheet for my budgeting, with formulas and charts I've written and maintained over the last 25 years. It's gone from old Microsoft formats (xls/xlsx) to ODS, to Gnumeric, back to ODS, and now I use Apple's Numbers since I have a Mac and an iPhone, and iCloud web works on pretty much any device with a browser I might have in front of me. If I do ever feel like ditching my Mac and going back to an open source OS, I can just export it to ODS again and all my formulas and tools transfer over (I don't use anything proprietary from Numbers, though color fills don't always match right up).
I am salaried with weekly payout, and so I have a weekly chart for where my money goes on payday (bills/loans/cards/savings), an amortization schedule for each account that allows me to see how extra payments will affect the payoff and interest, and a brainstorming sheet for planning future large purchases (cars, maybe a bigger house one day). I can do pretty much anything with this that I could with Firefly III or a paid solution, but (for me at least) this is less hassle and my data stays between me and Apple's iCloud server; I trust them enough with that basic data to not bother with maintaining and securing a VPS just to balance my budget.
I feel that it muddles storage logic with business logic. If it's an error-detecting raid1 storage system, can't we just use raid1 storage configurations separately from the application?
Technically speaking, it's not really necessary. It does help to validate database consistency, because the sum of all transactions is zero.
It also prevents you (from an architectural perspective) to pull money out of thin air. If you create an account with 1000 on it from the start, there has to be a source for that money. That account is hidden and invisible, but will have a balance of -1000. It may look like nothing, but it helps to keep things in check.
In practice most computer-based accounting packages only simulate the appearance of a double-entry bookkeeping system. In traditional double-entry bookkeeping one must manually enter the data for each transaction into multiple journals: a minimum of twice, or more than twice for split transactions. This is what allows the journals to be cross-checked for consistency. The reports produced by computer-based "double-entry" systems will always be consistent, however, because they're really just different views of the same set of multi-account transactions recorded in a general ledger rather than distinct single-sided transactions recorded in account-specific journals.
"General-ledger accounting" (for lack of a better term) is superior in terms of having a single source of truth, but not very practical for manual accounting since all the transactions are mixed together. The introduction of computers changed all that by making it easy to generate targeted reports from the general ledger.
I currently use Mint by Intuit. I hate the new UI, the constant ads, and the amount of trust I have to give them (with my bank credentials). I would love to self-host something else that can auto-import all of my transactions. I'll have to check out Saltedge and Nordigen. I might also write my own Plaid API integration. Just as much trust though...
Open banking data APIs sounds like an easy win for regulators, but probably the Intuit lobby would oppose that.
If you’re technical enough to self host and concerned about privacy, you might want to try using GNU Ledger and hand-rolling importers.
I was in your position about 3 years ago, and have no regrets going down this path.
Downloading all of the necessary files by hand only takes a couple minutes with a decent password manager. You’ll spend more time (re-)categorizing and running interesting reports, and IME the ledger apps have the best experience in this dimension, although YNAB isn’t bad.
I am about ready to throw in the towel and use mint. It’s the only product Apple has built a native integration for, with no news of other products.
I’ve written asking about it but nothing. It’s pretty annoying because Apple Card is supposed to offer privacy, then they turn around and make the first transaction integration with mint. Wth.
It really just depends on how comfortable you are in the command line. If you know how to get your transactions downloaded from your bank and don't ever want to leave the command line, hledger is great for you -- I've been using hledger since 2019 and love every minute of it.
If you need something point and click, or, need a high "wife-acceptance factor," firefly-iii is not a bad choice.
After coming from hledger, I did try firefly, but, stuck with hlegder due to how amazingly powerful it is with nothing but a text input.
hledger has a decent front-end web UI [1], it runs as a local server on your machine by default.
The filter and searching on this view is quite good, and visualization is decent.
We are able to add txns from this UI but I have never used it.
When I tried this after importing data and setting things up for a bit through the web UI, I somehow managed to get the database into an invalid state and it broke.
For finance, you need simple and obvious recovery and this just doesn't have it.
I've always used the approach of allocating spending before it's spent. I've not attempted expense tracking. Has anyone got experience with it, and an opinion to share?
That being said, it's good that there's discoverable information there.
At my previous job, Symphony[0] chat was set up to launch at startup for all employees. I remember when the icons I call "Pyramid of Infinite Fun" and "Drone Strike" showed up in Symphony. There was no mouseover alt-text for the icons, and the Pyramid of Infinite Fun was right next to the icons for bold, italic, etc. text. So, people naturally clicked on the new icon a few times to see what it did, but it seemed to do nothing. The thing was, it caused a musical ding (like striking a musical triangle) for everyone else in the current Symphony room (channel), without any visual or auditory feedback for the person clicking the icon. So, being in Asia at the time, we heard waves of ringing noises from all over the trading floor when the London office got in. (Deployment of new versions was usually midnight NYC, so mid-day in Tokyo, Hong Kong, and Singapore, so the deployment for us was more gradual as people responded to notifications to restart Symphony to pick up the new version.) The sound was closer to a triangle than a bell, but I suspect the driver for using a triangle instead of the traditional bell icon was just to be perceived as making progress.
"Drone strike" was just the screen shot icon. However, it looked like a targeting reticle and showed up the same day as the Pyramid of Infinite Fun, so I was somewhat hesitant to try it out.
It seems like someone or something has crashed the demo.
It outputs an error log.
Whoops! An error occurred.
Unfortunately, this error was not recoverable :(. Firefly III broke. The error is:
Could not save preference: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'data' at row 1 (SQL: update `preferences` set `data` = [{"ip":"00.000.00.00","time":"2022-05-30 20:02:06","notified":false},{"ip":"00.000.00.00","time":"2022-05-30 20:02:10","notified":false},{"ip":"00.000.00.00","time":"2022-05-30 20:02:15","notified":false},{"ip":"00.000.00.00","time":"2022-05-30 20:02:16","notified":false},
...
My IP was in the list.
Let's just say it is hard to trust a piece of software with my financial data after this.
(I changed all the IP addresses for 00.000.00.00 to preserve some anonymity.)
> Let's just say it is hard to trust a piece of software with my financial data after this.
Definitely don't upload your real financial data to the shared hosted demo. I definitely wouldn't trust the demo with real data.
... but for the actual app, you run it locally on a server you control. You can add whatever form of auth in front of it, whether that's nginx basic auth, or requiring a client certificate, or so on. The app's designed with that in mind, with the user being a trusted person, so of course it's fine for it to dump sqlstate for you to debug.
Since this is AGPL free software, and self hosted, it's about as trustworthy as can be for putting data into it, and if you don't trust it yet, you can read the code and gain such trust.
Apologies. Firefly III tracks the IP's you login with and warns you when a new one appears. For a demo site that gets slashdotted, that is less than convenient. The issue is fixed and the site is back up.
