Firefly III – Self-hosted financial manager
firefly-iii.org
firefly-iii.org
We used ledger-cli and beancount with fava and built automatic creation of accounting entries using machine learning and Bayesian alogrithms by analyzing bank and credit card statements. You can use powerful icsv2ledger [5], smart importer [6] and the awesome list [7] to get importers for various banks and other utilities.
[1] https://www.ledger-cli.org/
[3] http://furius.ca/beancount/
[4] https://beancount.github.io/fava/
[5] https://github.com/quentinsf/icsv2ledger
[6] https://github.com/beancount/smart_importer/blob/master/READ...
[7] https://github.com/siddhantgoel/awesome-beancount/blob/maste...
Note: corrected the entry for ledger-cli, its primarily written in C++ with some emacs lisp scripts.
I'm currently using ledger-autosync (https://github.com/egh/ledger-autosync) to import OFX/QFX files. For some banks it can automatically pull the data using ofxclient (https://github.com/captin411/ofxclient) but for most of my bank accounts this is broken and I need to manually download the OFX file before importing with ledger-autosync. It works OK, I wish I didn't have to do the manual download, but the simplicity of the setup is nice.
I've read of other setups using Plaid or Puppeteer to download their data. Would be interested to hear about what other people are currently using in mid-late 2019 to pull their financial data.
Currently I’m using plaid2qif (https://github.com/ebridges/plaid2qif) to pull CSV from US banks via Plaid’s (https://plaid.com) API. This is more developer friendly and gets the latest data to me faster, but the data is not quite as good as Tiller/Yodlee’s, at least for Wells Fargo bank; Plaid gives more truncated transaction descriptions.
Both of these have the big downside of sharing your bank credentials with others. With Plaid I guess there’s one less party involved. My current alternative is manually visit each bank’s site and download CSV. Ideally I want to get timely data every day (the easiest way to stay on top of the books), so the manual downloading (click, wait, click, relogin after timeout..., wait, wait for paypal’s download, retry when it gets stuck..) gets really tiresome.
FWIW, USAA, Ally, Fidelity, AmEx, Chase, no charge for OFX.
However, I've been pulling OFX data from my Wells Fargo for years via AqBanking (https://wiki.gnucash.org/wiki/Setting_up_OFXDirectConnect) and have never been charged.
To be frank, I spend 90+% of my time in KMyMoney. I need Ledger only for its virtual transaction features (for budgeting). The other use case I have for ledger is to perform some analyses/reports in it that KMyMoney doesn't provide.
There's nothing "smart" about it. It's simply a script that takes in a kmy file and creates a valid Ledger file. It's been a while since I looked at it, but at the moment I doubt it handles things like stocks and commodities, etc.
Still, I'd rather use KMyMoney to enter transactions than using the Emacs mode for Ledger.
Does Firefly also support the features of YNAB, if you know by any chance?
https://docs.firefly-iii.org/en/latest/import/ynab.html
--- EDIT: misread! I don't know about the _features_. They support importing, which doesn't imply supporting the features.
> You can also import from bunq, from YNAB, using FinTS or simply by uploading CSV files. [1]
This was discussed for beancount a few years ago[1] and basically means that I want to distribute the money for a budget across multiple accounts but last I looked (over a year ago) there was no tool that provides this feature.
[1] https://groups.google.com/forum/#!msg/beancount/ddi5fOuAFoU/...
https://postimg.cc/gallery/2chl5bji2/
Edit: sent email with details to listed address on landing page.
Self-hosted means you control your data, though it certainly leaves you open to more attacks if it's open to the internet, but you can always protect it by hiding it behind a VPN. Having financials available everywhere is very convenient, and not having data on a mobile device (but accessible on your mobile device) is great for privacy-concerned people.
I've since stopped using even the 'manual import' and I've found that reconciling to my bank/financial-company statements manually is much easier overall as importing auto-reconciled transactions but then it was basically impossible to then match any specific balance reported by the bank/financial-company.
Edit: PHP is actually in a pretty good state right now, so I think it's a poor criticism, but probably a common one.
- Source/destination (as used here) is awkward when transactions have more than one split: at best there's a single source/destination which is entered multiple times and you need to make sure the splits add up right (and that single $50 charge to your credit card doesn't show up that way in the register); at worst you have an m:n split.
- Simple plus/minus without debits and credits (à la hledger, which I am otherwise quite happy about) runs into situations like: I increase my liabilities (e.g. by paying by credit card) by subtracting from the account?!?
I think if you're going to use a GUI then going full debit/credit isn't hard, I got up and running with Quickbooks pretty quickly and GNUCash seems about the same.
EDIT: I don't mean to downplay the accomplishments of the authors of any of the software mentioned, like I said I'm a happy user of hledger and Firefly III looks pretty polished from what I saw of the demo. This is really meant to be more of a meta-comment around the idea that bookkeeping is hard and double-entry debit/credit is doubly so.
Maybe I'm just inured to the convention, but this makes perfect sense to me. You subtract money from any other account you pay from. At a sufficiently abstract level, paying by credit card is the same thing as overdrawing your checking account. You need to add money to get the balance back to zero.
(And possibly dangerous fiction. I think a big part of the way people get in trouble with credit cards is by thinking their credit line is "the money they have", instead of "money they can borrow really fast".)
'0xcde4c3db makes a good point about it making the flow of value clear in the transaction, but the transaction view is already the easy thing to interpret. The value (heh) of bookkeeping is when those flows are aggregated, and the meaning of those aggregations is (admittedly only somewhat) obscured when optimizing for clarifying flows in single transactions.
Charging a credit card to make it more negative does match our intuition of how it affects our overall financial position, but that's due to serendipity. What does it mean that expenses are normally positive, is that a good thing then? Or that my paycheck account is negative?
In the end it's a nit, a small thing I mostly ignore. I just think that part of the complexity it tries to eliminate is essential, with results like negative revenues. It's a leaky abstraction.
A different way to do double-entry-lite might be to retain plus/minus, but have that operate on the account's normal balance -- pay for expenses by decreasing an asset or increasing a liability. Transactions still balance even if they don't sum to zero -- it makes sense that an IOU balances out the coffee you just got. You do need to understand the four basic account types (explicit equity accounts are arguably not relevant to most individuals), but that's something that's needed anyway. You still don't need to explicitly learn about debits and credits, but if you do it's much closer from here than from the flow-based approach.
Flow is easy, but I feel that in the end modeling the effect on balances is simpler.
I'm halfway between going full accountant (never go full accountant) and basically human. I'm pretty happy with the results so far.
And more importantly is it possible to import data from GnuCash? Last time I tried it I failed.
The reason I was drawn to FF III in the first place was because of its aesthetic appeal and visualization features. The graphing and reporting abilities of GnuCash are not to my taste.
After some time, I settled down to converting from Gnucash to Ledger using PieCash (https://github.com/sdementen/piecash), and visualizing the ledger file using LedgerWeb (https://vifon.github.io/ledger-web/). A bit of a workaround, but can be scripted and works fine for me.
So it'll see a comma when I open the file on windows and just report an error.
Right now I'm considering running it in on my server and then connecting to it somehow from all the different platforms.
See the part about adding an environment file on Windows. On Linux, I set my LANG to en_US.UTF-8 but all the LC_* variables (apart from LC_ALL) to en_CA.UTF-8 and that gets me the right UI/formats mix in GnuCash (and also Chromium, which tries to speak British to me otherwise), and hopefully that works on Windows too.
[0] https://akaunting.com/features
Updating is a bit annoying as there are no Debian packages and one has to essentially re-install from scratch on each update, but everything else is working perfectly well. Categorising expenses allows for easy monthly reports on shared expenses, too.
I’m happy with every donation. I use it to pay the AWS bill and maybe get a beer.
But make no mistake, a lot of people have donated one-time over PayPal which is greatly appreciated as well.
What made you leave YNAB if you don't mind me asking?
In additional to my personal finances, I currently use Xero for my business, but I also run everything through YNAB as well to actually know the health of my business and how much money I'm making. The book "Profit First" made a lot of sense through a YNAB approach.
I just want the balance on that budget to roll over for every month, so I know how much there is for that particular thing. And if you don't buy any clothing for 2 months, $400 is added to the available fund for that particular budget category.
It extends to a lot of things:
* Day trips
* Saving for car repairs and ultimately a new one.
* Groceries
* Holidays
* Hobbies
* TakeawayThis way, every time I receive salary, a fixed amount of my Income:Salary is (virtually) is debited to the virtual account "Clothing". In turn, whenever I make an expense in "Expense:Clothing", the amount is credited from the virtual "Clothing" account with an automatic transaction.
The way ledger keeps track of virtual and real accounts means that I can both see the (accurate) real balance of my checking account, as well as the virtual balance of my Budget accounts.
You do have to set this all up manually however, and it's... complicated. I really like ledger because it lets me setup things this way, but it's not something I'd recommend to others.
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.
But budget rollover isn't a bad idea at all and it could fit what Firefly III is doing at the moment. I'll make sure to think of a way to implement it.
In essence, it's just the "envelope" system with a rollover - i.e. if I don't spend all my grocery money this month, just add them to the next months envelope.
This sort of diagram is only easily possible if you can specify “here are the deposits that I think are going to happen, and here are the expenses that I think are going to happen.”
And for that, those envelopes are crucial, especially the ability to graph the amounts in the various envelopes and the amount that’s not in any envelope.
For my personal economy it come out such that the "account" for all of those recurring payments are always significantly in the positive - in other words, I can "borrow" from that "account" without it interfering with my ability to pay the bills. E.g. you have two annual bills of $600, one has a payment date of Jan 1st and the other have Jul 1st. I need to set aside $100 monthly to pay them, but at any payment date there will be $900 in the account, so it's always at least $300 in the positive. It's just a peculiarity that can happen.
So that leaves all the variable expenses, food, clothing, going out, ect, things you can control the magnitude of. Those are well suited for the envelope system. I would personally treat necessaries such as food and transportation as a special envelope in the sense that it's only variable down to a minimum but no further. Clothing on the other hand can be turned down for $0 for quite a while, and "going out" certainly can be $0 for as long as it need to.
How does all that fit in a cash flow analysis then? Well for bills and fixed income it's easy - just make the graph. But for variable expenses it's a bit more hand wavy, because I cannot not buy food for my children, but I can certain not go to that sushi restaurant. And that is where the envelope system is helping me. If I have an unforeseen expense that is greater than what I have in my emergency fund, and there is not enough to borrow from the fixed expense account without compromising payments. Well I have to transfer some funds from the envelops that have a surplus that i can control, such as the "going out" envelope.
I am about to leave YNAB because I am using version 4 (standalone software) which is 32-bit only. My main machine is a Mac so I won't be able to use the software with the next major version. Also, I do not want to use the new YNAB web-based app because the privacy policy is contradictory and their subscription offer is just shitty.
Currently I am using Outbank, which is more like a banking app but has automatic categorization which is quite cool, and you can define budgets. Still, no suitable replacement. I really hope for Firefly to take off with a powerful budget planning somewhere in the future.
-https://gitlab.com/caleb3141/financier
-https://gitlab.com/josh-whitney/financier-backend
Biggest downside is that it doesn't have an OFX/QFX import option.
Given how awesome YNAB is for me managing my finances, I'm more than happy to pay the subscription.
But I understand your reluctance nonetheless.
It also might be, that lots of people don't even know how to create desktop applications anymore, but most will have done something on the web already.
Here are the docs: https://docs.firefly-iii.org/en/latest/import/spectre.html
(For what it's worth, now I use Pocketsmith, a NZ-made Mint clone that I'm pretty happy with.)
I'm not trying to scrap bank sites, even though I could, because a) it's a PITA to get through the increasing amount of login hoops they deploy, and b) I don't want to risk even a small chance that they'll lock me out of access to my own money because I "hacked" their site.
https://docs.firefly-iii.org/en/latest/import/spectre.html was the killer feature, in my mind. Not having to manually enter all of my data myself made it usable.
Ultimately I'm lazy so I stopped doing much with it, but if you're interested in it, I highly recommend getting the Salt Edge account to handle importing everything.
I see that there tags, categories, and budgets. I understand the differences between these, and why they are presented as different concepts. How did these different features evolve? Did you have budgets first, then categories/tags? Did you ever consider implementing categories as tags and not having a separate category concept?
Just wondering if what you have now evolved from a simpler model (at least fewer concepts—maybe not simpler implementation or mental model), and if so why/how.
Tags were added later on by user request. Most users use them to categorize transactions. I don't use them myself. I tried using tags for meta-data like "expensive" or "wasnt worth it" but never bothered to tag everything.
demo@firefly / demo
I'd strongly suggest putting that on the demo page itself.
Most banks I've dealt with support downloading transactions via QFX, which makes working with GNUCash pretty easy.
PHP, on the other hand, requires fifty packages and your sister's phone number before you get segmentation faults from the caching script and give up.
It's a bit telling that I essentially need to run a docker container for something so simple. Statically compiled binaries are super simple to use.
At least the packages are often done professionally (e.g. symfony developed ones etc.). The standard library is pretty great so you don't always have to rely on packages. Often the same third party packages you'd have to rely on in PHP, you'd have to rely on similar packages for go.
> you get segmentation faults
Not sure where you get this from. In my 6 or so years of professional PHP development I've never seen a segmentation errors.
Anyway, still prefer a single go executable. It's just so much simpler.
If accurate, then it's sad to see PHP to fall this way. I remember the good days when all it took to deploy your PHP project was (S)FTPing the code to a folder and pointing Apache to it.
I would assume that most people here have stocks or bonds or something of some type.
Most of my assets are investments which makes this fairly useless for me, even if it does look very nice :-(.