> ## 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. # Bank Match AI > How DualEntry's Bank Match AI matches bank feed transactions to GL entries, from deterministic matching to LLM review to drafting new payments. Bank Match AI is DualEntry's engine for matching bank feed transactions to GL entries during reconciliation. It is a hybrid system rather than a single model: a deterministic matcher resolves exact matches first, a large language model (LLM) evaluates the ambiguous items the deterministic pass leaves behind, and a separate heuristic scorer drafts a new payment when a bank transaction has no GL entry to match against. Exact matches are applied automatically, ambiguous candidates are judged by the LLM, and anything the system cannot resolve stays unmatched for you to handle. ## How matching works When you open a [bank reconciliation](./bank-reconciliation), DualEntry works through a bank account's unmatched transactions in stages, ordered from strictest to most lenient: 1. **Deterministic matching.** DualEntry indexes GL entries by amount and direction, then looks for an unmatched bank transaction with the same amount, the same date, and the same description. Amount is an equality check, not a range. These exact matches are applied automatically. 2. **LLM review.** For transactions the deterministic pass cannot resolve, DualEntry builds a candidate pool of GL entries within a fixed date window (7 days by default) whose amount matches exactly, then asks an LLM to judge whether the memo, vendor, and check number describe the same transaction. The LLM returns a match or no-match decision; it does not emit a numeric similarity score. 3. **Payment drafting.** When a bank transaction has no GL entry to match against, a separate heuristic scorer decides whether to draft a new payment for it. This is the only stage that combines signals into a single weighted score. Only the payment-drafting stage produces a composite confidence score. The deterministic and LLM stages do not: they rely on exact gates and a match or no-match decision respectively. ## What each signal means Bank Match AI reasons about four signals. How strict each one is depends on the stage that uses it: * **Amount.** Amount is always an exact gate, never a tolerance. The deterministic pass requires equal amounts, the LLM candidate pool includes only exact-amount GL entries, and the drafting scorer treats amount as a pass or fail gate. Pairs whose amounts differ, including differences from foreign-currency rounding or fees, do not auto-match. * **Date.** Date is handled differently at each stage. The candidate pool uses a single fixed window (7 days, adjustable through an environment setting) applied uniformly to every transaction type, with no wider window for items such as credit card settlements. The deterministic pass requires the exact same date. Only the drafting scorer treats date as a proximity score, decaying linearly over 90 days past the due date. Bank transfers use a tighter window of 3 days on either side. * **Description.** The deterministic pass requires exact string equality. The LLM compares memo, vendor, and check number semantically. The drafting scorer normalizes both descriptions (removing long ID numbers, reference tags, card masks, and dates, and lowercasing) and then scores them with character-sequence similarity. This handles truncated and reformatted bank descriptions, but not synonyms. * **Past matches.** DualEntry mines your previously confirmed matches into reusable memo-to-rule mappings and feeds them to the LLM as context, and it reuses prior matches to infer the entity and type when drafting a payment. Past matches shape the LLM's context and the drafting inputs; they are not added as a separate weighted term in a score. Because amount is an exact gate at every stage, pairs that differ only by foreign-currency rounding or bank fees never auto-match. Reconcile those items manually or record an adjusting entry so the amounts agree. ## Backend refresh and processing limits Bank Match AI results refresh automatically on a backend schedule, not only when you open a reconciliation. A background job runs every 30 minutes, regenerating match suggestions so suggested and auto-matched results stay current as new bank feed transactions and GL entries post. Each scheduled run operates within fixed limits to keep processing predictable across organizations of different sizes: * **Accounts per run (default: 25).** A single run processes up to 25 bank accounts. Organizations with more than 25 accounts are covered across consecutive runs, so every account is refreshed on a rolling basis. * **AI tasks per account (default: 25).** Within each account, a run evaluates up to 25 AI matching tasks. Any remaining tasks are picked up on subsequent runs. Because refreshes run continuously in the background, the suggestions you see when you open a reconciliation reflect the most recent completed run rather than a calculation triggered at the moment you open the workspace. ## How Bank Match AI drafts new payments The payment-drafting stage is the only place where Bank Match AI combines signals into a single weighted score, and it applies only when a bank transaction has no GL entry to match against. DualEntry scores the candidate payee, date, and description, and requires the result to clear fixed thresholds before it drafts a payment. The signals carry these weights: payee 0.50, date 0.30, and description 0.20, with amount acting as a pass or fail gate on top of the weighted score. A draft requires a composite score of at least 0.80 and a payee score of at least 0.80; prepayments require 0.90. These are fixed constants chosen by hand, not values tuned against a measured accuracy target. Because these thresholds sit high, the drafting stage is conservative: it drafts a payment only when payee, date, and description all agree strongly and the amount matches exactly. Transactions that fall short stay unmatched for you to resolve. ## How Bank Match AI reuses your past matches Bank Match AI does not train a model on your reconciliations in real time. Instead, it reuses the outcomes of your confirmed matches in two concrete ways: * **Mined memo rules.** When you confirm matches, DualEntry uses an LLM to distill recurring memo patterns into reusable memo-to-rule mappings. On later runs, those mappings are injected into the LLM prompt as context, so a memo you have matched before is more likely to be recognized again. * **Similar-transaction lookup.** When drafting a payment for a bank transaction that has no GL entry, DualEntry looks up similar past transactions to infer the likely entity and transaction type. Because this context is rebuilt from your confirmed matches, suggestions can shift over time as your history grows. There is no separate positive or negative training loop behind these signals, so accuracy does not improve through a scheduled model retrain. ## Relationship to manual rules Bank Match AI and rule-based matching are complementary. Rules run first and handle deterministic cases, such as "match any bank transaction with description containing 'PAYROLL' to the payroll clearing account." The AI runs second on whatever the rules didn't catch. If a rule and the AI would both match the same pair, the rule wins. This means you can use rules to enforce hard business logic (such as always matching a specific recurring charge to a specific GL entry) while letting the AI handle the long tail of variable transactions. Rules are also useful for edge cases where the AI consistently gets it wrong: creating a rule for that pattern ensures it's handled correctly every time and frees the AI to focus elsewhere. You configure rules under **Settings → Cash Management → Matching Rules**. For the reconciliation workflow that brings rules and AI together, see [How to Reconcile Bank Accounts](./bank-reconciliation). ## How strict each stage is DualEntry does not track precision, recall, or per-signal accuracy for Bank Match AI, and there is no accuracy dashboard. What determines real-world behavior is how strict each stage is by construction: * **Exact gates favor precision over recall.** Amount at every stage, and date and description in the deterministic pass, are exact checks. They rarely produce a wrong match, but they also skip valid pairs that differ even slightly, such as a rounded foreign-currency amount or a date that lands a day off. * **The LLM and drafting score are the lenient parts.** The LLM's match or no-match judgment and the drafting stage's weighted score are where most recall, and most of the false-positive risk, comes from. The drafting stage's 0.80 to 0.90 thresholds are what hold that risk in check. The practical consequence is that Bank Match AI errs toward leaving items unmatched rather than matching them incorrectly. Two behaviors follow directly from this design: pairs that differ only by foreign-currency rounding or fees never auto-match, and the candidate date window is the same for every transaction type, with no wider window for credit card settlements. If you want either behavior to change, it has to be added to the matcher. For related topics, see [How to Reconcile Bank Accounts](./bank-reconciliation) for the workflow where Bank Match AI runs, [Automated Categorization](../../ai-automation/automated-categorization) for DualEntry's AI for categorizing transactions by GL account, and [AI Accounting Copilot](../../ai-automation/ai-accounting-copilot) for the broader AI feature set.