| A bank transaction is drafted as a vendor prepayment when it should be a direct expense with no invoice | The payment-drafting stage runs when a transaction has no GL entry to match against, and doesn’t check whether a real invoice exists before drafting a prepayment. This is a known limitation. | Reject or delete the draft. A rule for the vendor reduces recurrence but won’t fix drafts already created. |
| A new rule doesn’t stop a transaction from being drafted or miscategorized the way you expected | Payment drafting is a separate stage from rule-based matching, and a rule never re-evaluates a line that’s already matched or drafted. | Confirm the rule’s condition matches exactly. If drafting continues for the same vendor, treat it as the limitation above rather than a misconfigured rule. |
| A rule matches some transactions but not other, similar ones | Rules match on a fixed, narrow set of fields (description, amount, check/reference number). Transactions that vary outside those fields, or that would need a distinction like transaction type or a date range, fall through even with several AND conditions combined. | Split into several narrower rules. See Keep rules narrow. |
| A transaction isn’t matching a rule even though it looks like ones that do match | Rule matching is exact, not fuzzy. A description that varies slightly transaction to transaction (extra reference numbers, reformatted text) won’t match consistently. | Confirm the condition matches the exact field value. If the variation is unavoidable, broaden the condition or match on a more stable field. |
| A new rule doesn’t seem to apply to a transaction that was already sitting unmatched before the rule was created | DualEntry evaluates a saved rule against every unmatched transaction in To Match, not just new ones. This usually means either the transaction doesn’t actually meet the rule’s criteria, or the rule hasn’t been applied yet. Saving a rule doesn’t create or match anything by itself. | Check the transaction for a bolt icon indicating a rule match. If it has one, choose Create & Match on the To Match tab. If it doesn’t, adjust the rule’s condition to match the transaction’s fields exactly. |
| A rule you created to recategorize transactions you already matched changes nothing | Rules only ever evaluate unmatched bank lines. Age doesn’t matter, match state does: a line that’s already matched or drafted is never re-evaluated, so a new rule can’t reclassify it. | Unmatch the affected transactions on the Matched tab, then choose Create & Match on the To Match tab. Unmatching handles one match group at a time, so for a large recategorization contact support rather than working through them by hand. Records created by the original match need to be corrected or deleted separately. |
| An unmatched bank transaction can’t be edited | An unmatched bank feed line isn’t a posted accounting record, so there’s nothing to edit directly. | Match it, exclude it, or post a correcting journal entry so it can be matched instead. See Recording adjustments. |
| A transaction you expected to see in To Match isn’t there | DualEntry automatically excludes transactions dated before your bank-match start date and duplicates detected from another connected account. Transactions can also be excluded manually. | Check the Excluded tab. If it shouldn’t have been excluded, select it and choose Include to bring it back into the matching workflow. |
| An old transaction you manually included stays included even after you unmatch it | Matching or unmatching something older than your account’s bank-match start date marks it to stay included going forward. Unmatching doesn’t undo that. | This is expected behavior, not a bug. If you need it excluded again, exclude it manually from the To Match tab. |
| Matching fails with “Existing match found for provided IDs” or “is already matched” | One or more of the items you selected is already part of another match. The same bank transaction or GL entry can’t belong to two matches at once. | Open the existing match on the Matched tab and choose Unmatch, then try the new match again. |
| Matching fails because one of the selected items is excluded | DualEntry blocks matching for excluded transactions, whether they were excluded automatically or by hand, even if you select the item manually or as part of a larger group. | Go to the Excluded tab, select the transaction, and choose Include before matching it. |
| Matching or unmatching fails with “Match collision detected” or “kept racing a concurrent match. Please retry.” | Another match or unmatch action touched the same bank transaction or GL entry at nearly the same moment. The usual cause is a teammate working the same account, a rule or Bank Match AI matching in the background, or two browser tabs open to the same page. | Retry the action. If it keeps failing, refresh the tab to confirm which items are actually still unmatched before trying again. |
| Uploading a CSV bank statement doesn’t create or post journal entries automatically | Manual upload brings transaction data into Bank Match for matching only; it doesn’t read or post accounting entries from a statement file on its own. | Connect through a certified aggregator for automated feeds, or upload and match manually. See How to Connect Bank Accounts. |
