Brand new to Kmymoney. Used gnucach for a long time, but always frustrated at having to assign categories manually. I used a tool I discovered called qifqif to semi automate it by updating the qif file to be imported, it works but it is a kludgy solution.
I was delighted to discover KM had a feature to automate that problem, but I’m having trouble understanding how it works. My assumption was this. If I have a load of transactions for one payee, but the payee name contains unique data in each transaction (presumably some sort of transaction code or something meaningful to the payee) that I could select one of them, modify the payee name to a common string that exists in the payee name for all transactions, and associate that with a category. Then all transactions that contain the string I’ve defined in the payee name would automatically have the matching category assigned to the transaction.
However, every which way I tried it, it didn’t work.
The single transaction I had modified did get the category assigned to it, but none of the others did. I tried deleting all the transactions and importing them again from the original qif file, but the result was the same. It seems the category association I had set up was associated only with the unique payee string of the transaction I’d modified.
What am I doing wrong?
Thanks, Ian
I don’t think you are doing anything wrong, I think you are not understanding what in KMyMoney are two separate issues. First, transaction matching on import: You do not need to modify the name of the payee to get transactions to match. If you go to the Payees View and select the payee, look at the matching tab. You can enter multiple strings, any of which can be used to match imported transactions to that Payee.
Categories are completely separate from Payees, and you can’t match on them in the same way. However, one of the other tabs in the Payees View is default category, and if you specify a Category there, then any new transaction for that payee (whether imported or manually entered) will be assigned that category.
Since a picture is worth a thousand words, I found a live example on file and try to explain how to deal with it.
Initially, two transactions got imported using the KBanking online importer (just mention that, because I don’t know if e.g. QIF or OFX importer work exactly the same way). Since they have a different payee, both created an entry in the payees table as follows:
and
On the right, the entries of the Matching tab are shown which were automatically created during the import. To beautify the displayed name, combine those two, make sure the next time it will not create yet another payee and assign an initial category, we do the following:
- Rename one payee
- Delete the other payee
- Modify the regular expression for the match
- Assign an initial category
Once step 1 has been performed, the view looks like this:
Note: The second VISA COOP entry is not visible anymore due to sorting of the payees
Selecting the second VISA COOP entry (VISA COOP-5934 CHUR CITY K.) and deleting it needs to be confirmed by the user and then results in the following dialog to be shown (and I manually entered the first three letters of the new name before taking the screen shot):
Selecting the Coop Switzerland entry and continuing with OK now leaves just one payee with two regular expressions (and both transactions, we come to those in a second):
Next we continue with step 3: modify the regular expression. This step really depends on the names to match and your creativity to create an expression to do so.
In my case, I take the first one and change it to ^VISA\ COOP\-\d+\ .+ and simply delete the second one which results in:
This will take care of matching the next import of any purchase from VISA COOP followed by a dash, a number, a blank and at least one more character to be assigned to Coop Switzerland. You can try it on regex101.com. Make sure to use the ECMAScript flavor.
This brings us to step 4: Both transactions are not yet assigned a category. Because they were both made from the same account, I simply open the ledger for that account and select the two transactions in question (here easy, because I can filter for erroneous transactions which only leaves those two):
Next I start editing them with a right click and Edit transaction which opens the editor without any data. I only change the category field and press Enter. Since they are not erroneous anymore, they disappear from the ledger. Changing the ledger filter to show only Coop matches, brings them back to the view which now shows (after selecting the transactions again):
If you only shop groceries at Coop then you can setup that as a default category with the payee. If you don’t, KMyMoney will search if historic transactions can be used during import. The category of the one with the closest value will be used. This may still need some adjustment if the amounts are too close to another.
That concludes the magic behind payee matching and category assignment during transaction import.
@ostroffjh thanks for the reply.
If I understand you correctly. First off, every transaction I have imported into KM has a unique payee id, even if the payees are the same. Simple example, all my atm cash withdrawal transactions begin with the string, “ATM#0”, the rest of the string is unique. So what I want to do is, on importing a transaction, if the payee begins with the string “ATM#0”, then assign the category “Cash in Wallet” to the transaction.
If I understand your explanation, what you are saying is that it is possible to assign other strings to a payee, and if any transaction is imported with one of those strings in it, it will be assigned to that payee.
So I created a new payee called “ATM Cash Withdrawal”, and created a matching string, “ATM#0”, for it. I also allocated a default category for it (Cash in Wallet). I reran the import, but none of the atm transactions were allocated a category, and my new payee was not displayed in the ledger, presumably because there were no transactions for it.
I tried all the matching options but the result was the same.
So I tried allocating a matching string to one of imported transactions (with a unique payee). This time the transaction was allocated to the “ATM Cash Withdrawal” payee, with the correct category and amount.
So what this means, it seems to me, is that, every time I import a qif file, I have to manually update every transaction to allocate the matching string to the payee I want the transaction allocated to. It would be easier to manually update every transaction with the category I want it assigned to, and not use payee matching at all.
Have I understood correctly, or have I got something wrong?
Thanks,
There’s definitely a disconnect somewhere, but I’m not sure where. One question - when you retry the import, have you deleted the transactions imported from the previous try? If not, the system recognizes the newly imported transactions as having already been imported, and does not make any changes to the existing transactions.
Next, if two transactions are assigned to the same payee, they will have the same payee id.
If you get your transactions to properly match to the desired payee, then they will also get assigned the default category for that payee.
Hopefully the above will help, but I think you also misunderstand what happens when you edit a transactions which was imported. If you edit a transaction, and change the payee, you are changing the payee. You are not allocating a matching string. Matching is something that happens during import only, not at any time later.
Hopefully this helps.
Hi All,
Apologies for the last reply, Christmas kinda got in the way. 
I finally worked my way through the info kindly provided by responders, and got it working. The key, as it turned out, was to delete all the other payees in the payee with the same name (but different names in the import, if you see what I mean) in the payee list once I had modified one with an appropriate pattern (as alluded to in the reply from @ipwizard, so I’ve marked his answer as the solution). Then they all matched the pattern and were allocated to the specified category as expected.
Thanks once again for all the help and patience, much appreciated.
Happy New Year,
Ian
That was a great tutorial. Thank you for taking the time to write it up. It would be a great inclusion with the documentation. I had no idea how to use the tool.
Jason