Uncategorized transactions

A transaction with no category isn't a failure — it's the app declining to guess. There are exactly two reasons it happens, they need different fixes, and the review screen separates them for that reason.

Reach it from the To review card on the Transactions screen, which counts uncategorized transactions alongside any unresolved duplicate groups.

Why a transaction has no category

No matching rule. Nothing you have written, and nothing the first pass created, describes this transaction. The usual causes are a merchant you have never had before, a one-off (a paper cheque, an ATM withdrawal, a foreign transaction fee), or a merchant whose descriptor is different enough from its usual form that the pattern misses it.

A conflict. Two or more rules matched, tied at the same rank and at the same level of specificity, and named different categories. There's no principled way to pick between them, so nothing is applied and the transaction is handed to you with both rules named.

Note what a conflict is not. Overlapping rules that agree on the category are resolved silently — the broadest one is credited and nothing is reported. Rules that disagree but differ in specificity are resolved silently too: the more specific pattern wins, so UBER EATS beats UBER without ever asking. A conflict is the narrow case where the app genuinely has no basis to choose.

Fixing a no-match

The row gives you both repairs, side by side:

• Set the category from the picker to settle this one transaction and move on. Right for a one-off — a cheque, a refund, a fee you'll never see again.
• Create rule opens the rule editor prefilled from this transaction's description. Right for anything that will happen again, which is most things.

If you take the rule route, consider switching the match target to Merchant and using the Match this merchant button. The description the bank wrote carries a store number and a city; the merchant key doesn't, so the rule keeps working when the same merchant charges you from a different location. See Categories and rules.

Deleting a transaction is a legitimate third answer, and it's available on the row. Sometimes a line in a statement isn't a transaction you care about at all. Deletes are recoverable — see Your data.

Resolving a conflict

Conflict rows show a line naming the tied rules and the category each one wants. Resolve expands them so you can edit or delete any of them in place.

You have four ways out, roughly in order of how often they're right:

• Make one rule more specific. Usually one of the two is meant to be narrower than the other, and the fix is a pattern that says so — the specificity tiebreak then resolves it for good, with no further conflicts from that pair.
• Change one rule's rank. A lower rank wins outright. Right when one rule genuinely takes priority and no pattern change would express that.
• Delete the rule you didn't mean to write. Common after a first-pass categorization, where a broad merchant rule and a rule you wrote yourself land on the same charge.
• Override the transaction. Settles this row but leaves the conflict in place for every future charge that hits both rules. Fine as a stopgap, not as a fix.

Editing or deleting a tied rule re-checks the transaction immediately, and the background pass carries the change to everything else the rule touches.

If several transactions are conflicting for the same reason, fix the rules once rather than the transactions individually — one pattern edit usually clears the whole run.

When the queue is empty

An empty queue means every transaction has a category from a rule or from an override — and the screen says so plainly.

Worth knowing: this screen tells the difference between "nothing to review" and "nothing loaded yet". A load that failed shows an error, never a clean bill of health. Zero rows because your data hasn't arrived is not zero rows because there are none.