Skip to content

IR56M Recipient modal audit list — show enriched displayName with the raw bank description as tooltip

Why (owner, 2026-06-25)

The audit-list on page 1 of the IR56M Recipient modal (the contributing- transactions table T-121 added) was showing the raw bank-statement description verbatim — e.g. Purchase at PAYPAL *OMNISALE, … — which matches the Bank's wire-text but doesn't match the enriched display name the rest of the Accounting page shows for the same row ([5000 - Audio Software & Plugins] OmniSale GmbH // 778229 etc.).

"Can you make it so that the transactions in the IR56M modal shows display name with tool tip showing the original name?"

So: render the same display name the Bank Tx tab + WPP show, with the raw description tucked behind a hover tooltip for cross-checking.

What shipped

Backend (pages/api/accounting/ir56m/recipient-payments.ts)

  • After the existing filter loop, the matched docs are run through the same enrichTransactionDisplayNames the Bank Tx tab calls. The row type now carries displayName + description separately.
  • Best-effort: a failure during enrichment (e.g. a missing doc-type template) leaves each row's displayName defaulted to the raw description so the UI never goes blank — the catch logs a warning.
  • One shared enrichTransactionDisplayNames call covers all matched rows instead of N per-row calls (the enricher batches its COA fetch internally).

Frontend (components/accounting/tax/IR56MRecipientModal.tsx)

  • The audit table's Description column now renders displayName as the primary text. When the raw description differs from the displayName, the cell wraps it in an antd <Tooltip> (titled "Bank-statement description") with a dotted underline so the affordance is obvious.
  • When they're equal (or there's no raw description), no tooltip wrapper — avoids a hover that would show identical text.

Why it's built this way

  • Enrich at the endpoint, not in the modal. The modal already gets a denormalised row payload; adding the displayName server-side lets the front-end stay presentational. The alternative — fetching the full V1 tx per row and enriching client-side — would multiply network round-trips and re-implement the enricher.
  • Tooltip, not a second column. The bookkeeper's primary task is to read down the list checking the AMOUNTS, not the descriptions. Putting the raw description in a tooltip keeps the table narrow and lets the eye focus on the enriched name; cross-check is one hover away when needed.
  • Defensive fallback to raw description. If the enricher ever throws (a deleted template, a Firestore blip), the UI keeps showing the bank text — never goes blank. The audit feature is about verification; rendering nothing would defeat that.

Decision log

2026-06-25 — T-127 opened + shipped

  • ✅ Attestation (Accounting (Diagnostics)): read AGENTS.md (tip 26330aac); board scan by scope — T-121 owns the audit table, T-126 fixed the helper-drift, T-127 polishes the row presentation.
  • Source: Accounting (Diagnostics) · https://claude.ai/code/session_01G58Y71noihrYCDEDMexmea
  • Owner direction (verbatim, 2026-06-25):

    "Can you make it so that the transactions in the IR56M modal shows display name with tool tip showing the original name?"

  • Tests + tsc: npx tsc --noEmit clean. No new unit test — the enricher is the same one the Bank Tx tab already exercises in prod; the modal change is purely presentational (tooltip wrap on one cell).
  • Blast radius: server-side adds a single enricher call per audit- list fetch (which already does a Firestore scan, so the marginal cost is N small in-memory transforms). UI change is one table column's render function; no other surfaces touched.