Transaction categorization controls how Worthic turns raw transaction activity into cash flow reports, targets, forecasts, real estate statements, business summaries, and search/filter results. A transaction can carry a simple category label, but the Worthic model is richer: it stores a category bucket, parent category, subcategory, category labels, and a category assignment source.
The practical result is that users can work with familiar labels such as “Groceries” or “Rental income”, while Worthic keeps enough structure to group transactions correctly in reports.
Category trees
Worthic uses category trees rather than one flat category list. A tree is scoped by:
- Workspace
- Reporting-line type: personal, business, or real estate
- Account type: for example transactional, liability, or asset/investment
- Business-line specific scope
A category tree has three levels:
- Bucket: the top-level reporting group, such as Income, Expenses, Transfers, or Capital items.
- Parent category: the mid-level reporting section.
- Subcategory: the category selected on a transaction.
Worthic seeds a default tree where a category tree does not yet exist, in the case of new reporting line and account type combinations. Current defaults include personal transactional accounts, personal investment-detailed accounts, business transactional accounts, real estate transactional accounts, and liability accounts.
Editing category trees
Users with edit access can add, rename, reorder, move, or deactivate category nodes from the category tree editor. Viewers cannot change categories.
Category edits are ID-based. Existing transactions store the selected category IDs and the labels that were present at the time. When Worthic displays transactions, it tries to resolve the current active category node by ID. If the category, parent, and bucket are still active, the transaction reflects the current category labels. This means renaming or moving an active category can affect how historical transactions display and report, because they still point to the same category ID.
If a category node is deactivated, historical transactions are not deleted. Worthic falls back to the stored labels on the transaction. This preserves the old transaction context even where the category is no longer offered for new selection.
Reordering categories changes the tree presentation, not the transaction amounts.
Immutable subcategories
Some subcategories are protected because they support reporting models and structured breakdowns. Protected subcategories cannot be edited, moved, or deleted from the category editor.
Examples include selected personal payroll/tax categories and selected real estate categories such as rental income, booking fees, direct costs, finance costs, deposits received/refunded, and related property-reporting categories. These categories are protected because reports and document workflows depend on their meaning remaining stable.
Manual categorization
A user can edit a transaction and select a category from the relevant category tree. The available tree depends on the transaction’s account and reporting-line context. Manual selection writes the structured category IDs and labels onto the transaction.
Manual categorization is the strongest user-controlled categorization. Later saved rules can forward-apply only to pending-confirmation transactions that are uncategorized or machine-categorized; they do not overwrite confirmed/manual historical work in bulk.
Transaction splitting across categories and reporting lines
A transaction can be split into multiple components. Each split component has its own amount, date, reporting line, description, category, notes, and supporting links. The split total must match the source transaction amount before Worthic saves it.
This supports cases such as one card payment containing groceries and household supplies, one bank transfer that belongs partly to a personal line and partly to a business line, or one imported transaction that needs to be divided across real estate income and fees.
Technically, Worthic stores a split group for the source transaction and creates separate split-component transactions. Those components flow into account balances, cash flow, targets, forecasts, and reports as separate categorized lines. The transaction card shows a “Split transaction” marker.
When a user creates a split transaction with multiple components, Worthic can also save a split rule from the source description. Future matching imported transactions can then be auto-split using the saved component pattern.
Auto-categorization
Worthic supports several types of auto-categorization:
- Imported category match: when an imported document or statement provides category information that Worthic can map into the category tree.
- Saved auto-rule: a rule based on transaction description text, with contains or exact matching. Rules can be scoped by reporting-line type, account type, optional reporting line, and optional account.
- History similarity: Worthic can infer a category from similar previously confirmed transactions on the same account/context.
- AI suggestion: where history or rules are ambiguous, AI can suggest a category during document processing or review.
- Auto-split by rule: a previously saved split pattern can create multiple categorized split components automatically.
- API assignment: API clients can submit transactions with category fields where permitted.
Rule matching is context-aware. More specific rules are preferred over general rules: scoped reporting-line matches outrank broad matches, account-specific matches outrank general account-type matches, exact matches outrank contains matches, longer match text wins where relevant, and higher-use/more-recent rules rank higher.
When a new auto-categorization rule is saved, Worthic forward-applies it only to pending-confirmation transactions that are uncategorized or already machine-categorized by import/rule/split logic. This is deliberate: it helps clean up current review work without unexpectedly rewriting confirmed history.
Auto-categorized UI markers
Transaction cards show categorization provenance where it matters. Current markers include:
- “Imported category match” for categories supplied or matched from an import.
- “Auto-categorized” for saved rules, history similarity, or AI suggestions.
- “Auto-split by rule” for transactions split automatically from a saved pattern.
- “Split transaction” for split components or grouped split transactions.
- “Confirmation pending” where the transaction still needs user review.
These markers help users decide what needs attention. A machine-assigned category may be right, but it is still useful to know that it came from an import, rule, history match, AI suggestion, or split rule.
Review behaviour
Pending-confirmation transactions still affect balances and downstream reporting, but their review state tells the user they have not yet been accepted as final. From the workbench, users can confirm, edit, discard, restore excluded candidates, apply tags, and correct categories.
Discarding a pending transaction removes it from the ledger, so it stops affecting balances and reporting. Confirming it changes the review state but does not suddenly make it start affecting balances, because it was already included once committed as a ledger transaction.