Skip to main content
A rule matches bank transactions against criteria you define, then assigns them to a GL account, vendor or customer, or category automatically. Rules run before Bank Match AI: if a rule and the AI would both match the same pair, the rule wins. Use a rule for anything recurring and predictable, like a specific vendor charge or a payroll clearing sweep, so you’re not reviewing the same match every period.

Prerequisites

  • A DualEntry role with permission to create Bank Match rules. Admin, Controller, and Accountant have this permission by default, but it’s configurable, so check with your Admin if you’re not sure.
  • The GL account, vendor, customer, or category you want the rule to assign to already exists.

Create the rule

  1. Open Close Management → Close Workflows → Bank Match, then the Rules view, and start a new rule.
  2. Define the condition: what the rule matches on. Current options are description or merchant text, amount or amount range, or check/reference number. You can combine multiple conditions on one rule using AND logic, and optionally scope the rule to specific bank accounts.
  3. Define the action: which account, vendor/customer, category, or transaction type the rule assigns matching transactions to. Optionally, name the rule and set whether it applies to deposits, withdrawals, or both.
  4. Choose Save Rule.
  5. Open the To Match tab and choose Create & Match to apply the rule to every line it flagged.
After step 4 the rule is active and flags every unmatched line meeting its criteria with a bolt icon, however long that line has been sitting there. Saving alone creates and matches nothing; step 5 does.

If the transactions are already matched

A rule never re-evaluates a line that’s already matched or drafted, so it can’t reclassify one. Unmatch the lines first, then apply the rule from To Match. See Common Errors with Bank Match for what that involves at volume, and Rules or AI: Which Should Handle a Bank Match? for why rules are scoped to unmatched lines.

Keep rules narrow

Rule criteria are currently limited to description, amount, and check/reference number, even though you can combine several of these with AND logic; a rule still can’t reason about broader context like transaction type or a date range. A narrow rule targeting one specific vendor, description pattern, or amount is far more reliable right now than one rule intended to cover many different transactions at once. If you find yourself trying to write one rule to handle several unrelated cases, that’s usually a sign to split it into several narrower rules instead.

What’s next

Last modified on September 8, 2026