Understand what a bank rule will post

Active Rules Always Post

A rule reaches further than most people expect. Know its scope before you save one, and before you edit one that is already running.

This is the part that surprises people: an active rule does not just code a matching row, it posts it. There is no separate switch for that, and it is independent of the firm's AI auto-post setting.

Not Only Forward-Looking

A rule can code rows that arrived before it was created, as long as they are still uncoded, unposted, and eligible. Creating or editing a rule can change work already sitting in your queue.

It cannot touch rows that are already posted. Posted activity is ledger history and only changes through the supported reversal path. When Tally retires a bad rule, it says the same thing: past postings stay put.

What Blocks Automatic Posting

A rule cannot post a row that is pending at the bank, excluded, already posted, missing an account, zero-dollar, a suspected duplicate, a suspected transfer, removed by the provider, or otherwise carrying a warning that needs a person.

Those safety gates are why a rule you expect to have fired sometimes has not.

When Two Rules Match

Priority decides — the higher-priority rule is checked first, so the more specific rule must sit above the more general one. If the wrong rule keeps winning, the fix is usually priority, not another rule.

A rule that never wins because another always matches first is shadowed. Tally reports those.

A Human Choice Wins

If someone manually coded a row to a different account, a rule does not overwrite it.

Before You Save An Edit

Ask what the changed match text would catch among the rows already waiting. If you are not sure, disable the rule, check its matches, then enable it.

See Stop an overbroad bank rule and Review what posted and who posted it.