4 ms·
Right now, the differences are all in the details (income categories, no weird credit card handling, etc), and there are many of them. But instead I'll focus on
by jlongster 6y ago
Right now, the differences are all in the details (income categories, no weird credit card handling, etc), and there are many of them. But instead I'll focus on what is to come soon:
* A custom rules engine (to be released in a few weeks). You'll be able to write a list of conditions for matching transactions, and a list of actions to apply when matched. The system will automatically encode what it learns as rules (apply category X to payee Y) so you can see what it's doing and adjust.
* Multiple budget types. Zero-based budgeting is cool, but Actual is just a tool for you. If you want, you can use a simple report based that just shows income vs expense. You choose the type you want adapt it to your lifestyle.
* Custom reports. This is really where having all your data local is incredible. You'll be able to write queries into your data, process it, and render any kind of visualization.
- boarnoah 6y ago> You'll be able to write queries into your data, process it, and render any kind of visualization. Now that sounds very cool. Out of curiosity, do you have any plans to handle things that cannot be local first (for example with YNAB I like the Plaid Integration to pull transactions data out of banking). Something like that for your application would need to clear through your own API right?
- jlongster 6y agoYep, bank syncing is going to launch by the end of the year. It's tough. I've wrestled with this for over a year. Bank syncing has to come from my server, which means by doing so you are giving us access to your transactions. No banking provider has any way for clients to contact them directly. I think this is possible with the right encryption, but nobody is working on it. I've given this feedback to Plaid but they don't care. The majority of people need the convenience of syncing though. So I plan to launch it, and it'll go through my server, and I plan to communicate clearly the privacy that you are giving up by doing so.
- jpeeler 6y agoI assume by mentioning Plaid, you'd be using their services to extract the transaction data? I keep hoping to find a (maintained/viable) open source project that uses headless browsing to login locally and extract transaction details.
- MarkSort 6y agoI'm also interested in automated exports performed locally. For my credit union, I "reverse engineered" the API and export multiple times throughout the day. I wrote an extension that exports the data for CapitalOne, but I haven't gotten around to trying it either headless or even just in any automated fashion. Easy automated export of user data, even beyond financials, is something I'd like to see more of. Feels like it could be a workaround while there's so little decentralization.
- jlongster 6y ago@jpeeler @Marksort I wish the same. I've also given feedback to Plaid that they should implement an encryption scheme that allows data to be encrypted from Plaid to the user, so at least apps which sit in the middle couldn't read your data. Nobody is interested in that though. There _sort of_ is a solution where your computer directly connects to the bank. The format is called OFX (https://github.com/libofx/libofx https://github.com/libofx/libofx), and there is a directory of banks that provide these files directly online. This site (https://www.ofxhome.com/ https://www.ofxhome.com/) lists the URLs to use for each bank. I used that for a while many years ago. But it's terrible and requires massive maintenance. For an app that requires connections to arbitrary banks, there's no way developers can support these direct downloads. There's always different errors in data for different banks, etc. Unfortunately, Plaid is solving a real problem