> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dualentry.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Rules or AI: Which Should Handle a Bank Match?

> How to decide whether a bank match rule or Bank Match AI should handle a transaction, given the current strengths and limits of each.

Bank Match gives you two ways to automate matching: rules you define yourself, and Bank Match AI. They're built for different kinds of transactions, so the choice isn't one-size-fits-all. This page explains when to use a rule and when to let Bank Match AI handle it.

## What rules are good at

A rule is deterministic: you define the exact criteria, and it always wins over an AI suggestion for the same pair. That makes rules the right tool for hard business logic you want enforced the same way every time, such as always matching a specific recurring charge to a specific GL account. Rules are also the fix for a pattern the AI consistently gets wrong: once you've noticed the AI mishandling a specific vendor or description, a rule for that pattern handles it correctly from then on and frees the AI to focus elsewhere.

Rule criteria are limited to description or merchant text, amount, and check/reference number. You can combine several of these with AND logic on one rule, but a rule still can't reason about broader context like transaction type or a date range. Rules also apply only to unmatched transactions: once saved, a rule flags every matching bank line in **To Match**, old or new, but nothing is created or matched until you select **Create & Match** on that tab. A transaction that's already matched or drafted is never touched. See [How to Create a Bank Match Rule](./how-to-create-a-rule) for the mechanics.

## What Bank Match AI is good at

Bank Match AI's matching stages are conservative by design. The deterministic pass requires exact amount, date, and description matches; the LLM review stage only judges candidates within a fixed date window and exact amount, and it makes a plain match-or-no-match call rather than a fuzzy score. Both stages err toward leaving a transaction unmatched rather than matching it incorrectly. This is exactly the tool for the long tail of variable, one-off transactions a rule can't state deterministically: truncated descriptions, reformatted memos, or vendors that don't type the same reference twice.

The stage to watch more closely is payment drafting: when a bank transaction has no GL entry to match against, Bank Match AI can draft a new payment for it based on payee, date, and description scoring. It doesn't check whether a real invoice exists before drafting a prepayment, so direct expenses can come through as prepayment drafts instead. Review anything the AI drafts as a new record more carefully than something it matched to an entry you already posted. See [Bank Match AI](./bank-match-ai) for how each stage works, and [Common Errors with Bank Match](./common-errors) for what this looks like in practice.

## A practical way to decide

* **Predictable and recurring**: If the vendor, description pattern, and target account are always the same, write a rule. It's deterministic and always wins.
* **One-off or worded inconsistently**: Let the AI attempt a match, and review its suggestion before accepting it. The matching stages are conservative, but not infallible.
* **Drafted as a new payment rather than matched to an existing entry**: Give it extra scrutiny. This is the drafting stage, the part of Bank Match AI that most needs a human check.
* **The AI keeps getting the same pattern wrong**: That's your signal to write a rule for it, not to keep correcting the same mistake by hand every period.

## Related reading

* [How to Create a Bank Match Rule](./how-to-create-a-rule)
* [How to Use Accounting Intelligence to Create Bank Match Rules](./ai-copilot-rules)
* [Bank Match AI](./bank-match-ai)
* [Common Errors with Bank Match](./common-errors)