if
%description 3 SQUARE CAFE|A.A ROOTS|BAJA FRESH|...
%description BBQ|BURRITO|DINER|...
...
but with my csvs at least, whole-record matching usually just works.
Oops, I answered a question you didn't ask, but I'll leave the example there in case it helps someone.
To also sanitise payee names, it might look something like:
if
AMZN
AMAZON MKTPL
Amazon\.com
AMAZON-SERVICES-KI
CMX UNLIMITED
COMICS
description Amazon US | %description
account2 expenses:books/periodicals
if
BLANKSPACES
CULVERWORKS
description Blankspaces
account2 expenses:rent
That will be a lot of rules to maintain, if you want to do this consistently. Another option is to get data from a bank aggregator instead of directly from the bank; they usually do a certain amount of payee name cleanup for you.
Listing multiple names for a match is cheap and cheerful, I am with Simon on this: whenever I have something that slips the net, i just add a rule. I have maybe a couple of rules to add per month of transactions (unless I do something drastically different from my usual routine, but then it is basically expected)
That will be a lot of rules to maintain, if you want to do this
consistently. Another option is to get data from a bank aggregator
instead of directly from the bank; they usually do a certain amount of
payee name cleanup for you.
My issue is that a lot of places use payment providers, sometimes you
might use one, sometimes the other.
That makes it hard to group them all together.
Is it possible to also reassign %to and %from? I would like to do that
so that I can still use the same setting for the description field.
I'm not sure about using an aggregator for privacy reasons and missing
API's on my banks side. Oh good do I wish that Nordic banks would make
it possible to use HBCI/FinTS.
You can create a file that assigns, say, just the description and account2 fields.
You can then include this file into multiple CSV rules files, each of which would assign account1 the way they see fit, and this way you would share some/all of the rules between them
Also you can of course assign account1, 2, ... based on conditions, independently of description. So you may have different if rules handling different parts of the transaction. (And later assignments override earlier ones, so you can set generic values then override for specific patterns.)