If there was a sufficiently good import, something deeply customized for at least the top N banks, I think I’d be ok with that workflow. But even Quicken was disappointing on that front.

▲

a-fadil 8 hours ago | parent | next [-]

The app support mapping profiles. I hope we will have a profile for each major broker.

I'm also experimenting with local llm models to parse files and statement and call the app tools to feed data.

	▲	ioblomov 2 hours ago \| parent [-]
		This doesn't appear to be documented... https://www.google.com/search?q=site%3Awealthfolio.app+map+p... Would be happy to contribute profiles.

▲

ryandrake 8 hours ago | parent | prev [-]

Quicken is getting even more and more disappointing.

Used to be, you'd use what Quicken calls "direct connect" where the client software itself connects to your bank's servers and pulls down your transactions and balances. They also had this "quicken connect" where the client software connects to Quicken servers, who, in turn, contact your bank--making Intuit an unwanted middleman. Slowly, but consistently, Quicken has been dropping "direct connect" support and coercing their users to go the middleman route.

I, too, have been looking for an alternative to Quicken, but: 1. I don't want to have to go to each bank's crappy web site and download a crappy CSV to import, and 2. I also don't want the software developer inserting itself into what should be a data transfer between me and my bank.

The Holy Grail personal finance software would 1. be free and open source, 2. download data directly from financial institutions without CSVs or a middleman and 3. store the data in an open format like sqlite that I can query and manipulate outside of the application.

▲

BrenBarn 6 hours ago | parent | next [-]

My understanding is that part of the problem is that many banks do not provide that kind of "direct connect" functionality anymore. Some used to provide OFX but no longer do. Also, financial regulations aimed at "open banking" (like PSD2) bizarrely seem oriented towards enabling middlemen like Plaid. They don't require anything like "each individual customer must be allowed to access their individual data by using an API however they want"; it all has to go through a "third-party provider".

So the holy grail is really "Banks must be required to provide all customer info in a machine-readable format, via a programmable API, directly to their customers." :-)

	▲	workworkwork71 3 hours ago \| parent [-]
		You're correct here. The banks have limited who they are allowing into their systems more and more right now. We wanted to build direct partnerships with trading institutions to leverage their brokerages but they'd tell us to speak with their whitelisted partners like Plaid or a new (YC backed) incumbent, Snaptrade.

▲

GlibMonkeyDeath 7 hours ago | parent | prev [-]

If you can be a little flexible on (2), then Beancount hits most of the Holy Grail points. The ledger format is literally text (it is plain-text accounting after all) but there is a query language the works really well.

I end up saving CSV's locally and importing the transactions from there (no hand entry, but I still need the intermediate download step.) I don't find it that too burdensome since I don't have a zillion different accounts.

[This](https://reds-rants.netlify.app/personal-finance/the-five-min...) project (I am not affiliated in any way) claims to automate ledger update even further.

	▲	ryandrake 7 hours ago \| parent [-]
		Yea, (2) is always the tough one. Looking at my Quicken, I have 28 active accounts that I regularly (like daily) update from online, and manually finding, downloading, importing, and reconciling 28 CSVs is just not going to be acceptable. That said, I'll check out Beancount!