How to handle different expense accounts sharing same IBAN?

[stefan-girlich]

Scenario

My bank data (exported CSV) shows the same IBAN being used for different opposing account names, e.g.

Account name;Account IBAN;
FIRST ACCOUNT;DE49500105174978599682;
ENTIRELY DIFFERENT ACCOUNT;DE49500105174978599682;

(random example IBAN)

The account names are different supermarkets and service providers. I assume that they simply share the same payment provider.
The importer incorrectly considers these both as the same expenses account FIRST ACCOUNT, making it hard to filter e.g. for a specific supermarket by account.

Question

Is there a way to prevent this and allow for FIDI to create accounts by account name in the CSV, sharing the same IBAN?

Setup

• latest stable version of Firefly III
• latest stable version of FIDI
• all installed via docker-compose and latest tags

[JC5]

What I do myself is that I create a placeholder account for that IBAN and then filter the rest myself. Ie. "Ayden (placeholder)".

[stefan-girlich]

"filter" would mean filtering by other transaction properties (like Description or Notes) containing more detailed info?
I'll also do so, and I also renamed the account sth like "Payment Provider" via web UI.

Final thoughts:

• It was not intuitive for me that IBAN is used as an identifier for the account when it's an optional property in the web UI (e.g. http://myhost/accounts/edit/24 => Optional fields). Could it make sense to use a combination of account name and account IBAN?
• I'd assume that future imported transactions for this problematic IBAN would use the existing (manually renamed) account entity for that IBAN - is this correct?

[JC5]

Yes, that's what I do as well. Regarding your final fields: IBAN's may be optional for me, but are unique values everywhere else. So no, they will not be joined with the account names. As for your second remark: that's true, any account that refers to this IBAN will get the "placeholder"-account.

[stefan-girlich]

Thanks so much!

[LeoSum8]

Hi there,
I just ran into the same problem.
It is kind of messy to recover the information after the transactions have all been mapped to the same account name during import. This means that the actual account names of the transactions have been deleted and I need to go through the original csv and find the correct transactions again to retrieve the account names and store it into the description.
Would it be possible to store the account name in a different field aswell to not loose it for such transactions to not-unique IBANs?

[shrippen]

Same here. It's kind of hard to even notice the problem to be honest when importing historical data.
It would be nice if there could be some kind of detection of this kind of problem. I don't want to manually check the imported transactions to my csv just to make sure that this stuff isn't happening...

The proposed solution by JC5 is only possible if you a) know that this IBAN is faulty, b) if you know every expense account that is "using" this IBAN and c) the transactions have meaningful descriptions. Am I wrong?
The interesting data that is available in the CSV, the opposing accout name, is discarded during the import as far as I can see.

Or should I just always discard the IBAN and only use the account name?

[shrippen]

Just had a good idea to (potentially) solve this.

I have the feeling that at the moment firefly works like this.

When importing a transaction firefly wants to map the transaction to a specific expense account. To find out which one to map to it first checks:

• IBAN -> if IBAN is found with an existing account then the transaction is linked to this existing account
• if IBAN is available but has no available existing account then a new expense account will be created
• if no IBAN is available the same procedure will be done with the data available in Opposing Account (name)

Would it be possible to change this procedure as follows.
If IBAN is available and found -> check if the data in opposing account name and the account name of the existing expense account matches to a certain threshold. If they differ too much then create a new expense account with a new name but the same IBAN. This would also work if multiple expense accounts share the same IBAN. Then the expense account with the highest match percentage will be chosen (if above a certain threshold).
This would be the most elegant solution for my data I think.

[lenzls]

I'm having the exact same problem. Multiple businesses using the same IBAN for payments.

Your suggestion makes sense to me, a layman.

I think we could even ditch the matching percentage part and simply always do exact matches.

[Hypoferalcus]

I'm just setting up my firefly and I encountered the same problem - it seems that every shop that uses the payment provider "sumup" has the same IBAN
Now an expense account was created with the name of the first shop that uses that - and every following sumup transaction is connected to the same shop.

Is there any solution yet? I couldnt find a way to set up a rule like "when that iban is present, link the transaction to an account resembling the name that is in the bank transaction (where the name of every shop is shown perfectly but somehow is discarded during import)

thanks

[shrippen]

Unfortunately there is no solution for this in sight.

My "solution" at the moment is to rename every IBAN where I notice this behaviour to "Dummy Account" and when I have the time I might go through my import data and sort this by hand. Maybe. Problem is I won't really notice the Dummy Accounts without checking all entries in the first place...

[Hypoferalcus]

That's sad to hear - about 30-50 % of my daily expenses are over such payment providers - so this means, auto-mapping is almost useless in my case :-(

[Hypoferalcus]

Is there at least a way to preserve the "ultimate creditor" field from the import somewhere in the transaction so you can look it up in firefly instead of having to browse through the bank account?