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

1 Like

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

1 Like

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.

Added to the latest version (21.5.50).

You can now set multiple description conditions on both payment and receipt rules.

image

5 Likes

This is a fantastic development because we frequently use buyers that purchase items that are categorized differently and would not create rules for these to prevent mistakes. Every time we needed to clear these manually from the suspense account. Now we can easily automate this.

Do you plan to add the use of AND and OR operators?

I assume there is an implied “and” operator (as is the case everywhere else in Manager).

In this case the “Or” operator is functionally already available, just duplicate the bank rule with the other “or” option. Imo, given the single string which is bsing searched, expanding the rules in this manner is unlikely to result in significant user disadvantage.

This is in contrast to custom reports and localisations where much more data / complicated searches are appropriate. For those areas I do look forward to support for an “or” operator.

1 Like

we made a separate converter, which adds the payee’s or payer’s and bank account number in addition to the explanation field, so its much easier to create a rules

description // payee’s or payer’s name // bank account number