| 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 | Rules aren’t retroactive, and payment drafting is a separate stage from rule-based matching. | 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 | A saved rule is evaluated against every unmatched transaction in To Match, not just new ones, so 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, select Create & Match on the To Match tab. If it doesn’t, adjust the rule’s condition to match the transaction’s fields exactly. |
| 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. |
| 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. |
