OFX - not worth the time investment?

[Chris Jansen]

I've been using beancount for about 2 years now, and in the last month I've started looking more closely at the External Contributions. I decided to try reds-importers, and pretty quickly discovered a few things:

1. ofxhome.com is gone.
2. ofx.chase.com doesn't work anymore ("Name or service not known")
3. FDX is a new thing, and does not appear to be friendly to open-source accounting tools like beancount.

For those that have used OFX for a long time - is it slowly going away? Are there alternatives that facilitate automatic downloads?

[Timothy Jesionowski]

I've seen write-ups of other people's setups that claim 40% availability but so far Fidelity is the only service I could get it to work on. Amex canned it in 2022 IIUC, and every other service I use did so long before that.

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/aad4ef72-a10e-451d-b64c-9d3937dca6cdn%40googlegroups.com.

[Rick F]

I wonder if something like SimpleFin might work if someone writes a wrapper around their API.  SimpleFin is similar to Plaid and others but it's available for one-offs so to speak whereas I think Plaid and some others want it integrated into an app and there's probably fees or something.  SimpleFin has costs that you pay which are $15/yr or monthly .. I've been using it with Actual Budget without issues for the past few months.  You'd have to check if your bank or institutions are supported obviously. Anyway, just passing that along

[Red S]

Anectodally speaking, here’re some banks that I know of that support it as of today:

• alliant
• ally
• becu
• capitalonebank
• chase
• citi (direct download supported)
• etrade (direct download supported)
• fidelity (direct download supported)
• morganstanley (direct download supported)
• target
• techcubank
• vanguard

And again, anecdotally, here are the banks that removed support for it in the last couple years:

• amex
• discover
• schwab

Ofx was introduced in 1997. In the tech world, that is old. It will eventually go away. But nobody knows when the remaining institutions will remove support for it.

So how should one approach ofx when writing importers? Here’s my two cents:

1) For me, the interesting question is not “should I invest time into setting up an ofx import” as much as it is “how can I setup my import system for adaptability so swapping out a file format for another is easy?”

• Consider also that the download method and the file format are only, say, 20% of your import system with respect to setup effort and complexity

2) Consider your alternatives. Here’s an example of development times (this is unscientific, and the relative times are more important than the absolute numbers):

• ofx: 5mins
• csv: 1-2 hours

• some_other_format (json, xml): 2-4+ hours

  In addition, Non-ofx formats unfortunately have a lot of
  downsides.

3) Don’t confuse direct downloads with ofx. Some banks have pulled support for direct downloads, but continue to support ofx if you download them manually from their website. An example is Chase.

Summary: setup ofx today when you can. There’s no downside to doing so IMHO as it’s low effort. Focus on building a robust ingest system where changing file formats is an easy, small part.

And finally, what does the future hold?

• Europe is ahead of the US/North America: finance.ec.europa.eu
• The US is doing something about it as well. See federalregister.gov, though so far, despite mentioning “consumer access” here and there. it seems to be somewhat focused on “third party access.”

​

[Red S]

A couple things to add:

• the goal of reds-importers is to simplify and fully automate your ingest. It is definitely not wedded to, not does it prefer the ofx format or any other format in particular. Quite the opposite: it make it easy to use any file format, and add your own. csv (and tsv, xls) is well supported because of its ubiquity, as are xml, json, and pdf
• if you’ve used IBKR, they’re awesome in allowing complete customizability over the reports, including the file format. Here is an example Beancount importer for it. And to boot, they let you download it via a REST API. Well documented, and very straightforward to setup. I can only hope other institutions follow suit

​

[Martin Blais]

On Fri, Oct 4, 2024, 15:13 Red S <redst...@gmail.com> wrote:

A couple things to add:

• the goal of reds-importers is to simplify and fully automate your ingest. It is definitely not wedded to, not does it prefer the ofx format or any other format in particular. Quite the opposite: it make it easy to use any file format, and add your own. csv (and tsv, xls) is well supported because of its ubiquity, as are xml, json, and pdf
• if you’ve used IBKR, they’re awesome in allowing complete customizability over the reports, including the file format. Here is an example Beancount importer for it. And to boot, they let you download it via a REST API. Well documented, and very straightforward to setup. I can only hope other institutions follow suit

Don't hold your breath

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/e79be64d-a5b4-4320-91fd-18d7298cb1c8n%40googlegroups.com.

[Chris Jansen]

These are good points. I had been conflating automated OFX statement download with using OFX in general, and most of my accounts support manual OFX statement download.

One of the benefits of OFX is being able to reduce manual download time by including all accounts in a single file. To that end, is it possible to configure beancount to use the same statement file for multiple accounts?

[Red S]

One of the benefits of OFX is being able to reduce manual download time by including all accounts in a single file. To that end, is it possible to configure beancount to use the same statement file for multiple accounts?

 Yes, of course, I do that with all my accounts. There's nothing special you need to do, this works out of the box.

