Why Expense Apps Get Merchant Names and Categories Wrong

An expense app may show the wrong merchant because it often receives a compact payment descriptor, not the shop name printed above the door. That descriptor can include a trading name, processor, marketplace, location, reference, or abbreviation. The app then has to turn incomplete payment data into a readable label and category.

This matters increasingly in Australia. Device-based methods such as mobile wallets accounted for about 40 per cent of in-person card payments in the 2025 Consumer Payments Survey, according to the Reserve Bank of Australia. More wallet capture means more convenient expense records, but it does not remove the need to verify an unfamiliar transaction.

Apple makes the boundary explicit: Wallet can show recent activity, but the card issuer holds the most accurate record, and some Apple Pay transactions may look different from the final charge. See Apple's transaction-history guidance. Google gives similar advice, telling Wallet users to check bank statements for a full debit or credit card history. See Google Wallet transaction help.

A payment descriptor is not a display name

A merchant descriptor is compact payment data intended to help identify a charge. A display name is the human-friendly label a wallet, bank, or expense app presents after interpreting the available data. Those two strings can match, but they do not have to.

The exact handoff varies by issuer, wallet, processor, and capture method. A practical model looks like this:

shop or platform -> acquirer or processor -> card network and issuer -> wallet or notification -> expense app -> reviewed display name

Each step can preserve, shorten, combine, or interpret fields. For example, Visa's Merchant Data Standards Manual allows 25 spaces for the merchant name in its authorisation and clearing systems. Long names must be abbreviated, and a location may be added to distinguish an outlet. Payment-facilitator and marketplace transactions can combine the facilitator or marketplace with the seller.

Processors add their own constraints. Stripe's statement-descriptor documentation describes static prefixes, optional transaction-specific suffixes, and a 22-character limit for a complete card descriptor. It also notes that some banks may display the information incorrectly or not at all. These are examples of why an app cannot assume every incoming string is a clean retail brand.

These examples are illustrative, not real transaction records.

Why merchant names look unfamiliar

The short answer is that the payment route may be more visible than the retail relationship.

Trading and legal identities can differ. A venue may trade under a familiar brand while its payment account uses another registered or operating name. Network rules aim for a recognisable merchant name, but data can still be confusing when viewed outside the shop.

A facilitator or marketplace can share the field. The descriptor may contain both the service that handled the payment and the business that sold the item. That is common enough to be covered explicitly in Visa's merchant-data rules.

Locations and terminals create variants. A chain may add a city, outlet number, or other identifier. Separate businesses at the same premises can also use different points of sale and merchant categories. The same customer-facing brand can therefore generate more than one input pattern.

Abbreviations remove context. Character limits can compress a long name into something a person would never type into a map search. A dynamic suffix can add an order or product clue while leaving even less room for the brand.

The record may still be provisional. A wallet alert is useful for timely capture, but it is not always the final account record. If you use an Apple Pay expense-tracking workflow, keep the issuer's settled transaction as the reconciliation reference.

Why categories differ between systems

A merchant category code, or MCC, usually describes the merchant's primary business. It does not necessarily describe the exact item in your basket.

Visa defines an MCC as a four-digit number that generally reflects a merchant's primary business, based on annual sales volume. If a merchant has multiple lines of business, it may use the category for the line with the highest sales volume or separate categories for different lines. This creates predictable mismatches. A pharmacy purchase inside a supermarket may arrive under a supermarket category. A meal bought through a marketplace may inherit a platform or merchant classification that is too broad for your budget.

An expense app adds another layer. It may translate a network category into its own taxonomy, apply a user rule, consider a confirmed merchant mapping, or infer a category from limited context. Your preferred category can also be different from the network's category. A mixed-use shop might reasonably be Groceries for one purchase, Home for another, and Gifts for a third.

For that reason, category disagreement is not always evidence that one system is broken. It can mean the systems answer different questions:

• Network category: what kind of business accepted the payment?
• App category: where should this transaction sit in a personal spending view?
• User category: what purpose did this particular purchase serve?

Why confident automation can still be wrong

Confidence measures how strongly a system favours an answer. It does not make missing context appear.

Two merchants can share similar abbreviated descriptors. One merchant can sell many kinds of goods. A mapping can become stale after a store changes processor, location, owner, or payment setup. A previous correction can also be inappropriate for a one-off purchase. In all of these cases, automatically choosing the most likely label may produce a polished but incorrect result.

A responsible uncertain state should show enough evidence for a quick decision. It should preserve the source text, distinguish an inferred label from a confirmed one, make the merchant, amount, and category editable, and avoid silently replacing a user's confirmed choice. When accuracy matters, the issuer record and receipt should remain available as references.

What a confirmed correction can teach Marnie

