A bank description changed and an accounting rule started misclassifying payments

Retrieve examples from before and after the misclassification began. Preserve the original bank text, displayed description, amount, account and assigned category. A bank or data provider may have changed a reference format, while the accounting application may show a simplified merchant description. Establish which field the rule actually reads.

Intuit distinguishes bank text received from the institution from the simplified description shown in QuickBooks Online. Its rule conditions can use different fields, and priority affects which rule applies first. That distinction explains why a rule can behave differently even when the transaction looks familiar to the reviewer.

Identify when the description changed and list transactions classified by the rule since then. Inspect both money-in and money-out activity if the conditions could reach either. Check whether the rule applied only to one account or across several accounts. A broad condition can misclassify unrelated payments that happen to share a short text fragment.

Look for refunds, reversals and transfers mixed with ordinary purchases. The same counterparty name can appear on events with different accounting treatment. A rule based only on the name may be too broad even if it worked during a period with simpler activity.

If automatic posting is active, pause or narrow the affected automation through the supported process while reviewing it. Preserve the old rule definition and the date of the change so another reviewer can understand which transactions were exposed.

Define the intended transaction type and the evidence that distinguishes it. Use account, direction, amount or more specific text where appropriate and supported by the software. Avoid adding conditions solely to fit one example without testing ordinary variations and known exceptions.

Review representative transactions that should match and transactions that should remain excluded. Include a refund or transfer when the same bank text can appear there. Check the rule's position relative to other rules; a correct new condition may still never run if an earlier rule captures the transaction first.

Keep classification separate from substantiation. A correct expense category does not prove the business purpose or replace the invoice. The revised rule should reduce repetitive entry work while leaving the necessary evidence and review responsibilities intact. Record who may edit the rule and require another reviewer for changes affecting tax treatment or several accounts. That makes an unnoticed condition change easier to identify later.

Have the accountant review the affected transactions and correct the supported classifications. Check any tax codes, departments, customer allocations or supplier balances changed by the rule. A category correction alone may not repair all fields the automation populated.

When prior periods are involved, use the company's correction and approval process. Preserve links to the original bank events and documents. Avoid deleting a reconciled transaction merely to rerun the rule; that can disturb the bank reconciliation and create a second problem.

Inspect the first batch after the revised rule is enabled and record the result. Assign an owner to review future bank-format changes and recurring exceptions. If the transaction population remains too mixed for a dependable rule, keep it in a human review queue with a clear decision guide instead of repeatedly broadening the automation.