The rule for merchant aliases
Preserve the bank description, normalize in a separate field, and use cautious rules for payment processors and branches.
The same merchant can appear under multiple descriptions, while one payment processor can represent many merchants. Normalization makes patterns visible but can also create errors if it is too aggressive.
Keep an audit trail
Use separate columns for raw description, normalized merchant, confidence, and review note. Never replace the raw description. A future statement or receipt may be needed to correct the mapping.
Apply rules from specific to general
- Exact known aliases, such as branch or store-number variants.
- Stable prefixes with changing reference numbers.
- Payment-processor descriptions only when the underlying seller is present.
- Manual review for ambiguous abbreviations.
Merchant normalization at a glance
A normalized merchant joins genuine name variations without replacing the raw bank description. The original text remains the evidence for later corrections.
Signals for a safe alias
- A stable merchant name with changing branch or reference numbers
- A payment processor string that also names the underlying seller
- Repeated examples that do not match unrelated businesses
Finish with this decision
Leave the merchant unresolved when the seller cannot be supported. A missing label is safer than a confident but false match.
Use the cleaned merchant layer
Build aliases only after the underlying transaction file is preserved and checked through How to Clean Transaction Data Before Analysis.
If a repeated description may represent a service agreement, test its cadence using How to Find Forgotten Subscriptions.
Review the normalized merchants and their category totals in the merchant spending analysis tool.
Avoid category leakage
A merchant is not always a category. A pharmacy can sell medicine, groceries, cosmetics, and photos. Normalize the merchant first; classify the purchase separately using receipt evidence or a consistent dominant-purpose rule.
Maintain the rules
Track how often each rule is used and sample the results. Retire aliases when ownership changes or one pattern begins matching unrelated merchants.
Design rules that fail safely
An alias rule should be narrow enough that a false match is unlikely. Exact aliases and merchant-plus-location patterns are safer than deleting every number or processor prefix. Keep the rule used, the date added, and a sample raw description so later errors can be traced.
| Raw description | Safe output | Confidence |
|---|---|---|
| RIVER CAFE #1880 | River Cafe | High when branch digits are the only change |
| SQ *RIVER CAFE 4912 | River Cafe | High when the seller name is present |
| SQ *PAYMENT | Unresolved processor charge | Low because the seller is missing |
| ONLINE PAYMENT THANK YOU | Card payment transfer | High after the matching account is confirmed |
Measure rule quality, not only coverage
For every bulk rule, inspect a sample of matched transactions and count false positives. Prioritize rules that affect a large amount or many rows, but keep an unresolved queue when descriptions are genuinely ambiguous. A coverage rate near 100% is not an achievement if unrelated sellers were merged.
Separate merchant normalization from transaction classification. The same normalized supermarket can contain groceries, pharmacy items, fuel, and a cash withdrawal. The merchant layer supports grouping; it does not decide the purpose of every purchase.
Review rules when a merchant changes ownership, a processor changes its format, or a known alias begins appearing with unfamiliar amounts or locations.