Better Recognition of Payment/Receipt Rules

I use payment and receipt rules to automatically allocate dividends and taxes to the relevant stock (‘division’). This will look like “BAC - Div on” or “BAC - Tax on Div” for example. However, I have the problem that for some stocks, such as ‘Citibank’ (“C”) or ‘Kellogg’ (“K”), I have to do manually, because the software is trying to allocate irrelevant transactions to them. For example, BAC is being allocated to C; VTRS to S etc.

It would be ideal if the software would allocate something to the best match available, rather than the first match available, whilst still not requiring an exact match. So for example I can still have the rule as “BAC - Div on” rather than requiring the rule to be “BAC - Div on X XXX Sh”. So the software may find that “C - Div on” has fewer characters matching than “BAC - Div on” and thus allocate it to BAC as intended.

Can you demonstrate with some screenshots how your payment/receipt rules are configured? Not really sure why you can’t configure your payment/receipt rules so there is no ambiguity.

Sure, below are 3 screenshots. There are other examples where this clash happens. When I import transactions, one example is that it wanted to allocate “BAC - Div on” to “C” division rather than “BAC” division.

I see what you mean now. I agree with you. Manager should take into consideration the length of the description to determine the best match.


Great to hear. Looking forward to seeing this in a future update :slight_smile:

Should be fixed. Check the latest version (21.7.8).

Yes, and ideally should not have items of the search string split (as also shown in screenshot) but be “exact” and unique. Also when adding another search line this alsos should be treated as “exact” but where the AND condition allows it to not be adjacent to the first “exact” search string.

I just installed v21.7.8 on Ubuntu server and find it strange that it still picks a single word such as “TO” in addition to the longer string that includes something like:

The TO in CusTOmers should not be marked as the Payment rule only uses SALARY from COMPANY LIMITED

The “best” match is an ambiguous term as it depends on the user’s interpretation.

In my opinion using rule priority based on rule length results in a decrease in rule power not increase because

  • rule priority for longer rules could easily be achieved in the past by putting the longer rule first. For example in the above example just drag the “BAC - Div on” above the “C - Div on” rule.

  • The reverse is not the case though. When the search algorithm uses orders based on one of the character counts, the user can no longer specify which rule is the most specific. The limitation is most obvious for multi-line searches with relatively short individual search term, which can be used to create very specific searches.


@lubos, can you be more specific? Exactly what was “fixed?” How do payment and receipt rules now function differently than before v21.7.8?

I also do not see that @SheldonSwanepoel actually illustrated any problem. Two somewhat vague receipt rules were shown (no bank accounts, no payees). But no results of their application were illustrated. So we do not know if those rules worked or not. The third screen shot in post #3 shows the result of searching the Receipt Rules list. It shows that that the Search function worked exactly as it does when searching any other list in Manager, by finding partial strings. It does not show that the receipt rules depicted failed to find the right transactions or improperly posted any receipts from an imported statement.

I agree with @Patch. More to the point, a receipt or payment rule should require an exact match, not some algorithmic “best match,” whatever that might mean. I don’t want a transaction classified on the basis of “close enough” after defining an exact criteria. And I would think that, particularly in a situation like @SheldonSwanepoel’s, where imported definitions might differ only slightly, the requirement for an exact match would be especially necessary.

1 Like

I agree with Patch and Tut, rules cannot be best match, it has to be exact match. The only enhancement I can suggest is that we have a priority setting on rules which the User would set, i.e. which rule should be executed first based on User input, not the length of the rule. E.g. if I have two transaction descriptions, Cash Deposit Fee and Cash Deposit where Cash Deposit Fee should be allocated to Bank Charges and Cash Deposit should be allocated Sales, I cannot setup a rule for Cash Deposit as it will allocate Cash Deposit Fee to Sales as well. If we were to have a priority, we would be able to set a rule for Cash Deposit Fee to execute before a rule for Cash Deposit. There may be scenarios where the first rule to be executed should be the one with the shorter description.

Also taking multiple conditions into consideration (which is a wonderful feature) how would you determine length? Only the first condition, or the total number of characters of all conditions? I believe anything that is not an exact match will only create confusion and may result in unwanted allocations.

1 Like

Nothing has really changed in implementation. The best rule is determined only when there are two or more rules with exact match as per OP request.

