What is this charge on my bank statement? A step-by-step way to find out

You're scanning your statement and there it is: a charge you don't recognise, from a name that means nothing to you. Before you assume fraud and start a dispute, it's worth knowing that most unrecognised charges turn out to be legitimate — they just appear under a name that doesn't match the shop, app or service you actually used.

Why the name on your statement looks wrong

The descriptor on your statement is set by the merchant's payment processor, not by the brand you interacted with. Three things routinely garble it:

• Processor prefixes. Small businesses that take payments through Square appear as SQ *SOMETHING; PayPal checkouts appear as PAYPAL *SELLER; app-store purchases hide behind APPLE.COM/BILL or GOOGLE *. The prefix tells you the rail, and the part after it is your actual merchant. Our prefix guide decodes the common ones.
• Legal names vs trading names. The cafe you know as one name may bill as the owner's registered company. Restaurant groups, franchises and online sellers do this constantly.
• Truncation and reference noise. Statement fields are short; city names, store numbers and reference IDs crowd out the part you'd recognise.

A five-minute method

1. Check the date against your life. Money leaves on the settlement date, often one to three days after the purchase. A Saturday coffee can post on Tuesday.
2. Search the exact descriptor. Paste the whole line — prefix, asterisks and all — into a descriptor lookup or a search engine. Exact strings match far better than a cleaned-up guess.
3. Match the amount to a subscription. Amounts like 9.99, 12.99 or 15.99 recurring monthly are usually a subscription — possibly a free trial that converted. Check the same amount in previous months.
4. Ask your household. Shared cards and family app-store accounts explain a surprising share of "mystery" charges.
5. Call the number, not the bank, first. Many descriptors include a phone number or URL. A refund from the merchant is faster than a dispute — and disputing a legitimate subscription can get your account with that service suspended.

When it actually is fraud

Genuine red flags look different: several small charges in quick succession (card testing), merchants in countries you've never transacted with, or amounts just under common verification thresholds. If the charge fails the five checks above, contact your bank immediately — for cards, ask them to replace the card, not just reverse the charge, because the number is already in someone else's hands.

A field guide to common descriptor patterns

Once you've seen a few hundred statements, the same shapes repeat. Here are the patterns worth memorising:

• SQ *NAME / SQU*NAME — Square. The merchant is a small business: cafes, barbers, market stalls, food trucks. The part after the asterisk is the trading name, often truncated.
• PAYPAL *NAME / PP*NAME — PayPal checkout. The name is the seller's PayPal business name, which may differ from the website you bought from. Your PayPal activity page has the exact order.
• APPLE.COM/BILL / GOOGLE *SERVICE — app-store billing. One line can bundle several subscriptions; check the store's subscription page, not the merchant.
• AMZN MKTP / AMAZON.CO.UK*ORDER — Amazon marketplace. Match the amount against your order history; split shipments create multiple part-charges from one order.
• TST*NAME — Toast, a restaurant point-of-sale. The charge is from a restaurant even if the name looks corporate.
• POS DEBIT / CHKCARD prefixes — your own bank's labelling for card payments, not a merchant. The merchant is in the text that follows.
• All-caps company + city you've never visited — usually the merchant's head-office or processor location, not where the purchase happened. An online order from a company registered elsewhere is the classic case.

The full prefix guide covers these and the rest of the processor patterns in detail, with reliability notes for each.

Pending vs posted: why amounts and names change

A charge often appears twice in slightly different forms. The pending entry posts at authorisation with a provisional descriptor and sometimes a provisional amount — petrol stations pre-authorise a fixed sum, hotels and car hire add deposit headroom, restaurants may authorise before tip. When the transaction settles (typically one to three days later), the descriptor and amount take their final form. If a mystery line is pending, wait for settlement before investigating — half the time it resolves into something you recognise, and banks generally won't dispute a pending transaction anyway. Bank-side codes beside the descriptor (POS, ACH, DD…) narrow things further — the transaction code lookup decodes those.

How automated identification actually works

When you paste a descriptor into our lookup, four signals are checked in order of reliability: known processor prefixes (theSQ * family — see the Square and PayPal guides), exact matches against a database of thousands of verified merchant descriptors, alias and trading-name matching with location context, and — only when those fail — AI research over public sources. Every result carries a confidence level, because a wrong identification presented confidently is worse than an honest "unknown". Community confirmations from other users who verified the same descriptor raise confidence over time.

Checking a whole statement at once

Doing this line-by-line for a full statement is tedious, which is why we built the analyzer: upload a statement and every descriptor is matched in one pass, with subscriptions, trials-turned-paid, duplicates and fees flagged automatically — and honest confidence labels on every match. The manual method above is exactly what it automates, including the exact-string matching and the pending-vs-posted awareness.