A familiar description appears each month and someone chooses the same account again. A merchant rule can reduce repetitive work, but it can also repeat a mistaken decision. Its usefulness depends on the text it recognizes and the action it proposes. Before saving a rule, establish what the movement represents and why the proposed category fits that particular event.
Categorization is not an invoice payment link
If a withdrawal pays a bill already recorded, the task is to link the payment to that document. Categorizing it as another expense may repeat its effect. Tario distinguishes document and transaction matching from merchant rules. Do not use a rule to bypass checking whether a supplier invoice already exists with the relevant amount and reference.
The same applies to incoming customer money. Recognizing the customer's name does not establish a new sale. Look for the invoices or existing receipt first. Categorization belongs to the appropriate flow for a movement without an associated document, not as a substitute for investigating a document relationship. The bank description rarely explains the complete commercial event.
Hypothetical example: a condition that is too broad
Imagine two fictional withdrawals: SERVICE CLOUD ALPHA 0815 for CRC 18,000 and SERVICE COURIER BETA 0815 for CRC 12,000. A rule containing SERVICE recognizes both. If it points to a software account, it also proposes software for the courier charge. The system is following the condition it was given; the mistake is selecting a word that does not distinguish the merchant.
A condition containing CLOUD ALPHA is more specific to the first movement. The September description changes to SERVICE CLOUD ALPHA 0915 and still matches. A changing reference number should not be an essential part of that pattern. These names are invented to illustrate text selection. They do not describe actual providers or recommend a particular account for your company.
Correctly identifying the merchant still leaves the event to investigate. The CRC 18,000 withdrawal may settle a bill already received. In that case, link the payment rather than generate another categorized expense. Separating merchant identification from document review prevents a precise text rule from producing the wrong accounting treatment. Recognition is only one part of the decision.
Exact match, contains, or starts with
Tario supports exact match, contains, and starts with conditions for merchant rules. Exact match uses the whole description and may stop working when the bank appends a date. Contains finds text anywhere, so choose distinctive words. Starts with is useful when the prefix identifies the merchant, provided it is not a generic label shared by unrelated movements.
- Select text identifying the merchant rather than only the payment method.
- Compare several previous descriptions before saving a pattern.
- Consider a similar description that should not match.
- Look for an existing document or transaction being paid.
- Recheck the destination account when the supplier's use changes.
Xero's official documentation also describes bank rules as conditions producing proposals during reconciliation. It is cited for that general concept, not to imply that its fields exist in Tario. A rule captures an observed repetition. It does not prove that every purchase from the merchant has the same purpose or that an unexpected amount is correct.
Save a rule only after understanding the line
In Tario, rules can be created while reviewing an import or categorizing a line. Choose the condition and destination account. There is also an option to remember similar movements when accepting or changing a category. Review that option carefully: an exception resolved today should not automatically become the preference colleagues encounter in every later statement import.
Suppose one vendor supplies both a subscription and equipment, with identical bank descriptions for each. A single rule cannot establish which purchase occurred. Review the evidence and preserve the document links instead of assuming the vendor's name is enough. If the description cannot distinguish the cases, manual review remains necessary even when the rule consistently recognizes that merchant.
Lines recognized by rules appear under the merchant memory matching method and can be reviewed before posting. Reconciliation settings also allow certain suggestions to be accepted automatically. Accepting a decision is not the same as reviewing its supporting evidence or, on its own, posting an import. Inspect the preview and outcome of the accounting action you actually confirm.
Maintain rules using actual examples
After the first import using a rule, inspect the lines it recognized. Look for an unexpected match and for a movement it should have found but missed. That contrast helps identify an overly broad or overly strict pattern. You do not need an accuracy percentage to discover that a generic word is capturing payments to unrelated suppliers.
Tario lets you view and delete merchant rules in Settings under Automation. If a rule is no longer appropriate, review or remove it using the available options. Removing it for future use does not automatically correct confirmed records. Investigate affected earlier operations separately and follow their correction process, particularly when the accounting period is already closed.
When several people handle the same bank account, agree who maintains rules and how changes are communicated. A short explanation can identify the pattern, intended event, and person who resolved the category. Without that explanation, an unsuitable rule may remain in place because each colleague assumes that somebody else verified it. Keep the rationale alongside your working procedures.
Check before confirming
In the example, CLOUD ALPHA should not capture COURIER BETA. That is the first test. The second is ensuring that no categorized line duplicates an existing bill or receipt. The third is checking that the destination account still fits the actual use. If any test fails, change the pattern or handle the event manually rather than confirming a batch because most lines look familiar.
A useful pattern reduces repeated choices, not responsibility for the records. Save rules you can explain with examples and retain document review where it matters. Afterwards, the team should be able to explain why a line received its category and where the evidence is, without attributing the decision solely to an AI suggestion or a rule inherited from an earlier colleague.