Marnie can learn from a confirmed correction to a merchant, transaction name, amount, or category, then use that confirmation to improve future transactions from that merchant. Confirmation is the important part. A suggestion is evidence to review, not permission to rewrite the record invisibly.

The useful learning target also depends on the field:

• A corrected merchant or transaction name can help normalise a repeated descriptor.
• A corrected category can help with later purchases when the merchant is consistently used for the same purpose.
• A corrected amount records that the captured value needed review. It should not be treated as a reusable amount for future purchases.

Learning has limits. A marketplace seller can change. A department store is mixed-use. A franchise can route payments differently across outlets. A pending record can settle under another label. In these cases, asking again is better than forcing an old answer onto new evidence.

Reviewing uncertain captures also protects forecasts. A duplicate, wrong amount, or wrong category can distort the inputs behind Safe to Spend, even when the forecasting logic itself is working as intended.

What should an expense tracker that learns categories remember?

An expense tracker that learns categories should reuse a confirmed preference only when a new transaction is sufficiently similar. It should distinguish a user's explicit rule from a preference inferred across corrections, and it should not turn an exceptional purchase into a permanent default.

Mixed-use merchants need the most restraint. A supermarket purchase categorised as Health once may contain medicine, while the next visit may be Groceries. A marketplace, department store, or service station can create the same ambiguity. The app should ask again when the merchant supports several plausible categories, recent corrections disagree, the payment route has changed, or the record may represent a different purchase.

Before using a correction as learning evidence, resolve any duplicate-looking transactions. Otherwise, two records for one payment can create a false pattern. Category quality also affects AI spending insights, so a reviewable exception is more useful than a confidently repeated mistake.

Community learning changes the privacy trade-off

Shared merchant knowledge can reduce repeated cleanup, but only if the shared fields are narrow and the controls are clear.

In Marnie, community merchant learning is disclosed as on by default and can be disabled in Settings. It submits a normalised merchant name, confirmed category, country, and general source type. It excludes amounts, dates, account details, transaction IDs, and raw transaction text.

Core financial records are stored locally on the device. Cloud Backup is optional and off by default, and raw notification bodies and payloads are removed from a private backup. Deleting a Marnie account removes contributor-level merchant-learning records along with the remote account, account-linked records, cloud backup objects, and local Marnie financial storage.

That design involves a clear trade-off: contributing a small, normalised merchant record can improve recognition, while disabling the feature keeps those contributions from being submitted. Read the local-first money app privacy guide and Marnie Privacy Policy before choosing which setting fits your preferences.

How to audit a repeated merchant error

Start with the record, then decide whether the pattern is safe to reuse.

1. Compare the amount and date with the receipt or order history.
2. Check the final issuer record, especially if the wallet entry is pending or unfamiliar.
3. Look for a processor prefix, marketplace name, store number, city, or order reference.
4. Confirm whether the purchase came from a mixed-use merchant.
5. Correct the merchant, transaction name, amount, and category fields that are actually wrong.
6. Recheck the next transaction from that merchant before trusting the mapping broadly.

Escalate rather than relabel if the charge is still unrecognised, appears duplicated, has an unexpected final amount, or cannot be matched to a receipt or order. A neat category is not proof that a payment is legitimate. Contact the merchant or card issuer using a trusted channel when you need to question the charge.

If you prefer to reconcile several capture methods without account aggregation, see how to track spending without linking your bank account.

Frequently asked questions

Why does the same shop have multiple merchant names?

The shop may use different processors, payment facilitators, terminals, outlet identifiers, or online and in-person payment paths. One record may also be provisional while another is final. Match the amount and date first, then compare the issuer record before saving a broad merchant rule.

Why did my transaction category change again?

The app may have received different merchant data, applied a rule, used a confirmed correction, or reclassified an ambiguous merchant. Mixed-use businesses are especially difficult. Check whether the new category reflects the purpose of this purchase, not merely the merchant's primary business type.

Can my correction affect other Marnie users?

It can contribute to community merchant learning when that setting is enabled. The contribution is limited to the normalised merchant name, confirmed category, country, and general source type. It excludes the amount, date, account details, transaction ID, and raw transaction text. You can disable the setting, and account deletion removes contributor-level learning records.

Should an expense app auto-approve a learned merchant?

Not in every case. A repeated, specific descriptor may justify a strong suggestion, but marketplaces, mixed-use retailers, changed processors, and provisional records still need context. The safer pattern is to show the source, make the result editable, and ask for confirmation when the evidence is ambiguous.

The practical rule

Treat a wallet notification as a timely signal, a descriptor as an identifier, and the final issuer record as the reconciliation reference. Then let confirmed corrections reduce future work without hiding uncertainty.

See how Marnie captures and reviews spending across Apple Pay Shortcuts, supported Android notifications, and manual entry.