Why statement descriptors look like gibberish

The anatomy of a billing descriptor

A bank statement descriptor (also called a billing descriptor) has three parts: a processor prefix (who handled the payment), a merchant identifier (who you actually paid), and sometimes a suffix (a location code, user ID, or order number). The card network (Visa, Mastercard, Amex, Discover) delivers this string to the issuing bank, and the bank prints it as-is.

Take SQ *DAILY GRIND CAFE. SQ * is Square's processor token. DAILY GRIND CAFE is the merchant name Square attached to the charge. Without knowing the SQ * convention, the descriptor reads like a random code.

See examples: SQ * is Square — with the full breakdown.

The character limit problem

The card networks limit the merchant descriptor to between 22 and 25 characters (the exact limit varies by network). That's roughly three or four words. When a merchant name like "Verizon Communications Inc." has to fit, the card network truncates it to something like VZWRLSS* — a back-office code that means nothing to the consumer who sees it.

Truncation explains most "mystery" charges. A charge you recognize at full length is unrecognizable at 22 characters, especially when the bank drops spaces or concatenates words.

Example: ACHMA VISB is "Automated Clearing House Merchant Authorization Visa" — five words compressed into eight letters.

Processor tokens vs. merchant names

When a merchant uses a payment processor (Square, Toast, PayPal, Stripe, CCBill), the processor's name goes first and the merchant's name comes after an asterisk or other delimiter. This is the single biggest source of confusion on statements.

TST* RIVERSIDE DINER — the processor is Toast (TST*), the merchant is Riverside Diner. PAYPAL *NOVELTYSHOP — the processor is PayPal, the seller is Novelty Shop. The bank statement hides the connection between the two parts unless you know the delimiter convention.

Processors that use this pattern: SQ* (Square), TST* (Toast), PAYPAL*, PADDLE.NET*, and others.

ACH vs. card network descriptors

Bank transfers (ACH) use a different naming system than card network charges. ACH descriptors come from the originating depository financial institution (ODFI) rather than the merchant, so they often carry bank codes and reference numbers instead of a recognizable merchant name.

IRS TREAS 310 TAX REF is a Treasury ACH credit. 310 is the SEC code (a type of ACH entry), TAX REF is the purpose code. It's a deposit, not a charge, but the code-heavy format makes people search for it.

See the full guide on IRS TREAS 310 and other bank code & transfers entries.

Why the same charge looks different on different banks

A merchant submits one descriptor to the card network, but each bank formats it differently. Chase may add the transaction type (PURCHASE or DEBIT), Bank of America may capitalize differently, and Wells Fargo may trim extra characters. The same coffee shop charge can look like three different merchants across three bank statements.

Our Chase, Bank of America, Wells Fargo, Citi, and USAA hubs document these formatting behaviors.

How to read any descriptor

The unknown-charge playbook walks you through a step-by-step investigation. Start there if you have a specific charge you can't identify.

Otherwise, these tools work on any cryptic line:

• Decode a descriptor — paste the line, get cleaned input.
• Billing phone lookup — if a phone number is in the descriptor.
• Hold or charge? — determine what you're looking at.
• Report a new descriptor — send in one we haven't covered.