Handle a merchant name that the client does not recognize

Preserve both merchant labels while investigating

Give the client recognizable transaction context and retain their explanation so the reviewer does not have to ask again.

If your evidence is a supplier invoice PDF, ParseMill can turn its invoice details and line items into a reviewable Excel workbook. Compare the source and correct the result before export. Receipt photos, missing-document requests and transaction matching belong in your existing receipt and accounting tools.

If the client does not recognize the transaction, record that response and route it through the organization's appropriate review process. Do not pressure the client to select the nearest receipt merely to clear a query. An unrecognized transaction and a missing receipt can require different next actions.

Build a descriptor comparison

Capture transaction date and date type, descriptor, amount, currency, limited account reference, receipt merchant, receipt date and any order or payment reference. Preserve original text alongside any proposed normalized label. The comparison should show the evidence behind the relationship, not just the conclusion.

Intuit: Matching bank transactions describes reviewing links between bank transactions and existing records. Intuit: Transaction requests describes collecting transaction explanations and receipts. The proposed descriptor worksheet prepares a focused question for that review. It does not claim that software suggestions or a client's first impression establish a valid match.

Compare a fictional payment processor label

In this synthetic example, the bank descriptor differs from the shop name printed on the receipt. Staff record the potential relationship without assuming the descriptor is a known alias.

A focused question can ask whether the client recognizes the purchase and can provide the payment or order reference connecting it to B96. The date and amount comparison narrows the investigation, while the additional context supports or rejects the proposed relationship. If several receipts have the same amount, keep each candidate visible.

Avoid turning a one-off match into a universal rule

Even after a reviewer accepts this relationship, do not automatically map every future PAY*CEDAR17 entry to the same merchant or category. Record the scope of the decision and test new transactions against their own evidence. Shared payment descriptors and repeated amounts can create misleading similarities.

• Retain the raw descriptor and receipt name.
• Distinguish purchase dates from posting dates.
• Compare currency as well as amount.
• Record supporting references or client confirmation.
• Escalate unrecognized or conflicting items appropriately.

If the receipt contains a different entity or currency, make that conflict explicit. Do not remove inconvenient text when normalizing merchant labels. A cleaned display name should make the record easier to read while preserving the original information needed for review.

Close the recognition question with a basis

Record who confirmed the relationship and which evidence supported it. If the reviewer rejects the candidate, retain the rejection reason and keep the transaction query open with the correct next action. Avoid leaving the rejected receipt attached in a way that still implies an accepted match.

Use the related workflow guide for the wider receipt process and the workflow audit checklist to examine recurring descriptor confusion. A practical workflow test includes two same-amount candidates and one unrecognized item, so success depends on evidence rather than a convenient name guess.