Firefly III: A free and open-source finance manager

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.

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.

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]

1: https://ofxtools.readthedocs.io/en/latest/client.html

2: https://sagar.se/blog/where-is-the-money/

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.

Here's two free solutions you can use for bank data sync (Nordigen & Saltedge): https://docs.firefly-iii.org/data-importer/install/nordigen-...

Agreed. I've found https://lunchmoney.app/ really nice.

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.

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.

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.

It’s also one of the few that does a good job of forecasting balances.

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.

They have a docker instal option. Granted it’s a bit of overkill but you can run it like desktop software.

Agree, ive installed this in the past and it was a pain in the ass. If i ever did budgeting/financial tracking again i would use a paid option

That was also my gripe with Firefly III. I liked the looks of it but the setup was a PITA

I listened to a talk by YNAB's creator last year (about development not the program itself). Didn't realize until this thread how popular it is.

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.

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