Reference

Transaction Categorization

Review imported transactions, AI suggestions, matches, transfers, exclusions, rules, and posting outcomes.

Transaction review turns source activity from Plaid, uploaded documents, manual entry, QuickBooks, or the client portal into supported journal entries. Open Banking and work from the transaction feed.

Understand the row state

StateMeaning
PendingThe transaction still needs a final accounting outcome
PostedThe row is linked to a journal entry
ExcludedThe row was intentionally kept out of the books
ReviewWesley found one or more possible duplicates that must be resolved
DuplicateThe row was confirmed as a duplicate and should not be posted again

Filtering a row does not change its state. Posting, excluding, or resolving a duplicate does.

What Wesley can suggest

Wesley can use merchant text, description, amount, direction, frequency, account, prior decisions, documents, and available accounting context to propose:

  • a ledger account or split;
  • a vendor, customer, or employee;
  • a class, location, or project;
  • a memo;
  • a match, transfer, or post action;
  • a rationale and confidence indicator.

A suggestion can be proposed, accepted, or dismissed. It is review evidence, not proof. Accepting an account without understanding the transaction can create a balanced but incorrect journal.

Choose the accounting action

Quick Post or Post

Post when the business purpose, account, payee, dimensions, date, and evidence are sufficient. Verify split lines total the source amount and the resulting journal is balanced.

Match

Match when the bank row is the cash side of an existing journal, invoice payment, bill payment, or other record. Compare amount, date, account, entity, and source evidence. Do not create a second journal for the same event.

Transfer

Use Transfer for movement between the client's own accounts. Wesley's strongest exact-transfer candidates use equal amounts on opposite sides of different accounts within a narrow date window, but you must still confirm ownership and currency. Credit-card payments, loan payments, processor settlements, and owner activity are not automatically transfers merely because amounts match.

Exclude

Exclude only when the transaction should not affect the books, such as a true duplicate or a bank-feed entry that is not a real transaction. Exclusion is not a substitute for categorizing a difficult business transaction.

Ask client

Ask the client when the business purpose or support is missing. The request can stay linked to the transaction or journal so the answer is reviewable later.

Categorize safely

  1. Confirm the real-world account and transaction date.
  2. Open linked documents and the original source description.
  3. Identify the business purpose and transaction intent.
  4. Check for an existing match or transfer counterpart.
  5. Select the account and payee.
  6. Add class, location, project, memo, or split lines when required.
  7. Review the suggestion rationale and unusual-amount indicators.
  8. Post, or leave the row pending with a clear follow-up owner.

Never guess when the source document is missing, the merchant is ambiguous, the amount is unusual, the same row could receive materially different accounting treatment, or tax/owner/loan/payroll activity is not understood.

Use bulk actions carefully

Bulk actions are appropriate only when every selected row has the same accounting outcome. First filter to a narrow set, then spot-check dates, signs, source accounts, payees, and evidence. A repeated description can still contain refunds, annual charges, or different business purposes.

Create rules for stable patterns

Rules can evaluate merchant, description, amount, account, direction, and transaction scope, using grouped AND/OR conditions and exclusions. A rule targets one ledger account and can add at most one payee plus supported class, location, project, and memo values.

  • Pending rules are drafts for review and preview.
  • Active rules apply to matching pending transactions according to priority.

Preview the matching rows before activation. Keep conditions narrow enough to explain. Reverting an applied rule can pause it and attempt to unpost affected transactions; closed periods can block that rollback.

AI operating modes

Client settings separate suggestion behavior from permission to create accounts:

  • Self-Driving automates eligible activity while leaving flagged checks and exceptions for review.
  • Collab focuses automation on repeated, routine work.
  • Off leaves AI in a suggestion-oriented role.

Allowing AI to create new chart-of-accounts records is a separate explicit setting. Turning on an AI mode does not by itself authorize account creation.

Check before leaving the feed

  • Posted rows have the intended journals and evidence.
  • Duplicate-review rows are resolved, not hidden.
  • Transfers have both sides or a documented exception.
  • Remaining pending rows have a client question, document request, or reviewer owner.
  • Rules are narrow, previewed, and active only when trusted.
  • The period can still be reconciled to the statement.

See Statuses and Glossary for related document, work, and reconciliation states.