Fix one wrong transaction category without changing the right ones

A category mismatch is a reason to look closer, not permission to rewrite every transaction from that merchant. GlidePath’s Transaction health view keeps this repair deliberately narrow: find one same-description group, inspect the matching rows, select only the row that is wrong, and verify the result.

What you’ll learn

• What a category-variation group does—and does not—tell you
• How Review rows preserves the exact account, merchant, and description scope
• How to change one selected transaction without changing its neighbors
• Why correcting a row does not repair a future payee rule

Before you start

This workflow applies when matching rows on the same account use different categories. If every row is categorized consistently, Transaction Health has no variation group to show, even when the shared category is wrong.

Open Transaction health under Money. Look for Category variations.

Step 1 — Treat the group as a prompt

A variation group means transactions with the same normalized merchant and transaction description, on the same account, currently use more than one category. It does not decide which category is correct.

That boundary matters. A warehouse store, pharmacy, or bank can legitimately produce similar-looking rows that belong in different categories. Read the dates, descriptions, amounts, and surrounding records before changing anything.

Step 2 — Open the exact rows

Choose Review rows on the group you want to inspect. The Transactions page opens with an Exact category-variation rows notice.

That view stays scoped to the same:

• account
• merchant
• transaction description

Do not clear the review filter while you are deciding which row is the outlier. The narrow scope is the safety feature.

Step 3 — Select only the row that is wrong

Compare the visible rows and tick only the transaction whose category the evidence does not support. Leave the already-correct rows unchecked.

Open Edit selected rows, tick Set category, and choose the corrected category. Then select Review selected change.

The confirmation names how many rows will change. Stop if that count is larger than the number you intentionally selected.

Step 4 — Apply and verify

Choose Apply selected change. The page reports how many rows were updated and keeps the exact review scope in place, so you can verify the corrected row beside the rows that were already right.

Return to Transaction health. If the matching group now uses one category throughout, that variation group disappears. That proves the mismatch was resolved; it does not prove every category choice is universally correct.

Try it: Open Transaction health ↗ (works when the desktop app is running on this computer—just browsing? Use the fictional demo)

The rule is a separate repair

A row-level category edit changes the selected transaction IDs. It does not create or repair a learned category rule for future imports.

If the existing rows are now right but the next import keeps assigning the wrong category, review the payee rule separately. GlidePath stores category rules in payee-rules.csv; Clean up payee names manages display-name cleanup instead, so changing a rename rule will not change transaction categories.

The safe pattern

1. Narrow the evidence.
2. Decide which row is actually wrong.
3. Select only that row.
4. Confirm the selected-row count.
5. Apply the correction.
6. Verify the matching rows and the Transaction Health result.

That is slower than changing an entire merchant blindly—and much faster than repairing a ledger after a broad rule changed the right rows along with the wrong one.