Feature request: More advanced bank rules

The current bank rules only so simple string matching.
With for example the Dutch tax agency, you cannot use this, as the string differs in between:
(basically: tax return (some digits) vat, or: tax return (some digits) wages)

This could be fixed by either allowing wildcards tax return * vat, or regular expressions.
I know most people don’t really understand regular expressions, but there’s another case for this:
Invoice payments.

If I receive a transaction with the description INVOICE20190029, I think it makes sense to allocate this to debtors -> debtor -> matching invoice

With regular expressions we can use a (named) capture group. When using names, we can use different specifiers for this:

Payment for INV20190123 regarding something
(?INV\d{6,8})

(?D\d{4})

And similar.

Another thing I’d like to add is the source / destination bank account (With my .sta files it’s not imported, so I’m not sure if this would actually help anyone). For this, I could use a capture group with the IBAN of the debtor. something like debtorIban.

The different kinds of matching methods should have a dropdown with the type (normal, wildcard support, regex) to be backwards compatible and still easy to use

I support having wild cards in bank rules.
Use case: the description often has a changing transaction number but with constant information either side. A wild card would enable this variable number to be ignored but other information used for matching and creating a more reliable / specific rule.

While I agree regular expressions are more powerful again, they are too complex for 95% of users, so more difficult to justify

Currently, you don’t need a wild card feature to resolve this use case.
If the bank statement import has both fixed and variable data, then when you create the bank rule just save the fixed data by deleting the variable data from within the bank rule Description field.

So the bank import description

Becomes the bank rule description
0000000%20Bug%201a

So that when its next imported, it becomes highlighted

While it is correct you can use the text before OR after a variable part (eg transaction number). We can not currently use BOTH the text before AND after a variable part (eg transaction number).

To use your example above, if this feature was added I would replace the transaction number “1753989” with “*” when creating the rule. The rule would then use all other text so be more specific, enabling accuracy processing a larger range of descriptions.

While it is correct, transactions numbers are sometimes put at one end or have specific enough text on one side. Some of the descriptions I receive have the specific text spread across both sides, hence the support for more advanced rules.