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.