This is why it’s important to test the implementation and not to speculate.

If you setup rule with description Cash Deposit Fee, it will never be matched to transaction wich says Cash Deposit only.

But if you have transaction Cash Deposit Fee, it will be matched to two rules

  • Cash Deposit
  • Cash Deposit Fee

In this case the rule with the longest description wins.

That works only if rules only have one line.

  • Rules can now have multiple lines requiring a match
  • The matching strings the user enters can overlap
  • As a result the longest string or even the sum of the search string lengths no longer identifies the most specific search in all cases.
  • That existed in the past.
  • Rules were evaluated from the top of the list to the bottom of the list
  • It is true reordering could have been optimised
1 Like

I am sorry @Lubos but why would it be a problem to implement exact search or at least disallowing a split in search string (see my earlier message about doubling TO)? Additional lines must not only lengten the search string as it does now but prevent other options to appear and thus makes search and application of rule more precise.

Exact search is implemented - it was always working that way. The highlighting is wrong. I will fix that.

The only reason that case selects the most specific is longer sting includes all of the shorter string.
In general that is not how rule searches are written.
The specificity of a search sting depends on how common it is in the data set not how long it is.

For example by far the majority of payments from and ANZ bank account start with the 29 character string


so including this is actually a catch all for most business payments.

In contrast many quite specific search strings are about 6 characters long.

In summary string length has a variable correlation with search specificity.
The actual search specificity depends on

  • the data set being searched
  • the test string
  • the alternative test string

Only the user can reliably determine which is the specific entry and which is the catch all remaining.

Yes. That’s the point. Make your rules so they include as much as possible. If they have to include ANZ INTERNET BANKING PAYMENT, they should include it.

But they should be written that way. That is my assumption. The alternative is to ask users to set priority for their rules which for most of them (if not for all) is pointless.

Ok thank you. Just a matter of curiousity do you use find, compare or regex?

  • Most systems evaluate rules from the top to the bottom of the list.

  • When writing rule sets were matching order matters the easiest way of understanding what your rule set actually does is to put related rules together in the list with what the user wants to be the most specific at the top.

  • Which is why most rule sets can be easily reordered.

  • It is true only a sub set of users are capable of writing and using rule sets with variable matching.

If you want a claytons rule priority then perhaps the rules should be shown sorted by the priority Manager uses. Total sting length then alphabetical would be readable and informative.

1 Like

I did not include a screenshot of the rules allocating to the incorrect division/rule because I had already processed the transactions for June. But as stated in the original post, it was trying to allocate “BAC - Div on” to “C - Div on”, and “VTRS - Div on” to “S - Div on”. So the problem described does in fact occur prior to the update. The update seems to have fixed the problem based on the few test imports I just tried, so thanks @lubos. As for ‘best match’, as Lubos interpreted, I was meaning only in the case of a conflict. Obviously nobody would advocate for a ‘close enough’ match. But it is very sensible that where multiple matches exist, you would want some mechanism to pick between the two rather than having no control of that, or else one of your rules is rendered useless. And as for the lack of payee/bank account specified, this is because the descriptions across broker accounts are consistent so this prevents me having to create an exact duplicate of the rule for every broker account when that is not needed.

@Patch, dragging to sort is not an option. Maybe it is different on Windows or the online version, but on Mac that was not. Below is a screenshot from before I updated to the version with the fix. And anyway, Lubos’ solution is much more practical for anyone with any volume of rules. Between receipt and payments, I have 373 rules in one business, and another 242 in another (these were re-done after the split from ‘bank rules’, so they are not duplicates). And I’m sure there are many people with far more rules than that. Manually sorting those would be an absolute nightmare, especially as you add more over time.

Thanks Lubos for sorting this.

I still don’t understand what was changed. When you say:

I interpreted that to mean a rule stating “…and the description contains BAC - DIV on” would be allocated to account C - Div on.

In such a situation, a receipt containing only C - Div on would not be found or allocated. So what exactly was the problem and how has it been solved?

Yes, it is. Go to the Edit screen for the rule and drag the double-ended arrows to the left of the various lines:

Screen Shot 2021-07-11 at 3.43.49 PM

This works the same regardless of operating system or edition. Doing this on the above example yields:

Screen Shot 2021-07-11 at 3.45.24 PM