Improve account identification to differentiate accounts with same name but different account numbers

[yourwater]

Support guidelines

• I've read the support guidelines
• My request is not listed as a very good idea, but unfortunately...
• I've used the search and this has not been requested before.

Description

Currently, accounts such as "Income Account" and "Expense Account" are identified by their names only, which may result in errors when importing data if two accounts have the same name but different account numbers. In such cases, the system might mistakenly treat them as the same account, leading to issues like incorrect fund transfers or mistaken transactions. Ideally, the system should recognize accounts as distinct if they have different account numbers, even if their names are the same.

Solution

It would be beneficial to add an option where accounts with the same name but different account numbers are treated as separate entities. This could involve enhancing the account identification logic to include both name and number for uniqueness.

What are alternatives?

Well, the alternatives may be doing nothing and continuing to rely solely on account names, which leads to the current issues.

Additional context

This could involve changes in account management logic, database structure, and UI adjustments to allow users to define accounts by both name and number. A careful consideration of how this would impact current data models would be necessary.

[JC5]

Hi,

Thanks for opening an issue!

They are already treaded as different entities. So, as far as this ticket goes, this is very easy to implement.

Could you explain your problem before we discuss potential solutions?

[yourwater]

The actual situation I encountered is that I have multiple accounts, and the bank's exported CSV file includes both "account name" and "account number." When I batch import the data, it is grouped as one account, even though it’s for different bank accounts. Additionally, in my assumption, if I were to transfer money to two people with the same name, it could mistakenly be recorded as one person, which could lead to some incorrect assumptions.
Thanks

[JC5]

If you add the bank account numbers to the Firefly III accounts, and add them to the import configuration, they will not be mixed up.

[yourwater]

I tried as you suggested, but I am still only able to associate one name with one account.
For example:
Name: "Eric", Account: "6222 ****5050"
Name: "Eric", Account: "6235 ****6862"
Something like this.

[Brewmaster1782]

I am new to Firefly, so forgive me if I am missing something.

I had the same problem. In my case, I have two accounts with the same name (one shared asset and one expense), and I wanted one transaction to be booked as a transfer and the others as an expense. However, Firefly kept assuming that they were the same account.

What helped me was setting up the two roles: "Asset Account" and "Opposing Account" in the .csv file and the Data Importer. Initially, I only had the "Opposing Account" role set up, but that did not seem to be sufficient. So, I created a script that first adds a column for "Asset Account" to the .csv file. Then, it populates the "Asset Account" column with the account number from the account I downloaded the .csv from if there is a transaction involving one of the accounts with the same name.

I also couldn't understand why Firefly would assume that the accounts were the same, even though the account numbers are different. I hope this helps! Let me know if there is a another workaround.

[JC5]

It depends a little bit on what your import configuration looks like exactly, but consider this example:

date-transaction,description,amount,destination_name,destination_iban
20170101,"Some test transaction 1",-12.34,FriendA,NL02RABO2454554658
20170101,"Some test transaction 2",-12.34,FriendA,NL13ABNA8672131290

You see here two transactions to FriendA, where FriendA has two different IBANs. The IBANs are fake, btw.

Now, import this using the following configuration:

    "roles": [
        "date_transaction",
        "description",
        "amount",
        "opposing-name",
        "opposing-iban"
    ],

What you see is that the opposing name and opposing IBAN are both mapped to their respective columns (the last one and single-last).

The result is that Firefly III gets two transactions. Here is what happens.

1. One is addressed to FriendA with IBAN NL02RABO2454554658
2. Firefly III creates (or finds!) an expense account with this IBAN. The name is optional in this context, but if the account does not exist yet, it will be "FriendA".
3. Firefly III has created expense account "FriendA" with the mentioned IBAN.
4. The next transaction is (also) addressed to FriendA, but with IBAN "NL13ABNA8672131290".
5. Firefly III tries to find an expense account with the other IBAN but cannot find one. A new one shall have to be created. But! An expense account with name "FriendA" already exists!
6. Firefly III creates a new expense account called "FriendA (NL13ABNA8672131290)".

Here is the result:

So even when accounts have the same name in your import, it does not have to be a problem.

[marek-zeleny]

Hi,

I think I'm experiencing this issue as well, in particular with opposing accounts. My bank's CSV export has two related fields (mapped accordingly in the importer):

• opposing-number
• opposing-name

Transactions typically only have one of those two fields filled in, although some transactions have neither (e.g. credited interest, fees, etc.). I perform mapping on opposing-number to match opposing accounts for transfers (i.e. when the opposing account is one of my asset accounts). For other account numbers I use the option "(do not map / automap)".

When I import transactions with such configuration, the result is that only opposing-name is used to create expense (or revenue) accounts, and the opposing-number field is essentially ignored. All transactions that don't have opposing-name filled in get collapsed under a "(no name)" account which simply keeps account number of the first transaction without opposing-name in the CSV.

I tried to go around this issue by ignoring the opposing-name field and only use opposing-number for the import. Unfortunately, this didn't help - now all transactions got grouped under the "(no name)" account (see screnshot).

What worked was using the "opposing number" field in the CSV as opposing-name instead, but it would be annoying to modify all the expense/revenue accounts manually so that they actually have the opposing-number field filled-in correctly.

Could this be a bug caused by treating opposing-number differently from opposing-iban if IBAN is missing?