Why we categorise transactions and why merchant names are difficult

A transaction list is accurate in one sense and confusing in another. The amount and date may be clear, while the description looks nothing like the place where the purchase happened.

Budgeting software categorises transactions because a long statement is hard to read as a pattern. Grouping activity into areas such as groceries, transport, household costs and subscriptions gives the interface a way to summarise what happened over a period.

The category is an interpretation added by the product. It is not a fact supplied with perfect consistency by every bank.

What a bank feed can contain

An open banking transaction can include an amount, currency, booking date, value date, status, account reference, transaction code and one or more description fields. Merchant information may also be present. Which fields are populated depends on the bank, account, payment type and stage of processing.

A card transaction might arrive with a recognisable trading name. It might instead show the legal company name, a payment processor, a store number, a town, a shortened reference or a string assembled by several systems.

A bank transfer often reflects whatever reference the sender entered. A direct debit may use the service provider's legal entity rather than the consumer brand. Cash withdrawals, refunds, fees and internal transfers have different structures again.

The product receives this uneven material and has to turn it into something readable without pretending the source is cleaner than it is.

Why merchant names change

The name above a shop door is not always the name that settles a payment. A hospitality group can operate many venues under separate trading names. An online marketplace can appear as the merchant even when the order came from an individual seller. A digital wallet can sit between the card and the merchant.

Location text is not always a reliable clue. Head-office processing can attach a town that is far from the purchase. Store numbers can be reused or omitted. International processing can add a country code even when the customer bought something from a UK-facing website.

Descriptions can also change between pending and completed states. The first record may carry a temporary processor label. The completed record may contain a clearer merchant name. Treating them as unrelated can create a duplicate or assign two categories to one purchase.

How a category is assigned

Categorisation usually combines several signals. The product can inspect transaction codes, merchant category information, cleaned description text, known merchant mappings, payment type and previous corrections associated with the user.

Some cases are straightforward. A known supermarket descriptor has a strong groceries signal. Others are not. A large retailer may sell food, clothing, electronics and household items under the same merchant identity. The payment record does not contain the shopping basket, so the category can only describe the merchant context.

Rules are useful for stable patterns. They also need boundaries. A rule that classifies every transaction containing a common word can catch unrelated merchants. A mapping that was correct for one payment type can be wrong after a provider changes its descriptor.

The interface therefore treats automatic categories as editable product data. A correction is not an admission that the bank record was wrong. It means the user's understanding of the purchase is more specific than the description available to the software.

Transfers require different treatment

Moving money between a person's own accounts can look like spending from one account and income into another. If both accounts are connected, counting each side as ordinary activity distorts summaries.

Matching transfers is not always simple. Dates can differ, references can be blank and amounts can be altered by currency conversion or fees. Two unrelated transactions can share the same amount. The product needs a confidence threshold and a way to reverse a mistaken match.

Shared payments add another ambiguity. A restaurant payment may later be partly reimbursed by friends. The feed contains separate movements, not the social context that connects them.

Recurring activity is a related problem

Subscription and bill detection looks for repeated descriptors, amounts and timing. A monthly service that changes its amount slightly can still be recurring. A regular supermarket shop is repeated activity but not a subscription. An annual renewal provides less history than a monthly payment.

Categorisation supplies useful context, but it cannot be the only signal. The product has to keep the original transaction visible and distinguish a detected pattern from a confirmed one.

Why corrections matter

An editable category makes the output more honest and more useful. The correction can apply to one transaction or, where the user chooses, to future transactions with a matching merchant pattern.

That preference should not rewrite the original amount, date or description. Source fields and product interpretation serve different purposes. Preserving both makes it possible to explain why an item appears in a report and to investigate a mismatch later.

Corrections also reveal where a global merchant rule is too broad. They can improve the product's mapping logic in aggregate, but personal transaction details do not need to become public training examples to achieve that.

Categories are a reading aid, not a verdict

A category is there to organise information. It does not say that a transaction was good, bad, necessary or wasteful. Two purchases at the same merchant can have different meanings to different people.

The product's responsibility is to show the original record, make its interpretation clear and allow uncertainty to remain visible. Merchant names are difficult because payment infrastructure was built to settle transactions, not to write a human-friendly diary. Categorisation is the translation layer, and translations sometimes need correction.

For current service details, read the company's open banking explanation and Privacy Policy.