[Gary Roach]

On Sunday, October 13, 2024 at 2:42:15 PM UTC-4 Red S wrote:

One of the benefits of OFX is being able to reduce manual download time by including all accounts in a single file. To that end, is it possible to configure beancount to use the same statement file for multiple accounts?

 Yes, of course, I do that with all my accounts. There's nothing special you need to do, this works out of the box.

Have you had any luck getting that to work with Fava's import UI?

I had to split my OFX import files up by account in order to get them to work with Fava. With both accounts in a single OFX file, Fava recognizes them and displays the extract and move buttons for each account, but when you click either one of the extract buttons, it only extracts the first account's transactions.

The move button also doesn't really make sense in this case because you can only move the file once. I can't move it to both /bank/checking and /bank/savings. I'd have to duplicate the file if I wanted that or store it at /bank instead. If you stored it at just /bank, that would make more sense, but I don't see how to do that and keep the postings assigned to the underlying account in Fava. 

[Red S]

On Thursday, November 28, 2024 at 2:56:22 PM UTC-8 groa...@gmail.com wrote:

On Sunday, October 13, 2024 at 2:42:15 PM UTC-4 Red S wrote:

One of the benefits of OFX is being able to reduce manual download time by including all accounts in a single file. To that end, is it possible to configure beancount to use the same statement file for multiple accounts?

 Yes, of course, I do that with all my accounts. There's nothing special you need to do, this works out of the box.

Have you had any luck getting that to work with Fava's import UI?

Unfortunately, I've never used or tried Fava for imports. Perhaps others on this list might know.

[Gary Roach]

On Thursday, November 28, 2024 at 10:45:51 PM UTC-5 Red S wrote:

Unfortunately, I've never used or tried Fava for imports. Perhaps others on this list might know.

Fava works pretty well with the beancount_reds_importers framework, for the most part. The reason I like using it is it adds a nice way to quickly step through each transaction, verify it, and make adjustments to any where you didn't like the result generated by smart_importer. Then it imports them into the specific section or file relevant to the main account of the importer. It's fast, displays only a single import candidate at a time so you don't get confused and reduces the frequency in which you have to work with the raw ledger. 

Importing an OFX file with multiple accounts is the only thing so far that it really doesn't work with. Although it's not a huge deal to split them up by account. Arguably could be preferable for a document filing perspective.

By the way, thank you so much for your work on beancount_reds_importers! I'm new to beancount and python and your importer framework made it possible for me to get up and running quickly!

[Chris Jansen]

After integrating beancount_reds_importers into my workflow, I've shifted from doing the import via fava to doing it manually, because of fava's limitation of one-file-per-account. I've still been using it to file, though. Based on config, fava moves it to the folder for the first configured account, and I just know that the OFX file also has data for other accounts at the same bank.

[Red S]

On Thursday, November 28, 2024 at 10:48:33 PM UTC-8 groa...@gmail.com wrote:

Fava works pretty well with the beancount_reds_importers framework, for the most part. The reason I like using it is it adds a nice way to quickly step through each transaction, verify it, and make adjustments to any where you didn't like the result generated by smart_importer. Then it imports them into the specific section or file relevant to the main account of the importer. It's fast, displays only a single import candidate at a time so you don't get confused and reduces the frequency in which you have to work with the raw ledger. 

Importing an OFX file with multiple accounts is the only thing so far that it really doesn't work with. Although it's not a huge deal to split them up by account. Arguably could be preferable for a document filing perspective.

Very helpful summary, thanks! My own process is [documented here](https://reds-rants.netlify.app/personal-finance/putting-it-all-together-into-a-workflow/), and is basically the same thing, except it's all scripted (gists are in that article)  My editor (neovim) is setup with the Beancount related tools you can find here, especially the one that autocompletes accounts to correct what smart_importer didn't get right. I use [a patch](https://reds-rants.netlify.app/personal-finance/structuring-your-source-tree/) to maintain per-account `.beancount` files, which makes it easy to have context when appending from an import.

Glad to know Fava has a similar workflow. I'll add it to that article.

 

By the way, thank you so much for your work on beancount_reds_importers! I'm new to beancount and python and your importer framework made it possible for me to get up and running quickly!

Most welcome, and glad that helped in that way! And thanks for contributing the pdf reader! I'll have a look at the PR soon.

[Red S]

 Friday, November 29, 2024 at 4:03:29 PM UTC-8 chri...@gmail.com wrote:

After integrating beancount_reds_importers into my workflow, I've shifted from doing the import via fava to doing it manually, because of fava's limitation of one-file-per-account. I've still been using it to file, though. Based on config, fava moves it to the folder for the first configured account, and I just know that the OFX file also has data for other accounts at the same bank.

Ah, good to have confirmation. Perhaps this could be posted as a feature request on the Fava github page. If folks who originally contributed the import are tagged, they might possibly be interested in adding multi-account imports.