Category rule record
Document each reusable rule well enough that another reviewer can test or reverse it.
Trigger
Specify the normalized description, account, value condition, or payment channel that activates the rule.
Destination
Assign the category and subcategory in separate fields while retaining the bank's original description.
Exceptions
Identify refunds, transfers, marketplace activity, and mixed-use payments that must be reviewed manually.
Review history
Keep the confirmer, review date, and reason for every rule change.
Let the intended decision determine the category design
Start by defining what the classification must help decide. A budget, accounting ledger, tax file, and unauthorized-activity review each need different category boundaries.
Use a short top level, adding narrower subcategories only when they affect an action or conclusion.
Design categories for a decision. Household analysis may group discretionary spending with saving, debt, health, transport, food, and housing. Bookkeeping instead needs account codes, while tax review requires supported treatment. Keep these systems in separate fields over a stable source ledger so changing a budget label cannot modify bookkeeping or tax classification.
Write a category definition with inclusions, exclusions, and an escalation rule. For example, a transport category might include public transit, fuel, tolls, and verified ride services while excluding vehicle loan principal, insurance, and transfers to a travel wallet. A marketplace payment should remain unallocated until the underlying purchase is known. When definitions are explicit, two reviewers can reach comparable results and a later change can be applied as a documented rule update rather than a silent rewrite of prior months.
Standardize merchant identity while retaining the bank's wording
Keep the exact transaction description beside a normalized merchant field. Strip changing references only when enough information remains to identify the recipient reliably.
Shared words do not justify combining separate recipients or locations into one merchant identity.
Represent transfers and supported splits without changing totals
Assign owned-account transfers a distinct type and connect both entries where possible, preventing income and spending summaries from counting them twice.
Divide an entry only with evidence such as an itemized receipt. Retain the source total and check that all components reconcile to it.
Handle split transactions without altering the source amount. A fictional 186.40 warehouse-store payment might contain 112.20 of groceries, 44.20 of household supplies, and 30.00 of clothing. Preserve the 186.40 bank row, then create linked allocation lines whose total equals the source. Record whether the split came from an itemized receipt or an estimate. If evidence is missing, keep the whole row in a broader reviewed category or unresolved queue instead of manufacturing precise allocations that the statement cannot support.
Send ambiguous and unusual classifications for review
Require inspection for uncertain rules, first-seen merchants, cash activity, and amounts that are unusually large for the account.
Record human corrections so the next data refresh preserves rather than overwrites a verified choice.
Measure review debt in both rows and value because one open 4,000 transfer carries different risk from ten unknown coffee purchases. Report confirmed, rule-assigned, manually reviewed, and uncategorized values plus the largest exceptions. When charts omit unresolved activity, show the excluded amount so polished presentation cannot overstate underlying decision quality.
Measure category coverage before presenting a chart. Report total debit value, confirmed category value, rule-assigned value, manually reviewed value, uncategorized value, transfer value, and the largest unresolved rows. Ten small unknown purchases and one unknown 4,000.00 transfer carry different analytical risk. If a visualization excludes unresolved activity, place the excluded amount beside it. A complete-looking chart can otherwise suggest that every transaction was understood even when a material part of the ledger remains outside the category model.
Write category rules before applying them
Give each category explicit boundaries supported by examples of what belongs and what does not. For a household food budget, restaurant dining and delivery might qualify while prepared food bought at a grocery counter does not; tax classifications need separate rules and stronger support.
Build hierarchy only to serve the decision. Housing may group rent or mortgage, repairs, utilities, and insurance, whereas merchant-level categories often add noise and ongoing maintenance without improving the comparison.
Measure category coverage and review debt
Show how much debit value is confirmed, assigned by rule, assigned manually, or still uncategorized. Coverage should remain visible so a polished chart built from partially reviewed rows is not mistaken for a fully verified result.
Recheck classification logic when merchants are new, descriptions change, or values are unusual. Store human overrides apart from automated rules so later imports preserve reviewed decisions.
After applying consistent categories, test their concentration with the browser-based spending analyzer without uploading account data.
If the same categorized merchant appears on a regular cadence, follow the recurring bank payment review before labeling it as a subscription.